New Xojo Framework Thoughts

I don’t think application development is very hard. It is however complex and this, I think more than anything else, makes it appear hard because people equate complexity with being hard. Xojo does a pretty good job of making things less complex for us and I honestly truly appreciate that.

The new framework that we’re really seeing for the first time in iOS has some good things in it. Database errors throw an exception. I like that that because that’s what we (BKeeney Software) does with our own SQLSelect and SQLExecute extends methods (name SQLSelectRaiseOnError and SQLExecuteRaiseOnError). Not everything I agree with though.

In the existing framework we would do something like this to get the integer value of the aTextField.

dim i as integer

i = TextField1.text.val

We’ve been using this for close to 15 years. Works great. Now, in the new framework we have to use different converters and use code like this:

dim i as integer

i = Integer.FromText( TextField1.Text)

Seems pretty straightforward, no? Well, no, because in their infinite wisdom, if there is no text (i.e. a blank string) an “InvalidArgumentException” is thrown. WTF?!

Instead, you will have to do this instead.

Dim i As Integer

If Not TextField1.Text.Empty Then
   i = Integer.FromText(TextField1.Text)
End If

But even then, if there text there that can’t be converted to an integer it throws the exception. I sort of agree with that change.  But, I don’t see this change as being ‘better’ or even simpler. If anything it’s more complex and it’s getting away from the strengths of BASIC that made many us use it over other languages in the first place.

So really what you’ll need to do is something like this:

Dim i As Integer

   If Not TextField1.Text.Empty Then
      i = Integer.FromText(TextField1.Text)
   End If
catch e as InvalidArgumentException
   i = 0 //if that’s what you really want.

You really want to do that several thousand times in a big accounting application?  When I suggested that I’ll just create my own extends methods to match current functionality the response was “Not doing so is a great opportunity for silently doing something really wrong.” Well, I guess at that point it’s MY problem, no?  If something goes wrong, and I did my own method, it really *is* my problem.  Or are the Xojo Programming Police going to take away my license?

Xojo is trying to make a complex process idiot proof. I appreciate the effort, I really do, because Lord know I can be an idiot at time. All they did, in my opinion, was make this simple process more complex. I think they may hinder adoption of the new framework. My guess, though, is that they’ll force it down our throats for console, desktop, and web when the time comes.

What do you think, my friends? Is the new framework helping us or hurting us or is this just a “this is different so I hate it” reaction?

38 thoughts on “New Xojo Framework Thoughts

  1. I think you know my opinion on the new framework. I argued against it while with Xojo. What I see is a desire to mold Xojo’s new framework from Cocoa conventions. It’s often academically perfect, but practically awful.

    • Actually, I did not know your opinion on the new framework. I do now. 🙂

      I totally get the desire to throw an exception for errors. I would argue, however, that converting a blank string to a number isn’t an error. Rigid doctrine is not what I’m looking for in my development language.

  2. I pretty much said teh same things as Thom said here on the forum… I also said basically the same thing in beta.

    They are not listening and I am beginning to think they don’y understand WHY many of us liked RB so much… This more than bugs or late features has the capability of bring down teh company.

    If coding in Xojo is no longer fun. If it as much of chore as in the ‘mainstream’ languages just in a different way, many will chose other tools or for hobbyists decide maybe it’s not the hobby for them.

    I know that sound dramatic BUT there seems to be a a lot of this stuff in the framework and likely a lot more to come if the attitude stays the same. The new framework does not feel like what I fell in love with and that is not just because it different.

    RB HAD a good balance between safety and convenience.. Was it a perfect balance? No… But they are now tilting towards purist thinking and that often results is a disaster. You need to know your customers…

    They are loosing one the key things that helped RB/RS/Xojo be successful IMO.

  3. I’m pretty sure to have read somewhen in the past Geoff’s reassurance that the migration to the new framework will be a smooth and straight forward process. Now what you just show in the above example here confirms my impression: it is severely going to break my code.

    Then it is said: Don’t worry, the old framework will exist for years. What the heck?! How should this ease me? For instance, I have one project which results in more than 10’000 pages when printing it to pdf. I WILL port this project to the future and staying with the old framework ‘for a long time’ is not an option.

    We see what happens when something gets deprecated. It quickly fades away and does no longer get any love, speak: bug-fixing or adoption to new operating system versions.

    Unfortunate move.

  4. I’d love your thoughts on this:

    I’m okay with throwing an exception for true errors. As we’ve see with database errors over the years that people just don’t check for errors and it’s a real (not imagined) problem.

    However, for things like conversions from text to a value, there must be some happy middle ground. In my example above, if it’s not an integer I’m okay with a 0. Heck, I expect it. Same with converting to a double and probably a dozen other things. To me that’s NOT a throwable error. I get what I get and if it’s converting wrong that’s my problem. That’s what the original framework does.

    So how do we find a balance that also protects Xojo from the “you can’t add” accusations (which are silly but valid from Xojo’s perspective)?

  5. Can’t you just take the code you arrived at and make a extends function or a helper function – that is, encapsulate the error checking and excess junk that you rightfully complain about?

    MyInt = TextFieldInteger(TextField1)

    On your comments about Framework: I came from VB during RB3. To make the transition easier I wrote a whole bunch of functions so I could continue to use VB syntax while writing in RB. (Like LCase() for Lowercase().) I still use those things out of complete habit. So really I made my own framework to shield me from the RB one.

    I totally see your point though, but then again writing these functions is a one time thing; write it, forget it.

    I like Karen’s usage of the word “fun”. That’s an important concept with REAL/.Xojo, that’s part of the reason we use the product. I truly think that if fun wasn’t so important, we’d all be using XCode.BASIC, and ease-of-use IDE, makes programming enjoyable – less useless repetitive tasks, more things looking like English. There were massive complaints when Microsoft went away from the simplicity of VB6 and tortured it (similarly to what Xojo is going now) – Xojo should reread those.

    • Fully agree with these points. Fun comes from simplicity and flow in the process of programming.

      Some of the modern software design/programming concepts make a lot of sense in theorytically aspects, or in some special cases. But some of them had stopped my flow in thinking and programming and increased the complexity in an unecessary way.

      For my success in bringing software to live, it is more important to wrote simple and robust code with an software IDE and framework that is also simple and robust in use by preventing unnecessary complexity to get hte things we want to do done.

  6. Oliver, Bob did point out that converting ActiveRecord did not take very long. Was their some conversion to do? Sure. But it didn’t take all that long.

    • Correct, BUT, the conversion of text to a numeric is a huge deal outside of ActiveRecord. What is an inline process is now 4 or 5 lines of code. I have an accounting application that literally has several thousand TextField.Text.val’s. Converting those to the new framework requires that I make my own function and do a global search and replace. Doable, but still a pain.

  7. Exceptions should be exceptional. Geoff admitted in the threads on forum that (a) he’s not a full time programmer and (b) he didn’t even know what exceptions were a few years ago. And yet, he’s there defending the merits of turning user input blunders into code-level exceptions.

    I kinda wish “wall of code” had made it into the release. That made it really clear how little attention Xojo was paying to regular people who had to use its product and the tons of old code they might want to use with new platforms. Coincidentally, “wall of code” coincided with several alpha testers evaluating Swift for their iOS needs since they’d have to start from scratch anyway.

    • The ‘wall of code’ doesn’t concern me too much. During the initial run of videos thing that are in both frameworks, Dictionary, for example, if it was using the new framework I actually preferred to use the full namespace rather than the simple references. That way there’s no confusion on which one it’s referring too.

      Anyway, I agree that *some* things should be exceptions. Database errors are probably good ones. FolderItem.Delete failure, Text/Data Input/Output stream failures are probably pretty good to. Conversion routines? Those fail so often it’s overkill.

      • Try the wall of code on a smallish (e.g. 720p) laptop :-). Look. There are a lot of things all at once where Xojo has gone down the road of stodgy, formal, and rigid at the expense of approachable and familiar (also compatible). Meanwhile, the big vendors are working to make syntax easier (e.g. Swift) to attract more developers to native tools. As several of my own customers concluded during the alphas… if we can’t even use the code we have without modification and parallel source bases during transition, why not just switch to a language Apple won’t be hostile to in the future?

  8. Raising an exception when the return value is indistinguishable from a valid output is the correct thing to do (Google “semipredicate problem”). I haven’t used Xojo since 2013 so I can’t speak from experience, but I don’t necessarily think that using exceptions like this is a bad thing. Exceptions are extremely powerful flow control structures, not just error handlers.

    That being said, the new Text class sounds like a PitA.

    • Well, in the example I gave above converting a blank string to an integer will result in an exception. I don’t feel that’s an exception, I expect it to return a zero and have for 15 years.

      Right now I can bitch a little and see what everyone wants from the language and maybe effect a little change. If, in the long run, that’s they it works in the new framework (it’s an exception) I’ll modify my coding habits.

      • I agree that the integer value of a non-numeric string should be zero and not an exception, even though an exception is technically correct. Thom is right when he describes it as “academically perfect, but practically awful.”

  9. I probably represent limited user base, those who are not programmers but work in engineering/science developing hardware and systems, and only occasionally developing software to control and/or analyze these. Nonetheless, the cost of these hardware/systems sometimes can run in the 3 digits, so errors are very costly. Before RB I used VB and Java, all good but quickly became complicated and bloated.
    The one and only thing that drew me to RB (and now XOJO) was the efficiency in coding and the apparent lack of bloat. This is, I could create something really quick to address my immediate problem at hand and did not had deal with the strict adherence that the bigger languages forced upon you. I could get to my “real” work a lot faster. At the same time I could provide something that had a very small footprint. And I have to say RB delivered just that, and quite impressively. Enough so that some co-works also moved to it, and some suppliers which sometimes include their own software applications to use in evaluations started asking about what we were using to develop our internal applications (cause they look cooler, and we could turned them quickly).
    I believe the new direction is going more towards the “bigger” languages; in which case there are tons of those out there, the differentiator factor lessens significantly.
    I completely agree with Karen on the “fun” factor, and with Bob on that it is up to me to know what I am doing (otherwise even a monkey can do it). I refrain from posting on the forums much, because I have learned if you are in the minority you are shunned immediately.
    My applications (if in Windows) are now significantly bigger even though they haven’t changed – that just wrong. Now go say that in the forums; you get scolded that today’s world is in TB – I could care less there are TBs out there, we don’t tolerate such bloat in my practice (it’s usually an indicator of bad Engineering processes). Again, this probably makes me even a smaller minority.
    I do want to thank you Bob for providing this alternate method to communicate which is free from the mob-like mentality that seems to be prevailing on the forums. And I miss the dissenting voices on the forum (e.g. Brad, Andrew).

    • I appreciate the kind words although they are ironic because I’ve been accused of inciting a mob mentality on this blog. To each their own I guess.

      Anyway, at the end of the day we all want something that’s easy-to-use yet powerful. The trick is finding that balance in Xojo.

      Xojo needs a new framework for lots of good reasons. This is simply the first iteration and these discussions are good to have BEFORE they become the defacto standard in desktop/web/console applications.

      From a previous lifetime as an engineer it’s much easier to lock things down very tight and loosen them up afterwards. Perhaps we’ll see some of that.

      • Bob, I apologize for having said that you created a mob mentality against the new IDE. I don’t think I was incorrect about the chances of them rolling back to things you liked about the old IDE. The benefit of hindsight tells me that was the start of a pretty appalling pattern of behavior.

  10. I’ll repost this here as it will probably get removed from Xojo’s forum:

    Geoff: “FWIW, I’m not a full-time programmer either and I’m constantly advocating for simplicity.”

    That explains it all.

    I recall telling a RS programmer that the new RS ide did not work on with a multiple monitor and that it was much slower than RB. I was told, on the old RealbasicGuru forum that no longer exists, that’s how it was going to be and if I didn’t like it I could go elsewhere. Then after looking at this former RS employee’s no longer existing personal web site what did I find – he worked at home on a single monitor. I was like wtf?

    I am getting a real ill feeling in my stomach – the kind of feeling one gets when one reads about a politician in Washington spending the country into financial ruin, but yet having the gall to tell us “little folk” back home how to do things right.

    This makes no sense whatsoever. The reason I wanted to use RB, RS, and MAYBE Xojo, was that is was not like trying to learn the math behind physics. The language was easy to use and made sense. Now you are trying to convert it into something so complex and no one would want to use it. How on earth are the planned changes going to be more simple.

    Is this suppose to be some kind of very early April Fool’s joke or is this company trying to commit financial suicide?

    You seriously need to consider selling the company and leaving us alone because you do not know better than US – which is the message I feel WE have been getting for years.

    “Don’t worry, the old framework will exist for years.”

    I just don’t believe anything your company says anymore.

    • Sorry Art, but your post makes no sense. Like in: at all. You don’t like the changes that Xojo makes? Fair enough, I don’t like some either (like that IDE). But then getting insulting and saying you don’t believe anything they say anymore ist just very … childish. There is no argument, no logical progression in your post. It is just a pretty silly rant …

  11. Bob, i disagree. 🙂
    What you want to be easy makes the things before complicated. In your string source, in that case an edit field, you have to make sure that there’s never entered anything, but a number…
    Maybe for your very personal requirement in that special app it would be ok to return 0 on non-convertable input, but it’s clear that this is for general behavior dangerous.
    An empty string is nothing. You want it 0. I want it 968 or -1 or… Who is right? 😉
    If the input is mixed (number & chars) it is even more clear this is something unexpected, likely a flaw in the earlier code. Of course I want to be notified about that as soon as possible, and not getting a subtle, hard to track down bug with strange 0 values… I might even never notice the actual bug, instead my app just produces silently wrong results….BAD! 🙂

    Coming from AppleScript, I was at first very annoyed by the expliciticy of RB. Why do I have to declare variables? What a nonsense!!! 😀 Now I LOVE the expliciticy which quite everything requires. Gone are the days of endless subtle bugs. OOP and encapsulation helps of course too…

    Regarding the people who “want to have fun with easy coding”. You say Xojo might loose customers if it’s more strictly. Maybe loosing some, but as you have noticed, other, more strict languages are way bigger in the market, for many reasons (I will not turn THIS post into a Xojo-bashing one ;)). ONE reason might be the quality of apps. Back in the Versiontracker years you could read end user warnings like “This is an RB app, think twice before you download”. And they had a point…

    If easyness is at the expense of producing subtle bugs, then that’s the wrong area “to make things more easy”. There are other areas open.
    Easy is the dot notation. Easy would be a standard text editor instead of a canvas-based editor. Easy would be a clear and easy menu editor. Easy would be a working window/tab/workspace handling, there is none.
    There are so many areas where Xojo is easy and probably a few more where they could improve a lot to help us coding. Too much is half baked, oops, stop, this is not a bashing post! :-))

    Making it impossible for the developer to code subtle bugs is at the first view more complicated in some cases (ie thread no UI access), but it pays off, because it saves us from headaches of tracking down subtle bugs later.
    And THAT does make things easier overall, and even saves time in the end.

    Bob, let’s face it – you just have a bad habit. ;-P Garbage in = 0 isn’t a good thing and I’m glad if they fix that a cow and a sheep are no longer both Zero…
    I would be ok if they strip white space from the input left and right, to make a friendly offer. ;-D

    Best regards

    • I like type safety… to a reasonable point. There needs to be the right balance between safety and efficiency for productivity- particularly in a RAD environment. Where that is, is certainly a judgement call but needs to be guided by overall productivity.

      I can tell you about work processes I created early in my career that were logically sound and air-tight but did not get used because they were too much of pain day to day. Some risk was acceptable for higher productivity.IMO the same applies to writing software in a RAD environment.

      In this case guess I need to hear about common real world (as opposed to theoretical based on principle) situations where returning 0 is a significant issue. I have never run into one in practice so it seems to me Val has a reasonable balance.

      If a situation did arise when it mattered, I would then check for 0 and determine if the string was valid for that application… And that code I would need to write for an exception as well … except as I said I have never needed it… but in the new framework I would always have to deal with it anyway.

    • “Bob, let’s face it – you just have a bad habit. ;-P Garbage in = 0 isn’t a good thing and I’m glad if they fix that a cow and a sheep are no longer both Zero…”

      When is a bug or bad behaviour so ingrained that it becomes a feature, or tradition?

      Men used to treat women badly and thought it normal. Or Blacks. Or Chinese. In a lot if places they still do. The (Western) World changed massively, and it seems a LOT more complicated than 50 years ago, when people can break into your homes while sitting at a desk 5,000 miles away, when the border between flirting and sexual harassment seems ill defined, when racism can raise its ugly head. But that is it exactly: Racism can raise its head because most of the time that head is down, women can dress beautiful and feel good about themselves without being grapped all the time (well, in some countries at least), and communication via the Internet is what we are doing right now, from thousands of miles apart.

      But also a lot of good is being lost. Going forward is a balance act, and the jury is out on wether Xojo gets that balance right. In the IDE I don’t think they did. With the framework … we’ll see.

      I’m not so fussed about Val. It IS a bad habbit to rely on buggy behaviour. I’m more worried about name spaces and what they might do to readability of code.

      • Markus,

        It’s not buggy IMO. It is a very practical design… In any case Xojo Inc has relented and will give Val like capabilities to the new framework that will be a bit more type safe.

        BTW What how did you get bit badly by an implcit conversion? Did it involve Val or maybe variants?

        • I’ve mostly seen this with variants, but there have been some bugs fixed in the R3 release dealing with Currency.

          In prior versions dividing a currency data type converted it to a floating point number internally so the rounding wasn’t always right. Obviously, this meant some subtle errors could creep in.

    • The more I think about it. The TextField that I want a numeric for should be a Numbers Only field to begin with. I’ve already subclassed the TextField to allow only a number so I’m already filtering my data.

      So in my case, I’ll never have Garbage in the text field though it’s a reasonable assumption it might be blank – especially on a new record. That’s the only place where I’ll have a potential error situation.

Comments are closed.