12 ms·

Lisp-Flavored Programming Languages

98 points by pcr910303 7y ago

haileris 7y ago
I already see a trend building behind functional programming and LISP. Oh brother, right after I started reading SICP.
- zabzonk 7y ago
  LISP is a functional programming language.
  - sigzero 7y ago
    The OP probably meant that.
  - braythwayt 7y ago
    For some definition of "functional" that was appropriate when LISP was discovered, and of course any claim about LISP tends to be met with, "which one?" LISP really deserves to be "grandfathered in" as the original functional programming language, but if it were discovered today, we'd likely call it a multi-paradigm language that supports functions as first-class entities. And as a "programmable programming language," we can use LISP to implement many other paradigms, including what we now consider "functional" programming.
    - erik_seaberg 7y ago
      Lisp's development was skewed by the high cost of memory. Early on, scope was dynamic, lists were mutable and often spliced in-place, linear searches were typical (hash tables were almost unheard of), and there were very few first-class types because a pointer only had so many tag bits available.
      - lispm 7y ago
        Things evolved in the 70s. Hash tables were added over time, with some alternatives were using some tree like search. Usually the first thing was to make the symbol table not a list -> making the symbol table a hash table was reportedly done in 1971 by Jon L White. Tag bits then also were not a part of the pointers (with only very few exceptions), but a part of the data object (numbers, strings, arrays, symbols, ..).
  - klez 7y ago
    To be fair lisps are multi-paradigm languages, especially Common Lisp.
    - rusini 7y ago
      And even Scheme.
pjmlp 7y ago
What about Dylan and other Lisps with Algol based syntax (M-expressions)?
swlkr 7y ago
Toccata seems very interesting! I like the clojure-like syntax and the gradual typing aspect of it.
byron_fast 7y ago
Where "flavor" means "subset of". But good on them.
manifestsilence 7y ago
The python ones, Hy and Pixie, look pretty cool. Two very different takes on what it means to "use python" for a lisp. Pixie uses the RPython toolchain and is totally its own language, with its own VM and JIT. Hy appears to be python with lisp syntax. Both sound fascinating.
- Naac 7y ago
  Hy is indeed very cool, but other than a different syntax it is still at the end of the day, identical to python. Pixie does look very cool, but the project on github seems dead?
- fernly 7y ago
  Yeah, I thought so too. I've been teaching myself Lisp as a side project, working through online tutorials and, more productively, Paul Graham's "ANSI Common Lisp", using SBCL and CLISP in a terminal window. OK, cool, try another Lisp, leverage my Python knowledge. Took a look at the github of Pixie: "pre-alpha" and no docs whatever. Not for the student. Hy is cleanly packaged, installed with pip3, has complete(ish) docs[1], great. So I installed it and started it, it puts up a REPL prompt, and I paste in one of the functions I've worked out: (defun hello () (write-line "this is the prompt:") (let ( (name (read-line)) ) (format t "Hello, ~A.~%" name) ) ) Error message: "empty expressions are not allowed at top level" Sorry? Exactly that usage, an empty expression when a function takes no argument, is used on (I just checked) page 20 of Graham. But ok, I try it without, "(defun hello" etc. Error message: "NameError: name 'defun' is not defined" You what? defun is introduced on page 14, and defined in the "Language Reference" Appendix of Graham. OK, wait, what does Hy use, if not defun? Search their tutorial chapter: "Define named functions with defn". OK, this is a deal-breaker for somebody trying to learn (ahem) COMMON Lisp. Why would you do that, just arbitrarily change the probably third or fourth name a student learns after car, cdr and setv? And more importantly, if you have taken it on yourself to dick around with (ahem) Common Lisp at this basic point, what else have you changed that will break the examples in my textbook or online tutorial? pip3 uninstall hy [1] https://docs.hylang.org/en/master/index.html https://docs.hylang.org/en/master/index.html
  - 7y ago
c3534l 7y ago
I'm amused by the fact that when you criticize LISP's syntax, defenders always say the syntax doesn't matter and real Lisp programmers don't even see the parenthesis. But then you look at these implementations of Lisp-like variants of existing programming languages and the thing the developers are most enamored with is the repetitive, parenthesis-laden syntax of Lisp, while keeping the majority of the non-Lisp semantics in tact (adding just a few functional conveniences like first class functions). I'm not even criticizing, most of these are hobby projects and you can code how you like. I just think it's funny how hard Lisp clings onto the parenthesis thing while claiming the parenthesis thing doesn't matter.
- manifestsilence 7y ago
  I think the appeal of the syntax for those who get used to it is the regularity, like you said. The advantage of the regularity isn't its human readability, but its ability to macro, no? What I'd like to see is better tools for reading and editing such a regular syntax. Probably I should just learn emacs, but I'm thinking someone could make a more intuitive structured editor for LISP syntax. No need to mush around blobs of text when everything is nested lists.
  - braythwayt 7y ago
    > The advantage of the regularity isn't its human readability, but its ability to macro, no? This. You can write macros for less regular languages, but there's always additional friction involved. At some point, it comes down to whether you think LISP is a "programmable programming language." If you do, macros are a core part of the paradigm, and s-exprs make macros easy to work with.
    - kazinator 7y ago
      I already really liked Lisp's syntax before I learned about the macros. No ambiguity; no brain cycles required to work out what element is a child or sibling of what element. Great editing ergonomics.
  - c3534l 7y ago
zitterbewegung 7y ago
Cool list I made a pull request .
cracauer 7y ago
A quick look at what Quicklisp has to offer for libraries should quickly convince people that fooling around with anything but Common Lisp would be very energy-consuming. http://blog.quicklisp.org/ http://blog.quicklisp.org/
- kryptiskt 7y ago
  Racket has a package manager and plenty of packages. https://pkgs.racket-lang.org https://pkgs.racket-lang.org It's also an actively developed modern language not stuck in the 80s.
  - mucholove 7y ago
    Question: how lean does a Racket GUI app run? Any samples I can use? Just did the tutorial and I really loved it! Only thing that’s difficult for me right now is named parameters because I’ve been using Objective C which is really clear on that front. If they can be hooked together too...that would be fun :)
- iLemming 7y ago
  A quick look at what the job market has to offer (for those who interested in Lisp) should quickly convince people that learning anything but Clojure would be not only energy-consuming but also impractical.
  - pjmlp 7y ago
    These guys are always looking for good coders. Fancy moving into Lisbon or Porto? https://www.siscog.pt/en/ https://www.siscog.pt/en/ https://franz.com/success/customer_apps/scheduling/siscog.lhtml https://franz.com/success/customer_apps/scheduling/siscog.lh...
  - kazinator 7y ago
    I know this isn't Reddit, but "nick checks out". Knowledge and skill useful for finding a job is not all the knowledge that is good. Clojure was developed by someone called Rich Hickey. Not only were there no Clojure jobs when he started hacking, there was no Clojure. That's a textbook example of an energy-consuming and impractical waste of time. For almost every piece of technology listed in a job ad that you think is worth knowing, someone had to put in a whole lot of time and energy, not knowing if it will pan out at all, and often that time and energy were uncompensated by anything other than the existence of the thing in the end.
rusini 7y ago
I have designed a programming language that borrows an important part of its architecture from Lisp(s) (maybe mostly Scheme, but also Kernel: http://klisp.org http://klisp.org). However, I have always opposed to the concrete syntax of S-expressions (being mostly unable to be productive with it). My arguments are not on the familiarity side (with the infix notation), but on the psychological one: 1. S-expressions are not the most simple, natural, or uniform surface form (as they claim); they do have syntactic sugar (quote, even lists themselves!, etc.), so why not to add some more sugar (but sufficiently abstract of course)? 2. Humans' brain has limited "stack" space (especially when closing parentheses); infix forms may "cascade" and do not consume the stack (equally machine on human, due to possibility of "tail recursion") 3. Lack of diverse "visual clues" for humans (note how most natural languages have 40-60 phonemes, and none less than 15) 4. S-expressions and homoiconicity are related but orthogonal features (so the homoiconicity argument is often not valid) Having that said, when I finally managed to write a working 50+-lines program in Scheme, with "proper" indentation, I was just proud of it, and I said, "Wow, it looks cool!". But I am still on the side of the above rational arguments! My point is that as my experiment demonstrates, it is probably too easy to get on an emotional side of computer-human interaction once you accomplished something a bit challenging (like speaking in classic S-expressions)?
- dreamcompiler 7y ago
  For me S-expressions feel like the most natural way to program because they compose naturally with zero ambiguity. Infix notation might be slightly clearer for simple expressions but it doesn't compose: As soon as you try to compose infix notation you have to add parens, depend on unstated precedence rules, or both. Lisp's philosophy is to just use parens everywhere, make everything composable, and have no precedence rules. That said, I would hate to write Lisp code with Notepad. Fortunately nobody does this. In conjunction with a paren-matching, auto-indenting programmer's editor (which is roughly all of them these days), S-expressions are easy. A good editor is vital not just for writing Lisp programs but also for reading them. I will not claim parentheses are mandatory. I find Haskell just as simple, unambiguous, and composable without (many) parens but that's only because it has automatic currying, and that takes a bit of practice to wrap one's head around.
threatofrain 7y ago
> julia --lisp
aidenn0 7y ago
C/C++ should really be separated. There are very few lisps with good C++ interop, and so they are an interesting category on their own.
rwmurrayVT 7y ago
AutoLISP for AutoCAD products :)

98 points by pcr910303 7y ago

haileris 7y ago

I already see a trend building behind functional programming and LISP. Oh brother, right after I started reading SICP.

zabzonk 7y ago
LISP is a functional programming language.
- sigzero 7y ago
  The OP probably meant that.
- braythwayt 7y ago
  For some definition of "functional" that was appropriate when LISP was discovered, and of course any claim about LISP tends to be met with, "which one?" LISP really deserves to be "grandfathered in" as the original functional programming language, but if it were discovered today, we'd likely call it a multi-paradigm language that supports functions as first-class entities. And as a "programmable programming language," we can use LISP to implement many other paradigms, including what we now consider "functional" programming.
  - erik_seaberg 7y ago
    Lisp's development was skewed by the high cost of memory. Early on, scope was dynamic, lists were mutable and often spliced in-place, linear searches were typical (hash tables were almost unheard of), and there were very few first-class types because a pointer only had so many tag bits available.
    - lispm 7y ago
      Things evolved in the 70s. Hash tables were added over time, with some alternatives were using some tree like search. Usually the first thing was to make the symbol table not a list -> making the symbol table a hash table was reportedly done in 1971 by Jon L White. Tag bits then also were not a part of the pointers (with only very few exceptions), but a part of the data object (numbers, strings, arrays, symbols, ..).
- klez 7y ago
  To be fair lisps are multi-paradigm languages, especially Common Lisp.
  - rusini 7y ago
    And even Scheme.

pjmlp 7y ago

What about Dylan and other Lisps with Algol based syntax (M-expressions)?

swlkr 7y ago

Toccata seems very interesting! I like the clojure-like syntax and the gradual typing aspect of it.

byron_fast 7y ago

Where "flavor" means "subset of". But good on them.

manifestsilence 7y ago

The python ones, Hy and Pixie, look pretty cool. Two very different takes on what it means to "use python" for a lisp. Pixie uses the RPython toolchain and is totally its own language, with its own VM and JIT. Hy appears to be python with lisp syntax. Both sound fascinating.

Naac 7y ago
Hy is indeed very cool, but other than a different syntax it is still at the end of the day, identical to python. Pixie does look very cool, but the project on github seems dead?
fernly 7y ago
Yeah, I thought so too. I've been teaching myself Lisp as a side project, working through online tutorials and, more productively, Paul Graham's "ANSI Common Lisp", using SBCL and CLISP in a terminal window. OK, cool, try another Lisp, leverage my Python knowledge. Took a look at the github of Pixie: "pre-alpha" and no docs whatever. Not for the student. Hy is cleanly packaged, installed with pip3, has complete(ish) docs[1], great. So I installed it and started it, it puts up a REPL prompt, and I paste in one of the functions I've worked out: (defun hello () (write-line "this is the prompt:") (let ( (name (read-line)) ) (format t "Hello, ~A.~%" name) ) ) Error message: "empty expressions are not allowed at top level" Sorry? Exactly that usage, an empty expression when a function takes no argument, is used on (I just checked) page 20 of Graham. But ok, I try it without, "(defun hello" etc. Error message: "NameError: name 'defun' is not defined" You what? defun is introduced on page 14, and defined in the "Language Reference" Appendix of Graham. OK, wait, what does Hy use, if not defun? Search their tutorial chapter: "Define named functions with defn". OK, this is a deal-breaker for somebody trying to learn (ahem) COMMON Lisp. Why would you do that, just arbitrarily change the probably third or fourth name a student learns after car, cdr and setv? And more importantly, if you have taken it on yourself to dick around with (ahem) Common Lisp at this basic point, what else have you changed that will break the examples in my textbook or online tutorial? pip3 uninstall hy [1] https://docs.hylang.org/en/master/index.html https://docs.hylang.org/en/master/index.html
- 7y ago

c3534l 7y ago

I'm amused by the fact that when you criticize LISP's syntax, defenders always say the syntax doesn't matter and real Lisp programmers don't even see the parenthesis. But then you look at these implementations of Lisp-like variants of existing programming languages and the thing the developers are most enamored with is the repetitive, parenthesis-laden syntax of Lisp, while keeping the majority of the non-Lisp semantics in tact (adding just a few functional conveniences like first class functions). I'm not even criticizing, most of these are hobby projects and you can code how you like. I just think it's funny how hard Lisp clings onto the parenthesis thing while claiming the parenthesis thing doesn't matter.

manifestsilence 7y ago
I think the appeal of the syntax for those who get used to it is the regularity, like you said. The advantage of the regularity isn't its human readability, but its ability to macro, no? What I'd like to see is better tools for reading and editing such a regular syntax. Probably I should just learn emacs, but I'm thinking someone could make a more intuitive structured editor for LISP syntax. No need to mush around blobs of text when everything is nested lists.
- braythwayt 7y ago
  > The advantage of the regularity isn't its human readability, but its ability to macro, no? This. You can write macros for less regular languages, but there's always additional friction involved. At some point, it comes down to whether you think LISP is a "programmable programming language." If you do, macros are a core part of the paradigm, and s-exprs make macros easy to work with.
  - kazinator 7y ago
    I already really liked Lisp's syntax before I learned about the macros. No ambiguity; no brain cycles required to work out what element is a child or sibling of what element. Great editing ergonomics.
- c3534l 7y ago

zitterbewegung 7y ago

Cool list I made a pull request .

cracauer 7y ago

A quick look at what Quicklisp has to offer for libraries should quickly convince people that fooling around with anything but Common Lisp would be very energy-consuming. http://blog.quicklisp.org/ http://blog.quicklisp.org/

kryptiskt 7y ago
Racket has a package manager and plenty of packages. https://pkgs.racket-lang.org https://pkgs.racket-lang.org It's also an actively developed modern language not stuck in the 80s.
- mucholove 7y ago
  Question: how lean does a Racket GUI app run? Any samples I can use? Just did the tutorial and I really loved it! Only thing that’s difficult for me right now is named parameters because I’ve been using Objective C which is really clear on that front. If they can be hooked together too...that would be fun :)
iLemming 7y ago
A quick look at what the job market has to offer (for those who interested in Lisp) should quickly convince people that learning anything but Clojure would be not only energy-consuming but also impractical.
- pjmlp 7y ago
  These guys are always looking for good coders. Fancy moving into Lisbon or Porto? https://www.siscog.pt/en/ https://www.siscog.pt/en/ https://franz.com/success/customer_apps/scheduling/siscog.lhtml https://franz.com/success/customer_apps/scheduling/siscog.lh...
- kazinator 7y ago
  I know this isn't Reddit, but "nick checks out". Knowledge and skill useful for finding a job is not all the knowledge that is good. Clojure was developed by someone called Rich Hickey. Not only were there no Clojure jobs when he started hacking, there was no Clojure. That's a textbook example of an energy-consuming and impractical waste of time. For almost every piece of technology listed in a job ad that you think is worth knowing, someone had to put in a whole lot of time and energy, not knowing if it will pan out at all, and often that time and energy were uncompensated by anything other than the existence of the thing in the end.

rusini 7y ago

I have designed a programming language that borrows an important part of its architecture from Lisp(s) (maybe mostly Scheme, but also Kernel: http://klisp.org http://klisp.org). However, I have always opposed to the concrete syntax of S-expressions (being mostly unable to be productive with it). My arguments are not on the familiarity side (with the infix notation), but on the psychological one: 1. S-expressions are not the most simple, natural, or uniform surface form (as they claim); they do have syntactic sugar (quote, even lists themselves!, etc.), so why not to add some more sugar (but sufficiently abstract of course)? 2. Humans' brain has limited "stack" space (especially when closing parentheses); infix forms may "cascade" and do not consume the stack (equally machine on human, due to possibility of "tail recursion") 3. Lack of diverse "visual clues" for humans (note how most natural languages have 40-60 phonemes, and none less than 15) 4. S-expressions and homoiconicity are related but orthogonal features (so the homoiconicity argument is often not valid) Having that said, when I finally managed to write a working 50+-lines program in Scheme, with "proper" indentation, I was just proud of it, and I said, "Wow, it looks cool!". But I am still on the side of the above rational arguments! My point is that as my experiment demonstrates, it is probably too easy to get on an emotional side of computer-human interaction once you accomplished something a bit challenging (like speaking in classic S-expressions)?

dreamcompiler 7y ago
For me S-expressions feel like the most natural way to program because they compose naturally with zero ambiguity. Infix notation might be slightly clearer for simple expressions but it doesn't compose: As soon as you try to compose infix notation you have to add parens, depend on unstated precedence rules, or both. Lisp's philosophy is to just use parens everywhere, make everything composable, and have no precedence rules. That said, I would hate to write Lisp code with Notepad. Fortunately nobody does this. In conjunction with a paren-matching, auto-indenting programmer's editor (which is roughly all of them these days), S-expressions are easy. A good editor is vital not just for writing Lisp programs but also for reading them. I will not claim parentheses are mandatory. I find Haskell just as simple, unambiguous, and composable without (many) parens but that's only because it has automatic currying, and that takes a bit of practice to wrap one's head around.

threatofrain 7y ago

> julia --lisp

aidenn0 7y ago

C/C++ should really be separated. There are very few lisps with good C++ interop, and so they are an interesting category on their own.

rwmurrayVT 7y ago

AutoLISP for AutoCAD products :)