 |
| 2 users recommended this comment. What they said: |
|
nemoniac Jun 5, 2016 | on: A tool for thought | context
Both. When I start adding type annotations, I'm usually aiming for a speed-up but more often it leads to reorganization and rationalization of the code. The code becomes more streamlined and beautiful. The post below resonates with me. He calls it 'programming by teaching', where you gradually shape a program to solve your problem. I think of it as 'programming by learning', where the Lisp way of developing helps me learn about my problem. It's only when you have the final version of your code that you fully understand the problem by seeing its solution in front of you. |
|
vram22 Aug 3, 2017 | on: Why I Choose Delphi | context
I just read scroot's comment (the grandparent comment to mine, and parent to yours). I found it somewhat uncannily similar to a sub-thread involving HN user mikelevins (a long-time Lisp developer) in another HN thread a while ago (about Lisp). He commented on something (it was a thread about a Show HN about Full Stack Lisp, a book), I asked a question, he replied in more depth. His description of some advanced features of Lisp was fairly similar to what scroot wrote above (but with more points added). So you might be interested to check it out: https://news.ycombinator.com/item?id=11834887 That is the top comment by him in that sub-thread. My question to him is 2nd reply below, then he replied at even greater length. Some pretty deep stuff.. (In another of his comments - this one, in a different thread: https://news.ycombinator.com/item?id=14677396 - he also mentioned that Lisp and Smalltalk are two of only a few languages that share some of the features he talks about.) |
| Also recommended by people who recommended this: | ||
| 1. | Delphi – why won't it die? (2013) (stevepeacocke.blogspot.com) | |
| recommended by 3 users | 2014 | 163 points by wx196 | original thread | | ||
Speaking as a longtime (nearly 30 years) Common Lisp programmer, I agree with what you've said here, but I would add one thing more. Common Lisp is one of a small number of languages that represent an approach to programming that is so out of fashion nowadays that it seems to be in danger of becoming extinct. The approach is one that treats programming as an exercise in interactively shaping a living thing in real time, rather than building an artifact from a blueprint. Programming-as-construction is the mainstream; Common Lisp and a small handful of other languages represent a different approach that we might characterize as programming-as-teaching.
Common Lisp and some older Lisps, along with Smalltalk and FORTH, treat programming as an ongoing interaction in which your main program is already running before you ever write any code. It's running, but it doesn't yet know how to be your application. You have to teach it. This you do incrementally, one small change at a time, gradually guiding and shaping the running program until, eventually, it becomes your application. It continues to run throughout the entire process; it just changes its behavior as you teach it new capabilities.
Common Lisp (and a few other languages) are designed with this approach to programming squarely in mind. Consider, for example, the standard Common Lisp functions CHANGE-CLASS and UPDATE-INSTANCE-FOR-REDEFINED-CLASS. In most languages these functions make very little sense. Once you understand how Common Lisp is designed to be used, it's obvious that they are necessary. They're necessary because obviously you're going to redefine classes as you progress, and obviously you don't want your running application to fail simply because you've redefined its types out from under it. So the language is designed to support that way of working. It provides facilities for gracefully handling the situation that arises when you redefine types out from under your code, and it gives you ways to ensure that the program keeps running as you make those changes.
This way of working is now sufficiently out of fashion that even new Lisps don't necessarily support it. Clojure isn't great in this area. Neither are some Schemes. Common Lisp and Smalltalk are the strongest remaining bastions of programming-as-teaching, as far as I can see.
Almost everywhere else in programming today, tools and languages uncritically assume the programming-as-construction model. Maybe that's okay. There's certainly good work being done in that mode. Programming-as-teaching is my native idiom, though. I'd guess that I'm somewhere around ten times more productive when working that way. That doesn't mean it's a better way, of course; it just means it's better for me. Nevertheless, I can't help but mourn when I think that maybe programming-as-teaching is disappearing from the world.