13 ms·

This Old Lisp

238 points by lispm 8y ago

ilovecaching 8y ago
God, Lisp is beautiful. You look at some of the older languages of yore and think, my god, how did people survive? Then you see a Lisp program in all it's homoiconic glory, and it looks just as good in 2018 as it did in the 1960s. A true testament to the expressiveness and generality of expression based programming and the lambda calculus.
- deleted 8y ago
  [deleted]
- gnulinux 8y ago
  This 1960 program is much better looking than pretty much all 2018 programs I saw. There definitely are some exceptions, but it's hard to get lisp wrong whereas it's too damn easy to get most 2018 languages wrong.
  - jorams 8y ago
    > it's hard to get lisp wrong That's not actually true, Lisp offers endless possibilities to work yourself into a hole. The average 1960s program was just written by someone a bit more knowledgeable and caring, who took a lot more time to get things right, than the vast majority of modern programming work.
    - sevensor 8y ago
      And the average 1960s program was written on a blackboard first. Computer time was expensive! I think being forced to confront the cost of the program ahead of time sharpened programmers' wits.
      - pfdietz 8y ago
        My first Lisp program was entered via punch cards. This was the early 1970s.
shntx 8y ago
Awesome. Two-Bit History's latest essay is also a fascinating dive into Lisp. https://twobithistory.org/2018/10/14/lisp.html https://twobithistory.org/2018/10/14/lisp.html
znpy 8y ago
I know I am going to write an unpopular opinion and get downvoted for it, but here it goes... I am still not convinced by the general "we don't need to upgrade the Common Lisp specification" attitude. It surely is remarkable as a specification, encompassing so many aspects of the language, yet it leaves so many other aspects to the particular implementation. Multi-threading for example is supported by most major implementations yet their syntax (and often, semantics) are very different from each other. Same goes for cooperative multitasking (corutines etc). Someone else could come up with other examples. In my opinion a new committee should be formed, to standardize the syntax and semantics of these so common functionalities. In this sense, the various C++ language working groups are doing a remarkable job. I wish something similar would happen in the Common Lisp world.
- blue1 8y ago
  a large part of the CL community treats the spec a bit like a sacred text, in the sense that it is both very good and impossible to change. The most important reason apparently is that there are no more the resources to do it. Maybe also the struggling commercial vendors do not want to standardize their offer to become too similar to open source implementations?
  - znpy 8y ago
    > a large part of the CL community treats the spec a bit like a sacred text Amen!
  - junke 8y ago
    > a large part of the CL community treats the spec a bit like a sacred text That's not my experience. I'd say that people know what the CL spec currently is, love its stability, and might fear what it could become after an "upgrade". Anybody can write something like CL21, for example, with one's own style and notations. That's why it is frowned upon to do so and to claim that "this" library is how "the" new Lisp should be. Part of growing in Lisp (and programming) is to learn how to work with a language, not against it, and avoid fixing what is not broken. However, I trust Common Lisp compiler developers and vendors to know how to make backward-compatible, useful changes: current common lisp environments have way more facilities and building blocks than the bare minimum required. They also know the pain points that currently exist in the standard in a way that goes beyond aesthetic things.
cblum 8y ago
That moment when you happen to know the person linked, but in a totally unrelated context (our kids are friends). Now I've gotta find some time to watch or read this :)
jacquesm 8y ago
If the author is reading this: typo in the first sentence, the year reads '2108' right now.
- lkuty 8y ago
  It's due to the fact that Lisp is ahead of its time :-)
- xrme 8y ago
  Oops. Fixed.
lerax 8y ago
Nice transcript. I would love if more often people did it.
hguhghuff 8y ago
One of the things that really put me off Lua was lack of a strong central control and organization for the language, resulting in fragmentation. How does lisp stand in this regard?
- blue1 8y ago
  Depends on what you mean by "Lisp". In the wider sense of the lisp family, there are obviously many differences (Clojure, Scheme, Common Lisp, etc.). If instead you mean Lisp == Common Lisp, the ANSI spec - which is a really well-made standard - is common to all implementations and basically works; for what came after that (threading, unicode, networking, etc.) the commercial implementations have their own extensions, while the open source ones rely on libraries, some of which are considered best practice.
- jorams 8y ago
  It's interesting that you say that about Lua, because it actually does have a strong central control and organization for the language itself. The "problem" is that it doesn't go further than the language, large parts of the community disagree with their choices, and they tend to not care about backwards compatibility too much. Lisp is very different in that area. I think that is because the language standard is large and doesn't change. As long as people want to conform to that standard, splitting up too much doesn't really make sense.
deleted 8y ago
[deleted]
winter_blue 8y ago
After 20 years of programming[1], I’ve gotten to a point in my life where an advanced type system (with strong static types, no nulls — optionals instead, type inference, type refinement, etc) is absolutely mandatory for any language I’ll pick (when I have the freedom to choose). I’ve heard that there are libraries that tack types onto LISP — but how good are they? LISP code I’ve seen anywhere has always been without types (ie dynamically typed). No LISP dialect that I’m aware of has prioritized or talked about or emphasized type checking. Is this something that’s even big on the radar of the LISP implementors and the LISP community at large? I’ve been burned too many times working on large (100k+ LOC) dynamically typed codebases that I really never want to work with such a codebase again. A sincere question: Besides its homoiconic syntax and probably the best implementation of macros — what does LISP offer over a modern programming language with a sophisticated type system – even, for instance, a language as old as OCaml? Peter Norvig has web page called “Is Lisp Still Unique? Or at Least Different?” that was last updated back in 2002 where he talks about the unique features LISP offers, and how other languages are catching up: http://norvig.com/Lisp-retro.html http://norvig.com/Lisp-retro.html Modern languages of today offer the features that made LISP unique and superior in its heyday, and languages with powerful type systems offer a huge advantage that LISP never has had. [1] I started programming in 1998, when I was 8 years old. I’ve developed software professionally for a far shorter period.
- VogonWorkEthic 8y ago
  I've heard racket is the way to go with types in lisp. https://racket-lang.org/ https://racket-lang.org/ Just passing along what I heard though, I personally don't use types and think things like clojure spec do a much better job fitting the bill.
  - peatmoss 8y ago
    I think some are bristling that Racket is the way to go, but Typed Racket is certainly a good way to go. https://docs.racket-lang.org/ts-guide/ https://docs.racket-lang.org/ts-guide/ You can start without types and later convert parts of your code to typed without too much headache. But, as the GP has mentioned, SBCL allows you to add type annotations which is similar in spirit to the idea of progressively adding types. Even as a Racket fan (and Racket’s performance is pretty good), I covet the blazing performance of SBCL, so the calculus is not cut and dry.
moron4hire 8y ago
I've never done work with CL, but I've done quite a bit of Racket. What does CL offer that Racket doesn't? I've found Racket to be fairly complete, and the areas where it's not are usually quite simple to fill in (thus seem pretty clearly intentionally left open-ended).
- peatmoss 8y ago
  As a Racket dabbler, I’d say there are a couple things: - performant implementations (SBCL in particular is a standout). I mean, Racket’s pretty good, and will typically blow the doors off Python, but SBCL is in a different league. - multiple implementations conforming more or less to a standard. This can also be a distraction, but is on balance a nice thing to have, particularly if you wanted, for example, an implementation that ran on the JVM (ABCL). - different set of libraries. Racket’s library situation is pretty good, but sometimes CL will have something that Racket doesn’t (and sometimes the other way around)
  - sigzero 8y ago
    Racket should be becoming more performant once the Chez integration is done.
    - dleslie 8y ago
      I wouldn't hold your breath; Racket isn't that much slower than Chez, and both are slower than sbcl. https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - bad_login 8y ago
      According to Mathew Flatt it will fasten racket. https://www.youtube.com/watch?v=t09AJUK6IiM https://www.youtube.com/watch?v=t09AJUK6IiM
- mikelevins 8y ago
  A language designed for modifying programs while they run. Common Lisp and Smalltalk are languages designed to support modifying programs while they run. It's the standard way to develop a program in old-fashioned Lisp and Smalltalk systems: you start up your language runtime and then teach it, incrementally and interactively, to be the application you want. Interactive repls are pretty common nowadays, but a repl is not the same as being designed to support programming-as-teaching. Consider the Common Lisp generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS. It's in the language standard. It provides an extensible mechanism that the runtime uses to update existing instances of a class when the class is redefined. Why would you ever want such a function at all, much less want it to be part of the language standard? Because the authors of the Common Lisp language standard were experienced Lisp hackers. They took for granted that the way you write a program is you start your Lisp and then interactively teach it how to be the application. You don't want to have to stop the program and rebuild it just because you redefined a class. That's silly. The runtime should know how to update any existing instances to reflect the new definition, because telling the Lisp new definitions as it runs is the standard way that you normally work. Old-fashioned Lisp and Smalltalk systems are full of features that make this assumption--that you build an application by interactively teaching a running program how to be the application. As far as I know, they're the only development systems designed with that assumption (although, if Racket has such features and I overlooked them, I'd be glad to know it!). If you're not familiar with that style of programming (and I think most programmers are not), or if you don't prefer it, then something like UPDATE-INSTANCE-FOR-REDEFINED-CLASS makes no sense. On the other hand, if you prefer that way of working, as I do, then the absence of features like UPDATE-INSTANCE-FOR-REDEFINED-CLASS is as uncomfortable as a missing tooth.

238 points by lispm 8y ago

God, Lisp is beautiful. You look at some of the older languages of yore and think, my god, how did people survive? Then you see a Lisp program in all it's homoiconic glory, and it looks just as good in 2018 as it did in the 1960s. A true testament to the expressiveness and generality of expression based programming and the lambda calculus.

deleted 8y ago
[deleted]
gnulinux 8y ago
This 1960 program is much better looking than pretty much all 2018 programs I saw. There definitely are some exceptions, but it's hard to get lisp wrong whereas it's too damn easy to get most 2018 languages wrong.
- jorams 8y ago
  > it's hard to get lisp wrong That's not actually true, Lisp offers endless possibilities to work yourself into a hole. The average 1960s program was just written by someone a bit more knowledgeable and caring, who took a lot more time to get things right, than the vast majority of modern programming work.
  - sevensor 8y ago
    And the average 1960s program was written on a blackboard first. Computer time was expensive! I think being forced to confront the cost of the program ahead of time sharpened programmers' wits.
    - pfdietz 8y ago
      My first Lisp program was entered via punch cards. This was the early 1970s.

shntx 8y ago

Awesome. Two-Bit History's latest essay is also a fascinating dive into Lisp. https://twobithistory.org/2018/10/14/lisp.html https://twobithistory.org/2018/10/14/lisp.html

znpy 8y ago

I know I am going to write an unpopular opinion and get downvoted for it, but here it goes... I am still not convinced by the general "we don't need to upgrade the Common Lisp specification" attitude. It surely is remarkable as a specification, encompassing so many aspects of the language, yet it leaves so many other aspects to the particular implementation. Multi-threading for example is supported by most major implementations yet their syntax (and often, semantics) are very different from each other. Same goes for cooperative multitasking (corutines etc). Someone else could come up with other examples. In my opinion a new committee should be formed, to standardize the syntax and semantics of these so common functionalities. In this sense, the various C++ language working groups are doing a remarkable job. I wish something similar would happen in the Common Lisp world.

blue1 8y ago
a large part of the CL community treats the spec a bit like a sacred text, in the sense that it is both very good and impossible to change. The most important reason apparently is that there are no more the resources to do it. Maybe also the struggling commercial vendors do not want to standardize their offer to become too similar to open source implementations?
- znpy 8y ago
  > a large part of the CL community treats the spec a bit like a sacred text Amen!
- junke 8y ago
  > a large part of the CL community treats the spec a bit like a sacred text That's not my experience. I'd say that people know what the CL spec currently is, love its stability, and might fear what it could become after an "upgrade". Anybody can write something like CL21, for example, with one's own style and notations. That's why it is frowned upon to do so and to claim that "this" library is how "the" new Lisp should be. Part of growing in Lisp (and programming) is to learn how to work with a language, not against it, and avoid fixing what is not broken. However, I trust Common Lisp compiler developers and vendors to know how to make backward-compatible, useful changes: current common lisp environments have way more facilities and building blocks than the bare minimum required. They also know the pain points that currently exist in the standard in a way that goes beyond aesthetic things.

cblum 8y ago

That moment when you happen to know the person linked, but in a totally unrelated context (our kids are friends). Now I've gotta find some time to watch or read this :)

jacquesm 8y ago

If the author is reading this: typo in the first sentence, the year reads '2108' right now.

lkuty 8y ago
It's due to the fact that Lisp is ahead of its time :-)
xrme 8y ago
Oops. Fixed.

lerax 8y ago

Nice transcript. I would love if more often people did it.

hguhghuff 8y ago

One of the things that really put me off Lua was lack of a strong central control and organization for the language, resulting in fragmentation. How does lisp stand in this regard?

blue1 8y ago
Depends on what you mean by "Lisp". In the wider sense of the lisp family, there are obviously many differences (Clojure, Scheme, Common Lisp, etc.). If instead you mean Lisp == Common Lisp, the ANSI spec - which is a really well-made standard - is common to all implementations and basically works; for what came after that (threading, unicode, networking, etc.) the commercial implementations have their own extensions, while the open source ones rely on libraries, some of which are considered best practice.
jorams 8y ago
It's interesting that you say that about Lua, because it actually does have a strong central control and organization for the language itself. The "problem" is that it doesn't go further than the language, large parts of the community disagree with their choices, and they tend to not care about backwards compatibility too much. Lisp is very different in that area. I think that is because the language standard is large and doesn't change. As long as people want to conform to that standard, splitting up too much doesn't really make sense.

deleted 8y ago

[deleted]

winter_blue 8y ago

After 20 years of programming[1], I’ve gotten to a point in my life where an advanced type system (with strong static types, no nulls — optionals instead, type inference, type refinement, etc) is absolutely mandatory for any language I’ll pick (when I have the freedom to choose). I’ve heard that there are libraries that tack types onto LISP — but how good are they? LISP code I’ve seen anywhere has always been without types (ie dynamically typed). No LISP dialect that I’m aware of has prioritized or talked about or emphasized type checking. Is this something that’s even big on the radar of the LISP implementors and the LISP community at large? I’ve been burned too many times working on large (100k+ LOC) dynamically typed codebases that I really never want to work with such a codebase again. A sincere question: Besides its homoiconic syntax and probably the best implementation of macros — what does LISP offer over a modern programming language with a sophisticated type system – even, for instance, a language as old as OCaml? Peter Norvig has web page called “Is Lisp Still Unique? Or at Least Different?” that was last updated back in 2002 where he talks about the unique features LISP offers, and how other languages are catching up: http://norvig.com/Lisp-retro.html http://norvig.com/Lisp-retro.html Modern languages of today offer the features that made LISP unique and superior in its heyday, and languages with powerful type systems offer a huge advantage that LISP never has had. [1] I started programming in 1998, when I was 8 years old. I’ve developed software professionally for a far shorter period.

VogonWorkEthic 8y ago
I've heard racket is the way to go with types in lisp. https://racket-lang.org/ https://racket-lang.org/ Just passing along what I heard though, I personally don't use types and think things like clojure spec do a much better job fitting the bill.
- peatmoss 8y ago
  I think some are bristling that Racket is the way to go, but Typed Racket is certainly a good way to go. https://docs.racket-lang.org/ts-guide/ https://docs.racket-lang.org/ts-guide/ You can start without types and later convert parts of your code to typed without too much headache. But, as the GP has mentioned, SBCL allows you to add type annotations which is similar in spirit to the idea of progressively adding types. Even as a Racket fan (and Racket’s performance is pretty good), I covet the blazing performance of SBCL, so the calculus is not cut and dry.

moron4hire 8y ago

I've never done work with CL, but I've done quite a bit of Racket. What does CL offer that Racket doesn't? I've found Racket to be fairly complete, and the areas where it's not are usually quite simple to fill in (thus seem pretty clearly intentionally left open-ended).

peatmoss 8y ago
As a Racket dabbler, I’d say there are a couple things: - performant implementations (SBCL in particular is a standout). I mean, Racket’s pretty good, and will typically blow the doors off Python, but SBCL is in a different league. - multiple implementations conforming more or less to a standard. This can also be a distraction, but is on balance a nice thing to have, particularly if you wanted, for example, an implementation that ran on the JVM (ABCL). - different set of libraries. Racket’s library situation is pretty good, but sometimes CL will have something that Racket doesn’t (and sometimes the other way around)
- sigzero 8y ago
  Racket should be becoming more performant once the Chez integration is done.
  - dleslie 8y ago
    I wouldn't hold your breath; Racket isn't that much slower than Chez, and both are slower than sbcl. https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - bad_login 8y ago
    According to Mathew Flatt it will fasten racket. https://www.youtube.com/watch?v=t09AJUK6IiM https://www.youtube.com/watch?v=t09AJUK6IiM
mikelevins 8y ago
A language designed for modifying programs while they run. Common Lisp and Smalltalk are languages designed to support modifying programs while they run. It's the standard way to develop a program in old-fashioned Lisp and Smalltalk systems: you start up your language runtime and then teach it, incrementally and interactively, to be the application you want. Interactive repls are pretty common nowadays, but a repl is not the same as being designed to support programming-as-teaching. Consider the Common Lisp generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS. It's in the language standard. It provides an extensible mechanism that the runtime uses to update existing instances of a class when the class is redefined. Why would you ever want such a function at all, much less want it to be part of the language standard? Because the authors of the Common Lisp language standard were experienced Lisp hackers. They took for granted that the way you write a program is you start your Lisp and then interactively teach it how to be the application. You don't want to have to stop the program and rebuild it just because you redefined a class. That's silly. The runtime should know how to update any existing instances to reflect the new definition, because telling the Lisp new definitions as it runs is the standard way that you normally work. Old-fashioned Lisp and Smalltalk systems are full of features that make this assumption--that you build an application by interactively teaching a running program how to be the application. As far as I know, they're the only development systems designed with that assumption (although, if Racket has such features and I overlooked them, I'd be glad to know it!). If you're not familiar with that style of programming (and I think most programmers are not), or if you don't prefer it, then something like UPDATE-INSTANCE-FOR-REDEFINED-CLASS makes no sense. On the other hand, if you prefer that way of working, as I do, then the absence of features like UPDATE-INSTANCE-FOR-REDEFINED-CLASS is as uncomfortable as a missing tooth.