ventuspilot

> Java's REPL is like a kick in the nuts compared to using one in Common Lisp.

An IDE connected to a running Java process via JDPA/JDI (Java debug interface) is probably a better comparison.

Sure, Common Lisp will allow you to load more substantial code changes into the running process, but using JDI you can "break on specific/ all exceptions" which will allow you to inspect code before the stack is unwound, you can drop frames and re-run stuff possibly after changing values.

What's funny is that I started noticing and using these possibilities at my Java job while learning Common Lisp. Before learning about Common Lisp I was almost exclusively an edit/compile/run guy, now I often take the shorter route of edit/CTRL-SHIFT-F9.

This is funny because in the 90s I was at a similar position. I was at a university department where everybody had a Solaris 2.3 or 2.4 box as well as a PC that would dual boot into OS/2 or a 5MB MSDOS partition. Solaris, OS/2 and MSDOS would all mount the users' homedirectory from the SunOS 4.1.3 box, either via NFS or Samba.

People sadly did most of their work by booting into MSDOS and then loading Windows 3.1 from a shared readonly Sambashare that had Windows, Office and a ton of other programs ready to use. This "immutable" Windows installation worked surprisingly well as Windows no longer could destroy itself by existing and reconfiguring itself, and users could no longer run setup.exe for unneeded programs that would break everything else.

Most programming languages are defined in terms of program text, Lisp is not. Lisp is defined in terms of in-memory structures and what happens if you pass these in-memory structures to a hypothetic of actually existing function "eval".

With this way of viewing things your "( is actually a command" no longer is useful/ no longer makes sense. (I wouldn't say you're completely wrong, though, just that another view of things seems simpler to me.)

You could probably implement a Lisp with a scanner and a parser but things are a lot easier if you follow the traditional read-eval route (or preferably read-macroexpand-eval).

-> the Lisp linked lists were gone

Cons cells and linked lists are not completely gone, though:

    user=> (cons 1 (cons 2 nil))
    (1 2)

Cons cells however are somewhat limited in that the second argument to cons must be an ISeq.

AMD's linux graphics driver has entered the chat