Same experience on my side. It autocompletes but won’t compile. Probably should not autocomplete, in fact.
Yes, we usually do the mistake when learning.
As far as I can see, it hasn’t changed in API 2. Still wondering why Tim’s trick works, then.
There is much more than whining going on in this discussion. I for one have learned a number of useful things. As Emile said, you don’t have to read it.
2 Likes
There are many versions of “decision X was bad or misguided”.
Coming from the .NET world, I privately grouse at times about the impedance mismatch between the .NET framework and the Xojo framework. For example it took me awhile to figure out that the equivalent of this in .NET:
myDict.Add(key,value)
… is:
myDict(key) = value
This is for the simple reason that I just can’t know what to look up in the docs to begin with. I was looking for an Add method because I’m used to using one. I didn’t find an explicit how-to.
In .NET we’re used to things either being, or acting like collections, and so we do:
value = myDataTable.Rows(rowNum)(“ColumnName”).ToString()
… treating it as a 2-dimensional array, rather than something method-driven and arguably a little semantically “off” of the form:
value = myRowSet.Column(rowNum,“ColumnName”).AsString()
Xojo lacks certain things – generics, data binding, etc, although it has a surprisingly comprehensive list of things I didn’t really expect in this kind of product – structs, MemoryBlocks, operator overloading, stellar performance, and more.
Xojo is fundamentally different in certain ways: not nearly so early-bound, strongly-typed as a .NET dev is accustomed to, and we are conditioned to fret about unboxing overhead which isn’t even discussed here, despite that it is surely going on (we left that behind around 2005 when generics were introduced in .NET framework 2.0, whereas Xojo devs are still using Variants or Objects). .NET devs are brainwashed to think that strong type safety is so big a deal as to be almost necessary to write decent software when it’s really just a different set of tradeoffs. And here is Xojo doing the dreaded reference counting instead of garbage collection and suddenly WeakRefs become a much bigger deal. And yet in a way it’s refreshing to me as nondeterministic GCs have their own issues. I spent my Thanksgiving break 2 years ago reading a whole book on .NET memory management internals and it’s not all rainbows and unicorns. Much of the book was preoccupied with how recent iterations have figured out how to garbage collect without “stop the world” approaches and yet with so much complexity to make that happen, is it really a net gain??
The truth is there’s nothing right or wrong about either approach, some things are always going to be “better” or “worse” because every design decision is a tradeoff. Also, no framework can possibly anticipate up front all the abstractions it will eventually have to provide and how they will interact, so all frameworks have awkward aspects and their abstractions will leak a bit at times and require painful things like Xojo API 2 or Python 3 or ASP.NET Core to plug the leaks. And that often “feels” like things are being jiggered around just to break existing code or confound well-established habits. But it’s never personal, and always undertaken with some angst on the vendor side, whether we’re privy to it or not.
Finally, Xojo is a relatively small team producing a relatively big product and doing an overall amazing job of same. I want bugs fixed and I want new features and I want to keep up with market expectations, but I do not expect them to re-cast everything to suit my particular habits and sensibilities. Even M$FT with all its resources always reminds us “shipping is a feature, too” and has to nix or delay feature request fulfillments all the time.
You can argue that, e.g., API 2 was a horribly misguided stupid mistake until the cows come home but to what end? It will not make API 2 go away or change in any significant way. Let it go. Pick your battles. Take yourself to another product if you feel that strongly about it. Otherwise you’re wasting your time and everyone else’s.
Documentation is a little different as it can always be iteratively improved or rewritten but even here I do not think that carping too much is going to help. I feel bad for the good faith effort that the docs represent. They are adequate and improving. Could they have been better out of the chute? Maybe or maybe not given the scope of the docs and the size of the documentation team. I have my own suggestions to improve them, but I am not going to hate on them either. In working through my first Xojo project I have encountered the warts in the documentation but I have ultimately found everything I needed to get the job done, too. It suffices. It can, should, and will get better. Patience.
So my general impression after a couple months working fairly constantly with Xojo (at least on my initial Desktop project) is: A+ product that has returned much of the fun of software development to this old codger. Some stuff I don’t especially like or agree with but not more than any other product and a lot less than many. I’m grateful for it.
I have a feeling I will not like the web side of the product quite as much but that is more about the challenges of web development in general. I still think Xojo will end up being a great tradeoff to insulate me from the chaos of the typical web stack and let me concentrate on actual functionality without having to wrangle a dozen different libraries. I may end up using something like .NET Blazor if I can’t get it to do the things I need to at scale, and my first web API will continue to be developed in C# and probably deployed on IIS. But I have a feeling Xojo will ultimately do the job most of the time.
4 Likes
Xojo once has something that could be described as data binding to controls which has since been removed, but I don’t know if that is what you are referring to…
it really was not used much and felt rather limiting… for myself I always preferred writing the glue code myself to have more control.
-Karen
3 Likes
Totally agree. I have never met a data binding abstraction that I liked or did not “feel rather limiting” and have always done my own scut-work. That way I never have to wonder WTF it is doing behind my back, lol
One thing to remember … The desktop framework has evolved over the last 25ish years. Web 2 is essentially new and I suspect will take at least 3 or 4 years (or more if it progresses like Xojo iOS has) to mature enough for many.
- Karen
1 Like
Reading between the lines it also looks like they bit off a bit more than they expected to chew when it comes to Android support, too. I worry sometimes that they may get bogged down trying to be all things to all comers. I’m not arguing against Android support – just wondering why Raspberry Pi, I guess. I hope the effort to make that available was as small as the lift I imagine they will get from Pi users. Or maybe they are filling a really big tooling gap in that market, and hope to dominate, IDK.
I guess as a dev it means Xojo gives me a toe-hold in whatever market there is there … maybe it’s a good thing. I just hope Xojo remains profitable and not spread too thin, is all.
I would guess Because they needed to support Linux anyway for web and it was not a big project given Linux support.
-Karen
2 Likes
RPi was hugely appealing to me initially, as I do a lot of hardware, but it’s become less significant now that other SBC’s in the price range (and maybe RPi itself) can run Windows. Nonetheless I think it was a great move on Xojo’s part - as Karen points out, probably not a lot of extra development since it supported Linux already, and it’s a market niche not well-served by other high-level languages.
4 Likes
My first thought was to quote Michel (above your essay) as an answer. But to be polite I don‘t do that. Maybe we need a new category „What experts know better“ 
In view of the length of this article, someone should say that anyone who formats his code has too much time.
1 Like
That’s one thing I hated when I had to use .Net…
1 Like
That’s one thing I hated when I had to use .Net…
MS VB6 with DAO
value = rs!LastName
there is still something that Xojo can optimize but not want.
1 Like
2022 R2 Web Toolbar control not in library may be a real-world example of the confusion this design causes. (If you search the Xojo IDE Library pane for the long class name ‘WebButton’, you get no matches). Only the short name works. ‘Button’
1 Like