I would not go as far as calling it an art, or poetry, but coding, like any language, is certainly culture. And syntax. Xojo is deeply rooted in Basic, and as such, has a precise lexical structure that underlines all constructions in it. Like in music, the constraints of the language is not an obstacle to creativity, but a discipline in which one can use his imagination to obtain a greater result.
Most of us have experienced other languages, which structure and philosophy make them better or worse for certain things. From typeless variables in PHP to dictionary-like arrays in JavaScript, through Regex in Perl, each has its own culture. And rules. To some extent, it is perfectly possible to creolize a language by making it function like another. For instance, Xojo has Variants à la PHP, dictionaries akin to JS, and Regex so keenly used by Kem. But it remains Xojo. A strongly typed declarative language.
Some innovations, ever so optional, like i++, are not a matter of simple programming style. They are of a different structure altogether. It seems rather difficult to implement without breaking Xojo itself. On the surface, i++ seems innocuous enough for numerics. But what about strings ? What about colors ? What about variants ?
[quote=167168:@Michel Bujardet]I would not go as far as calling it an art, or poetry, but coding, like any language, is certainly culture. And syntax. Xojo is deeply rooted in Basic, and as such, has a precise lexical structure that underlines all constructions in it. Like in music, the constraints of the language is not an obstacle to creativity, but a discipline in which one can use his imagination to obtain a greater result.
Most of us have experienced other languages, which structure and philosophy make them better or worse for certain things. From typeless variables in PHP to dictionary-like arrays in JavaScript, through Regex in Perl, each has its own culture. And rules. To some extent, it is perfectly possible to creolize a language by making it function like another. For instance, Xojo has Variants à la PHP, dictionaries akin to JS, and Regex so keenly used by Kem. But it remains Xojo. A strongly typed declarative language.
Some innovations, ever so optional, like i++, are not a matter of simple programming style. They are of a different structure altogether. It seems rather difficult to implement without breaking Xojo itself. On the surface, i++ seems innocuous enough for numerics. But what about strings ? What about colors ? What about variants ?[/quote]
I get where you are coming from, but i honestly don’t think that making small changes to be able to write better code is going to break any rules. Like some of the posts above the Xojo Language IS changing… slowly but progress is good. If the language wants to stay relevant it has to change and even sometimes evolve. Stagnation is death.
Variant makes note of what type you assign it and then does a lot of manipulation behind the scenes to transform that value into whatever type you want to take out of it. It can be a blessing and a curse. The IDE was developed taking advantage of that functionality and it has become evident over time that there are problems with it. Variant can lead to subtle, hard to find bugs. The Xojo team has been steadily removing the use of Variant from the IDE, and the new framework removes it from the language altogether.
And the ‘modern’ equivalent of Variant is the new Auto type. Unlike the Variant, it doesn’t try to be too smart, it leaves it up to you (through Introspection) to work out what’s in the Auto.
[quote=167176:@Nicholas Henson]I was thinking about this… does the type Variant apply to this functionality?
When you initialize a Variant it decides whats best based on what you pass it correct?
is there a down side to using Variants to “declare” a type rather than doing it yourself?[/quote]
Implicit conversions
You’ll learn to hate them once you cant figure out why things dont work the way you expect because you cant track down what got converted into what or why
Type safety
The compiler literally cannot help you write better code so you only ever discover bugs involving type conversions at run time
If you avoid them it can help you out & catch things at compile time
Actually its for the better.
Its a strongly typed language - like C, C++ and not a typeless one like so much PHP and Javascript code is written to be.
There ARE facilities to have dynamic types at runtime BUT they are still designed to help you write safer and better code keeping in mind the language is STRONGLY typed
Or a step forward, depending on your point of view. This is not a question of right vs. wrong. This is a question of the philosophy of the language. Xojo has a particular approach. It’s good to question the status quo, but the answers are going to be filtered through that philosophical world view. If an idea makes sense within that framework, Xojo has been open to considering it. If it doesn’t, it may leave you scratching your head.
[quote=167189:@Norman Palardy]Actually its for the better.
Its a strongly typed language - like C, C++ and not a typeless one like so much PHP and Javascript code is written to be.
There ARE facilities to have dynamic types at runtime BUT they are still designed to help you write safer and better code keeping in mind the language is STRONGLY typed[/quote]
Looking at Variant i can see what everyone is talking about. I was looking at Auto and it looks like really neat. do the same downfalls apply to this type also? It seems like its a lot more protected i guess you could say against those kinds of mistakes.