[pjmlp]

The way one interacts with the Xerox PARC and Lisp Machines environments is much richer experience than a plain REPL.

It was a graphical REPL that could embedd live objects, which were still active to further interactive changes.

Also the ability to have the whole OS exposed via the REPLs is hardly available in modern systems.

Not alk REPLs are made alike.

[ZenoArrow]

My point is that REPLs (and other dynamic programming tools) have been in constant use since they were invented, and although respect can be paid to the originators of the approach, we're not really experiencing a rediscovery of those first ideas, but rather we're experiencing an evolution of the ideas they started. In other words, there's been plenty of activity in this area between when they were invented and now, let's not discount that activity.

As for modern systems not allowing the whole OS to be exposed via a REPL, there is at least one actively developed OS that allows this, and that's Oberon. The most recent revision of the Oberon OS was from 2013.

https://en.wikipedia.org/wiki/Oberon_(operating_system)

[pjmlp]

I was an Oberon user for a while, back when it was still being developed.

The version 3 with the Gadgets framework was quite cool.

The only modern OS environments that come close to these experiences are Windows with .NET/VS/Powershell and OS X with Playgrounds, the OS X Frameworks and Applescript.

Don't get me wrong, it is great what they are doing and I for one enjoy Notebooks, Playgrounds, modern IDEs, tooling that allows for both for JIT and AOT, while offering safety.

Just a bit nostalgic how things could have been different.

For example, when Google brought out ChromeOS and Dart, I thought there was a perfect opportunity to have a similar experience, but that is not how it turned out to be.

[posterboy]

That REPL is called a command line. Sure, it's not the same, but then it does not run on a virtual machine either (OK, LISP isn't necessarily, either).

You can still hook up a remote debugger to your kernel, I guess, but that's not quite the same then is it.

[pjmlp]

That is not even close.

EDIT: I guess I should expand a bit on that answer.

Take Oberon, which like Java has the misfortune of using the same name for the language and the respective OS.

It was based on Niklaus Wirth experience on using the Xerox Star system with Mesa/Cedar environment.

The original Native Oberon used as only executable format shared libraries. Depending on the OS variant, they were either fully AOT, or JITted on load.

There was a convention on procedures that could be made visible to the REPL or mouse commands and what type of input they would act upon.

So you could either do module.procedure parameters at the CLI, select some text at a given open window or embedded object (think OLE) and select a module.procedure at the toolbox of loaded modules.

Very simple set of primitives exposing the whole OS, both CLI window and other GUI elements as programmable elements.

You see a bit of this way of working on the ACME editor used in Plan 9, specially later on Inferno with Limbo.

[posterboy]

> That is not even close.

Stream processing should be equally mighty as list processing. What about system level access?

Edit:

> both CLI window and other GUI elements as programmable

Sure, X sucks, but it supports that. X might be infamously complicated, but there's a security hole, either way.

[pjmlp]

Text stream processing is not as powerful as data structures and functional programming composition.

How do you in X protocol select an object that represents a table in a word document and add an extra column with the standard deviation of the other rows?

Just a possible example of the type of composition that was possible.

[posterboy]

nowadays, theres possibly a related System-D feature ;)