This intro is great, and the lighting is really, really nice.

But TBH I do not like accelerated intros/demos, because the most difficult part of the code, i.e. 3D graphics pipeline is implemented outside the demo, in a GPU driver. Many years ago, in a DOS, coders have to implement rasterization, clipping & lighting and fit everything in a 64kB. Watch for example Stash by TBL (http://www.pouet.net/prod.php?which=3), Jizz by TBL (http://www.pouet.net/prod.php?which=2), Photon by Purple (http://www.pouet.net/prod.php?which=502).

Looks interesting, but style of the program is terrible. Drawing function are mixed with model definition and sample circuit definition.

BTW resistance function do not handle division by zero.

See also FQA: http://www.yosefk.com/c++fqa/index.html

The sample plot is wrong. Domain of sin x + log(x+1) derivative is R - {-1}, so there must not be any vertical line at x = -1.

Most graphers have that problem - detecting a discontinuity numerically isn't trivial.

"You have reinvented Brainfuck but non-ironically" - brilliant. :)

Ah, so that is what this checklist yields for Urbit!

Because it is not designed for this purpose?

IMHO it's a matter of experience. When I was young I believed that programming is about writing a lot of code that "just work".

Now, after many private and commercial projects, I know that is about reading and understanding code. And about eliminating bugs. :)

Your project is great, Pascal is really underrated language.

I looked at parser (hand written are best), this part spotted my eyes https://github.com/lkesteloot/turbopascal/blob/master/Parser... - IMHO order of checking whatever node is identifier or not have to be reversed. Now, such simple program:

program Test;

procedure foo; begin end;

begin foo := 10; end.

produces error 'Error: can't cast from 70 to 76 ("10", line 8)' - whatever this means. :)

Well the error message is confusing (it's trying to cast from an integer (type 70) to a procedure (type 76)), but it's correct to fail to compile. But yeah I'm not sure that my logic there is altogether correct. I re-wrote it a few times as I found new cases that weren't correctly handled. Specifically, I'm not sure whether the type of the identifier should guide the parsing. It's similar to the "x*y" ambiguity in parsing C (multiplication or declaration of pointer variable y).

Looks like Algol68 with some OOP.

Looks like Golang but cleaned up and with generics added in.

Maybe it's a bird, maybe it's a plane, maybe it's Superman.

In other words, Python

Great list. Paper "Strongly universal string hashing is fast" is very interesting.