Niklaus Wirth has died • Hacker News Board

Re: Niklaus Wirth has died

#271

Post by senderista » Thu, Jan 04, 2024, 4:37 AM UTC

kragen wrote: post #258

jerf wrote: post #140

Earlier quoted context omitted.

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 diffic…

I was considering making a startup out of my simple C++ STM[0], but the fact that, as you point out, the transactional paradigm is viral and can't be added incrementally to existing lock-based programs was enough to dissuade me.

[0] https://senderista.github.io/atomik-website/

Re: Niklaus Wirth has died

#272

Post by kragen » Thu, Jan 04, 2024, 4:48 AM UTC

senderista wrote: post #271

kragen wrote: post #258

Earlier quoted context omitted.

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 diffic…

I was considering making a startup out of my simple C++ STM[0], but the fact that, as you point out, the transactional paradigm is viral and can't be added incrementally to existing lock-based programs was enough to dissuade me. [0] https://senderista.github.io/atomik-website/

nice! when was this? what systems did you build in it? what implementation did you use? i've been trying to understand fraser's work so i can apply it to a small embedded system, where existing lock-based programs aren't a consideration

Re: Niklaus Wirth has died

#273

Post by senderista » Thu, Jan 04, 2024, 5:00 AM UTC

kragen wrote: post #272

senderista wrote: post #271

Earlier quoted context omitted.

I was considering making a startup out of my simple C++ STM[0], but the fact that, as you point out, the transactional paradigm is viral and can't be added incrementally to existing lock-based programs was enough to dissuade me. [0] https://senderista.github.io/atomik-website/

nice! when was this? what systems did you build in it? what implementation did you use? i've been trying to understand fraser's work so i can apply it to a small embedded system, where existing lock-based programs aren't a consideration

It grew out of an in-memory MVCC DB I was building at my previous job. After the company folded I worked on it on my own time for a couple months, implementing some perf ideas I had never had time to work on, and when update transactions were <1us latency I realized it was fast enough to be an STM. I haven't finished implementing the STM API described on the site, though, so it's not available for download at this point. I'm not sure when I'll have time to work on it again, since I ran out of savings and am going back to full-time employment. Hopefully I'll have enough savings in a year or two that I can take some time off again to work on it.

Re: Niklaus Wirth has died

#274

Post by kragen » Thu, Jan 04, 2024, 5:03 AM UTC

senderista wrote: post #273

kragen wrote: post #272

Earlier quoted context omitted.

nice! when was this? what systems did you build in it? what implementation did you use? i've been trying to understand fraser's work so i can apply it to a small embedded system, where existing lock-based programs aren't a consideration

It grew out of an in-memory MVCC DB I was building at my previous job. After the company folded I worked on it on my own time for a couple months, implementing some perf ideas I had never had time to work on, and when update transactions were <1us latency I realized it was fast enough to be an STM. I haven't finished implementing the STM API described on the site, though, so it's not available for download at this po…

that's exciting! i just learned about hitchhiker trees (and fractal tree indexes, blsm trees, buffer trees, etc.) this weekend, and i'm really excited about the possibility of using them for mvcc. i have no idea how i didn't find out about them 15 years ago!

Re: Niklaus Wirth has died

#275

Post by StillBored » Thu, Jan 04, 2024, 5:37 AM UTC

RIP, and thanks for helping indirectly to put me on my career path.

I learned pascal fairly late in the grand scheme of things (basic->6502 assembly->C and then eventually pascal) but it was used for the vast majority of my formal CS education first by instruction, then by choice, and eventually in my first real programming job. The later pascal dialects remain IMHO far better than any other languages I write/maintain/guide others in using. Like many others of his stature it was just one of his many hits. Niklaus Wirth is one of the giants I feel the industry stands on, and I thank him for that.

"All those moments will be lost in time, like tears in rain..."

Re: Niklaus Wirth has died

#276

Post by samus » Thu, Jan 04, 2024, 5:39 AM UTC

amelius wrote: post #116

superluserdo wrote: post #102

Earlier quoted context omitted.

>His stance on compiler optimizations is another example: only add optimization passes if they improve the compiler's self-compilation time. What an elegant metric! Condensing a multivariate optimisation between compiler execution speed and compiler codebase complexity into a single self-contained meta-metric is (aptly) pleasingly simple. I'd be interested to know how the self-build times of other compilers have chan…

Hmm, but what if the compiler doesn't use the optimized constructs, e.g. floating point optimizations targeting numerical algorithms?

Rewrite the compiler to use a LLM for complication. I'm only half joking! The biggest remaining technical problem is the context length, which is severely limiting the input size right now. Also, the required humongous model size.

Re: Niklaus Wirth has died

#277

Post by jibal » Thu, Jan 04, 2024, 5:48 AM UTC

kragen wrote: post #246

amatecha wrote: post #210

Earlier quoted context omitted.

you don't get to dictate who does or doesn't get recognized for creating awesome works that influence and inspire others. take your persistent negativity elsewhere. btw, uxn is absolutely the exemplification of "software built for humans to understand" and simplicity. I mean... > the resulting programs are succinct and translate well to pen & paper computing. > to make any one program available on a new platform, the…

i don't think uxn is trivial, i think it's a first step toward something great. it definitely isn't the exemplification of "software built for humans to understand"; you have to program it in assembly language, and a stack-based assembly language at that. in that sense it's closer to brainfuck than to hypertalk or excel or oberon. it falls short of its goal of working well on small computers (say, under a megabyte of…

Yeah, these younguns have a lot to learn. :-) The notion that there's something innovative about using a small VM to port software is hilarious. BTW, here is a quite impressive and effective use of that methodology: https://ziglang.org/news/goodbye-cpp/

Dewey Schorre and Meta II, eh? Who remembers such things? Well, I do, as I was involved with an implementation of Meta V when I was on the staff of the UCLA Comp Sci dept in 1969.

Re: Niklaus Wirth has died

#278

Post by samus » Thu, Jan 04, 2024, 5:57 AM UTC

hathawsh wrote: post #236

jerf wrote: post #140

Earlier quoted context omitted.

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…

Meanwhile, in JS/ECMAScript land, async/await is used everywhere and it simplifies a lot of things. I've also used the construct in Rust, where I found it difficult to get the type signatures right, but in at least one other language, async/await is quite helpful.

Await is simply syntactic sugar on top of what everybody was forced to do already (callbacks and promises) for concurrency. As a programming model, threads simply never had a chance in the JS ecosystem because on the surface it has always been a single-threaded environment. There's too much code that would be impossible to port to a multithreaded world.

Re: Niklaus Wirth has died

#279

Post by kragen » Thu, Jan 04, 2024, 5:58 AM UTC

jibal wrote: post #277

kragen wrote: post #246

Earlier quoted context omitted.

i don't think uxn is trivial, i think it's a first step toward something great. it definitely isn't the exemplification of "software built for humans to understand"; you have to program it in assembly language, and a stack-based assembly language at that. in that sense it's closer to brainfuck than to hypertalk or excel or oberon. it falls short of its goal of working well on small computers (say, under a megabyte of…

Yeah, these younguns have a lot to learn. :-) The notion that there's something innovative about using a small VM to port software is hilarious. BTW, here is a quite impressive and effective use of that methodology: https://ziglang.org/news/goodbye-cpp/ Dewey Schorre and Meta II, eh? Who remembers such things? Well, I do, as I was involved with an implementation of Meta V when I was on the staff of the UCLA Comp Sci…

nice! which direction did meta-v go meta in?

i recently reimplemented meta-ii myself with some tweaks, http://canonical.org/~kragen/sw/dev3/meta5ixrun.py

i guess i should write it up

Re: Niklaus Wirth has died

#280

Post by pjmlp » Thu, Jan 04, 2024, 6:12 AM UTC

musicale wrote: post #232

bsimpson wrote: post #93

Earlier quoted context omitted.

For those who don't know, Pascal was what a lot of the classic Mac software was written in, before Objective-C and Swift. It grew into Delphi, which was a popular low-code option on Windows.

It's a shame that Pascal was largely abandoned (except for Delphi, which lived on for a while); I believe several Pascal compilers supported array bounds checking, and strings with a length field. In the 1980s this may have been considered overly costly (and perhaps it is considered so today as well), but the alternative that the computing field and industry picked was C, where unbounded arrays and strings were a com…

Delphi still lives on, to the extent that there is enough people to sell conference tickets in Germany, and a new release came out last month.