While I certainly enjoyed the read I also stumbled over that “don’t choose Xojo when maximum performance is required”-part. The problem is not that it is not correct - it is - but that you make the passer by believe, “oh, Xojo, looks interesting, hmm, pity, it seems to be slow”. When saying something is fast or slow it is important to put things into perspective by giving some real time numbers and then compare those with other languages. In 99,99% of the real life cases we’re looking differences of milliseconds.
Maximum performance means exactly what it implies. You will not get maximum performance from Xojo because of safety features, nature of language, large framework, total lack of concurrency, event model (which polling mechanism do they use on every OS? is it even documented?).
I also give the reader the benefit of the doubt that they will try the product and see if it is fast enough for them. I even go on to say in the article that for most use cases its a non-issue but there are cases where it is an issue.
The largeness of the Xojo framework is irrelevant to the question of performance.
Do you mean multi-core usage / parallel processing? Or threading? Or something else?
What do you mean by “event model”? Xojo’s / VB’s Events? Or the OS event in which you “hook up” for the certain events you want to react (or rather the Xojo framework wants to react to)? And why “polling”? Windows: isn’t this done with Callbacks? OS X: Observers and subclassing NSResponder?
What does that even mean?
[quote=348004:@Eli Ott]The largeness of the Xojo framework is irrelevant to the question of performance.
Do you mean multi-core usage / parallel processing? Or threading? Or something else?
What do you mean by “event model”? Xojo’s / VB’s Events? Or the OS event in which you “hook up” for the certain events you want to react (or rather the Xojo framework wants to react to)? And why “polling”? Windows: isn’t this done with Callbacks? OS X: Observers and subclassing NSResponder?
What does that even mean?[/quote]
It is widely known all over the Internet and on these forums that Xojo apps can be slower than counterparts written in other languages. The framework abstracting platform differences has some additional “weight” involved in a lot of features. FolderItem for example is slower than native file access in other languages.
Since Xojo has no multi-core, parallel or true threads then an application that requires any of those would be not ideal for Xojo.
Regarding to polling for events depends on the API/library/framework being used. Some allow you to use callbacks and others you have to use poll/epoll, etc. I don’t know the intricacies of how Xojo does it because that code is closed source. I do know from reading code and being involved in other communities like Node that how you poll and what poll mechanism you use can have pretty large performance ramifications. I am sure the implementation details vary by platform that Xojo targets.
“Nature of language” = high level rapid application development. Such tools are always slower than writing code closer to the machine.
My whole point in discussing performance is for the many examples I can conjure in half a second: network routing, bitcoin mining, GPU acceleration, real time stock market analysis, etc. A lot of those apps are specifically written in platforms like Go, Rust, etc. because of their ability to scale and being closer to the metal.
There is a reason why Xojo plugins can often be faster than native Xojo code doing the same thing.
Now whether performance for your application will be constrained by Xojo that is really dependent on what you are doing. For 99% of people it will not but I am not going to be dishonest in my review and claim that maximum performance is easily attainable (if at all) in Xojo when it is not. Does your application need “maximum performance”? Probably not.
There are some use cases where you simply cannot use Xojo because of concurrency/parallel needs. Those are the use cases I consider requiring “maximum performance.”
Threads are not the only way to achieve parallelism
Run multiple instances of a helper app - which is a lot simpler to debug initially, each gets its own 4Gb address space, the OS can schedule it and many other things that make this a much easier way to achieve parallelism.
There are lots of instances of people doing this and maxing out significant amounts of hardware
Heres two
Tinrocket, LLC | Work:Development
http://www.ucalgary.ca/styslab/imagetrak
[quote=348017:@Norman Palardy]Threads are not the only way to achieve parallelism
Run multiple instances of a helper app - which is a lot simpler to debug initially, each gets its own 4Gb address space, the OS can schedule it and many other things that make this a much easier way to achieve parallelism.
There are lots of instances of people doing this and maxing out significant amounts of hardware
Heres two
http://2002-2010.tinrocket.com/consulting/work/development/00174/index.html
http://www.ucalgary.ca/styslab/imagetrak[/quote]
Sure but that is not a suitable approach for every program is my point.
Thats not what you wrote just 2 hours ago
Threads are not a panacea and parallel processing is hard to reason about accurately
People do it poorly the more complex a system gets
A great thread concurrency - Why are multi-threading programs more prone to errors? - Computer Science Stack Exchange
Multiple instances of a single threaded app are much simpler to create & test since they CAN’T have most of the issues that threaded apps can (mutable shared state etc)
Making it simpler to set up such a scheme in Xojo would be useful
But its not impossible to do manually (as the examples I cited illustrate)
[quote=348009:@Phillip Zedalis]My whole point in discussing performance is for the many examples I can conjure in half a second: network routing, bitcoin mining, GPU acceleration, real time stock market analysis, etc. A lot of those apps are specifically written in platforms like Go, Rust, etc. because of their ability to scale and being closer to the metal.
There is a reason why Xojo plugins can often be faster than native Xojo code doing the same thing.[/quote]
What is a platform like “Go, Rust, etc.” these are not platforms. And through declares Xojo is very close to the metal (much closer than you think). You through around some terminology a bit lightheartedly in my opinion. By the way you’ll always find something faster. Assembly. Machine code instructions. Oh, and a better algorithm.
[quote=348046:@Norman Palardy]Thats not what you wrote just 2 hours ago
Threads are not a panacea and parallel processing is hard to reason about accurately
People do it poorly the more complex a system gets
A great thread https://cs.stackexchange.com/questions/50213/why-are-multi-threading-programs-more-prone-to-errors
Multiple instances of a single threaded app are much simpler to create & test since they CAN’T have most of the issues that threaded apps can (mutable shared state etc)
Making it simpler to set up such a scheme in Xojo would be useful
But its not impossible to do manually (as the examples I cited illustrate)[/quote]
Right threads are one concept.
I’ve been doing some socket and HTTP server programming in Elixir. As a functional language with a model similar to “fibers” it is much much easier to use a single process and scale to many CPU for a network service.
In Xojo that would be more difficult.
XOJO is a wonderful tool for rapid application development and especially suitable for customized ERP software. For example, my ERP application for a construction company has been running successfully for 8 years and is constantly being further developed.
https://jakobssystems.net/english/minicalc/
Some things have already been said about XOJO. As far as Windows is concerned, I can only add that the strategy and direction of Microsoft itself is anything but clear. Therefore, you should not be too hasty in your criticism of XOJO.
Where there’s light, there’s always shadow. As simple as the IDE is, the components and objects for GUI business applications are meagre. Example: Still no Date Picker:
To be able to work seriously in XOJO, you have to calculate the price for third-party components. This is the main point of criticism: the dependence on components. How many components have I seen in the years to come and go. I now only buy components in the source code, so that I am at least able to fix bugs or make adjustments. Lost time that I don’t actually have.
Another point: I recently had to work with matrix operations. Also here in XOJO there’s nothing built-in. The available information comes from Realbasic times and I was forced to reinvent the wheel and program the most important functions (like matrix multiplication and addition) all by myself.
Rust/Go can build much faster concurrent console based applications. There are go libraries for desktop development as well. I suppose how one defines “platform” but I mean alternatives to Xojo depending on need.
I did state in the review that Xojo can handle most projects. I am not sure why there is so much push back that Xojo may not be suitable for EVERY task. Yes of course assembly and machine CAN be faster but I am talking about programming languages and environments that people use on a daily basis.
If you write a socket server in Go it will perform faster across multiple CPU cores than Xojo + background apps. in Xojo you cannot share a socket between processes so I am not even sure how an accessory application would help in that circumstance. +1 to Go.
That is one example of one type of application where Xojo is not the FASTEST approach. For many use cases Xojo may still be fast enough.
At least it’s easy to build your own controls. I ended up building my own date picker, and combobox.
https://forum.xojo.com/36094-activex-datepicker-not-working
counterquestion: Why do you think they are included in Xcode/ Visual Studio (whatever IDE/language)?
As previously written: No customer pays me the time for such basic components. What remains is only the third party add-on market. Not really an option for such basic components.
It would be nice to have more controls included, but… I think I save enough time on other things to that I can write my own controls and still be ahead. I spent about 10 hours making the datepicker shown above and it works exactly how I want it to work. I couldn’t find a 3rd party control that worked like I needed.
Did you ever try to figure out the gridview in VS? Talk about time consuming.
but it was 10 hours you need to INVEST ONE TIME, and now you have a control that does what YOU want, how you want it, and can modifiy it to fit other situations as required.
This is one of those eye of the beholder things. I originally licensed the Einhuger components because the price was low enough to justify just for something else it contains. But it is still a one low price gets you access to everything license, and among them is a date picker. So I use it just because it was included in a package I could easily justify for other reasons. And renewals are ridiculously cheap.
It is like the MBS plugins – if I had to buy each separately, most I would not license. But the Complete license is a no-brainer in my book. You buy because of a few specific quick needs, then “for free” get access to an amazing array of extensions. Could I write the things I needed at the time I licensed each? Sure, if I had the time. But these are all royalty free distribution. And then you get access to all sorts of other pre-written and pre-tested stuff.
Even more so with the Omegabundle.
Sorry Dave, this is one place where we have a difference of opinion…
Nothing to be “sorry” about… Plugins are like politics or religon. We all have our opions and beliefs, and I won’t try to change yours if you promise not to try and change mine 
I’ll be honest I struggle with the logic of relying on a commercial closed source programming environment but then limiting yourself from using any plugins. It obviously does not stem from any ethical or legal concern regarding licensing. So it must be a practical issue of how plugins are implemented and supported in the marketplace.
However I don’t often get to bill customers for features that MBS can provide for insignificant cost. In fact MBS is kind of a hidden tax on Xojo because it opens so many capabilities for you that would be very difficult and expected from a customer due to it being available in most other environments out of box.
Instead of being anti-plugin I would like to see more from you Dave regarding a third party ecosystem and plugin model that you would support.
Well sorry, Phillip, but that will never happen. I have a very good (my opinion) reason for being “anti-plugin” (and this includes any 3rd party extension/add on for which source code is unavailable). Twice in my career, I have relied on a “plugin”, one time making a substantial investment not only financially, but in support, testing etc… To which I had designed a very extensive project that this plugin was a pivotal component. However it was lacking a few features, features which the Beta Test team (myself, and many others) had described in detail to the plug-in author… He agreed that our suggestion had extreme merit and would boost his plug-in to the next level. (Note: at the time there were at least 3 Fortune 500 companies that also had project centered on this plugin, and who knows how many hundreds or more hobby level, and other professional developers (Think the level of the Xojo community)). The author kept a running “blog” on release notes, and updated this “plugin” multiple times a week, and everything was going very well, and the entire forum he hosted was estatic about the pending release with these new required features. He had already released a version with the required hooks, so our code could be ready to “drop it in”…
Then one day he posts on his blog… “You know what, I bored… GOOD BYE” (or words to that effect), and he vanished. At the same time he took down all code repositories, the rest of the forum etc. And nobody has seen or heard from him since.
Now this was many years ago (mid 90’s maybe)… but since then, If I don’t have source code that I can read, understand, modify and conform to my needs… then I don’t want it… end of statement. period.
Now…previous to the past two years, I was paid quite well for my talents in a non-Xojo environment, so I didn’t have a restriction of “billing time” to worry about. I didn’t have customer imposed deadlines to worry about, So for every feature or function of a project that perhaps could have been made easier by MBS, or any of the other available plugin products, I devised my own solution, which I could read, understand, modify and conform to my needs. And perhaps even more important, I LEARNED SOMETHING.
So No Phillip, you will never see me use, purchase or advocate for the use of plugins., and now you know why…
As to Neil, he made an investment… one of time and not money, and that investment provided something that buying a plugin could not… and that was Knowledge… a valuable and vanishing commodity