6 ms·

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

by lukego 3y ago

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 homebrew CPU running on a random FPGA dev board with USB peropherals. My ambition is to be that kind of 80 year old one day, too.

kragen 3y ago
i hope you are! we miss you
cscheid 3y ago
> 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.
- kristianp 3y ago
  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.
- frognumber 3y ago
  Supported cooperative multitasking won in the end. It just renamed itself to asynchronous programing. That's quite literally what an 'await' is.
  - kragen 3y ago
    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 either async/await or cooperative multitasking. rather, the operating system used an event loop, like a web page before the introduction of web workers. you couldn't suspend a task; you could only schedule more work for later
    - nottorp 3y ago
      And these fancy new names aren't there just for hiding the event loop? :)
      - kragen 3y ago
        if the implied contrast is with cooperative multitasking, it's exactly the opposite: they're there to expose the event loop in a way you can't ignore. if the implied contrast is with setTimeout(() => { ... }, 0) then yes, pretty much, although the difference is fairly small—implicit variable capture by the closure does most of the same hiding that await does
        nottorp 3y ago
        Not asking about old JavaScript vs new JavaScript. Asking about explicit event loop vs hidden event loop with fancy names like timeout, async, await...
        kragen 3y ago
        do you mean the kind of explicit loop where you write for (;;) { int r = GetMessage(&msg, NULL, 0, 0); if (!r) break; if (r == -1) croak(); TranslateMessage(&msg); DispatchMessage(&msg); } or, in yeso, for (;;) { yw_wait(w, 0); for (yw_event *ev; (ev = yw_get_event(w));) handle_event(ev); redraw(w); } async/await doesn't always hide the event loop in that sense; python asyncio, for example, has a lot of ways to invoke the event loop or parts of it explicitly, which is often necessary for integration with software not written with asyncio in mind. i used to maintain an asyncio cubesat csp protocol stack where we had to do this to some extent, though, this vitiates the concurrency guarantees you can otherwise get out of async/await. software maintainability comes from knowing that certain things are impossible, and pure async/await can make concurrency guarantees which disappear when a non-async function can invoke the event loop in this way. so i would argue that it goes further than just hiding the event loop. it's like saying that garbage collection is about hiding memory addresses: sort of true, but false in an important sense
  - mkl 3y ago
    It has mostly won for individual programs, but very much not for larger things like operating systems and web browsers.
    - epcoa 3y ago
      Mostly won for CRUD apps (yes and a few others). Your DAW, your photo editor, your NLE, your chatbot girlfriend, your game, your CAD, etc might actually want to use more than one core effectively per task. Even go had to grow up eventually.
      - frognumber 3y ago
        It's moving in more and more. A core problem is that it's now clear most apps have hundreds or thousands of little tasks going, increasingly bound by network, IO, and similar. Async gives nice semantics for implementing cooperative multitasking, without introducing nearly as many thread coherency issues as preemptive. I can do things atomically. Yay! Code literally cooperates better. I don't have the messy semantics of a Windows 3.1 event loop. I suspect it will take over more and more into all walks of code. Other models are better for either: - Highly parallel compute-bound code (where SIMD/MIMD/CUDA-style models are king) - Highly independent code, such as separate apps, where there are no issues around cooperation. Here, putting each task on a core, and then preemptive, obviously wins. What's interesting is all three are widely used on my system. My tongue-in-cheek comment about cooperative multitasking winning was only a little bit wrong. It didn't quite win in the sense of taking over other models, but it's in widespread use now. If code needs to cooperate, async sure beats semaphores, mutexes, and all that jazz.
        funcDropShadow 3y ago
        Async programming is not an alternative to semaphores and mutexes. It is an alternative to having more threads. The substantial drawback of async programming in most implementations is that stack traces and debuggers become almost useless; at least very hard to use productively.
      - pjmlp 3y ago
  - smartscience 3y ago
    I always knew my experience with RISC OS wouldn't go to waste!
  - vram22 3y ago
    >Supported cooperative multitasking won in the end. Is this the same as coroutines as in Knuth's TAOCP volume 1? Sorry, my knowledge is weak in this area.
    - kragen 3y ago
      not exactly; see https://en.wikipedia.org/wiki/Cooperative_multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
      - vram22 3y ago
        Thanks, will check that.
        steveklabnik 3y ago
        The quick answer is that coroutines are often used to implement cooperative multitasking because it is a very natural fit, but it's a more general idea than that specific implementation strategy.
        kragen 3y ago
        interesting, i would have said the relationship is the other way around: cooperative multitasking implies that you have separate stacks that you're switching between, and coroutines are a more general idea which includes cooperative multitasking (as in lua) and things that aren't cooperative multitasking (as in rust and python) because the program's execution state isn't divided into distinct tasks i could just be wrong tho
        steveklabnik 3y ago
        Yeah thinking about it more I didn’t intend to imply a subset relationship. Coroutines are not only used to implement cooperative multitasking, for sure.
  - jerf 3y ago
    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" without considering whether you actually need it. Even in the network world, juggling hundreds of thousands of simultaneous tasks is the exception rather than the rule. Moreover, cooperative multitasking was given up at the OS level for good and sufficient reasons that I see no evidence that the current thrust in that direction has solved. As you scale up, the odds of something jamming your cooperative loop monotonically increase. At best we've increased the scaling factors, and even that just may be an effect of faster computers rather than better solutions.
    - hathawsh 3y ago
      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.
      - samus 3y ago
        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.
    - kragen 3y ago
      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
  - pjmlp 3y ago
    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.
    - Someone 3y ago
      Also (AFAIK) not in JavaScript. An essential property of cooperative multitasking is that you can say “if you feel like it, pause me and run some other code for a while now” to the OS. Async only allows you to say “run foo now until it has data” to the JavaScript runtime. IMO, async/await in JavaScript are more like one shot coroutines, not cooperative multitasking. Having said that, the JavaScript event loop is doing cooperative multitasking (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...)
- superluserdo 3y ago
  >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 changed by release (obviously pretty safe to say, generally increasing).
  - amelius 3y ago
    Hmm, but what if the compiler doesn't use the optimized constructs, e.g. floating point optimizations targeting numerical algorithms?
    - kragen 3y ago
      probably use a fortran compiler for that instead of oberon
    - bunderbunder 3y ago
      Life was different in the '80s. Oberon targeted the NS32000, which didn't have a floating point unit. Let alone most the other modern niceties that could lead to a large difference between CPU features used by the compiler itself, and CPU features used by other programs written using the compiler. That said, even if the exact heuristic Wirth used is no longer tenable, there's still a lot of wisdom in the pragmatic way of thinking that inspired it.
      - whartung 3y ago
        Speaking of that, if you were ever curious how computers do floating point math, I think the first Oberon book explains it in a couple of pages. It’s very succinct and, for me, one of the clearest explanations I’ve found.
    - hoosieree 3y ago
      Simple fix: floating-point indexes to all your tries. Or switch to base π or increment every counter by e.
- steveklabnik 3y ago
  Do you happen to remember where he said that? I've been looking for a citation and can't find one. I think that some of the text in "16.1. General considerations" of "Compiler Construction" are sorta close, but does not say this explicitly.
  - steveklabnik 3y ago
    Someone on reddit found it! https://www.reddit.com/r/programming/comments/18xqea3/niklaus_wirth_laureate_of_the_turing_award_and/kg7lmz5/?context=3 https://www.reddit.com/r/programming/comments/18xqea3/niklau...
    - microtherion 3y ago
      The author cited, Michael Franz, was one of Wirth's PhD students, so what he relates is an oral communication from Wirth that may very well never have been put in writing. It does seem entirely consistent with his overall philosophy. Wirth also had no compunction about changing the syntax of his languages if it made the compiler simpler. Modula-2 originally allowed undeclared forward references within the same file. When his implementation moved from the original multi pass compilers (e.g. Logitech's compiler had 5 passes: http://www.edm2.com/index.php/Logitech_Modula-2 http://www.edm2.com/index.php/Logitech_Modula-2) to a single pass compiler http://sysecol2.ethz.ch/RAMSES/MacMETH.html http://sysecol2.ethz.ch/RAMSES/MacMETH.html he simply started requiring that forward references had to be declared (as they used to be in Pascal). I suspect that Wirth not being particularly considerate of the installed base of his languages, and not very cooperative about participating in standardization efforts (possibly due to burn out from his participation in the Algol 68 process) accounts for the ultimately limited commercial success of Modula-2 & Oberon, and possibly for the decline of Pascal.
- pjmlp 3y ago
  Note that Oberon descendents like Active Oberon and Zonnon, do have premptive multitasking.
- spongebobism 3y ago
  That's fascinating. I'd imagine there are actually two equilibria/stable states possible under this rule: a small codebase with only the most effective optimization passes, or a large codebase that incorporates pretty much any optimization pass. A marginally useful optimization pass would not pull its weight when added to the first code base, but could in the second code base because it would optimize the run time spent on all the other marginal optimizations. Though the compiler would start out closer to the small equilibrium in its initial version, and there might not be a way to incrementally move towards the large equilibrium from there under Wirth's rule.
gjvc 3y ago
> ... his 80th birthday symposium at ETH where he showed off his new port of Oberon to a homebrew CPU running on a random FPGA dev board with USB peripherals. This was a fantastic talk. https://www.youtube.com/watch?v=EXY78gPMvl0 https://www.youtube.com/watch?v=EXY78gPMvl0
- lynguist 3y ago
  Thank you for sharing. I was there and didn’t expect to see this again. :) He had the crowd laughing and cheering, and the audience questions in the end were absolutely excellent.
  - gjvc 3y ago
    Always glad to be of service. I think I last watched it during the pandemic and was inspired to pick up reading more about Oberon. A demonstration / talk like that is so much better when the audience are rooting for the presenter to do well.
deleted 3y ago
[deleted]
vram22 3y ago
A Wirthwhile ambition. :) Sorry, couldn't resist. I first wrote it as "worthwhile", but then the pun practically fell out of the screen at me. I love Wirth's work, and not just his languages. Also his stuff like algorithms + data = programs, and stepwise refinement. Like many others here, Pascal was one of my early languages, and I still love it, in the form of Delphi and Free Pascal. RIP, guruji. Edited to say guruji instead of guru, because the ji suffix is an honorific in Hindi, although guru is already respectful.
microtherion 3y ago
According to his daughter (she runs a grocery store, and my wife occasionally talks to her), he kept on tinkering at home well past 80.

by lukego 3y ago

kragen 3y ago

i hope you are! we miss you

cscheid 3y ago

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

kristianp 3y ago
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.
frognumber 3y ago
Supported cooperative multitasking won in the end. It just renamed itself to asynchronous programing. That's quite literally what an 'await' is.
- kragen 3y ago
  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 either async/await or cooperative multitasking. rather, the operating system used an event loop, like a web page before the introduction of web workers. you couldn't suspend a task; you could only schedule more work for later
  - nottorp 3y ago
    And these fancy new names aren't there just for hiding the event loop? :)
    - kragen 3y ago
      if the implied contrast is with cooperative multitasking, it's exactly the opposite: they're there to expose the event loop in a way you can't ignore. if the implied contrast is with setTimeout(() => { ... }, 0) then yes, pretty much, although the difference is fairly small—implicit variable capture by the closure does most of the same hiding that await does
      - nottorp 3y ago
        Not asking about old JavaScript vs new JavaScript. Asking about explicit event loop vs hidden event loop with fancy names like timeout, async, await...
        kragen 3y ago
        do you mean the kind of explicit loop where you write for (;;) { int r = GetMessage(&msg, NULL, 0, 0); if (!r) break; if (r == -1) croak(); TranslateMessage(&msg); DispatchMessage(&msg); } or, in yeso, for (;;) { yw_wait(w, 0); for (yw_event *ev; (ev = yw_get_event(w));) handle_event(ev); redraw(w); } async/await doesn't always hide the event loop in that sense; python asyncio, for example, has a lot of ways to invoke the event loop or parts of it explicitly, which is often necessary for integration with software not written with asyncio in mind. i used to maintain an asyncio cubesat csp protocol stack where we had to do this to some extent, though, this vitiates the concurrency guarantees you can otherwise get out of async/await. software maintainability comes from knowing that certain things are impossible, and pure async/await can make concurrency guarantees which disappear when a non-async function can invoke the event loop in this way. so i would argue that it goes further than just hiding the event loop. it's like saying that garbage collection is about hiding memory addresses: sort of true, but false in an important sense
- mkl 3y ago
  It has mostly won for individual programs, but very much not for larger things like operating systems and web browsers.
  - epcoa 3y ago
    Mostly won for CRUD apps (yes and a few others). Your DAW, your photo editor, your NLE, your chatbot girlfriend, your game, your CAD, etc might actually want to use more than one core effectively per task. Even go had to grow up eventually.
    - frognumber 3y ago
      It's moving in more and more. A core problem is that it's now clear most apps have hundreds or thousands of little tasks going, increasingly bound by network, IO, and similar. Async gives nice semantics for implementing cooperative multitasking, without introducing nearly as many thread coherency issues as preemptive. I can do things atomically. Yay! Code literally cooperates better. I don't have the messy semantics of a Windows 3.1 event loop. I suspect it will take over more and more into all walks of code. Other models are better for either: - Highly parallel compute-bound code (where SIMD/MIMD/CUDA-style models are king) - Highly independent code, such as separate apps, where there are no issues around cooperation. Here, putting each task on a core, and then preemptive, obviously wins. What's interesting is all three are widely used on my system. My tongue-in-cheek comment about cooperative multitasking winning was only a little bit wrong. It didn't quite win in the sense of taking over other models, but it's in widespread use now. If code needs to cooperate, async sure beats semaphores, mutexes, and all that jazz.
      - funcDropShadow 3y ago
        Async programming is not an alternative to semaphores and mutexes. It is an alternative to having more threads. The substantial drawback of async programming in most implementations is that stack traces and debuggers become almost useless; at least very hard to use productively.
    - pjmlp 3y ago
- smartscience 3y ago
  I always knew my experience with RISC OS wouldn't go to waste!
- vram22 3y ago
  >Supported cooperative multitasking won in the end. Is this the same as coroutines as in Knuth's TAOCP volume 1? Sorry, my knowledge is weak in this area.
  - kragen 3y ago
    not exactly; see https://en.wikipedia.org/wiki/Cooperative_multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
    - vram22 3y ago
      Thanks, will check that.
      - steveklabnik 3y ago
        The quick answer is that coroutines are often used to implement cooperative multitasking because it is a very natural fit, but it's a more general idea than that specific implementation strategy.
        kragen 3y ago
        interesting, i would have said the relationship is the other way around: cooperative multitasking implies that you have separate stacks that you're switching between, and coroutines are a more general idea which includes cooperative multitasking (as in lua) and things that aren't cooperative multitasking (as in rust and python) because the program's execution state isn't divided into distinct tasks i could just be wrong tho
        steveklabnik 3y ago
        Yeah thinking about it more I didn’t intend to imply a subset relationship. Coroutines are not only used to implement cooperative multitasking, for sure.
- jerf 3y ago
  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" without considering whether you actually need it. Even in the network world, juggling hundreds of thousands of simultaneous tasks is the exception rather than the rule. Moreover, cooperative multitasking was given up at the OS level for good and sufficient reasons that I see no evidence that the current thrust in that direction has solved. As you scale up, the odds of something jamming your cooperative loop monotonically increase. At best we've increased the scaling factors, and even that just may be an effect of faster computers rather than better solutions.
  - hathawsh 3y ago
    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.
    - samus 3y ago
      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.
  - kragen 3y ago
    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
- pjmlp 3y ago
  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.
  - Someone 3y ago
    Also (AFAIK) not in JavaScript. An essential property of cooperative multitasking is that you can say “if you feel like it, pause me and run some other code for a while now” to the OS. Async only allows you to say “run foo now until it has data” to the JavaScript runtime. IMO, async/await in JavaScript are more like one shot coroutines, not cooperative multitasking. Having said that, the JavaScript event loop is doing cooperative multitasking (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...)
superluserdo 3y ago
>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 changed by release (obviously pretty safe to say, generally increasing).
- amelius 3y ago
  Hmm, but what if the compiler doesn't use the optimized constructs, e.g. floating point optimizations targeting numerical algorithms?
  - kragen 3y ago
    probably use a fortran compiler for that instead of oberon
  - bunderbunder 3y ago
    Life was different in the '80s. Oberon targeted the NS32000, which didn't have a floating point unit. Let alone most the other modern niceties that could lead to a large difference between CPU features used by the compiler itself, and CPU features used by other programs written using the compiler. That said, even if the exact heuristic Wirth used is no longer tenable, there's still a lot of wisdom in the pragmatic way of thinking that inspired it.
    - whartung 3y ago
      Speaking of that, if you were ever curious how computers do floating point math, I think the first Oberon book explains it in a couple of pages. It’s very succinct and, for me, one of the clearest explanations I’ve found.
  - hoosieree 3y ago
    Simple fix: floating-point indexes to all your tries. Or switch to base π or increment every counter by e.
steveklabnik 3y ago
Do you happen to remember where he said that? I've been looking for a citation and can't find one. I think that some of the text in "16.1. General considerations" of "Compiler Construction" are sorta close, but does not say this explicitly.
- steveklabnik 3y ago
  Someone on reddit found it! https://www.reddit.com/r/programming/comments/18xqea3/niklaus_wirth_laureate_of_the_turing_award_and/kg7lmz5/?context=3 https://www.reddit.com/r/programming/comments/18xqea3/niklau...
  - microtherion 3y ago
    The author cited, Michael Franz, was one of Wirth's PhD students, so what he relates is an oral communication from Wirth that may very well never have been put in writing. It does seem entirely consistent with his overall philosophy. Wirth also had no compunction about changing the syntax of his languages if it made the compiler simpler. Modula-2 originally allowed undeclared forward references within the same file. When his implementation moved from the original multi pass compilers (e.g. Logitech's compiler had 5 passes: http://www.edm2.com/index.php/Logitech_Modula-2 http://www.edm2.com/index.php/Logitech_Modula-2) to a single pass compiler http://sysecol2.ethz.ch/RAMSES/MacMETH.html http://sysecol2.ethz.ch/RAMSES/MacMETH.html he simply started requiring that forward references had to be declared (as they used to be in Pascal). I suspect that Wirth not being particularly considerate of the installed base of his languages, and not very cooperative about participating in standardization efforts (possibly due to burn out from his participation in the Algol 68 process) accounts for the ultimately limited commercial success of Modula-2 & Oberon, and possibly for the decline of Pascal.
pjmlp 3y ago
Note that Oberon descendents like Active Oberon and Zonnon, do have premptive multitasking.
spongebobism 3y ago
That's fascinating. I'd imagine there are actually two equilibria/stable states possible under this rule: a small codebase with only the most effective optimization passes, or a large codebase that incorporates pretty much any optimization pass. A marginally useful optimization pass would not pull its weight when added to the first code base, but could in the second code base because it would optimize the run time spent on all the other marginal optimizations. Though the compiler would start out closer to the small equilibrium in its initial version, and there might not be a way to incrementally move towards the large equilibrium from there under Wirth's rule.

gjvc 3y ago

> ... his 80th birthday symposium at ETH where he showed off his new port of Oberon to a homebrew CPU running on a random FPGA dev board with USB peripherals. This was a fantastic talk. https://www.youtube.com/watch?v=EXY78gPMvl0 https://www.youtube.com/watch?v=EXY78gPMvl0

lynguist 3y ago
Thank you for sharing. I was there and didn’t expect to see this again. :) He had the crowd laughing and cheering, and the audience questions in the end were absolutely excellent.
- gjvc 3y ago
  Always glad to be of service. I think I last watched it during the pandemic and was inspired to pick up reading more about Oberon. A demonstration / talk like that is so much better when the audience are rooting for the presenter to do well.

deleted 3y ago

[deleted]

vram22 3y ago

A Wirthwhile ambition. :) Sorry, couldn't resist. I first wrote it as "worthwhile", but then the pun practically fell out of the screen at me. I love Wirth's work, and not just his languages. Also his stuff like algorithms + data = programs, and stepwise refinement. Like many others here, Pascal was one of my early languages, and I still love it, in the form of Delphi and Free Pascal. RIP, guruji. Edited to say guruji instead of guru, because the ji suffix is an honorific in Hindi, although guru is already respectful.

microtherion 3y ago

According to his daughter (she runs a grocery store, and my wife occasionally talks to her), he kept on tinkering at home well past 80.