5 ms·

ADDENDUM: I love Lisp but I want to clarify that its secret sauce is that it enables exploratory programming: programming from inside the system. While most la

by sph 3y ago

ADDENDUM: I love Lisp but I want to clarify that its secret sauce is that it enables exploratory programming: programming from inside the system. While most languages are akin to preparing a detailed blueprint and executing it (then stop to update the blueprint and try again), exploratory programming is like sculpture. You have an unformed mass full of unrealised potential, and you slowly carve it to shape. The ADHD/Bipolar mind of the article isn't great at making plans, it's great at following its gut instinct, making shit up step by step. Lisp enables this flow, but also Forth, Smalltalk, Self, etc., which I've been deeply obsessed with lately. Sadly, all we have today on the mainstream are basic REPLs which are a harmless, defanged version of these old environments promoting creativity and flow state.

troupe 3y ago
> programming from inside the system. Can you elaborate on that? I think you are saying that REPLs in other languages don't do what you can do in Lisp, but I don't think I know enough to fully understand why.
- unixr 3y ago
  Imagine this: You start a fresh REPL session with a vague idea of something you want to build. You have good tooling that enables you to write code in your favourite editor and pipe it to the REPL through a socket. You write a couple of functions and send them to the REPL. You call them a few times with some test arguments, maybe define a couple global variables while testing, and realize one of the functions doesn't quite behave the way you want. You tweak the code and send it again to the REPL. The function is redefined and works properly now. You're happy with what you have for now, so you save the entire current environment of the REPL, functions and global variables and all, into a file (called an image) on your disk. The next day, you come up with a great new feature so you load up the image and continue exactly where you left off yesterday, with all your functions and even global variables as they were defined previously. You add your new feature, all while testing and tweaking your functions interactively, and then you save the new environment into an updated image. Any other code that loads that image will be able to take advantage of your updated functions and variables now. The power of lisp is not just the fact that there's a REPL — a lot of languages have that now. It's the ability to save and reload the entire current state of the REPL (interactively or programmatically), which enables the powerful interactive development that so many lispers, including myself, rave about.
  - bloopernova 3y ago
    This is the kind of thing that should be included in language tutorials! It particularly resonates with me because I think so many project teams neglect the Developer Experience. In my opinion DevOps should be more about making coding, testing and deploying as frictionless as possible.
    - convolvatron 3y ago
      when this term first came out, it really seemed like that was the point now it just seems like a hundred children you have to pacify and get to bed before you can even start working
  - troupe 3y ago
    That is very helpful. Thank you. Most of my exposure to Lisp has been Scheme and Racket and minimal at that. Are these images you describe something that is part of a particular distribution of Common Lisp?
    - whartung 3y ago
      Images are pretty routine amongst most of them (though not all). In the end what you have is a base image, and then a set of code and instructions to transform that image into your runtime image, then you distribute that image as your "application". I have never needed to do this, as all of my work has been utilitarian in nature, rather than some kind of monolith distributed to others. I simply load my code on to the stock image and go from there. But even then, for folks that do that, they may well load up the stock image with useful and common, personal, utilities, and snapshot that. Their "application" is their essential working environment. Smalltalk does, and Forth can work from this concept of an image. Schemes tend to not be this way. They are interactive, but the image concept is not as ingrained in the Scheme world. Instead, it's more like doing development in something like Bash -- an interactive environment to be sure, but one that always resets to the baseline state and must be reloaded when started. There are certainly Schemes that can do this, it's just not as routine.
  - mark_l_watson 3y ago
bloopernova 3y ago
"The ADHD/Bipolar mind of the article isn't great at making plans, it's great at following its gut instinct, making shit up step by step." Which is why I do best with the command line, piping outputs and rapidly iterating to get the output I want. And why I struggled so much writing Python in a larger, more complex script/app. I wanted to constantly run and rerun the smaller parts to get each one just right. Unfortunately that doesn't work great when you're interacting with a half dozen different APIs that take minutes to run each time. Until I realized what was slowing me down, I was just getting more and frustrated. Now I am at least aware of the issue. Part and parcel of growing from sysadmin to DevOps to coder, I guess? Now I know to look for shims or stubs that help me. Now I can write tests that isolate and verify, rather than run the whole damn thing end to end. It helps me to think of objects as those command line tools. Their method parameters are the stdin that get passed through pipes. I apologize that this isn't particularly profound, but sometimes epiphanies are made from smaller realizations. Maybe I should have tried writing part of my most recent script in Lisp? Just to see if it resonated like described in this thread?
- sph 3y ago
  > I wanted to constantly run and rerun the smaller parts to get each one just right. > Maybe I should have tried writing part of my most recent script in Lisp? 90% of Lisp programming is selecting an expression in your editor and pressing C-x C-e to execute it. And continue until you are satisfied it operates as you want, then integrate it in the larger system.
- jimmaswell 3y ago
  > I wanted to constantly run and rerun the smaller parts to get each one just right. One one hand, as you alluded too, I've found unit tests are a great solution to this. Kill two birds with one stone - rapidly iterate on a chunk of code and come out of it with solid test coverage. It's too bad that's not very feasible in gamedev most of the time with so much going on in the world, but over time I think that environment improved my skills to where it's less of a problem.
kragen 3y ago
what about gnumeric, observablehq, jupyter, the unix shell, and the browser console (firebug and its clones) admittedly it's hard to save the state of the page after you hack on it in the browser console, but jupyter doesn't really have that problem

by sph 3y ago

troupe 3y ago

> programming from inside the system. Can you elaborate on that? I think you are saying that REPLs in other languages don't do what you can do in Lisp, but I don't think I know enough to fully understand why.

unixr 3y ago
Imagine this: You start a fresh REPL session with a vague idea of something you want to build. You have good tooling that enables you to write code in your favourite editor and pipe it to the REPL through a socket. You write a couple of functions and send them to the REPL. You call them a few times with some test arguments, maybe define a couple global variables while testing, and realize one of the functions doesn't quite behave the way you want. You tweak the code and send it again to the REPL. The function is redefined and works properly now. You're happy with what you have for now, so you save the entire current environment of the REPL, functions and global variables and all, into a file (called an image) on your disk. The next day, you come up with a great new feature so you load up the image and continue exactly where you left off yesterday, with all your functions and even global variables as they were defined previously. You add your new feature, all while testing and tweaking your functions interactively, and then you save the new environment into an updated image. Any other code that loads that image will be able to take advantage of your updated functions and variables now. The power of lisp is not just the fact that there's a REPL — a lot of languages have that now. It's the ability to save and reload the entire current state of the REPL (interactively or programmatically), which enables the powerful interactive development that so many lispers, including myself, rave about.
- bloopernova 3y ago
  This is the kind of thing that should be included in language tutorials! It particularly resonates with me because I think so many project teams neglect the Developer Experience. In my opinion DevOps should be more about making coding, testing and deploying as frictionless as possible.
  - convolvatron 3y ago
    when this term first came out, it really seemed like that was the point now it just seems like a hundred children you have to pacify and get to bed before you can even start working
- troupe 3y ago
  That is very helpful. Thank you. Most of my exposure to Lisp has been Scheme and Racket and minimal at that. Are these images you describe something that is part of a particular distribution of Common Lisp?
  - whartung 3y ago
    Images are pretty routine amongst most of them (though not all). In the end what you have is a base image, and then a set of code and instructions to transform that image into your runtime image, then you distribute that image as your "application". I have never needed to do this, as all of my work has been utilitarian in nature, rather than some kind of monolith distributed to others. I simply load my code on to the stock image and go from there. But even then, for folks that do that, they may well load up the stock image with useful and common, personal, utilities, and snapshot that. Their "application" is their essential working environment. Smalltalk does, and Forth can work from this concept of an image. Schemes tend to not be this way. They are interactive, but the image concept is not as ingrained in the Scheme world. Instead, it's more like doing development in something like Bash -- an interactive environment to be sure, but one that always resets to the baseline state and must be reloaded when started. There are certainly Schemes that can do this, it's just not as routine.
- mark_l_watson 3y ago

bloopernova 3y ago

"The ADHD/Bipolar mind of the article isn't great at making plans, it's great at following its gut instinct, making shit up step by step." Which is why I do best with the command line, piping outputs and rapidly iterating to get the output I want. And why I struggled so much writing Python in a larger, more complex script/app. I wanted to constantly run and rerun the smaller parts to get each one just right. Unfortunately that doesn't work great when you're interacting with a half dozen different APIs that take minutes to run each time. Until I realized what was slowing me down, I was just getting more and frustrated. Now I am at least aware of the issue. Part and parcel of growing from sysadmin to DevOps to coder, I guess? Now I know to look for shims or stubs that help me. Now I can write tests that isolate and verify, rather than run the whole damn thing end to end. It helps me to think of objects as those command line tools. Their method parameters are the stdin that get passed through pipes. I apologize that this isn't particularly profound, but sometimes epiphanies are made from smaller realizations. Maybe I should have tried writing part of my most recent script in Lisp? Just to see if it resonated like described in this thread?

sph 3y ago
> I wanted to constantly run and rerun the smaller parts to get each one just right. > Maybe I should have tried writing part of my most recent script in Lisp? 90% of Lisp programming is selecting an expression in your editor and pressing C-x C-e to execute it. And continue until you are satisfied it operates as you want, then integrate it in the larger system.
jimmaswell 3y ago
> I wanted to constantly run and rerun the smaller parts to get each one just right. One one hand, as you alluded too, I've found unit tests are a great solution to this. Kill two birds with one stone - rapidly iterate on a chunk of code and come out of it with solid test coverage. It's too bad that's not very feasible in gamedev most of the time with so much going on in the world, but over time I think that environment improved my skills to where it's less of a problem.

kragen 3y ago

what about gnumeric, observablehq, jupyter, the unix shell, and the browser console (firebug and its clones) admittedly it's hard to save the state of the page after you hack on it in the browser console, but jupyter doesn't really have that problem