Several tools are resource hungry, making it challenging for small businesses to keep up with server costs. Zod for example is 150 slower than regular typeof checks. I wrote small article for those who are interested https://www.drakos.me/article/Zod-is-150-times-slower. The problem is not Zod, but rather the programmers who lack the ability to write efficient code. As I write this, my VSCode uses 4.37GB RAM, my terminal Warp (Built in Rust) uses 976MB RAM and Spotify 1.28GB. These numbers are outrageous to an old senior programmer. Let’s not forget that Nasa managed to launch rockets to the moon with only 64kb of RAM.
Why programmers choose convenience over performance?
1–10 of 25 posts
Re: Why programmers choose convenience over performance?
#2Do the tools save developers time? Do the tools make deployment or code more maintainable? Is the cost of resources greater than the cost of paying for developers time? They sent rockets to the moon with 64kb of ram because they had to, not because they were trying to skimp tooling.
Re: Why programmers choose convenience over performance?
#3[dead]
Re: Why programmers choose convenience over performance?
#4Do the tools save developers time? Do the tools make deployment or code more maintainable? Is the cost of resources greater than the cost of paying for developers time? They sent rockets to the moon with 64kb of ram because they had to, not because they were trying to skimp tooling.
JFK said so: "We choose to go to the Moon with 64KB of RAM not because it is easy, but because it is hard."
Re: Why programmers choose convenience over performance?
#5> Let’s not forget that Nasa managed to launch rockets to the moon with only 64kb of RAM.
We're not in the rocket launching business. Desktop memory is cheap and nodejs/electron makes it easy to develop cross platform.
Re: Why programmers choose convenience over performance?
#61. Convenience usually transfers to less development time, which means less cost. Unless the performance is so poor that it’s unacceptable to a majority of users, many companies are willing to ship less-performant software if it means saving on development time and cost.
2. There is a lot of software that is used because people must use them. If your workplace uses Microsoft Teams despite its problems, then you’re essentially stuck using it. The problems would have to be so bad that they affect the company’s bottom line in order to switch. If your local bank or DMV requires use to use a poorly-written Web app, what could you do about it?
3. Not all software developers are well-trained in topics such as algorithmic efficiency, computer and network architecture, the trade-offs of different programming languages and their abstractions, etc. There are plenty of developers who could hack up working solutions quickly but cannot write quality production-grade software. The result is buggy software that doesn’t perform well and doesn’t scale.
4. This is just my opinion, but I’ve found over the past few decades that most users are more forgiving about crappy software than the average technically-inclined users. Crappy software isn’t anything new. “What Grove gaveth, Gates taketh away” was a quip I first heard in the 1990s about software bloat expanding as hardware improved. I remember the days of constant blue screens on DOS-based versions of Windows, as well as Macs crashing due to the classic Mac’s lack of protected memory. Complaints about the bloat of Microsoft Office and Netscape Navigator were common. I was a teenager in the 2000s when Windows suffered from many security issues. Non-technical users generally grinned and beared personal computing, all chalking up the crashes and slowness as just part of computing. Us technical types were the ones who were upset enough to seek alternatives. But we’re vastly outnumbered.
As long as economic effects favor “moving fast and breaking things” over slower, more deliberate approaches to development, and as long as users don’t demand performant software, companies will continue to deliver bloated software. I don’t see this changing outside of niches where performance and other related concerns outweigh minimizing development costs.
Re: Why programmers choose convenience over performance?
#7Everybody knows that Real Programmers™ rely on the incredible raw performance of plain Typescript, not fancy libraries /s
Re: Why programmers choose convenience over performance?
#8A decompressed 4k texture uses ~80-90MB of VRAM.
Your development tools index millions of lines of code.
Not sure what your terminal does tho.
But finally it’s mostly the massive amount of data modern applications have to handle effectively that lead to large amounts of memory allocated.
Zod surely is slow. I never imagined it to be fast. It has multiple layers of abstraction and does lots of checks. A custom solution giving the same level of detailed type safety wouldn’t be fast either.
Software just got very complex. Data became larger. And sometimes you better don’t implement abstractions to reach at least some efficiency with all these petabytes of 8k cat pictures and tiktoks…
Re: Why programmers choose convenience over performance?
#9If there was a valid reason to write software that efficiently, besides idealism, I'm sure developers would do so. But there isn't in the vast majority of cases, so we don't. iow computing resources are cheaper than labor.
Re: Why programmers choose convenience over performance?
#10I think it's caused by the nature of how most companies scale their productivity up, which is by adding more people and creating more teams. As a result the codebase for any given product starts to reflect this organizational structure.
For example, a bank app might have a team for user management, and another team for product management. Then in the bank app, the designers added one module for selecting products on one page, and another module for selecting users on another page... and even though at the implementation level, these two modules are essentially the sam, they are implemented separately, as there is a lot of overhead in communication to have both teams implement one that handles both requirements.
I think this phenomenon guarantees that as codebases grow they accumulate tech debt. As more and more people develop on one application proper global abstractions that would be more efficient are not as common because of how the teams are structured in a way that is not aligned with this abstraction and instead is aligned with how the business side decides to structure teams.
I think it is born from a fundamental misconception of how software should scale as you add more and more features, and typically companies favor adding more people instead of asking their engineers to do the scaling using the software itself. Within a certain domain, there is very little reason not to abstract the implementation of features themselves, which would scale the application just by adding a few lines in a configuration file. Then a single engineer can be developing multiple features in the same amount of time an entire team completes only one. This might just be a blind side of someone who has not studied computer science theory, and instead thinks that if you want more software you need more people.