Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Niklaus Wirth has died

twitter.com

Post reply on HN
Print view View original

391–400 of 412 posts

Re: Niklaus Wirth has died

#391

Post by jibal »

kragen wrote: post #279
jibal wrote: post #277

Earlier quoted context omitted.

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

Heh, no way do I remember the details. I just remember that we were rewriting it in 360 assembler but I left before that was completed (if it was), and that I wrote an Algol syntax checker in Meta V that was obliquely referenced at the end of RFC 57.

Re: Niklaus Wirth has died

#392

Post by vidarh »

kragen wrote: post #320
vidarh wrote: 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.

i can't decode it either but i think you're right. note that this probably gives the bits in big-endian order rather than little-endian order like my original, but for my purposes in that notebook either one would be fine as long as i'm consistent encoding and decoding

I got a few steps further after lots of experimentation with ngn/k and the extra hints further downthread:

https://gist.github.com/vidarh/3cd1e200458758f3d58c88add0581...

The big caveat being it clicked too late that 1) "encode" is not "change base and format", but "for each element in this array, apply the module to the entire other array, and pass the quotient forward", and 2) encode returns a list of columns of the remainders rather than rows (the output format really does not make this clear...).

So you can turn a list of seconds into hour, minute, seconds with e.g.: (24 60 60)\(86399 0 60), but what you get out is [hour, minute, second] where hour, minute, second each are arrays.

If you want them in the kind of format that doesn't break the minds of non-array-thinking people like us because the order actually matches the input, you'd then transpose them by prepending "+", because why not overload unary plus to change the structure of the data?

   +(24 60 60)\(86399 0 60)
Returns (23 59 59 0 0 0 0 1 0)

Or [[23,59,59], [0,0,0], [0,1,0]] in a saner output format that makes it clear to casuals like me which structure is contained in what.

Now, if you then want to also flatten them, you prepend ",/"

I feel much better now. Until the next time I spend hours figuring out a single line of k.

Re: Niklaus Wirth has died

#393

Post by vidarh »

kragen wrote: post #262
ryukoposting wrote: post #260

Earlier quoted context omitted.

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.

do you think writing st is an achievement that merits a turing award because i've also written a terminal emulator, and it compiles from source in 0.98 seconds https://gitlab.com/kragen/bubbleos/blob/master/yeso/admu-she... screenshot of running vi in it at https://gitlab.com/kragen/bubbleos/blob/master/yeso/admu_she... (steps to reproduce: install dependencies; make; rm admu-shell admu-shell-fb admu-shell-wercam adm…

Last I checked, st was around 8k lines. It's not bad (xterm's scrollbar and button handling is in a similar LOC range), but I'd argue it's not minimalist, so even if writing a terminal had qualified, st isn't it.

WRT to the scrollback it seems like they're going overboard in being difficult about features that adds little code but has much impact, while not paying close attention to their dependencies. Things they could've done without (the copy on my system includes libz, libpng, libexpat (assuming for fontconfig, which is itself a giant steaming pile of excessive complexity), and even libbrotlicommon... I'm pretty sure I have no brotli images on my system that st has any business touching...

I used st until I replaced it with my own, and I can't fault it for many things in terms of usability, though. Other than the box drawing - it's not pixel perfect (I only bring that up because I bikeshedded a pixel-perfect override for the boxdrawing characters for my font renderer when I was bored a while back so it's the one place where I can crow about mine being better than st ;) - in every other area it still has warts to clean up)

Re: Niklaus Wirth has died

#394

Post by steveklabnik »

kragen wrote: post #378
steveklabnik wrote: post #371

Earlier quoted context omitted.

> arguably on that basis you could claim that they aren't quite 'cooperative multitasking' on their own Right, I think this is where I am coming from. Generators, for example, can be implemented via coroutines, but I would not call a generator "cooperative multitasking." That's very cool! Yeah, I have never done this myself, but in my understanding implementations in assembly can be very small. > when i went to go lo…

while python-style generators aren't cooperative multitasking (by the usual definition in which cooperative multitasking maintains a separate stack for each task), they can be implemented using cooperative multitasking, which is (arguably!) what happens if you use lua coroutines to implement generators it certainly isn't the final say! it's just an analysis of how my own code turned out, not any kind of universal les…

I'm gonna have to mull over "implement generators using cooperative multitasking" a bit :)

> i think the difference if you were to implement this same executor with rust generators is just that you probably wouldn't make the linked list of all tasks an intrusive list?

You still could, and IIRC tokio uses an intrusive linked list to keep track of tasks. There's no specific requirements for how you keep track of tasks, or even a standardized API for executors, which is why you'll hear people talk about why they want "to be generic over runtimes" and similar.

Re: Niklaus Wirth has died

#395

Post by Scea91 »

CRConrad wrote: post #386
Scea91 wrote: post #318

Earlier quoted context omitted.

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…

Thanks for the tips regarding Lazarus and LCL I will share them next time we meet.

Re: Niklaus Wirth has died

#396

Post by kragen »

jibal wrote: post #391
kragen wrote: post #279

Earlier quoted context omitted.

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

Heh, no way do I remember the details. I just remember that we were rewriting it in 360 assembler but I left before that was completed (if it was), and that I wrote an Algol syntax checker in Meta V that was obliquely referenced at the end of RFC 57.

oh, that's too bad. i guess memories fade

it's interesting to see programming language advancement cited as a major contribution to the development of a network protocol

Re: Niklaus Wirth has died

#397

Post by kragen »

vidarh wrote: post #393
kragen wrote: post #262

Earlier quoted context omitted.

do you think writing st is an achievement that merits a turing award because i've also written a terminal emulator, and it compiles from source in 0.98 seconds https://gitlab.com/kragen/bubbleos/blob/master/yeso/admu-she... screenshot of running vi in it at https://gitlab.com/kragen/bubbleos/blob/master/yeso/admu_she... (steps to reproduce: install dependencies; make; rm admu-shell admu-shell-fb admu-shell-wercam adm…

Last I checked, st was around 8k lines. It's not bad (xterm's scrollbar and button handling is in a similar LOC range), but I'd argue it's not minimalist, so even if writing a terminal had qualified, st isn't it. WRT to the scrollback it seems like they're going overboard in being difficult about features that adds little code but has much impact, while not paying close attention to their dependencies. Things they co…

yeah, i don't mean to bag on st here at all

it would be interesting to see what an even more minimalist and more usable terminal emulator looked like. both your work and st are constrained by having to support terminal control languages with a lousy strength to weight ratio, something oberon opted out of

Re: Niklaus Wirth has died

#398

Post by vidarh »

kragen wrote: post #397
vidarh wrote: post #393

Earlier quoted context omitted.

Last I checked, st was around 8k lines. It's not bad (xterm's scrollbar and button handling is in a similar LOC range), but I'd argue it's not minimalist, so even if writing a terminal had qualified, st isn't it. WRT to the scrollback it seems like they're going overboard in being difficult about features that adds little code but has much impact, while not paying close attention to their dependencies. Things they co…

yeah, i don't mean to bag on st here at all it would be interesting to see what an even more minimalist and more usable terminal emulator looked like. both your work and st are constrained by having to support terminal control languages with a lousy strength to weight ratio, something oberon opted out of

Yeah, there's a ton of cruft. On one hand I find it fun to see how much of vttest I can make it through, on the other hand, supporting DECALN (DEC service test pattern - just fills the screen with capital E) is just a boxticking exercise, and while that's one of the dumbest one there are also dozens that are hardly ever used, or that are used in rare cases but doesn't really need to.

That is one area where st's "tmux copout" on scroll somewhat makes sense - it would be a reasonable option to define a clean sufficient subset that lets you run enough stuff to tell people to just run anything that breaks under tmux/screen or a separate filter.

But from what I see with terminals, there's a lot of reluctance to do this not because people believe all these codes are so important but because it seems to become a bit of a matter of pride to be a precise as possible. I admit to having succumbed to a few myself, like support for double-width and double-height characters, as well as "correct" (bright/dim rather than on/off) blink and support for the nearly unsupported rapid blink... There is also a pair of escape codes to enable and disable fraktur. This is fertile ground for procrastinating terminal developers to implement features used by one person in the 70's sometime.

At the same time I sometime catch myself hoping some of these features will be used more... A very few I'll probably add support for because I want to use them in my text editor, e.g. different coloured underlines, and squiggly underlines are both easy to do and actually useful..

I think with a cleaner set of control codes, though, you could certainly fit quite a few of those features and still reduce the line count significantly...

Re: Niklaus Wirth has died

#399

Post by kragen »

nottorp wrote: post #385
kragen wrote: post #373

Earlier quoted context omitted.

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.

you didn't and i don't

Re: Niklaus Wirth has died

#400

Post by kragen »

vidarh wrote: post #398
kragen wrote: post #397

Earlier quoted context omitted.

yeah, i don't mean to bag on st here at all it would be interesting to see what an even more minimalist and more usable terminal emulator looked like. both your work and st are constrained by having to support terminal control languages with a lousy strength to weight ratio, something oberon opted out of

Yeah, there's a ton of cruft. On one hand I find it fun to see how much of vttest I can make it through, on the other hand, supporting DECALN (DEC service test pattern - just fills the screen with capital E) is just a boxticking exercise, and while that's one of the dumbest one there are also dozens that are hardly ever used, or that are used in rare cases but doesn't really need to. That is one area where st's "tmux…

i'd forgotten about bright/dim blink

i've been thinking that maybe nested tables would be better than character cells, for example, accommodating proportional fonts and multiple sizes much better

Post reply on HN