3 ms·

Common Lisp REPLs and Smalltalk have ruined me for life as far as that goes.

by fmakunbound 6y ago

tartoran 6y ago
Can you expand on that?
- Jtsummers 6y ago
  Not the GP, but for me it's that Common Lisp's REPL (I have very little experience with Smalltalk) lets me construct programs in an incremental way to a degree I can't easily achieve with most other languages (especially batch compiled languages). Suppose you want a program (whole program, can't pipe pieces together via your unix shell) that downloads a file from a URL, parses it, does some computation, and prints a result. In CL, I'd first use the REPL to download the file (so it's resident in memory). Maybe I extract that download code into a function at this point, it's not that complicated. Then I'd start extracting bits of the data piece-by-piece on the REPL. If it's JSON, there's a library for it, but what if it's something that no one else has published a library for yet? It's in my head, so I'll go with it: I had to write a parser for a bespoke data recording format. Everything was in 7200 word blocks (16-bit words), and the first one was a header which said how many other blocks to expect and some other things. So I have my data, still in the REPL I can use `subseq` to grab that header. Then I can break out all the data into it one piece at a time (in this case it was all in fixed positions, except some parts were strings that may only use a portion of their range). So I have written a dozen lines of code that look something like: > (parse-integer (subseq data 75 79) :radix 16) Turn that into a function in my source file, make a class or struct that can hold all of this data in a sensible way, repeat for each function (extending the class as I go along if I didn't enter all the fields the first time). I can then test the individual functions and make an instance of the record-header class: > (make-instance 'recording ;; all those lines) ;; it worked! Take that and make it a set of functions in my source file like: (defclass recording () (...)) (defun number-of-blocks (raw-header) (parse-integer (subseq raw-header 75 79) :radix 16)) (defun parse-header (raw-header (make-instance 'recording :number-of-blocks (number-of-blocks raw-header) ...)) I can then repeat this process for how I develop the code to handle each of the data blocks. I don't have to contort myself by writing multiple compilable source files to test each part. I don't have to create a bunch of flags to my program to run subsets of it (because I haven't really finished the whole thing yet, or want to test only a specific part of the parser). If you have a good test framework (I've been pretty happy with C# here), you can approach this idea more easily. But it's really nice to have both: A REPL and a solid test framework. I don't have to think about writing a function/method for everything, many times I really just want to try out a single line of code to see what the result is (especially when exploring a new library, or prototyping). A good REPL (like CL's) lets you write single expressions and see what happens, and then you can convert that into your real program later. And these single expression executions can become my test cases if I'm doing it properly. All this said: I generally use org-mode in emacs and source blocks (commented about that elsewhere in this discussion). But I use it in the same way I described above, the main difference is that everything is already located in my source code (but not all will be in the exported .lisp file) so I have a solid record of my experiments. Much like using Maple, Mathematica, or Jupyter notebooks.
- minerjoe 6y ago
  Once you get over the learning curve, you really begin to see the productivity gains in your day by day to the point that any language without those capabilities fall short. Combine that with a world where most jobs seem to place a higher priority on other things than programmer productivity such as programmer fungibility, and your left with very few choices of places to work that allow you to be at your most productive. Say only Common Lisp had floating point arithmetic (or first class functions, or...) , and most other languages only had integers. You'd probably feel a bit hamstrun when tasked to do certain tasks in those languages.

Common Lisp REPLs and Smalltalk have ruined me for life as far as that goes.

tartoran 6y ago

Can you expand on that?

Jtsummers 6y ago
Not the GP, but for me it's that Common Lisp's REPL (I have very little experience with Smalltalk) lets me construct programs in an incremental way to a degree I can't easily achieve with most other languages (especially batch compiled languages). Suppose you want a program (whole program, can't pipe pieces together via your unix shell) that downloads a file from a URL, parses it, does some computation, and prints a result. In CL, I'd first use the REPL to download the file (so it's resident in memory). Maybe I extract that download code into a function at this point, it's not that complicated. Then I'd start extracting bits of the data piece-by-piece on the REPL. If it's JSON, there's a library for it, but what if it's something that no one else has published a library for yet? It's in my head, so I'll go with it: I had to write a parser for a bespoke data recording format. Everything was in 7200 word blocks (16-bit words), and the first one was a header which said how many other blocks to expect and some other things. So I have my data, still in the REPL I can use `subseq` to grab that header. Then I can break out all the data into it one piece at a time (in this case it was all in fixed positions, except some parts were strings that may only use a portion of their range). So I have written a dozen lines of code that look something like: > (parse-integer (subseq data 75 79) :radix 16) Turn that into a function in my source file, make a class or struct that can hold all of this data in a sensible way, repeat for each function (extending the class as I go along if I didn't enter all the fields the first time). I can then test the individual functions and make an instance of the record-header class: > (make-instance 'recording ;; all those lines) ;; it worked! Take that and make it a set of functions in my source file like: (defclass recording () (...)) (defun number-of-blocks (raw-header) (parse-integer (subseq raw-header 75 79) :radix 16)) (defun parse-header (raw-header (make-instance 'recording :number-of-blocks (number-of-blocks raw-header) ...)) I can then repeat this process for how I develop the code to handle each of the data blocks. I don't have to contort myself by writing multiple compilable source files to test each part. I don't have to create a bunch of flags to my program to run subsets of it (because I haven't really finished the whole thing yet, or want to test only a specific part of the parser). If you have a good test framework (I've been pretty happy with C# here), you can approach this idea more easily. But it's really nice to have both: A REPL and a solid test framework. I don't have to think about writing a function/method for everything, many times I really just want to try out a single line of code to see what the result is (especially when exploring a new library, or prototyping). A good REPL (like CL's) lets you write single expressions and see what happens, and then you can convert that into your real program later. And these single expression executions can become my test cases if I'm doing it properly. All this said: I generally use org-mode in emacs and source blocks (commented about that elsewhere in this discussion). But I use it in the same way I described above, the main difference is that everything is already located in my source code (but not all will be in the exported .lisp file) so I have a solid record of my experiments. Much like using Maple, Mathematica, or Jupyter notebooks.
minerjoe 6y ago
Once you get over the learning curve, you really begin to see the productivity gains in your day by day to the point that any language without those capabilities fall short. Combine that with a world where most jobs seem to place a higher priority on other things than programmer productivity such as programmer fungibility, and your left with very few choices of places to work that allow you to be at your most productive. Say only Common Lisp had floating point arithmetic (or first class functions, or...) , and most other languages only had integers. You'd probably feel a bit hamstrun when tasked to do certain tasks in those languages.