What do you think of the new framework?

The new framework can be seen in iOS but will come to the Desktop sooner or later. And while the old framework will be around for a few more years, the transition from Carbon to Cocoa has taught us that one should probably not expect any bug fixes or new features in the old framework, meaning it will be obsolete very quickly.

So what do people think of the new framework?

I came to REALbasic for a reason, and that was BASIC. I see the new framework as making the language more complex and thereby more unfriendly to beginners and BASIC-lovers alike. Code becomes a LOT less easy to read. Maybe it has some big advantage, but I fail to see it. But then I’m not an advanced programmer. Which brought me to BASIC. So the circle closes.

So what arguments could sway me to be enthusiastic about the new framework? And no, separate namespaces everywhere is not an advantage but a hindrance in my opinion …

Ahhh, great minds think alike:

https://forum.xojo.com/18208-the-direcetion-of-the-new-framework/0#p151751

… and yes, small minds too …

Hi Marcus,
I have the same opinion, as already reported in other threads I am a Prepress and Graphic Design Professional and use RS / Xojo to suit my needs, have learn before Java and C # and no gave me the ability to run my projects as XOJO, change that I think would be a big mistake, even because there are several languages that use similar syntax and paradigms in equalize them would lose in ease and productivity that was what made me go for RS initially.

Bob brought up some pretty good points: New Xojo Framework Thoughts.

Yeah, I read it. Karen especially echoes my thoughts, and I thought this should be on the forum … so I opened a thread …

Come on, people, convince me that the new framework is a good thing! :wink:

My first language was AppleSoft BASIC. I can say with certainty that Xojo/REALbasic was never BASIC. Not even remotely close. Aside from a few keywords, what Xojo does share with BASIC is simplicity. The idea, for example, that every line doesn’t have to end in a semi-colon.

I would be curious as to what things in the new framework you see as more complex. There are certainly some new ways to doing things. Sometimes new and feel (at least initially) more complex because it’s new. Converting from text to a number is different. But far from being less readable, it seems more readable to me. Bob Keeney wrote about converting text to numbers being more difficult but I don’t see that. He feels the conversion rules should be more liberal. There’s an argument to be made there but it comes at a price. For example, today if you pass “A10” to the VAL function, you get 0. Why? Because the rules of VAL say that once we hit a non-numeric value, the value is numerically invalid. But this rule is something you have to learn about to know it works that way. And returning 0 is a lousy way to indicate that since 0 is a perfectly valid number.

I suppose an argument could be made that any of the numeric conversion functions should strip all non-numeric characters and then convert the value if for no reason other than convenience. So converting “$123” would become 123. And passing “$123.55” to Integer.FromText would drop the decimal. I think that’s logical, though there may be implications I’m not considering. However, even in that case, you’d have to consider locale. In Europe, the decimal separator is a comma whereas in the US it’s a period. I suppose the conversion functions could default to the current locale unless one is optionally specified.

For now, the obviously solution is to make sure that what you are passing to a numeric conversion function is, in fact a valid numeric value. That’s something you should be doing already anyway with VAL so you don’t get invalid results. Assuming you’ve done that in both cases, the difference between the old and new frameworks, in terms of numeric conversion is minimal. IMHO, Bob’s example is an academic one. I can see how he would come up with it when exploring the new framework. However, I think in a real world situation, it’s going to be less obvious. Considering reading values from a log file:

Old Framework:

reading = Val(LogFileValue)

New Framework:

reading = Integer.FromText(LogFileValue)

The numeric conversion functions in the new framework require certainly require a little more typing. However, it’s far more readable considering that conversion doesn’t always happen within eyeshot of the declaration of the type. In the first example, I have no idea what I’m going to get. In the second example, I’m certain that I’m converting to an integer. And if I have forgotten and use Double.FromText instead, I’ll know it at compile time. The latter is slightly more complex in that you have to think about the type of number to which you are converting, that is not implicit, but implicit often gets people into trouble. That’s why Xojo is a statically-typed language for example.

In Bob’s example, he’s letting the function do the type checking. And he admits that in his post. But we know from experience that we should not do it that way. We should make sure we have a valid numeric value before we convert it to a number. Depending on Val to return 0 we know is not good or obvious. If you are going to depend on the converting function, at least the new framework conversion functions will throw an exception so you can test for that. In fact, you could even use them to write your own function that you use to first determine if the value is numerically valid or not:

Function IsInt(input As Text) As Boolean Try Call Integer.FromText(input) Catch err As InvalidArgumentException Return False End Try Return True End Function

What we have seen over the years is that people play fast and loose with functions like Val only to create hard to find bugs later on because there’s implicit conversion going on and they frequently don’t know or remember the rules. The new framework makes these kinds of bugs far more difficult to accidentally create.

[quote=151765:@Joseph Claeys]

Bob brought up some pretty good points: New Xojo Framework Thoughts. [/quote]

Gives me a headache just reading it.

Just to be clear, believe me when I tell you that I advocate for simplicity where ever possible. But there’s a balance between asking the user to do a tiny bit more up front to then avoid problems later on. Ultimately, your code has to know what you mean to function correctly.

Geoff,

The rules for Val are simple… It goes from left to right. If It finds a valid number before it finds something that can’t be a part of a number it returns the number, If it does no find a number it returns 0. While one Might argue that instead of a 0 it should throw an except if it does not find a number the ‘rules’ are straightforward, very simple and pretty intuitive.

An 0 is fine really… it keeps code simple is is still fairly intuitive.

I submit that those that can’t understand that (or be bother to read docs) are not likely to be able to produce good code anyway and be support headaches… it seems to me you are trying to reduce support headaches, but what you are doing is to making the product more annoying to use.

In real life that behavior is very convenient as well as intuitive… Numbers often come with units, particualry when exported by scientific software. Being able to do X = Val(“12.6 mg/ml”) is nice. When parsing various parts of strings it comes in handily was well.

From reading your post it really seems like you feel of Xojo’s obvious BASIC heritage is a (marketing?) liability? Many of use use it instead of other products because of it…

You can go for prestige among the language snobs or you can go for more users … I think the latter is teh more profitable path…being the product for “the rest if us” that lets us do great things in an enjoyable way/

That is what got you much of your current user base IMO… And that is what this path is risking IMO.

You can not treat coders like children … you have to let is take a reasonable amount of responsibility for our code because usages differ immensely.

@Jim Smith to be fair, the true comparison in Bob’s example (which is academically correct), should be:

dim i as integer i = Textfield1.text.val

and

dim i as integer i = Integer.FromText(Textfield1.Text)

Adding the extra exception handling in Bob’s example makes the new framework appear more complex. However, in either case you have to know that you have valid numeric values or not. If you know that you have those, then you are really just talking about the difference between the two lines of code above. Otherwise, you have to do something in either case to make sure you have data that can be converted.

[quote=151778:@Karen Atkocius]The rules for Val are simple… It goes from left to right. If It finds a valid number before it finds something that can’t be a part of a number it returns the number, If it does no find a number it returns 0. While one Might argue that instead of a 0 it should throw an except if it does not find a number the ‘rules’ are straightforward, very simple and pretty intuitive.

An 0 is fine really… it keeps code simple is is still fairly intuitive.

[/quote]
I disagree. That they are simple or intuitive. You have learned them and are comfortable with them but I doubt they would be seen as intuitive to a new user. And 0 is not fine because it’s a valid value! How can you tell the difference?[quote=151778:@Karen Atkocius]You can not treat coders like children … you have to let is take a reasonable amount of responsibility for our code because usages differ immensely.[/quote]
It’s not a question of that. We know from experience that implicit conversions (for example) create hard to find bugs. So great, you were able to save a few seconds in writing the code to convert a value but you pay the price later on when you run into a bug.

There is no arguing that the implicit Val in the old framework and the explicit conversion functions of the new framework are different. But IMHO, that’s all they are: different.

I expect few Xojo users would make the argument that Xojo should be dynamically typed instead of statically typed. Dynamic typing can be convenient for coding but it also can create hard to find bugs.

I don’t think a new user would find that much difference between Val and the various conversion functions in the new framework. For existing users, it’s something new but they are extremely consistent so easy to remember.

[quote=151782:@Geoff Perlman]It’s not a question of that. We know from experience that implicit conversions (for example) create hard to find bugs. So great, you were able to save a few seconds in writing the code to convert a value but you pay the price later on when you run into a bug.

[/quote]

All I will say is that in over 13 years and a LOT of code covering strings to numbers, that behavior for VAL has never ever resulted in a bug for me.

This implementation is not just different, it does less for us. And many such decisions multiply the pain of using the new framework relative to the old.

It does not sound like you are open to the arguments Markus, Bob, I and others are making.

Well time will tell… though if people leave I don’t know how you will be be able to tease out why with all that is changing at once.

  • Karen

I was actually surprised that Bob wasn’t concerned about the use of exceptions of error handling. But as it turns out, he uses them himself quite a bit so that’s not a big deal to him. Before Xojo, I had no experience with exceptions since they didn’t exist in any language I had ever used. But even with Xojo, I sort of ignored exceptions for a long time thinking they were some alien and difficult thing to understand. But once I took just a few minutes to read about them, I realized that they aren’t difficult at all to understand and they make code far more readable.

In the new framework, rather than have many different ways to detect errors, which rarely occur, there’s now one straightforward way that keeps your code from being riddled with IF statements.

In what way does it do less? For doubles and singles, you can now provide a locale so it can correctly handle converting when the separates are different.

My bad. In the new framework, Single.FromText and Double.FromText both allow the inclusion of an optional locale.

It won’t parse out a leading number from a string. That was a feature not a bug! Now we would need to do it ourselves … and it is tedious…

  • Karen

I understand both sides of this argument.

I would image though, that if members are currently capable of understanding software development principles, and as a result are producing software, - they should have no problem remembering a slightly different syntax?

Ok, it means a slight learning curve, but if the code results in less chance of producing an error, and I get to think laterally and expand my coding knowledge beyond very basic style syntax - I personally see that as a good thing.

If the language became extremely cryptic, then that would be a different matter, but this seems very slight.

Again, I personally am happy to spend a few minutes more typing out new syntax, if it produces more stable code.

This will be one of those things which some will like, and some will hate.
Everybody codes differently, so I believe there is no right or wrong. This just seems to be a case of - different?

*flame proof jacket now on :wink:

I am not buying one bit into the switch from one framework to another is going to cause me a tiny bit of work. More like a little bit of work thousands of time all over my code base along with the required testing and debugging.

If Xojo becomes another cryptic, overly verbose language, and iOS won’t work out of the same code base as my desktop versions, not many reasons to press on.

In the example being discussed, you want to convert Text to an Integer, and do something like use a pre-determined value when you weren’t provided with a valid integer. It would look something like:

Classic framework:

i = TextField1.Text.Val If I = 0 Then //my code for when I couldn't convert End If

new framework:

try i = Integer.FromText(TextField1.Text) catch e as RuntimeException //my code for when I couldn't convert end

Very similar in length, except the New framework way appropriately catches a conversion error- your code would never be confused when “0” happened to be in the TextField like it would in the Classic framework. It is also more clear and less cryptic- because conversions to any type always follow the same pattern and the intent is readable to anyone without having to know Val vs Cdbl vs Str vs Format etc.