IMO the author of this article is right about what he is saying.
And I am glad I am not the only one who sees the increased inefficiency of software and thus computers.
Different times have different fashions and programming is also very influenced by fashion. But it seems like Free Pascal survived and Lazarus and fpc seem like a sane alternative, worth taking a look at.
Did we lose our way in making efficient software?
501–510 of 515 posts
Re: Did we lose our way in making efficient software?
#502Earlier quoted context omitted.
Interesting that zig does this. I wonder what the binaries miss out on by defaulting to such an old symbol version. That's part of the problem of course: finding that out requires reverse engineering the glibc source code.
Maybe just nitpicking but he _specified_ the target version for the zig compile. (Haven't tested what it would link against where that not given)
> Maybe just nitpicking but he _specified_ the target version for the zig compile.
Right, but I was able to do it as a whole. I didn't have to do it per symbol.
Re: Did we lose our way in making efficient software?
#503A 30 MB doc file is a problem per se.
Re: Did we lose our way in making efficient software?
#504[dead]
Re: Did we lose our way in making efficient software?
#505Earlier quoted context omitted.
> and now things are back to mostly snappy. This is the inverse of my experience. There are few applications that have a UI that I would refer to as 'snappy'. In fact, I am trying to come up with a single example, and atm I can't even think of one .
All mainstream apps are vast on recent Android phones. Most everything on recent Ubuntu is fast. Most mobile sites in general are fast, maybe not "2kb of HTML" fast, but fast enough I don't notice or think about performance when browsing. Although, I suspect a lot of programmers can think faster than average and seem to be bothered more by small delays than the rest of us, since they're able to do things like figure…
I disagree. I use Linux (including Ubuntu), Windows and Android apps regularly, on fairly decent hardware. Most apps I would describe as having "OK" to "tolerable" performance. Some I would call "draggy", and a few I would call outright pigs.
Again, off the top of my head I can't think of a single application I would describe as "snappy". Or, put another way, I can't think of an application that, in recent memory, really impressed me by how well it performed.
Re: Did we lose our way in making efficient software?
#506In my MacOS Passwords I have ±3400 entries. A roughly 341KB CSV. Searching in that list in the preference panel or Keychain app is dog-slow on my M1 Pro Studio or on my M3 MacBook Air. How??
It seems obvious how you could make it slow. Just naively iterate over the entire series of objects looking up the name for each. This is the obvious low effort, low complexity solution. Of course you could make it fast, but that would take time and effort for a feature most people won't notice.
I agree on the priority here, but this looks like an OS component that appears in other apps. Filtering history in Safari is equally slow.
Re: Did we lose our way in making efficient software?
#507There is perhaps some irony in the fact that this blog was posted to Medium, which serves 10.88 MB for a 265-word article.
The ads are the real content from Medium’s perspective. The article is actually the medium by which the real content is delivered, like a train carrying dark passengers. The article is not what Medium cares about delivering to your browser, but the ads. And delivering the ads requires a lot of complexity.
…what ads? See the last paragraph here [0].
Obviously your statement is true about most other sites, but I thought it was an odd thing to say about a platform that famously doesn’t serve ads.
Re: Did we lose our way in making efficient software?
#508Earlier quoted context omitted.
Because subverting users' expectations about scrolling is the step 0 of efficient software. /s
That's why I said it might be a good thing. My main point was that it's just as easy on the web for standard scrolling. But even if you don't want standard scroll behavior, it's still easier. There's nothing easier to do on qt than on web. Compare a qtgraphicsview or qt3dcanvas to a webgl canvas and again, it's fighting against the framework versus stuff just working. Now sure qt is much better for tons of other stuf…
You remind me when microsoft was claiming that bash was hard and as example did some crazy obfuscated bash scripts, rather than just doing them the sane way.
If you're doing a GUI, you have no reason to be doing canvas manually.
Re: Did we lose our way in making efficient software?
#509Earlier quoted context omitted.
In sweden you can't login to A LOT of stuff without a smartphone. Including taxes, getting a covid certificate, applying to rent an apartment.
This seems very unlikely to me, as Sweden is known to be one of the most social countries in Europe, and such a requirement would not only discriminate against the less well-off, but also against the elderly and disabled. It would be very surprising if a majority could be found for such a regulation in Sweden.
Sweden has one of the highest wealth disparity in europe, and it's increasing.
Also, as person living in sweden, let me tell you that marketing as inclusive is not the same as being inclusive. Spending money to let disabled people be able to get on trains, or checking that accessibility laws are respected (they aren't) are not things that happen in sweden.
Just last month I encountered a broken elevator at a train station. Which means no taking the train if you're on a wheelchair (and good luck with getting a refund). Even worse, if you actually were on the train, you're now stuck on the platform and can't leave until the next train shows up. Of course to buy the ticket for the next train you will need a smartphone.
Re: Did we lose our way in making efficient software?
#510Earlier quoted context omitted.
That's why I said it might be a good thing. My main point was that it's just as easy on the web for standard scrolling. But even if you don't want standard scroll behavior, it's still easier. There's nothing easier to do on qt than on web. Compare a qtgraphicsview or qt3dcanvas to a webgl canvas and again, it's fighting against the framework versus stuff just working. Now sure qt is much better for tons of other stuf…
You remind me when microsoft was claiming that bash was hard and as example did some crazy obfuscated bash scripts, rather than just doing them the sane way. If you're doing a GUI, you have no reason to be doing canvas manually.
What? Even with QT you often have to use a painter and draw what you want more or less. You also need a canvas to display anything that is visualisation related. In any case it doesn't matter, as I said, scrolling is just as easy on the web as it is on QT. my point was more general, if you want to do anything custom it's easier to do in JS than with QT. Even using the multiple tools QT offers to customize the view (the painters, canvases, 3d widgets, etc)