Live data from Hacker News

Niklaus Wirth was right and that is a problem

bowero.nl

141–150 of 198 posts

Re: Niklaus Wirth was right and that is a problem

#141
post #109

> 1995 was the year in which programmers stopped thinking about the quality of their programs. Oh, please. There are some good points in the article but that hyperbole was unnecessary. I was programming in 1995, and nobody stopped thinking about the quality of their software.

I’ve been programming since 1965, read Dijkstra, Niklaus Wirth. And these days I break software at people’s request. There is in fact much less concern and emphasis on quality these days. It is also interesting to note that Knuth also does not do libraries

I'd say it's probably more a factor of the _requirements_ of the software getting harder. Pre 1995 most developers were writing apps running on a desktop that wasn't even multitasking. Post 1995 you have preemptive multitasking, TCP/IP / GUIs / multi platform / search indexes, etc. Most don't have the brain power to be experts in all those fields, hence you have to pick where you can excel in quality.

Re: Niklaus Wirth was right and that is a problem

#142
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…

You're right about a lot but I really want to argue against the idea "people don't care." They do care. They care when their phone dies after 2 years and they have to buy a new one because updates have rendered it unusable. They care when the phone/pc/laptop gets hot with only a few tabs open. Polls seem to show people generally care about climate change, and as little as PC's use in energy (relative to transportation and electricity generation for things like heating), they probably would care about this too. Users just don't understand things could be better, especially if they're younger and they don't remember windows 2000 or dos for example. On the other hand, every older person I know curses the newfangled things, even if there are some new connectivity capabilities of modern machines.

And the thing is that connectivity has little shit to do with the layers of abstraction to idk render a button on a screen. Even developers, as your anecdote shows, lack the creativity to imagine better things! Christ if that doesn't show something is wrong than what will?

Re: Niklaus Wirth was right and that is a problem

#143

Earlier quoted context omitted.

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

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

that was one of the most enraging non-political things I've read in years

Re: Niklaus Wirth was right and that is a problem

#144

Earlier quoted context omitted.

In my experience what the switch to SSDs resulted into was Windows 10 becoming practically unusable on a mechanical HDD. Comparing how long the OS needs to start up, launch applications, etc on my laptop with Win10 vs a much older laptop with Win8 (the first and last time Microsoft bothered to optimize Windows the last decade) is night and day and that older laptop originally came with Vista! When i first installed W…

At Microcenter you can buy a house brand SSD hard drive with 128G on it for $58 and boot from that and store all your other files on a D:\ regular hard drive. That is how I set up my son's Windows 10 gaming rig.

Just know you can run a full Linux desktop experience on top of twenty-year-old spinning rust just fine. Micro$oft drooped the ball big time if one needs a ssd just to use a OS.

Re: Niklaus Wirth was right and that is a problem

#145
post #134
post #57

Earlier quoted context omitted.

How many dependencies do we need to put food on the table? Perform a surgery? Or make an optically flat piece of glass? I believe all pieces of technology have similar dependency graphs.

You might be missing the point. A hospital in which surgeries are performed should hopefully already contain all dependencies required for a surgery. So when a new surgery is starting, the hospital staff should not need to run out and get more supplies. In the same way, the "dependencies" required to build my hardware aren't counted in that number. What counts is the extra stuff that isn't already part of the running…

I had a totes badass response with [9] footnotes and backstory, an arc, with pull quotes and a heartfelt ending. I pulled it to post on medium for my sweet side hustle, you don't deserve my prose.

Take your "quotes" and use them to run NixOS on OpenBSD.

Re: Niklaus Wirth was right and that is a problem

#146
post #144

Earlier quoted context omitted.

At Microcenter you can buy a house brand SSD hard drive with 128G on it for $58 and boot from that and store all your other files on a D:\ regular hard drive. That is how I set up my son's Windows 10 gaming rig.

Just know you can run a full Linux desktop experience on top of twenty-year-old spinning rust just fine. Micro$oft drooped the ball big time if one needs a ssd just to use a OS.

It needs a SSD drive to boot faster. Otherwise it takes a few minutes instead of seconds.

Windows 10 is for newer hardware anyway, it runs slow on older hardware.

Re: Niklaus Wirth was right and that is a problem

#147
>A good way to start would be to split up libraries. Instead of creating one big library that does everything you could ever possibly need, just create many libraries. Your god-like library could still exist, but solely as a wrapper.

This isn't it. It's literally what is creating the problem. Small libraries mean duplication, a lack of shared abstractions and dependency hell. The reason garbage collection was such a huge win is that before that every C library shipped with it's own completely different way of managing memory, that's a nightmare.

We need bigger libraries providing better abstractions that are reused through out and written to allow composition and dead code elimination('tree shaking' for the JS crowd) to work well. So you can opt in to functionality you need and opt out of functionality you don't need.

Communities working on big libraries can actually do good release planning, backwards compatibility and timely deprecations. React is a example of a library that does a really good job of this. All the smaller libraries in the JS ecosystem are the cause of the pain in modern JS development.

Re: Niklaus Wirth was right and that is a problem

#148

> 1995 was the year in which programmers stopped thinking about the quality of their programs. Oh, please. There are some good points in the article but that hyperbole was unnecessary. I was programming in 1995, and nobody stopped thinking about the quality of their software.

It's like they never actually ran Windows 95 and had the experience of people accepting your operating system crashing daily. It was much more reliable than Windows 3.1 after all (and to be fair to MS, was also more reliable than MacOS System 7 and ran faster than OS2).

There's always been good software and bad software.

Re: Niklaus Wirth was right and that is a problem

#149
It’s true that lots of software is slower than it should be. It’s also true that software does a lot more than it used to. What’s not true is that abstraction is the reason for slow software, at least not on the order of magnitude that the article claims. Even in the worst case, the cost of language level abstractions is well outstripped by advances in processing power.

I’m not actually sure we really even have “slow” software. At least not relative to how much that software can do. Latency is a different story.

Re: Niklaus Wirth was right and that is a problem

#150
post #63

What gets me is part of the '95 quote about computing in the 70s "About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage" Such a text editor likely couldn't handle lowercase in English, let alone any other Latin script language, let alone cjkv or bi-di. The bloat in software of 95 and the present day is real, but there is no real effort to make an apples to apples co…

http://www.texteditors.org/cgi-bin/wiki.pl?TinyEditors A lot of these are less than 8K, none of them can't handle lowercase, and I bet the majority of them will be fine with "high CP437" bytes (so other Latin languages.)

Of course, but editors written in 1970 (25 years before the Worth quote in question) often couldn't handle lowercase (and neither could early versions of Pascal) often because platform support was limited or missing.

Much of the cability of a modern tiny editor comes from the environment in which it is running, we just expect more from an editor now, and the developer expects more from their operating system.

Post reply on HN