wscl VS gophernotes

You can't seriously say that, just because one targets a well-specified machine, that the language being used is well-specified. The determinism of a Clojure-on-JVM program would also be dependent on the particular code the Clojure compiler generates. In Common Lisp there is the Armed Bear Common Lisp implementation, which runs on a JVM. Does it benefit from JVM determinism or not? It probably does not, because the JVM is simply not aware of undefined behaviour that ABCL or Clojure are implicitly defining.

When it comes to having different platforms, it would also be necessary for any other compilers to generate semantically identical code. Different Clojure systems do _not_ do that. For example, arithmetic in ClojureScript uses JS floats where Clojure-on-JVM and others use integers of some size.

In my experience, writing a non-conforming CL program is hard, and much harder than writing a program without undefined behaviour in C. I am not sure why, other than vaguely suggesting the UB is more "localised" in some way. But there is also a modification of the ANSI standard being worked on, which attempts to eliminate undefined behaviour <https://github.com/s-expressionists/wscl>.

Common Lisp was standardised by an ANSI committee. Here is a list of issues that were voted on. Nowadays there is also the Well Specified Common Lisp project, but no issues have been voted on yet.

SICL is still an implementation of Common Lisp, and not of a new programming language (give or take some additional features, such as first-class global environments). That said, there is some overlap between the authors of SICL and the authors of Well Specified Common Lisp <https://github.com/s-expressionists/wscl>; but WSCL only really defines some undefined and contradictory behaviour in the ANSI Common Lisp specification.

The HyperSpec is a (derived work of a) language specification - its job is precisely to explain infrequently used things in too much detail. (And it ironically fails in many places.) Generally, one does not want to read a specification, unless they know they need to check something specific.

https://github.com/gopherdata/gophernotes

I've had this bookmarked for some time and just havent gotten around to it.

Gopher Notes Kernel for jupyter notebooks? Could be useful :)

I started this because gophernotes was not working for another project I'm slowing working on -- it is interpreted, and not up-to-date (generics, etc).

A go kernel is available at https://github.com/gopherdata/gophernotes

> You do know that statically typed languages have REPLs too? Like the ML family, including Haskell.

I do, but that I don't see how that relates to the bit of my post which you've quoted. I certainly didn't claim or imply that REPL and static type systems were mutually exclusive, only that REPLs are a poor substitute for many static analysis tasks.

> And when using something like a Jupyter notebook with a kernel for your compiled language https://github.com/gopherdata/gophernotes you can do similar interactive programming.

Yeah, I'm aware. I operate a large JupyterHub cluster (among many other things) at work. :)

> Lisp REPLs take that a step further, as you interact with and in your whole actually running program.

That sounds nice, but it's too abstract to persuade IMHO.

If you are coming from python,jupyter notebook, gophernotes is a great library to setup your own playground.

Why can't you just build libraries to make Go a better language for data science? There's already Go support for a Jupyter Notebooks kernel: https://github.com/gopherdata/gophernotes