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

151–160 of 198 posts

Re: Niklaus Wirth was right and that is a problem

#151

Post by pmoriarty »

LeftHandPath wrote: post #48
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…

There's another type of consumer-facing computing where performance matters: embedded computing on small, weak devices.

These are also very cheap devices, but they rarely have the resources to run something as bloated as an Electron app.

Re: Niklaus Wirth was right and that is a problem

#152

Post by pacaro »

joe_the_user wrote: post #71
pacaro wrote: 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 c…

Thought provoking questions for sure!

Some of the improvements are marginal, but not all, from a developer perspective moving between editors that support everything from syntax highlighting, intellisense, refactoring etc, to then using an editor that has none of that is quite a shock.

Re: Niklaus Wirth was right and that is a problem

#153

Post by pacaro »

IncRnd wrote: post #87
pacaro wrote: 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…

That text editor seems to have been enough for Wirth to create the Pascal and Oberon languages. VI came out in 1976. Even today, lots of people use VI or some derivative of it.

Even then a text editor isn't necessarily a necessity, I've been reading a lot of IBM 1130 code, (for example Guy Steele's LISP, and Chuck Moore's Forth)

There was no text editor. The code for these was entered on punched cards or tape. Somebody typed those cards from sources on paper, maybe on a bunch of K26-5994 forms

Re: Niklaus Wirth was right and that is a problem

#154

Post by m463 »

LeftHandPath wrote: post #48
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…

> It seems there are two distinct branches of computing emerging - one where performance matters, and one where it doesn't.

The thing is - there is no need to address performance if it does not matter. That would lead you to Knuth:

"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." - Knuth

So I think there is actually a dial: if performance matters you turn it one way and optimize as necessary; if it doesn't go onto the next project that is fighting to get out of your head.

Re: Niklaus Wirth was right and that is a problem

#155

Post by rocqua »

zokula wrote: post #144
cable2600 wrote: post #125

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.

they optimized for current hardware, sacrificing some performance on outdated hardware.

I'd rather windows uses my SSD to the fullest, than that it makes concessions to spinning disks.

Re: Niklaus Wirth was right and that is a problem

#156

Post by [deleted] »

nicoburns wrote: post #133
userbinator wrote: post #115

Earlier quoted context omitted.

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.

[deleted]

Re: Niklaus Wirth was right and that is a problem

#157

Post by m463 »

jesstaa wrote: post #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…

I think we should continually fold new libraries into the language. Basically "batteries included", collapse the dependency tree.

I found that the standard python library has enormous functionality that makes it possible to solve many problems in a self-contained fashion.

This sort of solution will give you a big toolbox spread out in front of you. You will be less likely to re-invent the wheel. Many eyes on the standard library may lead to optimizations used by everyone.

And it makes it possible to share effectively. You can talk about functions with others using common terms. You can share your code and it will work in other environments. Education can teach in an unambiguous fashion.

Re: Niklaus Wirth was right and that is a problem

#158

Post by fsh »

nicoburns wrote: post #133
userbinator wrote: post #115

Earlier quoted context omitted.

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.

Unless of course the developer uses yarn or whatever npm alternative is popular this week. The last time I tried building an electron app, it just spit pages of dependency errors at me and I gave up.

Re: Niklaus Wirth was right and that is a problem

#159

Post by soulofmischief »

cable2600 wrote: post #146
zokula wrote: post #144

Earlier quoted context omitted.

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.

You are completely missing their point. "For newer hardware" means slower. I remember how Windows 7 was so well-designed that it actually ran faster on my all of my old XP machines than XP did. It was a step up in performance, not a step down.

In 2018 Microsoft disbanded the Windows team and moved engineering efforts to its cloud and AI teams. Windows 10 is on life support by engineers who aren't intimately familiar with its codebase. Performance and usability will only degrade in this situation and the specifications of newer hardware don't excuse constant deterioration in performance.

Re: Niklaus Wirth was right and that is a problem

#160

Post by chridou »

m463 wrote: post #154
LeftHandPath wrote: post #48

Earlier quoted context omitted.

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…

> It seems there are two distinct branches of computing emerging - one where performance matters, and one where it doesn't. The thing is - there is no need to address performance if it does not matter. That would lead you to Knuth: "The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or…

Please do not take this (Knuths statement) out of context. It is necessary read the whole text to understand this sentence. It has nothing to do with whether performance matters.
Post reply on HN