Filler, for now. We're waiting for new moderators to volunteer, at which time we know they'll make this community great. Interested in the role? Is being a moderator your calling?
Filler, for now. We're waiting for new moderators to volunteer, at which time we know they'll make this community great. Interested in the role? Is being a moderator your calling?
Primarily PHP guy here and I loved this podcast (just added Restless Device to my feeds). I question associating the abstract ideas discussed with LISP. Admittedly, I'm not familiar with LISP. (I vaguely remember playing with the turtle in its derivative Logo on my Apple II but was mostly coding in BASIC, Pascal, and a bit of Fortran at the time.) He uses a lot of adjectives and even a bit of romanticism to make you want to learn more about it but nostalgia is not how you choose a programming language.
My favorite part was when he spoke about teaching kids programming not being about computer literacy or preparing them for jobs in computers but, instead, teaching them how to think and think about thinking (structure and interpretation). As a kid, I remember learning to reason and problem solving being huge turn-ons for me that drove me toward computers (or maybe it was the other way around). I agree that children learn by doing things, thinking about what they do and that, taught properly, computer languages give children tools that encourage them to think about processes and their own thinking. Programming is great to learn how to think abstractly, how to integrate, how to recognize patterns, and how to discover principles. Learning to code is a terrific model for human learning in general and I absolutely think I'm better at thinking because of its training (my detractors notwithstanding). But these are benefits of learning to program overall; I don't see them specific to any one computer language. I enjoyed these benefits from BASIC and Pascal (and "fourth-generation" languages later).
He says that, in LISP, there isn't any difference between data and programs (it's all symbolic). I don't doubt it was amazing in its day (late 1950s!) but he doesn't talk at all about the benefits of using LISP over other more recent languages. He makes it sound sexy by expressing it in terms of philosophy ("procedural epistemology... a science of procedures"; "meta-programming... writing programs that write programs" LOL). Perhaps LISP was the first programming language that allowed this technique but breaking up procedures/functions/variables is no longer specific to LISP - good programming technique always encourages breaking things down into smaller units. This helps with troubleshooting, testing, productivity (e.g., dividing code writing between people), performance tweaking, reusability, etc. and is a pillar for object-oriented programming.
Even during my artificial intelligence class in undergrad when we programmed neural networks, I don't remember using LISP (I don't remember what we used but I would think I would have remembered LISP if we used it). Putting aside Paul Graham's offshoot of LISP for Hacker News, the question becomes: given that LISP isn't widely used anymore, there don't appear to be any inherent efficiencies (relatively speaking - e.g., speed/performance, memory usage, coding productivity), very few people know it, and other programming languages are more widely used and maintained, why use (or even learn) LISP nowadays?
You might consider adding a few other tags to this post (e.g., philosophy, children, education, LISP).
Glad you enjoyed the podcast. I'll also be following Restless Device now. Great stuff.
(I typed up a lengthy response to this and my machine locked up before I submitted, so here goes a more concise attempt number two...)
Lisp, as a language family, is certainly special when compared to any other languages out there, and basically is by definition. Coding in Lisp is essentially coding directly in the language's AST. This more easily enables "metaprogramming" or "writing code that writes code" (because code is expressed using data structure literals that are the same as those used in the language runtime and APIs). What they're talking about is the macro system. Other languages have macro systems too, but none will ever be as straightforward as Lisp's. If they are, then they're a Lisp too. The macro system allows you to effect compiler behavior as opposed to runtime behavior. This means that you can extend the language to suit your needs, or bring the language closer to your problem domain. When used effectively, this allows for working at a higher level of abstraction.
Speaking of Paul Graham and the benefits of Lisps, his famous article on how Lisp was a competitive advantage for him comes to mind. Basically, he's claiming that it allowed his team to move faster. I also have the same feeling of increased efficiency when coding in Clojure, especially when using REPL-driven development. For me, solving a problem involves a LOT of exploration and the REPL is the best tool I know of for interactively exploring a problem space with a programming language.
Clojure might be the most popular Lisp language around today, and it is even recommended by Thoughtworks in the Tech Radar.
This is a bit abstract for me :)
As a coder, I don't understand why the way a language operates internally should make a difference outside some basic benchmarks (e.g., speed, cost). Sure, I'm going to design the functionality differently if I use a language that's object-oriented vs. functional vs. procedural. But there are other factors that are typically more important and, I would suggest, accessibility (e.g., what you know, ease to setup, resources available, acceptance) is much more relevant.
I want a programming language to run as fast as possible, be easy to learn, be easy to understand the code, be easy to test, be inexpensive to setup/run, have existing frameworks and resources I can leverage, etc. Granted, all programming languages have limitations requiring different designs/approaches/stacks (e.g., PHP has certain architectural limitations that sometimes require you to use Javascript) and choosing a language needs to be appropriate for the application (e.g., you wouldn't use a LAMP stack for aircraft controls). But assuming a few basics like language A's speed is comparable to language B and both are cheap to setup/run, I'm going to go with the language that takes into account other factors. Maybe Lisp is better for artificial intelligence applications because it runs faster and uses fewer resources than others, but I doubt it's faster or less resource intensive than compiled C at runtime. (I'm speculating as I haven't seen benchmarks.) Programmers typically don't pay too much attention to benchmarks - they go with accessibility, especially what they know/have learned.
I wasn't familiar with REPL so thanks for the link. (I sometimes use something similar for design and development of UI.) This is very useful for troubleshooting, especially if you're just learning to program. But my gut tells me this is much less useful to advanced programmers. The bugs you're solving in more advanced applications usually result from the integration of many different pieces of code. Thus, you need to trace how data is being passed and changed throughout many operations.
I don't doubt Paul Graham (quoting Eric Raymond) that learning another language like Lisp will make you a better programmer. There are always different ways to approach a problem and the more you know about good coding practices, approaches, and tools, the more effective and efficient you will be. Improving your mind is never wasted effort. But his reference to learning Latin to improve your mind even though it won't get you a job ("The reason Latin won't get you a job is that no one speaks it. If you write in Latin, no one can understand you.") is on-point to learning a programming language that has limited use or acceptance. An ability to "move faster" comes with a lot of presumptions about the goal and use case/scenario/resources.
There are many factors that should go into choosing the most appropriate technology stack and how a language operates internally is likely a very small factor.