5 ms·

Having programmed professionally in 36 languages, I must agree with this. I am having so much fun with Lisp, that I am not likely to go back. > Often developer

by wglb 2y ago

Having programmed professionally in 36 languages, I must agree with this. I am having so much fun with Lisp, that I am not likely to go back. > Often developers say how you can make a mess of a Common Lisp codebase because of such freedom it provides. But isn’t that the same with any language? There is a story about the code behind the terminal interface for Tops-10 for the PDO-10. It had been tweaked over the years adding various features, such as using control-T to see what was happening in the running program. Many attempts were made to rewrite it, but it was so intertwined, that whoever tried fixing it gave up. Three things are killer features for me with the slime+emacs running sbcl. First is that you can see the underlying source for anything down to the lisp implementation, e.g. the definition of 'macrolet'. The second thing is if there is an error, it displays the stack with the ability to see what the local variables are in any function on the stack. The third thing is that one can patch a running program, either once a breakpoint ('break) is encountered, or by doing control-C at the repl. And then resume it. It is also fun that SBCL is unreasonably fast. It compiles itself in 2m15s. I am pretty sure that gcc/clang/llvm take longer than that and also likely Rust. I have developed a habit of using s-expresions for lots of things, such as configuration files, and web page representations. I blame paredit and lisp for this tendency. See https://github.com/wglb/configuration-r https://github.com/wglb/configuration-r

ilc 2y ago
I wish you could use Genera. If you like emacs/slime. You would see how much we lost :(
- perihelions 2y ago
  What Genera ideas are Emacs/SLIME missing out on that would improve them?
  - anthk 2y ago
    A microcode tweaked down for Lisp. The whole OS being a Lisp image. Imagine running Common Lisp in bare metal. Like Mezzano OS does, but with your Intel malware ^U CPU firmware designed to run CL at even faster speeds.
  - KerrAvon 2y ago
    YouTube video demoing Genera, among other things: https://www.youtube.com/watch?v=7RNbIEJvjUA https://www.youtube.com/watch?v=7RNbIEJvjUA
- wglb 2y ago
  I've heard stories about that. Sounds awesome.
- whartung 2y ago
  But here's the thing, and I don't know, I never worked with Genera. But. Genera has been gone for over 30 years. At the time, it was certainly revolutionary. But in the computing world, where things move VERY fast, whatever made Genera amazing clearly wasn't amazing enough to replicate in full anywhere else. I'm not even talking about other languages, trying to get that dynamic environment in modern languages, with modern tooling (which has made enormous strides over the years). But not even in the Lisp world has it resurfaced. Nobody is talking about how amazing Franz Lisp is, or LispWorks, both long running, successful Common Lisp implementations. Run by smart people, run by people "who were there". We have Slime, with Emacs. We've had Slime forever. We've had solid Common Lisp implementations...forever! People still lament how good the Macintosh Lisp environment was (and honestly, I don't know how, or what made it more than what Slime might offer beyond nice access to the Mac toolbox). Do you know what has changed in modern Common Lisp implementations since Genera? NOTHING! It's Common Lisp! Common Lisp is 30 years old, and a superset of whatever Lisp Genera was running. And you can't tell me that we don't have modern Genera because Flavors (Genera's object system) is so amazing and CLOS is lacking (because even if it was, it's Common Lisp -- you can FIX IT!, or simply implement Flavors because it's written in LISP!). There are no secrets here. Veterans speak of Genera in hushed tones. Sing songs about it. But, however good it was, it's, demonstrably, not good enough to do it again. Meanwhile, there's been a dedicated pack of folks over at the Pharo side making Smalltalk even more Smalltalk with lots of new development tooling. These are folks that write Pharo so that they can make writing more Pharo even better. I swear, I think they're to the point that they just mount GIT as a file system now over there. I'm not a Smalltalk guy, but, boy, those folks have been riding a rocket for years. So, it's not lost. It's abandoned. Left behind. For whatever reason. There's a difference.
  - dokyun 2y ago
    Another thing is, that despite Genera having been gone from the real world for over 30 years, it is still nonfree, and most of the interesting software that ran on it hasn't been publically archived either. That has made it essentially worthless to most people who would otherwise be interested in it. On the contrary, the MIT Lisp Machine system from which Genera was derived is completely free, as well as the LMI system which was another derivative. And there are a small handful of enthusiasts who continue to use, share and improve them.
winter_blue 2y ago
> Three things are killer features for me with the slime+emacs running sbcl. First is that you can see the underlying source for anything down to the lisp implementation, e.g. the definition of 'macrolet'. If you’re working on a project (on its code), then you can (obviously) see its code as well. Statically typed languages make exploring the code a lot easier, especially with an IDE which leverages the type information to assist in code exploration. > The second thing is if there is an error, it displays the stack with the ability to see what the local variables are in any function on the stack. This works with debuggers (and is easy with an IDE) in most popular languages. > The third thing is that one can patch a running program, either once a breakpoint ('break) is encountered, or by doing control-C at the repl. And then resume it. You can do this with most major languages today as well.
- wglb 2y ago
  I was likely not clear in my explanation. These three things are all done from the REPL. I don't have any experience doing C or C++ from a REPL. I disagree that "Statically typed languages make exploring the code a lot easier." I'm not aware of an equivalent in C or C++ to the "esc-." method of going directly to the source. The keystroke combination to find the definition of a function or symbol using slime and emacs is "esc-." That takes you right to the code. If it is a symbol defined by Lisp, you see the underlying code in the actual source for Lisp. So the second thing is also done when running a program from the REPL. Once tripped, you can expand each element in the stack to see and inspect the variables local to that function. You can then edit the source for that function, compile only that function in place, then resume execution. I admin that I don't know how to do that in C or C++. My explanation should have referenced the REPL, which is key to these.
  - winter_blue 2y ago
    > Once tripped, you can expand each element in the stack to see and inspect the variables local to that function. When a breakpoint is tripped, with most modern IDEs and languages, you can see the local stack, global state (and pretty much all state), and this state is presented in a UI with dropdowns, etc. Debuggers in modern IDEs also let you evaluate an expression in place, where the breakpoint was tripped, so you can further dig into the local state with a debugger. This sort of works like a REPL (but you're "sort of" limited to a single expression -- but that's something you can still circumvent with an immediately-called lambda). >You can then edit the source for that function, compile only that function in place, then resume execution. This is supported by some languages, but admittedly support for this varies widely, and sometimes can be weak or finicky. For example, the JVM family of languages have a feature called HotSwap. This feature is quite old: https://www.jrebel.com/blog/java-hotswap-guide https://www.jrebel.com/blog/java-hotswap-guide -- it was introduced in 2002 with the Java 1.4 JVM. I use it even today, with personal projects, where I update the code of a running server live (without restarting the server). HotSwap unfortunately sometimes is broken with certain major JVM frameworks, but for my personal projects, I've always made sure to only use libraries that work well with HotSwap, since I consider live code patching of a running server to be an absolutely important feature. >the "esc-." method of going directly to the source To be honest, I'm not entirely sure what you mean here. When I'm working on a project (as in, I have an IDE open for it, and I'm writing the code for it), all the code is right there. When I use a debugger, I can see the stack of all the ancestral functions, and with a single click I can go to the definition of any function. Static typing basically makes the "Go to definition" more precise, as it always jumps to the place in the code (file & line) where any particular function or value is defined. With dynamically typed languages, an IDE can sometimes show you multiple option when there's multiple functions with the same name defined in different places. >These three things are all done from the REPL. I don't have any experience doing C or C++ from a REPL. Most of the features I've described above work with C and C++ IDEs (like CLion, Visual Studio, etc), except for the live code hot swapping -- I've only used live code patching with JVM HotSwap with Java, Kotlin, etc.
pfdietz 2y ago
> It compiles itself in 2m15s. My compile goes in about 1m18s. I do have it set to use multiple threads/cores.

by wglb 2y ago

ilc 2y ago

I wish you could use Genera. If you like emacs/slime. You would see how much we lost :(

perihelions 2y ago
What Genera ideas are Emacs/SLIME missing out on that would improve them?
- anthk 2y ago
  A microcode tweaked down for Lisp. The whole OS being a Lisp image. Imagine running Common Lisp in bare metal. Like Mezzano OS does, but with your Intel malware ^U CPU firmware designed to run CL at even faster speeds.
- KerrAvon 2y ago
  YouTube video demoing Genera, among other things: https://www.youtube.com/watch?v=7RNbIEJvjUA https://www.youtube.com/watch?v=7RNbIEJvjUA
wglb 2y ago
I've heard stories about that. Sounds awesome.
whartung 2y ago
But here's the thing, and I don't know, I never worked with Genera. But. Genera has been gone for over 30 years. At the time, it was certainly revolutionary. But in the computing world, where things move VERY fast, whatever made Genera amazing clearly wasn't amazing enough to replicate in full anywhere else. I'm not even talking about other languages, trying to get that dynamic environment in modern languages, with modern tooling (which has made enormous strides over the years). But not even in the Lisp world has it resurfaced. Nobody is talking about how amazing Franz Lisp is, or LispWorks, both long running, successful Common Lisp implementations. Run by smart people, run by people "who were there". We have Slime, with Emacs. We've had Slime forever. We've had solid Common Lisp implementations...forever! People still lament how good the Macintosh Lisp environment was (and honestly, I don't know how, or what made it more than what Slime might offer beyond nice access to the Mac toolbox). Do you know what has changed in modern Common Lisp implementations since Genera? NOTHING! It's Common Lisp! Common Lisp is 30 years old, and a superset of whatever Lisp Genera was running. And you can't tell me that we don't have modern Genera because Flavors (Genera's object system) is so amazing and CLOS is lacking (because even if it was, it's Common Lisp -- you can FIX IT!, or simply implement Flavors because it's written in LISP!). There are no secrets here. Veterans speak of Genera in hushed tones. Sing songs about it. But, however good it was, it's, demonstrably, not good enough to do it again. Meanwhile, there's been a dedicated pack of folks over at the Pharo side making Smalltalk even more Smalltalk with lots of new development tooling. These are folks that write Pharo so that they can make writing more Pharo even better. I swear, I think they're to the point that they just mount GIT as a file system now over there. I'm not a Smalltalk guy, but, boy, those folks have been riding a rocket for years. So, it's not lost. It's abandoned. Left behind. For whatever reason. There's a difference.
- dokyun 2y ago
  Another thing is, that despite Genera having been gone from the real world for over 30 years, it is still nonfree, and most of the interesting software that ran on it hasn't been publically archived either. That has made it essentially worthless to most people who would otherwise be interested in it. On the contrary, the MIT Lisp Machine system from which Genera was derived is completely free, as well as the LMI system which was another derivative. And there are a small handful of enthusiasts who continue to use, share and improve them.

winter_blue 2y ago

> Three things are killer features for me with the slime+emacs running sbcl. First is that you can see the underlying source for anything down to the lisp implementation, e.g. the definition of 'macrolet'. If you’re working on a project (on its code), then you can (obviously) see its code as well. Statically typed languages make exploring the code a lot easier, especially with an IDE which leverages the type information to assist in code exploration. > The second thing is if there is an error, it displays the stack with the ability to see what the local variables are in any function on the stack. This works with debuggers (and is easy with an IDE) in most popular languages. > The third thing is that one can patch a running program, either once a breakpoint ('break) is encountered, or by doing control-C at the repl. And then resume it. You can do this with most major languages today as well.

wglb 2y ago
I was likely not clear in my explanation. These three things are all done from the REPL. I don't have any experience doing C or C++ from a REPL. I disagree that "Statically typed languages make exploring the code a lot easier." I'm not aware of an equivalent in C or C++ to the "esc-." method of going directly to the source. The keystroke combination to find the definition of a function or symbol using slime and emacs is "esc-." That takes you right to the code. If it is a symbol defined by Lisp, you see the underlying code in the actual source for Lisp. So the second thing is also done when running a program from the REPL. Once tripped, you can expand each element in the stack to see and inspect the variables local to that function. You can then edit the source for that function, compile only that function in place, then resume execution. I admin that I don't know how to do that in C or C++. My explanation should have referenced the REPL, which is key to these.
- winter_blue 2y ago
  > Once tripped, you can expand each element in the stack to see and inspect the variables local to that function. When a breakpoint is tripped, with most modern IDEs and languages, you can see the local stack, global state (and pretty much all state), and this state is presented in a UI with dropdowns, etc. Debuggers in modern IDEs also let you evaluate an expression in place, where the breakpoint was tripped, so you can further dig into the local state with a debugger. This sort of works like a REPL (but you're "sort of" limited to a single expression -- but that's something you can still circumvent with an immediately-called lambda). >You can then edit the source for that function, compile only that function in place, then resume execution. This is supported by some languages, but admittedly support for this varies widely, and sometimes can be weak or finicky. For example, the JVM family of languages have a feature called HotSwap. This feature is quite old: https://www.jrebel.com/blog/java-hotswap-guide https://www.jrebel.com/blog/java-hotswap-guide -- it was introduced in 2002 with the Java 1.4 JVM. I use it even today, with personal projects, where I update the code of a running server live (without restarting the server). HotSwap unfortunately sometimes is broken with certain major JVM frameworks, but for my personal projects, I've always made sure to only use libraries that work well with HotSwap, since I consider live code patching of a running server to be an absolutely important feature. >the "esc-." method of going directly to the source To be honest, I'm not entirely sure what you mean here. When I'm working on a project (as in, I have an IDE open for it, and I'm writing the code for it), all the code is right there. When I use a debugger, I can see the stack of all the ancestral functions, and with a single click I can go to the definition of any function. Static typing basically makes the "Go to definition" more precise, as it always jumps to the place in the code (file & line) where any particular function or value is defined. With dynamically typed languages, an IDE can sometimes show you multiple option when there's multiple functions with the same name defined in different places. >These three things are all done from the REPL. I don't have any experience doing C or C++ from a REPL. Most of the features I've described above work with C and C++ IDEs (like CLion, Visual Studio, etc), except for the live code hot swapping -- I've only used live code patching with JVM HotSwap with Java, Kotlin, etc.

pfdietz 2y ago

> It compiles itself in 2m15s. My compile goes in about 1m18s. I do have it set to use multiple threads/cores.