Niklaus Wirth has died • Hacker News Board

Re: Niklaus Wirth has died

#251

Post by versteegen » Thu, Jan 04, 2024, 2:15 AM UTC

scubbo wrote: post #212

kragen wrote: post #104

Earlier quoted context omitted.

async/await has the advantage over cooperative multitasking that it has subroutines of different 'colors', so you don't accidentally introduce concurrency bugs by calling a function that can yield without knowing that it can yield i think it's safe to say that the number of personal computers running operating systems without preemptive multitasking is now vanishingly small as i remember it, oberon didn't support eit…

(To set the tone clearly - this seems like an area where you know a _lot_ more than me, so any questions or "challenges" below should be considered as "I am probably misunderstanding this thing - if you have the time and inclination, I'd really appreciate an explanation of what I'm missing" rather than "you are wrong and I am right") I don't know if you're intentionally using "colour" to reference https://journal.stu…

> I ask because I've found `async/await` to just be an irritating overhead

Then what you want are coroutines[1], which are strictly more flexible than async/await. Languages like Lua and Squirrel have coroutines. I and plenty of other people thing it's tragic that Python and Javascripts added async/await instead, but I assume the reason wasn't to make them easier to reason about, but rather to make them easier to implement without hacks in existing language interpreters not designed around them. Though Stackless Python is a CPython fork that adds real coroutines, also available as the greenlet module in standard CPython [2], amazing that it works.

[1] Real coroutines, not what Python calls "coroutines with async syntax". See also nearby comment about coroutines vs coop multitasking https://news.ycombinator.com/item?id=38859828

[2] https://greenlet.readthedocs.io/en/latest/

Re: Niklaus Wirth has died

#252

Post by cmrdporcupine » Thu, Jan 04, 2024, 2:18 AM UTC

Still remember at 14 scrounging $$ together to buy a 2nd hand copy of a Modula-2 compiler for my Atari ST and then eagerly combing through the manual as my parents drove me home from the city. Really was a different era. Like a lot of other people who have posted here who probably came of age like me in the 80s, I went from BASIC to Pascal to Modula-2 and only picked up C later. Wirth's creations were so much a part of how I ended up in this industry. The world of software really owes him a lot.

Re: Niklaus Wirth has died

#253

Post by svat » Thu, Jan 04, 2024, 2:19 AM UTC

usr1106 wrote: post #241

kragen wrote: post #2

begin this is terrible news; is there a better source than twitter (edit: https://lists.inf.ethz.ch/pipermail/oberon/2024/016856.html thanks to johndoe0815); wirth was the greatest remaining apostle of simplicity, correctness, and software built for humans to understand; now only hoare and moore remain, and moore seems to have given the reins at greenarrays to a younger generation; young people may not be aware of th…

> tex is written in pascal; Just thought about that when Donald Knuth's Christmas lecture https://www.youtube.com/live/622iPkJfYrI lead me to one of his first TeX lectures https://youtu.be/jbrMBOF61e0 : If I install TeX on my Linux machine now, is that still compiled from the original Pascal source? Is there even a maintained Pascal compiler anymore? Well, GCC (as in GNU compiler collection) probably has a frontend,…

> If I install TeX on my Linux machine now, is that still compiled from the original Pascal source?

If you install TeX via the usual ways–TeX Live and MikTeX are the most common—then the build step runs a program (like web2c) to convert the Pascal source (with changes) to C, then uses a C compiler. (So the Pascal source is still used, but the Pascal "compiler" is a specialized Pascal-to-C translator.) But there is also TeX-FPC (https://ctan.org/pkg/tex-fpc), a small set of change (patch) files to make TeX compilable with the Free Pascal compiler (https://gitlab.com/freepascal.org/fpc/).

For more details see https://tex.stackexchange.com/questions/111332/how-to-compil...

Re: Niklaus Wirth has died

#254

Post by kragen » Thu, Jan 04, 2024, 2:34 AM UTC

protomolecule wrote: post #202

kragen wrote: post #138

Earlier quoted context omitted.

thanks! i like lua a lot despite its flaws; that's what i wrote my own literate programming system in. lua's 'bytecode' is actually a wordcode (a compilation approach which i think wirth's euler paper was perhaps the first published example of) and quite similar in some ways to wirth's risc-1/2/3/4/5 hardware architecture family i hope they do go to open access; these papers are too valuable to be lost to future acm…

What are the lua's flaws in your opinion? Sincere question.

there are a lot of design decisions that are pretty debatable, but the ones that seem clearly wrong to me are:

- indexing from 1 instead of 0;

- the absence of a nilness/nonexistence distinction (so misspelling a variable or .property silently gives the wrong answer instead of an exception);

- variables being global by default, rather than local by default or requiring an explicit declaration;

- printing tables by default (with %q for example) as identities rather than contents. (you could argue that this is a simplicity thing; lua 5.2 is under 15000 lines of code, which is pretty small for such a full-featured language, barely bigger than original-awk at 6200 lines of c and yacc plus 1500 lines of awk, and smaller than mawk at 16000 lines of c, 1100 lines of yacc, and 700 lines of awk. but a recursive table print function with a depth limit is about 25 lines of code.)

none of these are fatal flaws, but with the benefit of experience they all seem like clear mistakes

Re: Niklaus Wirth has died

#255

Post by kragen » Thu, Jan 04, 2024, 2:35 AM UTC

bumbledraven wrote: post #199

kragen wrote: post #2

begin this is terrible news; is there a better source than twitter (edit: https://lists.inf.ethz.ch/pipermail/oberon/2024/016856.html thanks to johndoe0815); wirth was the greatest remaining apostle of simplicity, correctness, and software built for humans to understand; now only hoare and moore remain, and moore seems to have given the reins at greenarrays to a younger generation; young people may not be aware of th…

> wirth was the greatest remaining apostle of simplicity, correctness, and software built for humans to understand; now only hoare and moore remain… No. There is another. https://en.m.wikipedia.org/wiki/Arthur_Whitney_%28computer_s...

well, simplicity anyway, arguably (like moore) to an even higher degree than wirth

Re: Niklaus Wirth has died

#256

Post by kragen » Thu, Jan 04, 2024, 2:49 AM UTC

vidarh wrote: post #231

bumbledraven wrote: post #225

Earlier quoted context omitted.

The point of Whitney's array languages is to allow your solutions to be so small that they fit in your head. Key chunks should even fit on one screen. A few years ago, Whitney reportedly started building an OS using these ideas ( https://aplwiki.com/wiki/KOS ).

I'm aware of the idea. I'm also aware that I can read and understand a whole lot of pages of code in the amount of time it takes me to decipher a few lines of K for example, and the less dense codes sticks far better in my head. I appreciate brevity, but I feel there's a fundamental disconnect between people who want to carefully read code symbol by symbol, who often seem to love languages like J or K, or at least he…

i keep hoping that one day i'll understand j or k well enough that it won't take me hours to decipher a few lines of it; but today i am less optimistic about this, because earlier tonight, i had a hard time figuring out what these array-oriented lines of code did in order to explain them to someone else

    textb = 'What hath the Flying Spaghetti Monster wrought?'
    bits = (right_shift.outer(array([ord(c) for c in textb]),
                              arange(8))).ravel() & 1

and i wrote them myself three months ago, with reasonably descriptive variable names, in a language i know well, with a library i've been using in some form for over 20 years, and their output was displayed immediately below, in https://nbviewer.org/url/canonical.org/~kragen/sw/dev3/rando...

i had every advantage you could conceivably have! but i still guessed wrong at first and had to correct myself after several seconds of examination

i suspect that in j or k this would be something like (,(@textb)*.$i.8)&1 though i don't know the actual symbols. perhaps that additional brevity would have helped. but i suspect that, if anything, it would have made it worse

by contrast, i suspect that i would have not had the same trouble with this

    bits = [(ord(c) >> i) & 1 for c in textb for i in range(8)]

however, as with rpn, i suspect that j or k syntax is superior for typing when what you're immediately evaluating expressions rather than writing a program to maintain later, because the amount of finger typing is so much less. but maybe i just have a hard time with point-free style? or maybe, like you say, it's different types of people. or maybe i just haven't spent nearly enough time writing array code during those years

Re: Niklaus Wirth has died

#257

Post by kragen » Thu, Jan 04, 2024, 2:56 AM UTC

Someone wrote: post #226

thesz wrote: post #157

Earlier quoted context omitted.

You cannot add a loop skew optimization to compiler before compiler needs a loop skew optimization. Which it would not need at all because it is loop skew optimization (it requires matrix operations) that need a loop skew optimization. In short, compiler is not an ideal representation of the user programs it needs to optimize.

Wirth ran an OS research lab. For that, the compiler likely is a fairly typical workload. But yes, it wouldn’t work well in a general context. For example, auto-vectorization likely doesn’t speed up a compiler much at all, while adding the code to detect where it’s possible will slow it down. So, that feature never can be added. On the other hand, may lead to better designs. If, instead, you add language features tha…

perhaps you could write the compiler using the data structures used by co-dfns (which i still don't understand) so that vectorization would speed it up, auto- or otherwise

Re: Niklaus Wirth has died

#258

Post by kragen » Thu, Jan 04, 2024, 2:59 AM UTC

jerf wrote: post #140

frognumber wrote: post #100

Earlier quoted context omitted.

Supported cooperative multitasking won in the end. It just renamed itself to asynchronous programing. That's quite literally what an 'await' is.

It hasn't won. Threads are alive and well and I rather expect async has probably already peaked and is back on track to be a niche that stays with us forever, but a niche nevertheless. Your opinion vs. my opinion, obviously. But the user reports of the experience in Rust is hardly even close to unanimous praise and I still say it's a mistake to sit down with an empty Rust program and immediately reach for "async" wit…

in the 02000s there was a lot of interest in software transactional memory as a programming interface that gives you the latency and throughput of preemptive multithreading with locks but the convenient programming interface of cooperative multitasking; in haskell it's still supported and performs well, but it has been largely abandoned in contexts like c#, because it kind of wants to own the whole world. it's difficult to add incrementally to a threads-and-locks program

i suspect that this will end up being the paradigm that wins out, even though it isn't popular today

Re: Niklaus Wirth has died

#259

Post by kristianp » Thu, Jan 04, 2024, 3:09 AM UTC

cscheid wrote: post #89

lukego wrote: post #31

Besides all his innumerable accomplishments he was also a hero to Joe Armstrong and a big influence on his brand of simplicity. Joe would often quote Wirth as saying that yes, overlapping windows might be better than tiled ones, but not better enough to justify their cost in implementation complexity. RIP. He is also a hero for me for his 80th birthday symposium at ETH where he showed off his new port of Oberon to a…

> not _better enough_ Wirth was such a legend on this particular aspect. His stance on compiler optimizations is another example: only add optimization passes if they improve the compiler's self-compilation time. Oberon also, (and also deliberately) only supported cooperative multitasking.

In the past, this policy of Wirth's has been cited when talking about go compiler development.

Go team member, Robert Griesemer, did his Phd under Mössenböck and Wirth.

Re: Niklaus Wirth has died

#260

Post by ryukoposting » Thu, Jan 04, 2024, 3:11 AM UTC

kragen wrote: post #136

rollcat wrote: post #128

Earlier quoted context omitted.

> wirth was the greatest remaining apostle of simplicity, correctness, and software built for humans to understand; And yet far from the last. Simple, correct, and beautiful software is still being made today. Most of it goes unnoticed, its quiet song drowned out by the cacophony of attention-seeking, complex, brittle behemoths that top the charts. That song never faded, you just need to tune in.

who are today's new great minimalists?

I use Suckless's terminal, st. It's great. To install it, I compile it from source. It takes a couple seconds. Take a look at their work.