Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Niklaus Wirth was right and that is a problem

bowero.nl

Post reply on HN
Print view View original

41–50 of 198 posts

Re: Niklaus Wirth was right and that is a problem

#41

Post by sheepz »

baryphonic wrote: post #36
sheepz wrote: post #28

Earlier quoted context omitted.

No, it's the other way around. Advances in computer hardware have allowed the use more inefficient programming languages allowing more inexperienced and unskilled programmers to create programs leading to more resource hungry programs. When there are little resource constraints the only real constraint becomes developer time. I don't see how having IDEs implemented in browsers has anything to do with security, the sp…

> I don't see how having IDEs implemented in browsers has anything to do with security, the speed of light or compatibility. It's just the lack of constraints allowed by advances in computer hardware. This isn't a compatibility issue? We've seen about 8-16 branches of the write-once, run-everywhere tree over the past 25 years, I'm not sure how that isn't seen as a constraint on programmers. JWT, Swing, Web, Cordova,…

While there is certainly more complexity in modern software, it does not necessarily need to translate to increased memory, CPU usage and increased latency for the user. Are you saying that this increase in software complexity definitely increases these requirements?

Java is definitely not a good example of a memory-efficient language when compared to its non-GC alternatives.

It all comes down to economics, software is written as inefficiently as possible as long as it does it jobs and is not hindered by this and this actually the crux of "Wirth's law".

Re: Niklaus Wirth was right and that is a problem

#42

Post by cellularmitosis »

beervirus wrote: post #34
ummonk wrote: post #32

The referenced AppSignal post about 13,000 dependencies for a todo list is conflating dependencies required for the build tooling with dependencies that are actually bundled in to the web app. It's also hilarious that right after referencing the dependency problem in the JS ecosystem the OP then goes and advocates splitting up your library into a bunch of mini libraries. That's exactly how we got into this mess in th…

Responsiveness in terms of keypress latency has gotten much worse over time.

you should include a reference: https://danluu.com/input-lag/

Re: Niklaus Wirth was right and that is a problem

#43

Post by black_puppydog »

UweSchmidt wrote: post #18

There are many complaints but there doesn't seem to be a real movement to make/use/cultivate small and fast software for all purposes. I'd join. Fragmented parts could be suckless.org, old cheap thinkpads from ebay, fast Linux distros, unix command line tools, retrocomputing, raspberry pi; all things with communities and fans who like a certain quality, simplicity and the good old days.

check out the suckless suite of software. it's neat :)

Re: Niklaus Wirth was right and that is a problem

#44

Post by Sebb767 »

noobermin wrote: post #9
coding123 wrote: post #5

I 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.

Alternative question: Why do I need to download 50 GB of book index to search for that one title and that index can't even do a full text search?

That complexity is Google (or your favourite search engine) running a datacenter indexing exabytes of data so that you can search it in the blink of an eye. Yes, it takes 600ms now instead of 50ms - but that's like complaining that your new eco car engine can't even properly run on aftermarket lamp petroleum.

Re: Niklaus Wirth was right and that is a problem

#45

Post by Gibbon1 »

noobermin wrote: post #8
wrs wrote: post #6

The 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.

After 40 years I've decided that dependencies are the root all evil. There is something to be said for curated libraries and frameworks.

Re: Niklaus Wirth was right and that is a problem

#46

Post by Sebb767 »

I guess it's more of a natural selection process - the software house which can deliver a good enough working piece will (nearly) always beat the one which adds another two years of development time (and cost) to make the app a bit snappier. Ask Lotus Notes and Netscape.

I don't want to say that performance does not matter at all - it does - but with hardware being as cheap as it is and developer time and time-to-market being as expensive, optimizing that last 500ms and 200MB out simply is not going to be worth it.

And let's not disregard the expense of performance optimization - you'll not only need a reference to benchmark and test against, but also spend a lot of time debugging and writing very plattform-specific code with tons of edge cases. It's not like saving 2GB of memory comes for free.

Re: Niklaus Wirth was right and that is a problem

#47

Post by Gibbon1 »

realtalk_sp wrote: post #27

"In economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons effect) occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand.[1]" https://en.wikipedia.org/wiki/Jevons_paradox

See modern IRC clients that take 500MB of memory on the desktop. Compare with Orcad Capture a mid 90's schematic capture program that would run acceptably on a 486 with 16MB of memory.

Re: Niklaus Wirth was right and that is a problem

#48

Post by LeftHandPath »

ummonk wrote: post #32

The referenced AppSignal post about 13,000 dependencies for a todo list is conflating dependencies required for the build tooling with dependencies that are actually bundled in to the web app. It's also hilarious that right after referencing the dependency problem in the JS ecosystem the OP then goes and advocates splitting up your library into a bunch of mini libraries. That's exactly how we got into this mess in th…

I agree with the core point of the article, but I agree with your points as well. The conclusion of the article is definitely wrong.

I recently buddied up with someone who has a CS degree to try and make a desktop app, as a side project. I asked if he is familiar with MariaDB and whether or not he's used C++ ODBC.

Our discussion quickly turned into choosing libraries / existing code. He uses Spring and Hibernate and was bewildered by the concept of tying columns to application variables "manually". After I told him I have some CentOS servers where we could put a shared database, he bought a Windows Server because he "needs a GUI". He added, "Ideally, after it's setup, we'll never even have to remote in to it." For the actual desktop application, he wants to use Electron.

It seems there are two distinct branches of computing emerging - one where performance matters, and one where it doesn't. Performance will always matter in places like the stock market or on IBM mainframes. In the consumer-facing world, All that seems to matter is perceived performance. Slack and Discord seem fast, when you watch how quickly a new message pops up on your laptop screen after you sent it on your phone. They seem egregiously slow when you open up task manager and see just how much overhead the chromium-based engine adds -- but most people won't care.

Applications made for "consumers" tend to be made like a cheap car - corners are cut, the end result isn't pretty, but things in the category are what makes up 90% of ordinary use cases. Slack isn't meant to be open on your work machine while you're compiling code in the same way a Prius isn't meant to chauffeur top-level executives. It doesn't mean that the Prius is bad or unimportant - it will do far more for more people than the entire lineup of many luxury car brands.

But I am damn sure that I'd rather be engineering a Bentley than a Prius.

Edit: In the metaphor, luxury and performance are sacrificed, not efficiency. I probably should've used Fiat Chrysler, but unlike Fiat Chrysler, consumer-facing software has its place. I just don't enjoy working on it myself.

Post reply on HN