7 ms·

It's really not that much more efficient when you compare Lisps to modern languages that share features like interactive (REPL) development, garbage collection,

by evdubs 5y ago

It's really not that much more efficient when you compare Lisps to modern languages that share features like interactive (REPL) development, garbage collection, large standard libraries, concurrency primitives and abstractions, object/functional programming styles, integrated package managers, etc. When you compare modern languages, including Lisps, to something like C99, I think it's easier to see how you can be much more efficient/productive. If you take away the similarities of Lisps and modern languages, you're mostly left with the syntax and how the syntax enables macros that set Lisps apart from other languages. But, most of your Lisp code looks very much like your other code where you're writing functions, defining structures, calling object methods, etc. so it seems a stretch that the syntax and macros alone make you much more efficient/productive.

duped 5y ago
> It's really not that much more efficient when you compare Lisps to modern languages that share features like interactive (REPL) development, garbage collection, large standard libraries, concurrency primitives and abstractions, object/functional programming styles, integrated package managers, etc. pick 2! But seriously, what modern languages have all these features?
- evdubs 5y ago
  Java/JVM languages, C#/CLR languages, Python and Ruby (minus real threads, but compare to Racket with not-the-best real threading story), NodeJS (minus the "large" standard library, but compare to Scheme with a small standard library), can probably include Go
  - reikonomusha 5y ago
    I don't think any of these have REPL-driven development. They might have a "REPL" but not interactive code reloading as a part of the development cycle as is meant by a Lisp REPL.
    - School-Cotton 5y ago
      How does 'REPL-driven developent' work, exactly? Are you writing code in files and then testing it in the REPL? Or writing substantive code in the REPL and then copying it to files somehow?
      - oblio 5y ago
        From what I've seen, the cycle is a bit like this: - launch the program you want to run and have it running in the background - text editor open - bits of code in editor loaded in the running program through text selection and sending them to the be loaded (the most common scenario is doing this in Emacs) However my concern with this is... if you don't run the entire "code frozen" program at once, how can you guarantee the internal consistency of the program if over time you kind of haphazardly add bits of code to it? Maybe you loaded that function, maybe you didn't, did you add that dependency function in the correct order and at the correct "version" (where version is used loosely, every time you type in something, it's a new "version"). I'd really love for someone experienced with Lisp to describe their workflow and also maybe clarify how they handle this (in my opinion, huge) problem of possible program inconsistent states.
        synthc 5y ago
        For Clojure there are libraries to refresh the program: these stop the app, reload and evaluate all the source code files, and restart the app to ensure you are working with a consistent state that reflects the source code. Between such reloads you might end up in inconsistent states, but you benefit from fast iteration: My workflow is to update functions in the source code, send to to the repl, quickly test them in the repl, and once done, I save, commit and push the code. CI then runs the test suite from the source files.
        ravi-delia 5y ago
        I guess it just doesn't really come up that much? I personally aim to have whatever I'm not currently working on written to disk, and very rarely redefine things in the REPL once I've written them to source. Other than that every time you change anything it's automatically propagated, with a few known exceptions (macros mainly). I can say I've never wound up in an unknown state, and I'll keep a slime server running for days.
- Calamitous 5y ago
  Ruby covers everything but the concurrency story, I believe.
  - reikonomusha 5y ago
    GP didn't mention native code generation, which is a pretty compelling aspect of Common Lisp. I know there are some JITs for Ruby but it seems MRI is still canonical, just like cpython for Python.
- foldr 5y ago
  Elixir

by evdubs 5y ago

duped 5y ago

> It's really not that much more efficient when you compare Lisps to modern languages that share features like interactive (REPL) development, garbage collection, large standard libraries, concurrency primitives and abstractions, object/functional programming styles, integrated package managers, etc. pick 2! But seriously, what modern languages have all these features?

evdubs 5y ago
Java/JVM languages, C#/CLR languages, Python and Ruby (minus real threads, but compare to Racket with not-the-best real threading story), NodeJS (minus the "large" standard library, but compare to Scheme with a small standard library), can probably include Go
- reikonomusha 5y ago
  I don't think any of these have REPL-driven development. They might have a "REPL" but not interactive code reloading as a part of the development cycle as is meant by a Lisp REPL.
  - School-Cotton 5y ago
    How does 'REPL-driven developent' work, exactly? Are you writing code in files and then testing it in the REPL? Or writing substantive code in the REPL and then copying it to files somehow?
    - oblio 5y ago
      From what I've seen, the cycle is a bit like this: - launch the program you want to run and have it running in the background - text editor open - bits of code in editor loaded in the running program through text selection and sending them to the be loaded (the most common scenario is doing this in Emacs) However my concern with this is... if you don't run the entire "code frozen" program at once, how can you guarantee the internal consistency of the program if over time you kind of haphazardly add bits of code to it? Maybe you loaded that function, maybe you didn't, did you add that dependency function in the correct order and at the correct "version" (where version is used loosely, every time you type in something, it's a new "version"). I'd really love for someone experienced with Lisp to describe their workflow and also maybe clarify how they handle this (in my opinion, huge) problem of possible program inconsistent states.
      - synthc 5y ago
        For Clojure there are libraries to refresh the program: these stop the app, reload and evaluate all the source code files, and restart the app to ensure you are working with a consistent state that reflects the source code. Between such reloads you might end up in inconsistent states, but you benefit from fast iteration: My workflow is to update functions in the source code, send to to the repl, quickly test them in the repl, and once done, I save, commit and push the code. CI then runs the test suite from the source files.
      - ravi-delia 5y ago
        I guess it just doesn't really come up that much? I personally aim to have whatever I'm not currently working on written to disk, and very rarely redefine things in the REPL once I've written them to source. Other than that every time you change anything it's automatically propagated, with a few known exceptions (macros mainly). I can say I've never wound up in an unknown state, and I'll keep a slime server running for days.
Calamitous 5y ago
Ruby covers everything but the concurrency story, I believe.
- reikonomusha 5y ago
  GP didn't mention native code generation, which is a pretty compelling aspect of Common Lisp. I know there are some JITs for Ruby but it seems MRI is still canonical, just like cpython for Python.
foldr 5y ago
Elixir