Niklaus Wirth was right and that is a problem • Hacker News Board

Re: Niklaus Wirth was right and that is a problem

#131

Post by zozbot234 » Sat, Aug 01, 2020, 4:19 AM UTC

thelazydogsback wrote: post #25

Someone wrote: post #10

Earlier quoted context omitted.

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.

> so I'm not sure why we need to double the working-set size of all pointer-based data-structures.

If your data structures can fit in a 32-bit address space, you can just place them in an arena w/ 32-bit indexes. You do need to use a custom allocator for every element of that data structure, but other than that it ought to be feasible. Link/pointer-based data structures should be used with caution anyway, due to their poor cache performance

Re: Niklaus Wirth was right and that is a problem

#132

Post by known » Sat, Aug 01, 2020, 4:33 AM UTC

Reminds me http://www.kegel.com/c10k.html

Re: Niklaus Wirth was right and that is a problem

#133

Post by nicoburns » Sat, Aug 01, 2020, 4:47 AM UTC

userbinator wrote: post #115

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…

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. The point is that a dependency is a dependency, and making software needlessly complex in any way is bad. I've run into this a lot with open source stuff (not even JavaScript, just native code): I want to fix/modify something,…

"Effort to set up a build environment" is pretty much exclusively a problem with C and C++ code. Pretty much every other language has standard build tooling. e.g. with JavaScript you can 'npm install' and you're set.

Re: Niklaus Wirth was right and that is a problem

#134

Post by kqr » Sat, Aug 01, 2020, 4:48 AM UTC

sitkack wrote: post #57

danny_sf45 wrote: post #55

Earlier quoted context omitted.

Sure there are two types (or more?) of dependencies, but at the end of the day the AppSignal app requires those +13,000 dependencies in order to work properly (first to build it, and then to run it). That's horrendous.

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

Re: Niklaus Wirth was right and that is a problem

#135

Post by agumonkey » Sat, Aug 01, 2020, 5:03 AM UTC

alexisread wrote: post #19

agumonkey wrote: post #12

And the trend is not slowing. That said some people like low fat computing. Another thing.. computing is over. At least in the previous era form. It's not bringing dreams anymore, will probably turn into an ubiquitous invisible form where intrinsic details such as resource usage won't matter.

I think you might be a little pessimistic here - IOT has a wealth of fruit to bear, from: low power always-on devices with long range radio (LoRa), few resources (32k ram), the security constraints of securing every device, dealing with terabytes of log data in the cloud, ML at the edge (Kendryte K210), open-source firmware including radio (DASH7 firmware), open-source hardware (and open-source FPGA tooling) to creat…

I'm a bit jaded and at the same time not much.

These are all very advanced low level technology subjects (some of which I like a lot btw).

What Wirth said only concerns a few grams of people on earth, the rest will stop using computers just like they stopped using desktops and just stream/talk on smartphones. If you ask most users they'll probably root for whatever electron app they use compared to frugal but powerful programs. For the layman computing will fade and become like roads. And I believe they never really needed nor liked computers, it just was a 20 year period where it was thought to be a technological wonder to have in your home.

Re: Niklaus Wirth was right and that is a problem

#136

Post by agumonkey » Sat, Aug 01, 2020, 5:05 AM UTC

vvanders wrote: post #100

abraxas wrote: post #24

Earlier quoted context omitted.

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.

Was it this one(30 minutes in)? https://channel9.msdn.com/Events/Build/2014/2-661 Probably one of my all time favorite performance talks.

First half doesn't ring a bell, but cache talk and object sea vs contiguous was part of what I remember

Re: Niklaus Wirth was right and that is a problem

#137

Post by agumonkey » Sat, Aug 01, 2020, 5:08 AM UTC

pcstl wrote: post #29

agumonkey wrote: post #14

Earlier quoted context omitted.

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.

maybe this one https://www.youtube.com/watch?v=L7zSU9HI-6I .. damn memory (sic)

Re: Niklaus Wirth was right and that is a problem

#138

Post by jashmatthews » Sat, Aug 01, 2020, 5:13 AM UTC

vl wrote: post #82

ThrowawayR2 wrote: post #61

Earlier quoted context omitted.

> " It seems there are two distinct branches of computing emerging - one where performance matters, and one where it doesn't. " The unfortunate corollary being that the prevalence of developers who treat it as if it doesn't makes it darned hard to find one who treats as if it does when you need one. > " Applications made for "consumers" tend to be made like a cheap car " Not really a great analogy. The Prius has a re…

The main reason Priuses are used as cabs are local regulations, i.e. airports not allowing non-hybrid cabs, etc. For passengers experience is sub-standard compared to regular cabs.

What’s substandard about a Prius? They’re fantastic cars.

Re: Niklaus Wirth was right and that is a problem

#139

Post by hota_mazi » Sat, Aug 01, 2020, 5:13 AM UTC

> 1995 was the year in which programmers stopped thinking about the quality of their programs.

-yawn-

Prove it.

The number of books and articles about the quality of software engineering published in the past 25 years certainly seems to prove we care a great deal about code quality. Probably more than we ever did prior to 1995 when Pascal, BASIC, FORTAN, COBOL, and self-modifying assembly code were being taught in colleges.

As for the point of the article, that hardware doesn't accelerate as fast as programs using it, same challenge: prove it.

This article is all handwaving and speculation with no data to support any of its claims.

Re: Niklaus Wirth was right and that is a problem

#140

Post by jb_gericke » Sat, Aug 01, 2020, 5:15 AM UTC

The central conceit being we are all doomed as software becomes more bloated and less efficient while processing power remains at it's current levels?

While Moore's law may be over in terms of number of transistors per chip, we are still seeing growth in the number of cores per CPU, not to mention faster memory and the death of spindle storage.

ImO software will start leaning more heavily towards parallelesim (if it hasn't already, building a threaded or asynchronous application is no longer an arcane dark art). Couple that with the surge in adoption of distributed architecture (yes microservices), and the emergence of languages which encourage pragmatism and efficiency (ala Go and Rust) and I think we'll be okay for the next while. Can't speak to electron though (gross).