Live data from Hacker News

Niklaus Wirth has died

twitter.com

381–390 of 412 posts

Re: Niklaus Wirth has died

#381
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…

> in the 02000s there was... So sometime between "02000" and "02999"?

i meant between 02000 and 02010; is there a clearer way to express this that isn't ridiculously prolix

Re: Niklaus Wirth has died

#382

Earlier quoted context omitted.

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…

> You could argue that it's just syntactic sugar, but it's bloody important syntactic sugar. Yes, of course you could, since everything beyond, uh, paper tape, next-state table, and current pen-position (or whatever other pieces there are in a theoretical Turing machine) is basically syntactic sugar. Or, IOW, all programming languages higher than assembly are nothing but syntactic sugar. I like syntactic sugar. (But…

does this mean that lisp programmers are syntactic diabetics

i hear they're concerned about cancer of the semicolon

Re: Niklaus Wirth has died

#383
post #300
post #240

Earlier quoted context omitted.

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.

thank you! i haven't tried using .net more than a tiny bit

Re: Niklaus Wirth has died

#384
post #300
post #240

Earlier quoted context omitted.

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.

(it arguably needs to be updated, so that people stop writing single line 'return await' methods which waste performance for no reason (thankfully some analyzers do flag this))

Re: Niklaus Wirth has died

#385
post #373

Earlier quoted context omitted.

> it covers both what i'm calling 'cooperative multitasking' and things like async/await, the npm event handler model, and python/clu iterators Those are implementation details. What's actually happening in all cases is my definition. > also could you please answer my request for clarification in Yes, your examples or the 5 million other implementations of event loops. You forgot to add gtk's for example :) > in the…

thanks! but here we were discussing specifically the distinction between the approaches to concurrency that require you to explicitly structure your code around yield points, like async/await, and the kinds that don't, like preemptive multitasking and what i'm calling cooperative multitasking. this is unnecessarily difficult to discuss coherently if you insist on applying the term 'cooperative multitasking' indiscrim…

Where did I mix preemptive and cooperative multitasking?

And why do you think that in the case of an explicit event loop you don't have to yield? You do have to, and have to sort out some way to continue on your own. Which makes the new 'syntactic sugar' approaches much easier of course. Doesn't mean the principle isn't the same and they don't deserve the same name.

Re: Niklaus Wirth has died

#386
post #318
post #280

Earlier quoted context omitted.

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.

My father celebrated 60 two weeks back and told me he bought license for new Delphi and loves it, I was quite surprised with the development he described. I considered telling him that he could get most of the things (he also buys various components) for free today, but then.. he is about 5 years before retirement and won't relearn all his craft now. Myself, I am not sure whether its nostalgia but I miss the experien…

> My father celebrated 60 two weeks back

So about three months my senior.

> I considered telling him that he could get most of the things (he also buys various components) for free today, but then.. he is about 5 years before retirement and won't relearn all his craft now.

Free Pascal / Lazarus shouldn't be all that much to relearn.

> Myself, I am not sure whether its nostalgia but I miss the experience of Delphi 7 I started with 20 years back.

Delphi 1, 28 years now.

> In many ways, the simplicity of VLC and the interface is still unbeaten.

1) Yup.

2) VCL, btw.

3) Now that Embarcadero is hiking up the price of Delphi with every release, I think the standard-bearer for best librry / framework is probably the LCL, the Lazarus Component Library.

Re: Niklaus Wirth has died

#387
post #285

After having read some of the comments on Pascal here -- fellow HNers, what's your view on Pascal as a teaching/introductory language in 2023, for children aged 10+? Mostly thinking of FreePascal, but TurboPascal in DOSBox/FreeDOS/SvarDOS is also a possibility. I'm also thankful for references to "timeless" Pascal books or online teaching materials that would be accessible for a 10+ year old kid who is fine with read…

> what's your view on Pascal as a teaching/introductory language in 2023, for children aged 10+?

I think it's still the best language to start with.

And don't let yourself be dissuaded by comments here about "no ecosystem" etc; that's BS, IMnsHO. There are tons of compilers and IDEs you could use, from Free Pascal (with or without Lazarus), via PowerPascal (IIRC) and other smaller implementations, to the old versions that Borland / Inprise / CodeGear / Idera / Embarcadero have released as freeware over the years.

Re: Niklaus Wirth has died

#388
post #254

Earlier quoted context omitted.

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

Thanks!

Re: Niklaus Wirth has died

#389
post #48
post #16

@HN: Black banner, please?

Some people say that it doesn't matter if someone dies at age 89 -- after they have lived a full life and contributed all they had to give -- it's still just as sad and shocking. Personally, I don't agree, to me it's just not as sad or shocking. People don't live forever and Wirth's life was as successful and complete as possible. It's not a "black day" where society truly lost someone before they fulfilled their pot…

Yeah, that just shows you haven't yet grasped what mourning is.

Re: Niklaus Wirth has died

#390
post #312

Earlier quoted context omitted.

I'm sitting here with the K reference manual, and I still can't decode this. I'm wildly guessing that your approach somehow ends doing something closer to this: textb.bytes.flat_map{_1.digits(2)} Which I must admit it took me embarrassingly long to think of.

If you go to the link and press 'help' you'll see some docs for ngn/k The relevant line is I\ encode 24 60 60\3723 -> 1 2 3 2\13 -> 1 1 0 1 So (8#2)\x encodes x in binary, with 8 positions. And because k is an array language, you don't need to do any mapping, it's automatic. ,/+|x is concat(transpose(reverse(x))) (,/ literally being 'reduce with concat')

> If you go to the link and press 'help' you'll see some docs for ngn/k

Almost as impenetrable as the code unless you already know the language. But that's ok - I guess that's the main audience...

E.g. trying to figure out what "\" means, in that help is only easier now because you gave me the whole line, as there are 64 occurrences of "\" in that doc and I wouldn't have known what pattern to search for to limit it...

It's back to the philosophical disconnect of expecting people to read start to finish/know far more detail inside out rather than skimming and relying on easy keyword lookups... (yes, we're lazy)

> 'reduce with concat'

So "flatten" in Ruby-speak, I take it (though "flatten" without an argument in Ruby will do this recursively, so I guess probably flatten(1) would be a more direct match).

> you don't need to do any mapping, it's automatic.

After these pointers (thanks!), here's - mostly for my own learning, what I ended up with not in an attempt to get closer to the linenoise (we can do that with a horrific level of operator overloading that'd break most of the standard library, though we can't match k precisely). Please don't feel obliged to go through this unless you're morbidly curious; I just had to, but I'm sure you'd suffer going through my attempt at figuring out what the hell k is doing...:

    textb="What hath the Flying Spaghetti Monster wrought?"

    # Firstly, I finally realised after a bunch of testing that 1) "(8#2)" does something like this.
     # That is, the result of 8#2 is (2 2 2 2 2 2 2 2), which was totally not what I expected.
    def reshape(len,items) = [].fill(0...x)

    class Integer
      # For the special case of (x#y) where x is a positive integer, which is frankly the only one
      # I've looked at, we can do:
      # So now 4.reshape(2) returns [2 2 2 2] just like (4#2) in ngn/k
      def reshape(items) = Array(items)*self

      # Now we can do something somewhat like what I think "encode" is
      # actually doing - this can be golfed down, but anyway:
      # With this, "a".ord.encode(8.reshape(2)) returns [0,1,1,0,0,0,0,1],
      # equivalent to (8#2)\ "a" in ngn\k
      def encode(shape)
        rem = self
        Array(shape).reverse.map do |v|
          val = rem % v
          rem = rem / v
          val
        end.reverse
      end
    end

    # Now we can break Array too.      
    class Array
      # First a minor concession to how Ruby methods even on the Array
      # class sees the focal point as the Array rather than the elements.
      # E.g. `self` in #map is the Array. If the focus is to be on applying the
      # same operation to each element, then it might be more convenient
      # if `self` was the element. With this, we can do ary.amap{reverse}
      # instead of ary.map{|e| e.reverse} or ary.map{ _1.reverse}. 
      # To get closer to k, we'd have needed a postfix operator that we could
      # override to take a block, but unfortunately there are no overridable 
      # postfix operators in Ruby. E.g. we can hackily make
      # ary.>>(some_dummy_value) {a block} work, but not even
      # ary >> (some_dummy_value) { a block} and certainly not
      # ary >> { a block }
      #
      def amap(&block) = map { _1.instance_eval(&block) }

      # If we could do a "nice" operator based map, we'd just have left it
      # at that. But to smooth over the lack of one, we can forward some
      # methods to amap:
      def encode(...) = amap{encode(...)}
      # ... with the caveat that I realised afterwards that this is almost certainly
      # horribly wrong, in that I think the k "encode" applies each step of the
      # above to each element of the array and returns a list of *columns*.
      # I haven't tried to replicate that, as it breaks my mind to think about 
      # operating on it that way. That is, [65,70].encode(2.reshape(10))
      # really ought to return [[6,7],[5,0]] to match the k, but it returns
      # [[6,5],[7,0]]. Maybe the k result will make more sense to me if I
      # take a look at how encode is implemented...

      def mreverse = amap{reverse}
    end

    # Now we can finally get back to the original, with the caveat that due to
    # the encode() difference, the "mreverse.flatten(1)" step is in actuality
    # working quite differently, in that for starters it's not transposing the arrays.
    #
    p textb.bytes.encode(8.reshape(2)).mreverse.flatten(1)

    # So to sum up:
    #
    # textb            ->   textb.bytes since strings and byte arrays are distinct in Ruby
    # (8#2)           ->   8.reshape(2)
    # x\y               ->   y.encode(x) ... but transposed.
    # |x                ->   x.mreverse
    # ,/+x             ->   x.flatten(1)   .. but really should be x.transpose.flatten(1)
    #
    # Of course with a hell of a lot of type combinations and other cases the k
    # verbs supports that I haven't tried to copy.
Post reply on HN