4 ms·

It's possible that you have experienced an enlightenment that I have yet to, but ultimately I like lisp because parenthesis are pretty, I hate remembering synta

It's possible that you have experienced an enlightenment that I have yet to, but ultimately I like lisp because parenthesis are pretty, I hate remembering syntax, keywords/symbols are nicer than immutable strings, and typing out commas makes me sad (not that you'd know it from the way I abuse them in this comment). I mean, lots of languages have REPLs now- people get that they're really useful! This isn't secret knowledge, the pros and cons are on display. Macros are nice (though of course Ruby has them too), but I'm always surprised by how far people get with method call chaining (hell they have monads over in JS land now). The experience of writing lisp is very similar to that of writing Ruby, or even Javascript- really any dynamically typed language with good enough lambda support. It's by no means as strange as an array or concatenate language. It would surprise me very much if the reason you and I like lisp, or other people don't like lisp, was anything other than taste!

User23 3y ago
Nothing you say is in any way incorrect and I agree with it. However, for me, the experience of writing Lisp is very different from that of writing Ruby, or Perl, despite the latter languages having a great many Lispy features. In fact I jokingly call Perl a Lisp-6ish, because of how typeglobs let you mess with the symbol table directly and it has separate namespaces for SCALAR, ARRAY, HASH, CODE (I think that's the subroutine namespace), and a few others if I recall correctly. It's been a bit since I wrote any XS which is pretty much the best way to grok Perl internals. And that difference comes down to interactivity. I totally agree that REPLs are great and can bring a measure of interactivity to other languages. Except I barely ever use the REPL when I'm writing Lisp. I just evaluate the current form directly. Haven't you ever wondered why DEFPARAMETER and DEFVAR both exist? Having both makes no sense in a world where the Common Lisp REPL as equivalent to, say, irb. I'd say that notebooks are where non Lisp languages are coming closest to a kind of Lispy/Smalltalky interactive programming environment. And yes you can do some very very clever things with the JS console in a browser that are in tune with the Lisp way. And that's no surprise since JavaScript was originally a Lisp DSL and that very much shaped its philosophy. Interestingly enough the Lispiest non Lisp dev experience I've professionally had is writing java 8 using Eclipse on the JVM treating the unit test runner as a kind of C-x C-e. It's no wonder Clojure was such a good fit for the JVM.
- ravi-delia 3y ago
  I think this is mostly an issue of tooling! I admit I often find myself recompiling a full file because SBCL is just so goddamn quick it doesn't make a difference, so perhaps I'm missing something essential. But with tree sitter you could totally write a plugin to, say, run the literal content of a python expression in the REPL. It's just shuffling text around after all. The fact that people haven't done this may indicate, and I stress may, that this is not something that people are missing. I personally can't use anything without vim bindings. I have evil mode in Emacs, vimium while I'm in Firefox, vim bindings in Nyxt, and an aversion to using any program that isn't one of the above. This is not just hipsterism- on 10 occasions while writing this comment I've had to delete a kj or jk as I tried to exit edit mode. That doesn't really mean non-vim bindings are defective, if you catch my drift. No judgement here! But it's a possibility you might consider.
hajile 3y ago
Those REPLs aren’t even close to Common Lisp. Common Lisp borrowed parts of the smalltalk development strategy. You can start a process and gradually update it in very sophisticated ways as you live code against it. You wouldn’t dream of packaging up your Python REPL and shipping it to users. You certainly wouldn’t open a Python REPL on your production server and start redefining functions and data structures on the fly. This kind of experience is pretty much limited to Smalltalk, Forth, and Common Lisp (with Erlang having a more limited ability to do live updates).
- ravi-delia 3y ago
  I know, I enjoy CL quite a bit. I actually currently have REPLs running for a few services, because I like managing them from the inside. But while you can, if you want, deploy major changes by redefining a bunch of stuff on production servers without version control or backups, you...should not. It's really nice to be able to redefine classes while you're playing around- but CL's handling of class redefinition just isn't up to snuff on a production server. It's just like doing live changes to your schema, only you see, rather more so. Compared to scp->shutdown->mv->start, if you can possibly tolerate <10s of downtime, or the many existing solutions for gradual rollout if you can't, it just doesn't make sense. If you had to pick between having REPL access in production and REPL access locally, would it be close? Because I value being able to mess around with a REPL while developing thousands of times as much as I like a neat toy in production. And that ability is exactly what Python or Ruby or Erlang give you. Technically lacking compared to the full suite? Perhaps. But we're talking 0.999, not 0.5.
  - aidenn0 3y ago
    > If you had to pick between having REPL access in production and REPL access locally, would it be close? Because I value being able to mess around with a REPL while developing thousands of times as much as I like a neat toy in production. And that ability is exactly what Python or Ruby or Erlang give you. Technically lacking compared to the full suite? Perhaps. But we're talking 0.999, not 0.5. I can't speak to Ruby or Erlang, but the Python REPL is much less than 0.999 because of the semantics of "import" making it very challenging to change code once it's been imported.

User23 3y ago

Nothing you say is in any way incorrect and I agree with it. However, for me, the experience of writing Lisp is very different from that of writing Ruby, or Perl, despite the latter languages having a great many Lispy features. In fact I jokingly call Perl a Lisp-6ish, because of how typeglobs let you mess with the symbol table directly and it has separate namespaces for SCALAR, ARRAY, HASH, CODE (I think that's the subroutine namespace), and a few others if I recall correctly. It's been a bit since I wrote any XS which is pretty much the best way to grok Perl internals. And that difference comes down to interactivity. I totally agree that REPLs are great and can bring a measure of interactivity to other languages. Except I barely ever use the REPL when I'm writing Lisp. I just evaluate the current form directly. Haven't you ever wondered why DEFPARAMETER and DEFVAR both exist? Having both makes no sense in a world where the Common Lisp REPL as equivalent to, say, irb. I'd say that notebooks are where non Lisp languages are coming closest to a kind of Lispy/Smalltalky interactive programming environment. And yes you can do some very very clever things with the JS console in a browser that are in tune with the Lisp way. And that's no surprise since JavaScript was originally a Lisp DSL and that very much shaped its philosophy. Interestingly enough the Lispiest non Lisp dev experience I've professionally had is writing java 8 using Eclipse on the JVM treating the unit test runner as a kind of C-x C-e. It's no wonder Clojure was such a good fit for the JVM.

ravi-delia 3y ago
I think this is mostly an issue of tooling! I admit I often find myself recompiling a full file because SBCL is just so goddamn quick it doesn't make a difference, so perhaps I'm missing something essential. But with tree sitter you could totally write a plugin to, say, run the literal content of a python expression in the REPL. It's just shuffling text around after all. The fact that people haven't done this may indicate, and I stress may, that this is not something that people are missing. I personally can't use anything without vim bindings. I have evil mode in Emacs, vimium while I'm in Firefox, vim bindings in Nyxt, and an aversion to using any program that isn't one of the above. This is not just hipsterism- on 10 occasions while writing this comment I've had to delete a kj or jk as I tried to exit edit mode. That doesn't really mean non-vim bindings are defective, if you catch my drift. No judgement here! But it's a possibility you might consider.

hajile 3y ago

Those REPLs aren’t even close to Common Lisp. Common Lisp borrowed parts of the smalltalk development strategy. You can start a process and gradually update it in very sophisticated ways as you live code against it. You wouldn’t dream of packaging up your Python REPL and shipping it to users. You certainly wouldn’t open a Python REPL on your production server and start redefining functions and data structures on the fly. This kind of experience is pretty much limited to Smalltalk, Forth, and Common Lisp (with Erlang having a more limited ability to do live updates).

ravi-delia 3y ago
I know, I enjoy CL quite a bit. I actually currently have REPLs running for a few services, because I like managing them from the inside. But while you can, if you want, deploy major changes by redefining a bunch of stuff on production servers without version control or backups, you...should not. It's really nice to be able to redefine classes while you're playing around- but CL's handling of class redefinition just isn't up to snuff on a production server. It's just like doing live changes to your schema, only you see, rather more so. Compared to scp->shutdown->mv->start, if you can possibly tolerate <10s of downtime, or the many existing solutions for gradual rollout if you can't, it just doesn't make sense. If you had to pick between having REPL access in production and REPL access locally, would it be close? Because I value being able to mess around with a REPL while developing thousands of times as much as I like a neat toy in production. And that ability is exactly what Python or Ruby or Erlang give you. Technically lacking compared to the full suite? Perhaps. But we're talking 0.999, not 0.5.
- aidenn0 3y ago
  > If you had to pick between having REPL access in production and REPL access locally, would it be close? Because I value being able to mess around with a REPL while developing thousands of times as much as I like a neat toy in production. And that ability is exactly what Python or Ruby or Erlang give you. Technically lacking compared to the full suite? Perhaps. But we're talking 0.999, not 0.5. I can't speak to Ruby or Erlang, but the Python REPL is much less than 0.999 because of the semantics of "import" making it very challenging to change code once it's been imported.