sesquipedalian

1) Tastes bland. 2) Think about how it tastes. 3) Tastes salty now. 4) Think again about how it tastes. 5) Goto 1.

Hence the "strange loop".

Care to elaborate?

Very bare-bones implementation in one source file (+ 1 header) https://github.com/pedro-onate/eva/tree/84a62881c610ef23f9f1....

Later versions include GC, and bytecode compiler + VM.

Edit: I highly recommend SICP (dense, but elegant), and Matt Might's blog as resources.

Probably some form of verlet integration: http://gamedevelopment.tutsplus.com/tutorials/simulate-teara....

Author's github page also has links to a list of cloth simulation resources.

Interesting. I've never heard of D-list nomenclature before.

With the A-list method you typically need to write a "zipper" function, that recursively conses the heads of two lists to generate the A-list. Makes "apply" an expensive operation with needless allocations.

What's great about D-lists is that the "make-env" method is just a single cons operation. Clearly superior. I'm surprised its not more well known.

Its both a compiler and an interpreter. Read up on Petite Chez Scheme.

I'm very excited about this. I've been using Chez as my performance benchmark target for my own Scheme implementation.

First of all, it's great that you're exploring functional programming paradigms and their applicability to game programming/state management.

That being said I have to point out some things that bothered me: I believe you're conflating immutability and commutativity -- these things are not the same thing. Functional programming does not absolve you of paying attention to the order of operations. For example if you had two functions plus1 and plus2, you can order those any way you like since summation is commutative. However if you had plus1 divide2 functions, you have to pay attention to the order of application due to non-commutativity.

I've found that BSP trees are a quite elegant, albeit, more complicated alternative for handling point-in-polygon queries compared to raycasting. Essentially, it decomposes an arbitrary non-convex polygon into a binary tree of half-spaces. A point-in-poly test then just becomes a binary search.

That being said sometimes brute force is good enough.

I found the statement regarding runtime exceptions confusing as well. Perhaps what is meant by that statement is that Pony lacks unchecked (i.e. Java) rather than runtime exceptions.

What makes Common Lisp macros easier to use than Scheme's?

Good example. Minor nitpick, you listed 0.09 twice.

This is one of those things that seems obvious in hindsight. However, it never occurred to me that one could simply use the lock address to impose a consistent and unique ordering on the locks rather than some other explicit mechanism. It's a rather clever solution, the pointer is the sequence number!

I wouldn't place too much importance on their choice of implementation language. I'd imagine the goal of showcasing their reference implementation is to demonstrate the operational semantics of their virtual machine. Equivalent implementations could be produced in C for example.

Real computer scientists use comic sans for their presentations.

In all seriousness though, I've noticed that it was the font of choice for my CS professors in college.

Why does it matter what approach he took to solve the problem?

What relevance does it have that someone else without domain expertise or post-graduate education is capable of solving this?

I'm not an expert in this field, nor do I think this is "black magic", but it does seem like this kid applied a good amount of ingenuity in attacking this problem.

I believe something like http://sweetjs.org can polyfill "let" and "class" syntax.

If I'm not mistaken, this sounds like an incremental fisher-yates shuffle.

I don't believe non-stack based APIs prevent the implementation of the features you just mentioned. You don't necessarily have to expose the underlying stack manipulation routines as your defacto API although it is easier to do so. My gripe with this technique is that it makes it much harder for the compiler to catch errors. Personally, I think it would be better to expose the API as helper functions that compose (and hide) the underlying stack routines.

Agreed. The biggest drawback IMHO is you defer errors that could have been caught at compile time to runtime if you had a saner interface.

Google buys these guys out.

I know it is too early to say, but if I had to guess what the next Google would look like, it would be this.