Niklaus Wirth was right and that is a problem
1–10 of 198 posts
Re: Niklaus Wirth was right and that is a problem
#2Seems to me the software features interact in a kind of network effect, so that the amount of resources required grows faster than amount of functionality.
Re: Niklaus Wirth was right and that is a problem
#3For the most part, the output object/exe size should be the realm of the tooling, not the programmer's concern -- a dependency-walking package-manager, linker or loader -- and in dynamic languages, unused code should never be JITed. Of course, surrounding issues such as choosing bad or incompatible libraries, etc., is another matter.
Re: Niklaus Wirth was right and that is a problem
#4I was expecting Moore's Law to give us a renaissance in algorithmic thinking, but The Cloud has shown me I was wrong. First, we're going to have to fully explore Amdahl's law.
Eventually every problem goes to logn time, best case. The logn factor shows up over and over, from constraints on on-chip cache to communication delays to adding numbers of arbitrary size. We make a lot of problems look like they are O(1) until the moment they don't fit into one machine word, one cache line, one cache, into memory, onto one machine, onto one switch, into one rack, into one room, into one data center, into one zip code, onto one planet.
If we can't solve the problem for all customers, we dodge, pick a smaller more lucrative problem that only works for a subset of our customers, and then pretend like we can solve any problem we want to, we just didn't want to solve that problem.
Re: Niklaus Wirth was right and that is a problem
#5I feel like we had this debate a couple months ago. Someone posted that the computer at his local library could search and display data on available books super fast. (I think it was a twitter thread). The interface was programmed in the 90s or something. And then they complained about software today.
My reply was that now days you can, at home, search for a book on a specific interlibrary system, and find what specific libraries have it, download and check out an Ecopy, find out the number due back if you still wanted the hard one - AND have someone go hold it.
It's just not apples and apples anymore. I don't care how fast you can scan a text file in 90s written software.
Re: Niklaus Wirth was right and that is a problem
#6The argument got rather confused at the end. The todo list has 13,000 dependencies precisely because the NPM community follows the advice here to create many small libraries. So is that supposed to be a good or bad thing?
Re: Niklaus Wirth was right and that is a problem
#7[flagged]
Re: Niklaus Wirth was right and that is a problem
#8The argument got rather confused at the end. The todo list has 13,000 dependencies precisely because the NPM community follows the advice here to create many small libraries. So is that supposed to be a good or bad thing?
Yeah...not sure where they were going there. The many small libraries becomes a problem when said libs go out of sync, i mean that is where dependency hell bites.
Re: Niklaus Wirth was right and that is a problem
#9I feel like we had this debate a couple months ago. Someone posted that the computer at his local library could search and display data on available books super fast. (I think it was a twitter thread). The interface was programmed in the 90s or something. And then they complained about software today. My reply was that now days you can, at home, search for a book on a specific interlibrary system, and find what speci…
There is not reason you can't have the connectivity without having the unnecessary complexity of modern computing.
Re: Niklaus Wirth was right and that is a problem
#10For the most part, the output object/exe size should be the realm of the tooling, not the programmer's concern -- a dependency-walking package-manager, linker or loader -- and in dynamic languages, unused code should never be JITed. Of course, surrounding issues such as choosing bad or incompatible libraries, etc., is another matter.
There’s no way a linker, no matter how smart, can give us back the object size and performance of the ‘90s.
For starters, there’s 64-bits. Pointers were a quarter of the size in the ‘90s.
Then, there is Unicode. All programs need ICU (http://userguide.icu-project.org/icudata). Even if you dynamically link it, many of its symbols (or entry point IDs) end up in your executable.
Unicode isn’t an exception, though. Every library choice you make adds a bit more in size and takes a bit more in performance than the solution from the ‘90s would have.
For example, the moment you decide to use json, you get its entire feature set (arbitrarily nested arrays, a multi-line string parser, ability to read fields in arbitrary order, etc), even if all you need to do is pass two integers and get one back.
A parser generator that generates code for the json subset you need would help here, but would mean extra work for the programmer and the overhead typically isn’t that large, so why bother? It all adds up, though.
Even if you can’t remove some code, you still could optimize memory layout to move code you expect will rarely run into separate code pages so that it likely will never be mapped into memory, but that’s serious work.
And of course there’s all that argument checking/buffer overflow protection people do nowadays that ‘wasn’t necessary’ in the ‘90s.