>Coalton strives to implement Haskell or ML-adjacent semantics (in the type system, for example) with Lisp syntax. "With" here meaning that it is both implemented in and written with Lisp syntax.
Not exactly. Coalton brings ML-style strong typing to Common Lisp. But Coalton code is also Lisp code.
The backend, thus, is Common Lisp, and it is available at all times, thus leveraging all its power.
>SmallJS is file based, not image based, so you can develop in your favorite IDE
This project is nice, however if we don't have a specific, client-side IDE for interactive development, 70% of the power of Smalltalk is gone (one of the criticisms I give to Ruby)
How would one do to push changes to the web frontend (browser) without stopping the program ?
One could easily implement an Emacs (SLIME) plugin to "macroexpand" the (pseudo) expresion to real (concrete) Lisp code, and even to try again until the implementation satisfies you.
Then it becomes a concrete Lisp implementation and thus not unpredictable anymore.
>Easy to prove, can you think of an engineer that adds negative value?
Yes, i have many examples. Two of them I personally fired. One of them, I should have fired much early. I let this engineer basically add negative value by trying to make his peers (other engineers) finish the work it was delegated to him, thus creating negative value by preventing the other, highly productive engineers, to do their tasks.
I warned him not to do this, but he didn't heed. Sadly due to Human Resources the firing process took way too long. I should've acted earlier.
In the 1980s, complete workstations were written in Lisp down to the lowest level code. With garbage collection of course. Operating system written in Lisp, application software written in Lisp, etc.
We're talking about commercial, production-quality, expensive machines. These machines had important software like 3D design software, CAD/CAM software, etc. And very, very advanced OS. You could inspect (step into) a function, then into the standard library, and then you could keep stepping into and into until you ended up looking at the operating system code.
The OS code, being dynamically linked, could be changed at runtime.
>That means that a field called "date" can be either a string, integer days since the epoch or a Java Date, and (because this codebase isn't great) there's no way of knowing without tracing the call stack.
But this is because JSON is an untyped data structure. (And btw, a flawed one...)
You would have this problem in any programming language.
Not exactly. Coalton brings ML-style strong typing to Common Lisp. But Coalton code is also Lisp code.
The backend, thus, is Common Lisp, and it is available at all times, thus leveraging all its power.