5 ms·

>> live coding capability Since i was introduced to lisp, this is my number 1 desire everytime i write code. The js ecosystem gets a lot of hate but the power

>> live coding capability Since i was introduced to lisp, this is my number 1 desire everytime i write code. The js ecosystem gets a lot of hate but the power of some of the browser tooling coupled with some kinds of hot reloading (specifically the kind that maintains state), it can be super nice to work with. EDIT: To be clear this isn't as powerful as the lisp version of this - i.e. the condition system and just the nature of how cheap/fast/quick changing code is in lisp while it's running, not the approximation way this is done in JS by stopping, swapping and potentially reinitialising >> Smalltalk’s image also makes software deployment a breeze When i started playing with lisp this was one of my first concerns, how do i deploy this? I was dreaming up all these rube goldberg scenarios with OCI container images. Turns out it's easy to tell sbcl to create an image (save-lisp-and-die - this would be like publishing a fat jar for a java dev) then to run that elsewhere (sbcl --core). Everytime i poke at podman and buildah, i have this nagging annoying feeling about how much simpler this could all be.

regularfry 4y ago
What frustrates me with `save-lisp-and-die` is the `-and-die`. It would be so much nicer not to have to stop the world.
bitwize 4y ago
You can get 90% of the coveted "Lisp machine experience" with a modern IDE that does hot reloading in its debugger. Today, tooling matters much more than the language itself; and the tooling around modern languages is very advanced and powerful, having had more great minds working on it than Lisp and Smalltalk ever had.
- CraigJPerry 4y ago
  90% seems high. Pick the best IDE hot reloading experience you know of - for me that's JRebel so not actually provided by my IDE but available to me there and way more powerful than the hot swapping natively available in the JVM and usually exposed to me through intellij IDE. E.g. i can change the arity of a function with jrebel but not with hot swapping in intellij. Compare that experience with editing my code and inline without starting any companion process, without triggering any hotreload function, without even saving my source file, being able to evaluate the results of changing a function and seeing the results either inline or in a dedicated buffer depending on the keystroke i chose to trigger the evaluation. I'm doing a terrible job of explaining the difference i see - what i'm digging at is the lisp approach is completely frictionless. The JRebel experience which is great, the best i know if in a non-lisp language, is full of little (and some large) frictions. >> tooling matters much more than the language itself I'd suggest a counterpoint to that, the tooling for java is really very good - and yet, there's a better experience to be had with "structural editing of forms" in clojure than there is going back to "normal editing of lines of code" with java. I think most languages i've experienced can be interchanged to a large degree - java, javascript, c#, c, rust, python, ... unless the task is something exotic, i can probably complete the same task in any of those in a comparable way. Lisp, SQL, prolog and array languages are different though. The way i would solve the task in those is likely to be radically different in approach.
- duped 4y ago
  We have very different experiences then - hot reloading almost never works in native development, unless the language and ecosystem have been designed around it. Which is not really the reality we live in. It's nowhere close to "90%" when most projects cannot be reloaded.
- lispm 4y ago
  The Lisp Machine experience has obvious drawbacks, but there are things that are simply not there on modern platforms (with some exceptions, like a Smalltalk on the metal). Its OS is completely written in a high-level language, it uses a high-level OOP model (for example based on the Flavors / CLOS object systems) and running inside one memory pool. Receiving an TCP packet is a OOP method, just like sending a mail is an OOP message. In the development environment both are fully visible, on the fly changeable, ... If I'm debugging an NFS connection, I could change a UDP method on the fly and it will be immediately active system wide - without any 'hotloading' limitations. You can mostly edit/change everything in the OS and applications without boundaries. That offers countless ways to kill the system, but it means that the TCP implementation is open in the same way like an application is - it can always be used without much performance loss in a full debug mode, where things can be inspected, modified, replaced, edited, ... This is not hotloading of a component, it is a completely open architecture an all levels - from a mailer UI, over the SMTP implementation, the networking stack, down to the network interface. There is a single high-level stack and everything on the stack is accessible/inspectable. One is bringing the thing into a debug mode or deploying it in a debug mode, it can always run fully inspectable and changeable. As mentioned the drawback is that this makes it also fragile when there are very little protections. Make a wrong change to the UDP receive method and the running OS then won't receive any UDP packages...
scroot 4y ago
> The js ecosystem gets a lot of hate but the power of some of the browser tooling As a JS developer, this is what really irks me: we have this powerful, interactive, live JS-enabled environment (the browser) that also holds our application. It has great debugging and inspection tools. Why can't we develop our applications live inside the browser? Why do I have to go off to some other tool?

regularfry 4y ago

What frustrates me with `save-lisp-and-die` is the `-and-die`. It would be so much nicer not to have to stop the world.

bitwize 4y ago

You can get 90% of the coveted "Lisp machine experience" with a modern IDE that does hot reloading in its debugger. Today, tooling matters much more than the language itself; and the tooling around modern languages is very advanced and powerful, having had more great minds working on it than Lisp and Smalltalk ever had.

CraigJPerry 4y ago
90% seems high. Pick the best IDE hot reloading experience you know of - for me that's JRebel so not actually provided by my IDE but available to me there and way more powerful than the hot swapping natively available in the JVM and usually exposed to me through intellij IDE. E.g. i can change the arity of a function with jrebel but not with hot swapping in intellij. Compare that experience with editing my code and inline without starting any companion process, without triggering any hotreload function, without even saving my source file, being able to evaluate the results of changing a function and seeing the results either inline or in a dedicated buffer depending on the keystroke i chose to trigger the evaluation. I'm doing a terrible job of explaining the difference i see - what i'm digging at is the lisp approach is completely frictionless. The JRebel experience which is great, the best i know if in a non-lisp language, is full of little (and some large) frictions. >> tooling matters much more than the language itself I'd suggest a counterpoint to that, the tooling for java is really very good - and yet, there's a better experience to be had with "structural editing of forms" in clojure than there is going back to "normal editing of lines of code" with java. I think most languages i've experienced can be interchanged to a large degree - java, javascript, c#, c, rust, python, ... unless the task is something exotic, i can probably complete the same task in any of those in a comparable way. Lisp, SQL, prolog and array languages are different though. The way i would solve the task in those is likely to be radically different in approach.
duped 4y ago
We have very different experiences then - hot reloading almost never works in native development, unless the language and ecosystem have been designed around it. Which is not really the reality we live in. It's nowhere close to "90%" when most projects cannot be reloaded.
lispm 4y ago
The Lisp Machine experience has obvious drawbacks, but there are things that are simply not there on modern platforms (with some exceptions, like a Smalltalk on the metal). Its OS is completely written in a high-level language, it uses a high-level OOP model (for example based on the Flavors / CLOS object systems) and running inside one memory pool. Receiving an TCP packet is a OOP method, just like sending a mail is an OOP message. In the development environment both are fully visible, on the fly changeable, ... If I'm debugging an NFS connection, I could change a UDP method on the fly and it will be immediately active system wide - without any 'hotloading' limitations. You can mostly edit/change everything in the OS and applications without boundaries. That offers countless ways to kill the system, but it means that the TCP implementation is open in the same way like an application is - it can always be used without much performance loss in a full debug mode, where things can be inspected, modified, replaced, edited, ... This is not hotloading of a component, it is a completely open architecture an all levels - from a mailer UI, over the SMTP implementation, the networking stack, down to the network interface. There is a single high-level stack and everything on the stack is accessible/inspectable. One is bringing the thing into a debug mode or deploying it in a debug mode, it can always run fully inspectable and changeable. As mentioned the drawback is that this makes it also fragile when there are very little protections. Make a wrong change to the UDP receive method and the running OS then won't receive any UDP packages...

scroot 4y ago

> The js ecosystem gets a lot of hate but the power of some of the browser tooling As a JS developer, this is what really irks me: we have this powerful, interactive, live JS-enabled environment (the browser) that also holds our application. It has great debugging and inspection tools. Why can't we develop our applications live inside the browser? Why do I have to go off to some other tool?