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

Re: Niklaus Wirth was right and that is a problem

#111

Post by voldacar » Sat, Aug 01, 2020, 3:05 AM UTC

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…

Good post. I would add that since Moore's law is over, I think the long-term prospects for crap like electron and discord are not good. Future phones and laptops will (almost certainly) never be orders of magnitude more powerful for regular workloads, so assuming that people will want to do more and more with these devices, it seems that software that burns millions of cpu cycles and gigabytes of ram just to put some pixels on the screen and send some http packets will eventually get squeezed out of the marketplace.

Re: Niklaus Wirth was right and that is a problem

#112

Post by baryphonic » Sat, Aug 01, 2020, 3:07 AM UTC

Sebb767 wrote: post #39

baryphonic wrote: post #36

Earlier quoted context omitted.

> 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. This isn't a compatibility issue? We've seen about 8-16 branches of the write-once, run-everywhere tree over the past 25 years, I'm not sure how that isn't seen as a constraint on programmers. JWT, Swing, Web, Cordova,…

> JWT, Swing, Web, Cordova, React/ Native, Xamarin, Electron, Flutter and even quirky ones like Toga have all attempted to solve this problem, and ... and for the most part they have. You can write your app right now and the only thing you need to worry about is screen size. If you use bootstrap, even this is mostly solved. Your app is accessible on Windows, Linux and Mac; Chromebooks and Tablets; iPhones, Android an…

I basically agree, with the caveat that I'd still prefer a world where our write-once-run-everywhere lowest common denominator at least required native widgets and an ability to integrate new platform-specific capabilities at the expense of writing a small amount of native code, rather than barfing up web UI/UX at users (e.g. the execrable MS Teams).

Re: Niklaus Wirth was right and that is a problem

#113

Post by userbinator » Sat, Aug 01, 2020, 3:07 AM UTC

greggman3 wrote: post #94

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

That text editor quote really bugs me. Sure my Atari 800 had a word processor that came on a 8k cartridge. I couldn't type Chinese, Japanese, Korean, Russian, Arabic into. I could only type ASCII. Just the ability to do that alone would likely entail many many megabytes of code. For one, there is no text based system like those old machines that handles all that so I have to switch to graphics. Just the font alone fo…

Just the ability to do that alone would likely entail many many megabytes of code.

Just the font alone for all of those languages will be multi-mega bytes and I'll need multi-megabytes more for space to rasterize some portion of those fonts.

Then for each language I'll need multi-megabytes for handling the input methods.

Those statements clearly show your lack of awareness of what things were really like 40 years ago. They had CJK input and output(https://en.wikipedia.org/wiki/Cangjie_input_method was invented in 1976, for example) on the systems of the time, and that certainly did not entail "megabytes of code".

What it did entail, however, was a certain amount of skill, creativity, and an appreciation for efficiency and detail that lead to being able to do it with the hardware of the time, skills which are unfortunately a rarity today. Instead, we are drowning in a sea of programmers who think the simplest of tasks somehow requires orders of magnitude more resources than were available decades ago, when the reality is that there existed software at the time able to do those tasks perfectly well and at a decent speed.

The point being that we need the complexity.

The point is precisely that we don't.

Re: Niklaus Wirth was right and that is a problem

#114

Post by basementcat » Sat, Aug 01, 2020, 3:16 AM UTC

wldcordeiro wrote: post #26

Ah yes let's pine for the days when ~men were men~programmers were programmers and we coded real quality, unlike this current trend...

...and furry little creatures from Alpha Centauri were real furry little creatures from Alpha Centauri.

Re: Niklaus Wirth was right and that is a problem

#115

Post by userbinator » Sat, Aug 01, 2020, 3:22 AM UTC

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, and I know it's open-source, so it should be easy, right? After looking at the sprawling dependency tree, and the effort it would take to set up a build environment --- which might not even give me the same output as the original binaries, which are working perfectly fine except for the part I want to change --- I decide I'll just find the locations with a debugger and patch the binary directly.

tl;dr: the complaint is equally valid when applied to build tools, which are themselves also software and becoming bloated.

Re: Niklaus Wirth was right and that is a problem

#116

Post by xvilka » Sat, Aug 01, 2020, 3:23 AM UTC

Another solution would be to use the proper, statically and strictly typed programming languages with AOT compilation. Rust, Swift, Kotlin - these are the best of production-level languages that can produce both native code and WebAssembly. There are other, similar languages as well. They key point - when compiler knows more about your intentions (e.g. strict and sound type system) it can optimize it better. Especially with LTO or PGO.

Re: Niklaus Wirth was right and that is a problem

#117

Post by arexxbifs » Sat, Aug 01, 2020, 3:33 AM UTC

userbinator wrote: post #113

greggman3 wrote: post #94

Earlier quoted context omitted.

That text editor quote really bugs me. Sure my Atari 800 had a word processor that came on a 8k cartridge. I couldn't type Chinese, Japanese, Korean, Russian, Arabic into. I could only type ASCII. Just the ability to do that alone would likely entail many many megabytes of code. For one, there is no text based system like those old machines that handles all that so I have to switch to graphics. Just the font alone fo…

Just the ability to do that alone would likely entail many many megabytes of code. Just the font alone for all of those languages will be multi-mega bytes and I'll need multi-megabytes more for space to rasterize some portion of those fonts. Then for each language I'll need multi-megabytes for handling the input methods. Those statements clearly show your lack of awareness of what things were really like 40 years ago…

While parent's "many many megabytes" might be an overstatement, today's editors are expected to display any number of languages and alphabets simultaneously, using user-configurable, scalable, variable-width fonts that render in a variety of different resolutions with sub-pixel smoothing. Things like that add to the complexity of both the OS and the application itself.

Re: Niklaus Wirth was right and that is a problem

#118

Post by hnick » Sat, Aug 01, 2020, 3:35 AM UTC

badsectoracula wrote: post #35

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

None of the above require software to be as slow as it often is. Windows being able to run Win32 applications isn't what makes Windows Calc slow nor is anything else you mentioned - you do not need a supercomputer to download currency conversion rates (which, btw, is bloat by itself and could be handled by a dedicated program instead of being shoved into calc) and even the ability to download a CSV or whatever from a…

Calc is my favourite example too. Win+R+calc+enter and start typing, it used to work no matter how fast I was. Not anymore, I sit waiting at its convenience.

Android is pretty inconsistent too, the same series of steps are instant or hang the UI for 5 seconds depending on the current moon phase or something I haven't worked out yet.

Re: Niklaus Wirth was right and that is a problem

#119

Post by naikrovek » Sat, Aug 01, 2020, 3:36 AM UTC

markbnj wrote: post #106

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

Well if you have to pick a line, a point in time where the industry crossed a threshold, I'd say the author picked a good one.

There were people who didn't care about software quality in 1960 and there will be people who do in 2060, so no matter what year he chose, a lot of people would dismiss any chosen year as hyperbole.

As time moves forward, and more "healthy" ecosystems grow up around languages (like unwanted mold or fungus always does) software is going to get slower and slower and slower. And saying that it's a problem will always be an "old man is shouting nonsense again" moment to most young developers.

Re: Niklaus Wirth was right and that is a problem

#120

Post by xvilka » Sat, Aug 01, 2020, 3:51 AM UTC

black_puppydog wrote: post #43

UweSchmidt wrote: post #18

There are many complaints but there doesn't seem to be a real movement to make/use/cultivate small and fast software for all purposes. I'd join. Fragmented parts could be suckless.org, old cheap thinkpads from ebay, fast Linux distros, unix command line tools, retrocomputing, raspberry pi; all things with communities and fans who like a certain quality, simplicity and the good old days.

check out the suckless suite of software. it's neat :)

Suckless is neat, but it stuck in the past, in a way. Using modern programming languages and native frameworks is the way to go. But the philosophy is exactly what required.