Nice reading. There’s nothing like a good old rant - especially when it makes sense.
Nice reading indeed and true for Xojo also. My quite huge project compiled to 32 bit with Xojo 2014r3.2 weights little more than 100 megabytes with dependency folders, but compiled to 32 bit with Xojo 2018r2 weights slightly more than 200 megabytes and end product is remarkably slower
P.S. I started that project with RealStudio and there was no problem to fill listbox with 2 thousand rows. It took 1/100 of eye blink, but in Xojo there I can make 5 or 10 eye blinks and still I see how listbox fills up with rows by reducing scrollbar handle. Yes I freeze listbox now when I fill it with data so it will not seems so slow
Text editors! What can be simpler? On each keystroke, all you have to do is update tiny rectangular region and modern text editors cant do that in 16ms. Its a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load/unload resources. How come?
I guess he doesnt know the Xojo IDE, or the apps compiled in 2018r1 running on windows.
As he says:
[i]At least it works, you might say. Well, bigger doesnt imply better. Bigger means someone has lost control. Bigger means we dont know whats going on. Bigger means complexity tax, performance tax, reliability tax. This is not the norm and should not become the norm. Overweight apps should mean a red flag. They should mean run away scared.
We just throw barely baked shit out there, hope for the best and call it startup wisdom.
That is not engineering. Thats just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply.
You dont have to be a genius to write fast programs. Theres no magic trick. The only thing required is not building on top of a huge pile of crap that modern toolchain is.
I think it’s a product of our Society.
Hack it up - smash it out - get it done as quick as possible - cheap as possible, because I WANT IT NOW!!
Sure that’s fine for home delivery pizzas (arguably), but it shouldn’t be the case for software developers. But software developers have to keep up with the changing operating systems/frameworks etc.
So in the end it becomes a huge snowball, becoming even huger, and accelerating even more, as it hurtles down the hill in a never-ending loop to an #undefined end.
One may well ask the question, who is it benefiting?.. who is making ALL the money?.. well, certainly not the average software developer trying his/her best to keep up.
I’m only a hobby programmer, I feel for those that do it for their daily crust.
The worst thing is that nobody even cares.
Here is proof: https://forum.xojo.com/49816-compiled-app-size/9/
In my opinion sloppy programing (which apparently is the norm) results in slow, and also buggy apps.
In the POS that we currently use one report takes 60 seconds to run. Accessing the database directly I can run a query to get the same results in 47ms. WHY??? It’s foolishness!
[EDIT] After I complained they did an update. Now it takes 18 seconds instead of 60 seconds! Wow!
We don’t need slow choppy apps on a computer with an i7 processor. Come on…
You can drastically speed up load time by turning off the vertical scrollbar while adding rows.
Its all about that bass framework
I remember the days when app installers used delays so people felt like they got value for money waiting for their purchase to install, now they are just waiting for all the framework bloat to install as fast it can.
31MB isn’t bad for the 3533 functions in that library.
I work for a Printing Company. But these days it’s become ridiculous. Clients seem to think they can get their print job like they would download a movie off netflix.
There always seems to be this implied sense of urgency to to keep up… Quick, quick, hurry, hurry… like it’s a hospital trauma centre. What a Crock!!!
No-one has the time to do things properly in a professional manner, but at least I know the difference.
Someones making the big bikkies out of all this, but for the rest of us, it’s a new more frantic version of slavery.
There’s never enough time/money to do it right the first time. So you get something that mostly works. The programmer and the programming team knows that is has bugs and is missing features but they’ve already been tasked with doing the next thing.
This seems a bit extreme but the sentiment is definitely true. In my engineering days our department was a cost center and we spent money - we never made money - even though we saved money in process improvements, less down time, etc. Engineering wasn’t essential in the accountants eyes. That company eventually disbanded their entire engineering department and now I have no idea how they handle their five manufacturing facilities improvements (my guess is not well).
I was in car development for almost 20 years. It’s almost the same there: bloat and more bloat. And cars get every year more - badly developed - software.
@Beatrix Willius . I believe I have heard something about German cars with the magic software under the hood, which needs to be downgraded because it is over-designed.
I finished my CS degree back in 2003. Even back then, the frameworks I was using were bloated. Even doing something relatively trivial like basic operations on Strings meant needing to pull in a library in C++. Since then, the problem has just exploded. I have several friends who do full time web development, and they hop from framework to framework seemingly every month. Node.js, react, ExpressJS, SailsJS, DJango, Tornado, Laravel, Yii, RubyOnRails… it’s dizzying to try to even fathom keeping up.
I remember a few years ago a very simple node.js library broke (something about reversing a string, or capitalizing it or somesuch - it was a whole library with literally 1 function in it) and it brought down a large number of big websites, as they scrambled to figure out what went wrong.
Frameworks built upon frameworks with patches upon patches upon band-aids upon workarounds… at some point the entire popscicle-stick-and-elmer’s-glue leaning tower of Pisa concoctions that we build will come crashing down.
Hopefully I’ll have found some other way to earn a living when it does.
Ah, yes: The Left-Pad Debacle
Thanks a lot. I have thought about it, but never tried as I guessed that if I switch vertical scrollbar on and off, I will see that and it will be unpleasant to see for eyes. Instead of that I freeze a control by Windows API. Now I tried and I like it, as removing and placing back vertical scrollbar does not make any visual effect so vertical scrollbar stays visible all the time by refreshing the list. And indeed it seems to be light faster than freezing a listbox. Thanks one more time.
Isnt a difference depending on the used .AddRow syntax ?
I’ve done extensive testing. There are many things that can be done, but most of them only offer minute speed improvements. On the other hand hiding the vertical scrollbar makes a HUGE difference. I think it’s because every time an item is added the scrollbar needs to calculate position and height.
While this post is very good (albeit a bit overly simplistic to exacerbate a point) the real gem is the linked Electron post:
Whenever I talk about Xojo I’m told Electron is the real option. I know Xojo has its own flaws but I simply LOATHE electron apps. This was even before I knew they contain the most overbloated runtime environment you can think of.
Just because it works doesn’t mean it is good. That sort of thing drives me nuts.
I recently wrote a method that processed 80K+ records. It was taking about 5 seconds. It’s a program that runs every night to do price updates and 5 seconds wasn’t really a big deal, but I decided to try improving it. First I got it to 2.5 seconds, then 1.2 then to 0.8, and finally (to my surprise) I got it to run < 1ms by using dictionaries. It might not have helped this app at all, but I gained knowledge, and future apps will benefit from it.