I don’t see an issue with using a Variant…
And that is why your company is irrelevant. You don’t understand the product you’re selling.
4 Likes
Certainly not “best practices” in writing code
As I said above catching errors earlier is cheaper to fix
Using a variant the design wont be “obviously bad”
The compiler wont catch any error since with a variant passing anything is OK
Its only at runtime, assuming you do exhaustive testing, that the use of a variant will come to light & need to be corrected
Thats a LOT more expensive to fix
Esp if now you have hundreds to thousands of deploys that need to all be updated
2 Likes
Where’d you find that quote ?
citations would be amazing
But this time he is speaking the truths and for this Xojo is a nice solution. People having not that much need of a wide ecosystem and are not in the need for a devstack which is professional like dev stack but helps the devs to work with a small api over all platforms. So he is at least speaking here the truths. Xojo is not made for professional developers. May be it was in history and it was a solution for professional software development. It is not anymore. I can’t identification the breaking point but as fat as I can see it is a real scenario that he has in his perspective only the not professional developers. I mean: learn one language and at the end one single api and program for all platforms including mobile without understanding the concepts behind this scene. May be that this is the professional way of handling this. May be. But it is also possible that the real part behind is the situation that it is not possible to hold a professional solution with two hands of people, not even all of them are developers, on the market. Looking on this he does a good job, XoJo still exists. It would not if he would try to convince professional developers while he would get with this a big amount of discussions about bug handling and so on. So what should he do different.
1 Like
For many of us it was about the same time. API 2.0 was a fiasco and nearly everything we predicted has. Not listening to the platform advocates (i.e. the pro’s). Pursuing targets that no one was asking for.
3 Likes
I believe that ‘many’ people wanted Android, but based on the mistaken expectation that it would be ‘design once, deploy twice’
API2 was a car crash.
And Button should be button should be button.
The pre-API2 controls have always exposed properties/styles etc that don’t work on all platforms. It wasn’t the end of the world, as long as it was documented.
2 Likes
And I have dared to write another reply - in kind of a swiss-british way…
…not expecting any outcome, which is good (for me) since I don’t need to keep faith 
1 Like
Still amazes me that Geoff DOESN’T get WHY a variant is less than ideal
But then he never liked any of the “computer sciencey” explanations I used to have to give him as he felt they were not understandable by beginners
Oh well
1 Like
I responded in part with my ‘variants are evil’ pitch and then threw a Dungeons and Dragons analogy about them not being like lawful evil but more chaotic neutral with a dash of evil for (non) fun. Pretty happy with that analogy.
But, like everything else, I’m sure that Geoff either won’t get it or willfully not get it.
1 Like
30 years at the helm of a software company he should understand why they are evil and how they hamper the compiler from helping people write better more reliable code
That his response literally said
I don’t see an issue with using a Variant either
tells me he doesnt, hasn’t bother to learn why, and doesnt understand best practices or better practices in a tool like Xojo that is strongly typed
TypeScript exists because JS was so flexible (basically everything was like a variant) and that pushed every problem to runtime because you couldn’t catch things at compile time
Many other languages have moved to be more strongly typed
Dunno what else to say
The point is: I love Java for strictly being typed. And yes, I don’t like variants cause they are always potentially dangerous. And that makes them to a never good way to go. It is a bit like standing in front of a gangster with a gun in his hands. If somebody has a gun and yoiu not: surrender. But no, you start fighting. Last fight. That’s the feeling Geoff perlman gives to me when reading such nonsens. He has no Idea. On the other side: it is a sentence I can believe. That he rally has no Idea. That would explain why Xojo is standing at the point they reached until now.
1 Like
The fact there arent new consulting requests regularly says a LOT about the state of things
I’m told the last one was around the beginning of February - 3 months ago
Suggests a lack of interesting in the platform from new customers that are not just using it for personal use types of projects
And thats not good if Xojo is looking to maintain or grow their presence in any way
I know this got said repeatedly - consultants & contractors are GREAT free advertising
They advocate FOR the tool just by using it and promoting it in their own work
And that market appears to be completely gone now
Thats a big come down from say 10 years ago when there literally were more postings that people to handle them
And why over time so many that DID work in that realm have departed
Requests I get are mostly old applications which have to be renewed and that job is never done with XoJo. I am not interested to do that Job with Xojo. I will do it with Java and that’s it. There was never a complaining about. People are realizing that it was not the best Idea to rely on Xojo and also: sometimes they wrote the app as hobbyists and now as their company growed the application is not able to do the job anymore. So it is needed to rewrite and develop new features like double opt in and stuffs like this.
That somebody is writing a brand new application or let me say realize a bigger project today…I have my doubts there. People using toolchains which are cheaper (open Source) and the ones which are more modern. So I doubt that people want to use Xojo for new apps. And at the end - they will land in a rewrite when and if their needs growing up or if they - one day and that day will come - standing in front of a showstopper which can not be fixed with a workaround.
This is drifting off topic a bit 
1 Like
Indeed. One of the reasons why the transition to Go has been ‘easy’ is that it’s strongly typed - even more so than Xojo. In Xojo converting between Integer sizes won’t generate an error (I realize there IS an option to turn this warning on) but Go doesn’t give you an option. So if you want to work with UInt32’s and Int32’s, and so on, you’ll have to explicitly convert each and every time. Kind of a pain but you’ll never have to wonder.
30 years at the helm of a software company he should understand why they are evil and how they hamper the compiler from helping people write better more reliable code
He would if he was actually a developer and did serious work. He’s an unserious developer and doesn’t spend all day, every day, working in the product. He dabbles in Xojo and therefore never has to get deep enough into it to see its many flaws.
My calls for them to do consulting was my thought process for getting them to be serious about the product. If they’re ‘on the line’ with a client shit would get fixed or better workarounds found. But since their only commercial product is IDE their viewpoint is incredibly small. Reporting would be better. There would be grids, better RTF support and so on. There are all the things we’ve been clamoring for since I’ve been using Xojo. Instead we get half-baked solutions, rearranging the deck chairs (API 2), and giving every existing developer the finger.
Anyway, nothing new. Same bullshit we argued with them 20 years ago.
3 Likes
Why should he change that system? First: it runs. Second: he has only five or six developers. He is too small for the platforms he is targeting so the decision to survive with citizen developers is the conclusion he has done. And he will never change this. For what. Behind the curtain he can laugh about the problems while he only realizes: when and if it is only for the simple citizens it makes no problems cause they can live with small bugs. And the professional devs making too much trouble.
Inside of this decision is the resulting problem for professional software developer: more than playing with it is a dangerous part. Relying on it also. This is not the result of a bad product idea but of a business decision of their CEO. And in case of that there is no way to change that behavior. Nobody there wants to change this. Only protecting it. Critics leading in their forum to bans. Too loud critics about errors and bad decisions is ranting in their world.
And again I have to say sorry but this behavior and this wise of customer handling is something I don’t know looking on Java or also GO. Yes, go is young and it was in the early stages a problem. Today it is adult and even today a friend of mine mentioned it together with fyne GUI as a more and more professional tool.
And yes, GO is interesting and a performant language. If I would not be an old Java guy which is fixated on his platform cause of reliability and it’s unbeatable ecosystem around I would consider even to use GO language. They made everything right what Xojo did wrong. Simple answer.
1 Like
Certainly not perfect (but then is any language?) but I love the version 1 promise that if they add anything it won’t break existing code. Currently on 1.24.x and they’ve managed to add Generics, add a bunch of security stuff, made it faster, made the compiler repeatable, added better testing methods (mainly for concurrency), and simplified major parts of the framework. And that’s just in the 2 years I’ve been heavily involved with it. And I recently saw the proposed changes for 1.25 for this fall.
It’s been a while since I looked at Fyne. Last time I looked I felt the UI was very basic and not all that customizable. Maybe I should give it another go (pun intended).
I’ve been following Wails quite closely but it kind of pisses me off at how slow version 3 (multiple windows, native contextual menus, and linux support) is progressing as I think it has some promise with very good UI capabilities with the ability to use practically any front end you want. But then this is the breaks with an open source project as it may never finish or become viable (though there are definitely people using it).
Bob, they are starting and in the beginning of this process. Looking on Java it is a bit like in old times of AWT. But at the end I believe they will have a good UI capability. That it is not a totally good one: ok, something we can discuss. But it is much more than it was in the beginning.
And yes, GO has made a really good policy to grant the users that written code will be usable as long as it is possible. Reliability first! And really everybody could understand that from the first version on a change could be. There was non. Old code works.
TBH I suggested this at one time when I worked there and it went nowhere
No idea why
I agree with your thoughts about it pushing things along esp in areas that they dont use in the IDE
1 Like