johtela

There is something captivating in these old pictures that elevates them to pieces of art rather than just computer graphics. The sheer amount of work that went into crafting them makes each one special.

If you want to learn how HM typechecking works by studying working (Haskell) code, I would recommend the papers below. The code in these papers is closer to how you would actually implement a type checker in practice.

[1]: https://www.microsoft.com/en-us/research/wp-content/uploads/...

[2]: https://web.cecs.pdx.edu/~mpj/thih/thih.pdf

My sentiments exactly. The problem is that also traditional media now amplifies this negativity. A bleak world view is now the norm. Things have been much worse in recent past but still people didn't fall in to apathy. Objectively things are not nearly as bad as the common discource leads to believe.

S.P.Y. Special Project Y ad is my absolute favorite. Maximum 80s vibes : - D

We Finns especially struggle with this one: https://www.youtube.com/watch?v=xxxWwdeGz1Q

Being old enough to have used both Microsoft and Borland development tools back in the 90s, I think Borland was clearly ahead of the game in Windows development. GUI development with MFC was clunky and tedious. Tools generated ton of boilerplate code that you had to understand and maintain. Borland on the other hand offered much more developer friendly experience, especially when Delphi 1.0 came out on 1995. That was hands down the best development tool for Win16. They maintained the edge in Win32 development as well with Delphi 2.0. So, seeing all the dirty tactics MS employed to steer developers to using their tools just reminds me what an a-hole company they used to be.

Shameless plug of my own tool. If you want to write literate programs in TypeScript, check out https://johtela.github.io/litscript/

There is also a VSCode syntax highlighting extension https://marketplace.visualstudio.com/items?itemName=johtela....

You can agree or disagree about the design decisions made by people contributing to Haskell language, but you have to admit that it's a pretty clever bunch of people. Haskell has contributed more to PL research in past few decades than any other language. That alone makes it a language every programmer should learn. Not because they should use it daily, but to learn what functional programming is in its purest form.

I live less than 100 km away from Olkiluoto nuclear plant, and I have never been worried about its safety. I wonder why this incident ever got any publicity outside Finland. Even here it faded away very quickly.

For sure there is need for programming language research. Language designers benefit greatly from the work done by the academia - for example in the area of type systems. But, OTOH, scientific community is not very tuned in the everyday problems programmers have. That is why some of the popular languages are basically hobby projects spawned from some lone programmer's personal itch.

I think we should have the best of both worlds; people enjoying the mathematical rigor should do PL research. And hobbyist language designers should pursue whatever ideas they might have. But both camps should acknowledge that the other side is equally important.

Rather than spending a lot of time building a router table, I recommend making a Samurai Carpenter's router jig [1] which is far simpler to make, and more useful in most woodworking joinery tasks. I spent many evenings making a nice router table, and I've used it maybe a dozen times. The Samurai jig, on the other hand, I use all the time. Mostly cutting half lap joints in two-by material, but also for notching and general routing. It is much easier to use a router when you can the bit cutting. With a router table you have to rely on the fence for making accurate cuts. (A good fence is a mandatory accessory for a functional router table)

[1]: https://www.youtube.com/watch?v=DV9Cb_-Axos

> Broad phase collision detection usually involves three lists of the bounding boxes of the objects, ordered by X, Y, and Z.

Exactly. You first want to limit the set of objects that might collide as far as possible. A three-level interval tree [1] works great for finding overlapping bounding boxes. You need a three-level nested interval tree where the 1st level covers the x-direction, 2nd y-direction, 3rd z-direction. It also pays off to make sure that the interval trees are balanced. You can turn the interval tree into red black tree [2], for example, by adding the color flag in the interval node. Then you can balance the tree using rotations when inserting or deleting.

[1]: https://en.wikipedia.org/wiki/Interval_tree [2]: https://en.wikipedia.org/wiki/Red%E2%80%93black_tree

I have to admit that I haven't used Kakoune myself. I just like its approach of taking the good parts of Vim and adapting them to more "mainstream" style of editing.

Because Kakoune's editing operations are much closer to VS Code than Vim's, I think you can copy its functionality quite extensively with ModalEdit. The only limitation is that VS Code itself needs to have the commands to support these operations. The configuration involves just binding key sequences to the commands. However, VS Code marketplace has so many command extensions, so I bet you can find substitutes for most Kakoune features there.

Regarding the literate configuration, there is no Jupyter-style online editor for it, afaik. I use (of course) VS Code to edit my `settings.json` file. In the background I run [LiTScript][1] in watch mode to generate the documentation on the fly. I also use the [Live Server][2] extension to automatically reload the generated documentation when it has been changed. With this setup, saving the `settings.json` file causes VS Code to reload the configuration, LiTScript to generate the updated documentation, and Live Server to reload it automatically. So, it is almost like Jupyter in the sense that you see your changes in effect immediately.

[1]: https://johtela.github.io/litscript/ [2]: https://marketplace.visualstudio.com/items?itemName=ritwickd...

OP here. I completely agree with that. The goal of ModalEdit is not to emulate those verb-noun commands. VS Code's commands operate on selections, so it is very cumbersome to turn them to work in Vim way. Instead, you should try to mimick something like [Kakoune][1] which is another modal editor that uses the selection as command target.

I'm sure ModalEdit doesn't tempt any hardcore Vim users to use VS Code. But there are a lot of VS Code user's who have used Vim and like idea of modal editing. Having an extension that you can configure from ground up is the value proposition I was aiming for; not to make a poor man's Vim clone.

[1]: https://kakoune.org/why-kakoune/why-kakoune.html

Delphi is ancient - as am I. My first FOSS published in Internet was written Delphi in 1996:

http://delphi.icm.edu.pl/authors/a0000824.htm

The mainstream media conflates them as well, so the point of the article is valid.

I've been using my own property based testing framework https://johtela.github.io/LinqCheck/ for .NET projects and jsverify (https://github.com/jsverify/jsverify) for Typescript projects. Below are some repos using those:

https://github.com/johtela/Flop https://github.com/johtela/lamath

This article sums up all the reasons why I think documenting your code is important. But unlike the author, I take my comments one step further and generate documentation from them with my literate programming tool (for C#): https://johtela.github.io/LiterateCS/