Live data from Hacker News

Niklaus Wirth was right and that is a problem

bowero.nl

71–80 of 198 posts

Re: Niklaus Wirth was right and that is a problem

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

The main question is what should you do with all that application code space other than make the functionality of your core application richer? (adding Unicode is a perfect example - do that and for English language use, the app might seem identical but it's become much richer).

What use would one million, highly functional, stand-alone 8K programs be? What about a hundred thousand 80K programs?

I'd love wholly new categories of software to just pop up. I think about what those might be. But it seems like actually they appear quite seldom. So what else is there to do but throw code at what people use every day, for marginal improvements in existing functionality.

Re: Niklaus Wirth was right and that is a problem

#72

This article is the problem. It's the same freaking fallacy I see again and again on here - It's simple, easy to understand, and dead fucking wrong. The vast majority of the complexity you're dealing with in modern computing comes from three sources. In the order of impact 1. Networking. It turns out there are real and hard limits on how fast we can pass data around over copper wires. Fiber is better, but you just li…

The speed of a signal in wire or fiber is largely irrelevant. Most of your latency is taken going up and down your ginormous software stack. Take a look at what is required for wire-speed processing.

Security is improved by reducing the number of disparate components.

Re: Niklaus Wirth was right and that is a problem

#73
post #69
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…

"allowing more inexperienced and unskilled programmers to create programs" You realize that this is a good thing, right?

Until you ask those inexperienced and unskilled people to do something important.

Re: Niklaus Wirth was right and that is a problem

#74
"Languages like these made programming a lot easier and took many things out of the programmer’s hands. They were object-oriented and came with things as an IDE and garbage collection.

This meant that programmers had fewer things to worry about"

Yeah, right. Those lazy programmers.

It's obviously become easier to build complex software, but software is now required to be much more complex. There are still many things to worry about (actually far more than previously, I'd say), but they're not the same things.

Re: Niklaus Wirth was right and that is a problem

#75
post #46

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-mar…

Multiply that 500ms and 200mb by more than a few thousand users and you are talking about real time and money.

Everything seems to have been optimized for the enterprise market.

Re: Niklaus Wirth was right and that is a problem

#76

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…

So, having multiple tools with more capabilities makes up for being worse at a given task?

Re: Niklaus Wirth was right and that is a problem

#77
> About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage.

That would be in 1970, but my guess is that "ed" would be a hard sell today.

There is plenty of bloat to go around these days and I think we could do a lot more to address that. But we've all got too much skin in the web game to own up to the embarrassing fact that a chat program that's basically IRC with pictures feels like glue on a 2.4 GHz, multi-core CPU.

With that out of the way, we shouldn't get silly, either. Every actually useful feature added will increase complexity and resource usage. I like split-window, code-folding, auto-indented, word-completing, syntax highlighted multiple document editing more than I like saving a few fractions of a percent of my hard drive space.

Re: Niklaus Wirth was right and that is a problem

#78
post #75
post #46

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-mar…

Multiply that 500ms and 200mb by more than a few thousand users and you are talking about real time and money. Everything seems to have been optimized for the enterprise market.

That's why I've mentioned time to market. Take GitHub as an example: It's neither the fastest/most lightweight git hosting page (that would probably be Gogs/Gitea) nor the most feature-rich (GitLab is far more advanced, as far as I can tell). They are where they are because they've made a viable product first. Same with slack: Electron is not a good solution, but it was a desktop app in 5 minutes - can't beat that.

I'm not trying to say performance doesn't matter - I'm using lower-powered devices myself - but development time is also a big factor for b2c.

Re: Niklaus Wirth was right and that is a problem

#79
post #44

Earlier quoted context omitted.

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 properl…

What does google's datacenter for a book index have to do with editing a file or rendering a button? That doesn't seem relevant at all to Wirth's law and isn't an justification for the increase in abstraction that has made things slower.

Re: Niklaus Wirth was right and that is a problem

#80

This article is the problem. It's the same freaking fallacy I see again and again on here - It's simple, easy to understand, and dead fucking wrong. The vast majority of the complexity you're dealing with in modern computing comes from three sources. In the order of impact 1. Networking. It turns out there are real and hard limits on how fast we can pass data around over copper wires. Fiber is better, but you just li…

Networking isn't the bottleneck. As John Carmack quipped, "I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?"

Usually if there is latency caused by networking in an application it's usually unneeded roundtrips caused by inefficient programmers or inefficient layers in the software stack.

It's insane how much overhead there is.

Post reply on HN