I suspect that you can throw this exact comment for any post that at least tangentially concerns programming languages :)
Talking about details:
Lisp does not have a good way to scope methods and fields by an object (I suspect that the dot-syntax is the greatest invention of OOP ever, ergonomically);
Lisp as a language (or any of its core tooling) does not track history of source code changes; image-based approach of Smalltalk is more friendly to keeping history;
Lisp does not define any special tooling for interaction with the programmer (although REPLs are definitely a Lisp invention); SLIME-style connections to a running program grew organically later; Lisp has ability to re-run different parts of code in the same context, but does not have ability to track dependent parts of code.
Lisp does not track refactoring and copy-paste in any way. Even Java tooling is much better at automatic refactoring.
Also static types, algebraic types, monadic computation expressions, hindley milner type inference, type providers, no nulls by default.
But yes in a very twisted sense every language is a lisp, in the same way that every language is a kind of forth. Amazing what you can do once you disregard most things.
All these are nice things to have, but they still exist on the code level, not on the level of interaction with a programmer. The article talks about things specific to interaction of a language/environment with a programmer.
Although typed holes and type-driven development are an interesting new development in the ergonomics of programming languages, yes.
P.S. In case you are offended by my “calling” strongly statically-typed languages “Lisps”, that was not my intention: my point was that for any programming language on earth a Lisp aficionado can find an obscure research dialect of Lisp that had prototypes of some concepts from that language (or something which is not, but looks similar enough for them).
Not offended, I just felt that it was an overly broad characterization of programming experience. For the record I don’t dislike lisp in any way, and there is statically typed racket. You can recreate pretty much any language feature in any lisp but doing so eventually approaches creating an entirely new language. While you can do this in any language I’ll concede that it’s vastly easier to do this with a lisp or an ML.
[..] for any programming language on earth a Lisp aficionado can find an obscure research dialect of Lisp that had prototypes of some concepts from that language
Interestingly, the Lisp prototype of most of the above features was… ML.
Rather than treating programs as syntactic expressions, we should treat programs as results of a series of interactions that were used to create the program. Those interactions include writing code, but also refactoring, copy and paste or running a bit of program in REPL or a notebook system.
every single word is related to any of a lisp dialects.
It’s regular way to develop lisp programs.
You write function, play around with REPL, make sure it works or fails.
When you only use one language concepts that apply to many many languages appear to only apply to your language. That’s the only way I could assume you could possibly conflate an ML with a lisp.
Don’t you, as a ruby, developer, do most of your initial development in a REPL before saving the structures that work? This is a really common pattern with all scripting languages (and many non-interpreted languages that nevertheless have a REPL).
Long answer - REPL is not integrated with code editor. You cannot tell your editor to run this particular chunk of code.
But let’s assume you can integrate ruby REPL with your code editor. I cannot imagine how would you run particular method of some particular class you want to play around with. You have to evaluate the whole classes. But let’s assume it’s okay to evaluate whole class to run one method. What about dependencies?
For example you are writing project MVP with rails. Each time you want to test your super lightweight and simple class - you have to load every single dependency, since you cannot attach to the running ruby process.
And I’m not even talking about global immutability, which will add a lot of headache as well.
Ohh, you’re a rails developer. OK, I understand now – having a web server & a web browser in the way makes it hard to do anything iteratively in a REPL.
It’s pretty common, with scripting languages, to load all supporting modules into the REPL, experiment, and either export command history or serialize/prettyprint definitions (if your language stores original source) to apply changes. Image-based environments (like many implementations of smalltalk) will keep your changes persistent for you & you don’t actually need to dump code unless you’re doing a non-image release. All notebook-based systems (from mathematica to jupyter) are variations on the interactive-REPL model. In other words, you don’t need a lisp machine to work this way: substantial amounts of forth, python, julia, and R are developed like this (to choose an arbitrary smattering of very popular languages), along with practically all shell scripts.
Vim & emacs can spawn arbitrary interactive applications and copy arbitrary buffers to them, & no doubt ship with much more featureful integrations with particular languages; I don’t have much familiarity with alternative editors, though I’d be shocked that anybody would call something a ‘code editor’ that couldn’t integrate a REPL.
I think similar things can be done in scala. I mostly mean to say that a web stack represents multiple complicated and largely-inaccessible layers that aren’t terribly well-suited to REPL use, half of which are stuck across a network link on an enormously complex third-party sandboxed VM. Editing HTTP handlers on live servlets is of limited utility when you’re generating code in three different languages & fighting a cache.
Isn’t that reinventing lisp?
I suspect that you can throw this exact comment for any post that at least tangentially concerns programming languages :)
Talking about details:
My bad that I used word “LISP” instead of “LISP dialect” or even “Clojure” (as a good example of modern lisp dialect)
Also static types, algebraic types, monadic computation expressions, hindley milner type inference, type providers, no nulls by default.
But yes in a very twisted sense every language is a lisp, in the same way that every language is a kind of forth. Amazing what you can do once you disregard most things.
All these are nice things to have, but they still exist on the code level, not on the level of interaction with a programmer. The article talks about things specific to interaction of a language/environment with a programmer.
Although typed holes and type-driven development are an interesting new development in the ergonomics of programming languages, yes.
P.S. In case you are offended by my “calling” strongly statically-typed languages “Lisps”, that was not my intention: my point was that for any programming language on earth a Lisp aficionado can find an obscure research dialect of Lisp that had prototypes of some concepts from that language (or something which is not, but looks similar enough for them).
Not offended, I just felt that it was an overly broad characterization of programming experience. For the record I don’t dislike lisp in any way, and there is statically typed racket. You can recreate pretty much any language feature in any lisp but doing so eventually approaches creating an entirely new language. While you can do this in any language I’ll concede that it’s vastly easier to do this with a lisp or an ML.
Interestingly, the Lisp prototype of most of the above features was… ML.
How does this relate to LISP?
every single word is related to any of a lisp dialects. It’s regular way to develop lisp programs. You write function, play around with REPL, make sure it works or fails.
When you only use one language concepts that apply to many many languages appear to only apply to your language. That’s the only way I could assume you could possibly conflate an ML with a lisp.
Well I’m a ruby developer, far away from being pro-lisp-dialect developer.
Don’t you, as a ruby, developer, do most of your initial development in a REPL before saving the structures that work? This is a really common pattern with all scripting languages (and many non-interpreted languages that nevertheless have a REPL).
Quick answer is no.
Long answer - REPL is not integrated with code editor. You cannot tell your editor to run this particular chunk of code. But let’s assume you can integrate ruby REPL with your code editor. I cannot imagine how would you run particular method of some particular class you want to play around with. You have to evaluate the whole classes. But let’s assume it’s okay to evaluate whole class to run one method. What about dependencies? For example you are writing project MVP with rails. Each time you want to test your super lightweight and simple class - you have to load every single dependency, since you cannot attach to the running ruby process.
And I’m not even talking about global immutability, which will add a lot of headache as well.
Ohh, you’re a rails developer. OK, I understand now – having a web server & a web browser in the way makes it hard to do anything iteratively in a REPL.
It’s pretty common, with scripting languages, to load all supporting modules into the REPL, experiment, and either export command history or serialize/prettyprint definitions (if your language stores original source) to apply changes. Image-based environments (like many implementations of smalltalk) will keep your changes persistent for you & you don’t actually need to dump code unless you’re doing a non-image release. All notebook-based systems (from mathematica to jupyter) are variations on the interactive-REPL model. In other words, you don’t need a lisp machine to work this way: substantial amounts of forth, python, julia, and R are developed like this (to choose an arbitrary smattering of very popular languages), along with practically all shell scripts.
Vim & emacs can spawn arbitrary interactive applications and copy arbitrary buffers to them, & no doubt ship with much more featureful integrations with particular languages; I don’t have much familiarity with alternative editors, though I’d be shocked that anybody would call something a ‘code editor’ that couldn’t integrate a REPL.
Clojure has a really good story for working with HTTP servers at the REPL. It’s very common to start a server and redefine a HTTP handler function.
The multithreadedness of that JVM is awesome in this regard.
I think similar things can be done in scala. I mostly mean to say that a web stack represents multiple complicated and largely-inaccessible layers that aren’t terribly well-suited to REPL use, half of which are stuck across a network link on an enormously complex third-party sandboxed VM. Editing HTTP handlers on live servlets is of limited utility when you’re generating code in three different languages & fighting a cache.
Yeah that object oriented focus gets in the way, I get that. Lisp is also not the only functional programming language though.
[Comment removed by author]
Also applies to Ocaml, F#, python, ruby.
Edit: lol the article is about F#. That’s what I get for not reading the article I guess.