Live data from Hacker News

Niklaus Wirth was right and that is a problem

bowero.nl

21–30 of 198 posts

Re: Niklaus Wirth was right and that is a problem

#21
Meh, I think this whole argument is wrong. Software "bloat" is fine.

I'm reminded of this [1] article comparing Bruguet and Carson numbers. You have ever cheaper hardware. The marginal utility of any given unit of new, equally serviceable computing power is going to be less than the previous one. So eventually if something can be 2% better/more functionality, etc. at 10x the bloat it is rational to accept that. When you have lots of something you become less efficient in how you use it. If you're surprised by that go and read economics.

[1] https://www.cringely.com/2011/05/19/google-at-carsons-speed/

Re: Niklaus Wirth was right and that is a problem

#22
I do see this as a gap/opportunity in a lot of existing markets. Huge players who dominate these areas are doing so with these giant, slow, unwieldy web apps. Look at how Figma managed to take over in the design market by creating a lighter/faster product than what everyone else was offering. I wholly endorse any other teams that want to use Wasm to kick stagnant old web apps off their thrones.

Re: Niklaus Wirth was right and that is a problem

#23
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 literally cannot move faster than light, and latency is a big deal when the items you're accessing and changing live somewhere else (and basically everything of value does live somewhere else, or thinks you are "somewhere else").

2. Security. This is a direct consequence of number 1. When everything is connected, everything is connected. You can't just lock the lab door and call it a day now.

3. Compatibility. This is a direct consequence of both 1 and 2. Value is a consequence of compatibility (this is why a good chunk of you on here still support IE, even though you don't want to). We have more devices, of more kinds than ever before. We have more people, with more use cases than ever before. There is value in being as compatible as possible with all those devices and people. All those devices are connected in ways designed to keep them compatible, but also secure. It turns out this is not an easy task.

If you'd like to go wank off over how fast your pre-network, unsecured, unsupported, inaccessible and manually configured systems are, be my guest (oh, and I hope you read english...). The rest of us will continue to produce items of value.

Re: Niklaus Wirth was right and that is a problem

#24
post #4

I 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) unti…

Herb Sutter had a wonderful talk on constant factor plague. As much as I like clojure and similar convenience and algorithmic beauty.. I can appreciate the devil-is-in-the-details much more since this video (forgot the title sorry)

Could you please dig it up? I'm not sure hot to find it based on what you posted and would love to watch it.

Re: Niklaus Wirth was right and that is a problem

#25
post #10

For 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. Eve…

The article clearly focuses size due to the use of libraries.

As for pointer size, personally I agree -- most processes can get by just fine with their own 32bit address space, so I'm not sure why we need to double the working-set size of all pointer-based data-structures.

Re: Niklaus Wirth was right and that is a problem

#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

Re: Niklaus Wirth was right and that is a problem

#28

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…

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 speed of light or compatibility. It's just the lack of constraints allowed by advances in computer hardware.

Most software is written with no performance considerations in mind at first and the performance issues are addressed only when they become visible. However, if there is abundant memory available, why bother?

Re: Niklaus Wirth was right and that is a problem

#29
post #4

I 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) unti…

Herb Sutter had a wonderful talk on constant factor plague. As much as I like clojure and similar convenience and algorithmic beauty.. I can appreciate the devil-is-in-the-details much more since this video (forgot the title sorry)

I went looking for the talk and all I could find was this paper: https://www.researchgate.net/publication/337590358_Inflation...

I'd like to watch the actual talk. Hope you could try remembering the name.

Re: Niklaus Wirth was right and that is a problem

#30

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…

Why does any of that require a slow, bloated UI? The UI is largely what people mean when they say software is slow and bloated.
Post reply on HN