flavio81

>The end state of every garbage collected language is a suite of tools to prevent garbage collection at all costs. >I think we can learn something here.

You're making two mistakes here:

1. Confusing "no allocation" with "avoiding the garbage collector". In non-GC languages like Rust or C there are instances you want to avoid allocation too.

2. Being oblivious that in the past many GC'd languages also had mechanisms for circunventing the garbage collector. Since long, long, long ago. Common Lisp for example (1981-). This is not a modern "realization" or "revelation".

>Intuitively it seems like a match made in heaven, since the agent can directly manipulate the running program

This should be a BIG benefit for agent-driven development, but sadly it seems that few people is taking advantage of it.

This is exciting news, and I would like to say "hello" to Richard Kenneth Eng, the sole user of Pharo in the world.

A requirement for functional programming is that there's no action from a distance, thus, functions should not modify variables outside of their scope.

This doesn't exactly mean immutable data structures are mandatory, but it helps.

In any case, most of the functions that operate on data structures in Lisp (or Common Lisp) do it in an immutable way.

PSA: If you need a Lisp that talks to C++, Common Lisp has had seamless C++ interop in the few years thanks to the CLASP implementation. It should be fairly mature by now, I understand it was born to be used in serious projects.

>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.

>No multithreading, I/O locks under GNUs/eww, glacial slow

All this would not happen if RMS had chosen Common Lisp to implement it...

>It’s really interesting reading about LISP machines but no-one’s building a new one

There have been two open source Lisp Machine OS created in the last 15 or 10 years.

However a big part of the power of the Symbolics/LMI machines was in the software itself (applications), and this is still propietary code.

To reimplement the Lisp Machine applications would take quite a big effort.

>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.

>I want C++ do exactly and only what the programmer specifies

Good luck with that.

Add Common Lisp to the list. And even Scala has fast compile times today.

>Lisp killer features were GC, good data representation, first class functions.

Lisp's killer feature is procedural macros that are extremely easy to write and debug.

Lua doesn't have such a thing, that's why Fennel was created.

Erlang also doesn't have such a thing, that's why LFE was created.

>To whoever down-voted me, please do explain how HMRs are comparable to Erlang's true hot code swapping or even Lisp's live redefinition.

based

Exactly. A post full of bollocks.