Live data from Hacker News

Niklaus Wirth has died

twitter.com

291–300 of 412 posts

Re: Niklaus Wirth has died

#291
post #231

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 sometimes think it reflects a difference between people who prefer maths vs languages. I'm not suggesting one is better than the other, but I do believe the former is a smaller group than the latter.

This dichotomy exists in mathematics as well. Some mathematicians prefer to flood the page with symbols. Others prefer to use English words as much as possible and sprinkle equations here and there (on their own line) between paragraphs of text.

The worst are those that love symbols and paragraphs, writing these dense walls of symbols and text intermixed. I’ve had a few professors who write like that and it’s such a chore to parse through.

Re: Niklaus Wirth has died

#292

Earlier quoted context omitted.

And these fancy new names aren't there just for hiding the event loop? :)

Sort of and sort of not. The key thing about 2023-era asynchronous versus 1995-era cooperative multitasking is code readability and conciseness. Under the hood, I'm expressing the same thing, but Windows 3.1 code was not fun to write. Python / JavaScript, once you wrap your head around it, is. The new semantics are very readable, and rapidly improving too. The old ones were impossible to make readable. You could argu…

I never left 1991 and I haven't seen anything that has made me consider leaving ConcurrentML except for the actor model, but that is so old the documentation is written on parchment.

Re: Niklaus Wirth has died

#293
post #246

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…

There wasn't a single place I asserted that uxn is specifically novel or unprecedented. In fact, Devine's own presentation[0] about uxn specifically cites Wirth and Oberon, among countless other inspirations and examples. I'm saying it's awesome, accessible, simple and open.

I don't need to "develop more tolerance for differing opinions" - I have no problem with them and am completely open to them, even from people who I feel are communicating in an unfriendly, patronizing or gatekeeping manner. rollcat shared some other people and projects and you took it upon yourself to shoot down as much as possible in that comment - for what purpose? No one said Drecker is "on Wirth's level" when it comes to programming. We don't need him to write FizzBuzz, let alone any other software. I'm sorry you don't recognize the value of a publication like Low-Tech Magazine, but the rest of us can, and your need to shoot down that recognition is why I called your messages persistently negative.

Further, when I give kudos to uxn and recognize it as a cool piece of software, there's absolutely no point in coming in and saying "yeah but it's no big deal compared to ____" , as if anyone was interested in some kind of software achievement pissing contest. The sanctity and reverence for your software idols is not diluted nor detracted from by acknowledging, recognizing and celebrating newer contributors to the world of computing and software.

I have to come back and edit this and just reiterate: All I originally said was "uxn ftw" and you found it necessary to "put me in my place" about something I didn't even say/assert, and make it into some kind of competition or gatekeeping situation. Let people enjoy things. And now, minimizing this thread and never looking at it again.

[0] https://100r.co/site/weathering_software_winter.html

Re: Niklaus Wirth has died

#294
post #288
post #256

Earlier quoted context omitted.

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]),…

I think the K would likely be both simpler and harder than your first example by reading very straightforwardly in a single direction but with operators reading like line noise. In your case, my Numpy is rusty, but I think this is the Ruby equivalent of what you were doing? textb = 'What hath the Flying Spaghetti Monster wrought?' p textb.bytes.product((0...8).to_a).map{_1>>_2}.map{_1 & 1} Or with some abominable mon…

that all seems correct; the issue i had was not that python is less flexible than ruby (though it is!) but that it required a lot of mental effort to map back from the set of point-free array operations to my original intent. this makes me think that my trouble with j and k is not the syntax at all. but conceivably if i study the apl idiom list or something i could get better at that kind of thinking?

Re: Niklaus Wirth has died

#295
post #256
post #231

Earlier quoted context omitted.

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]),…

The k solution is ,/+|(8#2)\textb

k doesn't have a right shift operator, but you don't need that, you can use the base encoding operator instead

Personally I think this is clearer than both the array-ish python and the list comp.

https://ngn.codeberg.page/k/#eJwrSa0oSbJSCs9ILFEA4gyFkoxUBbe...

Re: Niklaus Wirth has died

#297
post #89
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.

Note that Oberon descendents like Active Oberon and Zonnon, do have premptive multitasking.

Re: Niklaus Wirth has died

#298
post #89

Earlier quoted context omitted.

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

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

Not in Java, .NET and C++ case, as it is mapped to tasks, managed by threads, and you can even write your own scheduler if so inclined.

Re: Niklaus Wirth has died

#299
post #105

Earlier quoted context omitted.

It has mostly won for individual programs, but very much not for larger things like operating systems and web browsers.

In the last 15 to 20 years asynchronous programming --- as a form of cooperative multi-tasking [1] --- did gain lot's of popularity. That was mainly because of non-scalable threads implementations in most language runtimes, e.g. the JVM. At the same time the JS ecosystem needed to have some support for concurrency. Since threads weren't even an option the community settled first on callback-hell and then on async/awa…

In .NET and C++ asynchronous programming is not cooperative, it hides the machinery of a state machine mapping tasks into threads, it gets prempted and you can write your own scheduler.

Re: Niklaus Wirth has died

#300
post #240
post #212

Earlier quoted context omitted.

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

well some of the things i know are true but i don't know which ones those are; i'll tell you the things i know and hopefully you can figure out what's really true yes! i'm referencing that specific rant. except that what munificent sees as a disadvantage i see as an advantage there's a lot of flexibility in systems design to move things between operating systems and programming languages. dan ingalls in 01981 takes a…

> async/await guarantees you won't have deadlocks

You will get them in .NET and C++, because they map to real threads being shared across tasks.

There is even a FAQ maintained by .NET team regarding gotchas like not calling ConfigureAwaitable with the right thread context in some cases where it needs to be explicitly configured, like a task moving between foreground and background threads.

Post reply on HN