5 ms·

The best way to kill a good Lisp is to remove the parentheses. The people who complain about parens are still going to ignore your language even after you remo

The best way to kill a good Lisp is to remove the parentheses. The people who complain about parens are still going to ignore your language even after you remove the parens, and then the Lispers will ignore you too. See Dylan. This debate is exasperating. It's like hearing people say "I'm not interested in that Ferrari because it has a manual transmission." The only response to which is a silent, cold stare.

mark_l_watson 7y ago
It is a great shame that I can only give you one upvote, you have it exactly correct. Removing parents ruins Lisp languages. That said, I consider Haskell to be a Lisp language. But, Haskell was designed from the ground up, from ML, to be as it is.
- dreamcompiler 7y ago
  Completely agree. Haskell is IMO the only paren-free Lisp that works. As you said, it was designed that way from scratch, not as an afterthought from s-expr syntax. I also think automatic currying and pervasive laziness contribute a great deal to making the parens unnecessary, and most Lisps don't work that way.
  - Oreb 7y ago
    > Haskell is IMO the only paren-free Lisp that works. Out of curiosity: Do you think Julia is not a Lisp, or that Julia doesn’t work?
    - dreamcompiler 7y ago
      I know Julia was originally a Lisp and it incorporates a lot of Lisp ideas, but I've never used it so I have no opinion about how well it works. Lots of Lispers consider Javascript a (primitive) Lisp because it has lexical closures, but I think its syntax is horrible and thus (IMO) it doesn't "work."
- nudpiedo 7y ago
  Why is Haskell a lisp? It is the first time I hear someone classifying Haskell in the “List Processing” family of languages, and although it does process lists I thought its main paradigma symbol and code representation goes in a complete different direction, more into pure function oriented programming.
  - dreamcompiler 7y ago
    When people say something "is a Lisp" that usually has little to do with list processing. It's about whether it inherits more from lambda calculus than from Turing machines.
    - lispm 7y ago
      Lisp literally stands for 'List Processor'. To claim that it has little to do with it, is really really strange. One of the main reasons to create Lisp was being able to compute with 'symbolic expressions', represented as linked cons cells in the form of lists... McCarthy about Lisp: === As a programming language, LISP is characterized by the following ideas: computing with symbolic expressions rather than numbers, representation of symbolic expressions and other information by list structure in the memory of a computer, representation of information in external media mostly by multi-level lists and sometimes by S-expressions, a small set of selector and constructor operations expressed as functions, composition of functions as a tool for forming more complex functions, the use of conditional expressions for getting branching into function definitions, the recursive use of conditional expressions as a sufficient tool for building computable functions, the use of lambda-expressions for naming functions, the representation of LISP programs as LISP data, the conditional expression interpretation of Boolean connectives, the LISP function eval that serves both as a formal definition of the language and as an interpreter, and garbage collection as a means of handling the erasure problem. LISP statements are also used as a command language when LISP is used in a time-sharing environment. === http://jmc.stanford.edu/articles/lisp/lisp.pdf http://jmc.stanford.edu/articles/lisp/lisp.pdf 'lambda calculus' wasn't even explicitly mentioned. But he mentions s-expressions, list structure, multi-level lists, ...
      - 7y ago
- dorfsmay 7y ago
  Isn't homoiconicity one of the requirements for a lisp? If so, that makes Julia a lisp, but not Haskell.
- lispm 7y ago
  > That said, I consider Haskell to be a Lisp language. Then Lisp (aka 'List processor') has lost its meaning. Haskell is at its core a lazy evaluated, statically typed, purely functional programming language. Lisp is none of that. The core of Lisp: an eager evaluated, dynamically typed, programming language supporting imperative, procedural and non-pure functional programming. > But, Haskell was designed from the ground up, from ML, to be as it is. Haskell was designed to have a common lazy language, instead of a dozen languages under development or in use (Miranda, Lazy ML, Clean, ...).
- lidHanteyk 7y ago
  You are missing quite a bit of context on the history of Haskell. From https://www.microsoft.com/en-us/research/publication/a-history-of-haskell-being-lazy-with-class/ https://www.microsoft.com/en-us/research/publication/a-histo... , it seems that Haskell's design did not arise out of Lisp, but out of several languages in the early 80s which were lazy/non-strict and purely functional. Indeed, removing parents ruins the perception of Lisp languages as just another language family, and promotes Lisp into some sort of privileged position. Simultaneously, mistaking Haskell for a Lisp means mistakenly thinking that Haskell has special meaning for pairs over tuples or lists, that Lisps are statically typed or that Haskell is optionally typed, that Haskell has macros, that Haskell's juxtaposition-based application syntax is related to Lisp's parenthesis-based application syntax, and so on. Consider example Lisp memes: "Data is code; code is data," or "all structures are lists." Compare with example ML memes: "If it compiles, it works," or "well-typed programs don't go wrong." Or even better, with Haskell memes: "Laziness leads to purity," "monads are programmable semicolons," "show me your types." The only meme common to these communities is "lambda the ultimate", and you are ignoring decades of Lisp philosophy if you nominate this meme to carry the flag for all of Lisp. When I first read this comment tree, I wondered if everybody had forgotten about the Land of Lisp and the Republic of Haskell: http://www.lisperati.com/landoflisp/panel01.html http://www.lisperati.com/landoflisp/panel01.html I consider Haskell to be an ML, and even then, it's worth remembering that lazy/non-strict MLs have different behavior from the rest of the family.
sansnomme 7y ago
Apple was not a unicorn that could single handedly force changes among developers then. Julia has plenty of funding and is pretty much a syntactic clone of Dylan (cleaned up somewhat) and it's trending on HN every other day.
- User23 7y ago
  I hope there isn't an AI Winter 2.0 that strangles Julia as the first go around did Common Lisp.
  - ddragon 7y ago
    Julia isn't that much positioned as an AI language, it's more of a numerical analysis and scientific computing language at this point competing with matlab, which is something that doesn't go through hype cycles. The fact that it's so well positioned for AI research is the result of that focus (high performance, expressive, interactive and math focused) plus being heavily inspired in Common Lisp, which means the language can be easily extended for new purposes (and CLOS was a brilliant system that didn't get the attention it deserved in the mainstream). Python is the AI language, and it's already more than large enough to survive many AI winters (plus "AI" is more powerful and useful every winter).
    - pjmlp 7y ago
      Python is the AI glue language. And it remains to be seen for how long, given C++20, Julia, ML.NET, Swift for Tensorflow and other approaches using the same underlying native libs.
rrdharan 7y ago
This is a weird analogy given that Ferrari no longer offers manual transmissions: https://www.bloomberg.com/news/articles/2016-06-17/why-can-t-you-get-your-300-000-supercar-with-a-stick-shift https://www.bloomberg.com/news/articles/2016-06-17/why-can-t... Or perhaps it’s entirely apt.
- dreamcompiler 7y ago
  I know. Likewise the German cars (at least in the US). And we are poorer for it.
jjtheblunt 7y ago
"See Dylan" : so well said!
jplayer01 7y ago
I don't understand the deal with parens. Or significant whitespace. Or other similar "issues". Surely people have bigger issues when writing applications than where you put your god damned brackets or if they're curved or braces or whatever else.
- jhbadger 7y ago
  Particularly when the "solution" to parens always seems to be significant whitespace, which is disliked by many as much as parens are by others. Both are just conventions that people get used to. I didn't care for significant whitespace when I first learned Python, but eventually I stopped seeing the problem, just as I stopped seeing the issue with parens in Lisps.
- breck 7y ago
  For me the obsession is with simplicity and theory, perhaps as much as the pragmatic effects. Things become a little bit simpler (fewer pieces), with indentation syntax. I find that really beautiful. As far as I can tell it can’t get any simpler than that. https://github.com/breck7/jtree/blob/master/papers/paper3/countingComplexity.pdf https://github.com/breck7/jtree/blob/master/papers/paper3/co...
  - jplayer01 7y ago
    Sorry, I meant I don't get why people complain about them so much.
pjmlp 7y ago
Dylan was a victim of political wars with the competing C++ group at Apple. The team even implemented Newton OS ahead of the C++ team just to prove a point, even knowing that they would be out anyway. Search for entries from wrs and mikelevins. https://news.ycombinator.com/item?id=15106802 https://news.ycombinator.com/item?id=15106802
- albanread 7y ago
  I also thought about Dylan when I heard of this racket direction; and took another look at it; Open Dylan has tremendous documentation (a very enjoyable read.) The compiler has been updated relatively recently to use LLVM; the command line programs run fine on Linux; I ran it on WSL2 and it seemed to work well there; it is a very nice and interesting language. I suspect luck, timing and fashion have a lot to do with language adoption; perhaps more than technical merit.
  - pjmlp 7y ago
    Thanks for the heads up, I thought that the effort to re-birth Dylan had died.
schpaencoder 7y ago
I agree, and Data and code is the same in a lisp.
slaymaker1907 7y ago
I was at Racketcon when Matthew first brought this up publicly. While it is a good way to kill a LISP, it is important to keep in mind that Racket is really an amazing workbench for creating new languages which interact with each other and being a LISP is mostly for the sake of making this easier. In addition to that goal, Racket was originally created as a teaching language and continues to be used as such. Some people in the community see the odd syntax of LISP as a barrier to entry and would like to see if it would be possible to use a more Algol-like syntax for ease of learning while also preserving the properties which make it easy to extend and define new languages in. Currently, there is already a distinction between parsing into s-exp and module-begin (i.e. all the interesting parts of your language) and this tech is already used to support languages which are based on s-exp and those which do fancier parsing such as the Datalog language. Personally, I would rather keep Racket with s-exp and focus on cleaning up the weird stuff that is a holdover from scheme such as not having a consistent interface for comparators like there is for equal?, adding in growable arrays as part of the standard library, and not insisting upon an enormous block of end parents all on the same line (this is largely a product of the API for extending DrRacket being somewhat obtuse for indentation).
- neilv 7y ago
  Regarding Racket being a teaching language, I'd like to make what I think is an important distinction... I don't consider Racket a teaching language. It was created (when it was called PLT Scheme) as a very practical and powerful implementation of Scheme, for at least 3 purposes: * implement multiple teaching languages (for incrementally introducing language complexity as a beginner learns); * implement an in-some-ways powerful IDE that would run on all desktop/laptop computers students might have access to; * be a programming languages research platform. I have an interest in education, but am not interested in using educational languages myself. I've always used Racket as a practical language, for industry production, university research, and personal techie learning/experimenting.

mark_l_watson 7y ago

It is a great shame that I can only give you one upvote, you have it exactly correct. Removing parents ruins Lisp languages. That said, I consider Haskell to be a Lisp language. But, Haskell was designed from the ground up, from ML, to be as it is.

dreamcompiler 7y ago
Completely agree. Haskell is IMO the only paren-free Lisp that works. As you said, it was designed that way from scratch, not as an afterthought from s-expr syntax. I also think automatic currying and pervasive laziness contribute a great deal to making the parens unnecessary, and most Lisps don't work that way.
- Oreb 7y ago
  > Haskell is IMO the only paren-free Lisp that works. Out of curiosity: Do you think Julia is not a Lisp, or that Julia doesn’t work?
  - dreamcompiler 7y ago
    I know Julia was originally a Lisp and it incorporates a lot of Lisp ideas, but I've never used it so I have no opinion about how well it works. Lots of Lispers consider Javascript a (primitive) Lisp because it has lexical closures, but I think its syntax is horrible and thus (IMO) it doesn't "work."
nudpiedo 7y ago
Why is Haskell a lisp? It is the first time I hear someone classifying Haskell in the “List Processing” family of languages, and although it does process lists I thought its main paradigma symbol and code representation goes in a complete different direction, more into pure function oriented programming.
- dreamcompiler 7y ago
  When people say something "is a Lisp" that usually has little to do with list processing. It's about whether it inherits more from lambda calculus than from Turing machines.
  - lispm 7y ago
    Lisp literally stands for 'List Processor'. To claim that it has little to do with it, is really really strange. One of the main reasons to create Lisp was being able to compute with 'symbolic expressions', represented as linked cons cells in the form of lists... McCarthy about Lisp: === As a programming language, LISP is characterized by the following ideas: computing with symbolic expressions rather than numbers, representation of symbolic expressions and other information by list structure in the memory of a computer, representation of information in external media mostly by multi-level lists and sometimes by S-expressions, a small set of selector and constructor operations expressed as functions, composition of functions as a tool for forming more complex functions, the use of conditional expressions for getting branching into function definitions, the recursive use of conditional expressions as a sufficient tool for building computable functions, the use of lambda-expressions for naming functions, the representation of LISP programs as LISP data, the conditional expression interpretation of Boolean connectives, the LISP function eval that serves both as a formal definition of the language and as an interpreter, and garbage collection as a means of handling the erasure problem. LISP statements are also used as a command language when LISP is used in a time-sharing environment. === http://jmc.stanford.edu/articles/lisp/lisp.pdf http://jmc.stanford.edu/articles/lisp/lisp.pdf 'lambda calculus' wasn't even explicitly mentioned. But he mentions s-expressions, list structure, multi-level lists, ...
    - 7y ago
dorfsmay 7y ago
Isn't homoiconicity one of the requirements for a lisp? If so, that makes Julia a lisp, but not Haskell.
lispm 7y ago
> That said, I consider Haskell to be a Lisp language. Then Lisp (aka 'List processor') has lost its meaning. Haskell is at its core a lazy evaluated, statically typed, purely functional programming language. Lisp is none of that. The core of Lisp: an eager evaluated, dynamically typed, programming language supporting imperative, procedural and non-pure functional programming. > But, Haskell was designed from the ground up, from ML, to be as it is. Haskell was designed to have a common lazy language, instead of a dozen languages under development or in use (Miranda, Lazy ML, Clean, ...).
lidHanteyk 7y ago
You are missing quite a bit of context on the history of Haskell. From https://www.microsoft.com/en-us/research/publication/a-history-of-haskell-being-lazy-with-class/ https://www.microsoft.com/en-us/research/publication/a-histo... , it seems that Haskell's design did not arise out of Lisp, but out of several languages in the early 80s which were lazy/non-strict and purely functional. Indeed, removing parents ruins the perception of Lisp languages as just another language family, and promotes Lisp into some sort of privileged position. Simultaneously, mistaking Haskell for a Lisp means mistakenly thinking that Haskell has special meaning for pairs over tuples or lists, that Lisps are statically typed or that Haskell is optionally typed, that Haskell has macros, that Haskell's juxtaposition-based application syntax is related to Lisp's parenthesis-based application syntax, and so on. Consider example Lisp memes: "Data is code; code is data," or "all structures are lists." Compare with example ML memes: "If it compiles, it works," or "well-typed programs don't go wrong." Or even better, with Haskell memes: "Laziness leads to purity," "monads are programmable semicolons," "show me your types." The only meme common to these communities is "lambda the ultimate", and you are ignoring decades of Lisp philosophy if you nominate this meme to carry the flag for all of Lisp. When I first read this comment tree, I wondered if everybody had forgotten about the Land of Lisp and the Republic of Haskell: http://www.lisperati.com/landoflisp/panel01.html http://www.lisperati.com/landoflisp/panel01.html I consider Haskell to be an ML, and even then, it's worth remembering that lazy/non-strict MLs have different behavior from the rest of the family.

sansnomme 7y ago

Apple was not a unicorn that could single handedly force changes among developers then. Julia has plenty of funding and is pretty much a syntactic clone of Dylan (cleaned up somewhat) and it's trending on HN every other day.

User23 7y ago
I hope there isn't an AI Winter 2.0 that strangles Julia as the first go around did Common Lisp.
- ddragon 7y ago
  Julia isn't that much positioned as an AI language, it's more of a numerical analysis and scientific computing language at this point competing with matlab, which is something that doesn't go through hype cycles. The fact that it's so well positioned for AI research is the result of that focus (high performance, expressive, interactive and math focused) plus being heavily inspired in Common Lisp, which means the language can be easily extended for new purposes (and CLOS was a brilliant system that didn't get the attention it deserved in the mainstream). Python is the AI language, and it's already more than large enough to survive many AI winters (plus "AI" is more powerful and useful every winter).
  - pjmlp 7y ago
    Python is the AI glue language. And it remains to be seen for how long, given C++20, Julia, ML.NET, Swift for Tensorflow and other approaches using the same underlying native libs.

rrdharan 7y ago

This is a weird analogy given that Ferrari no longer offers manual transmissions: https://www.bloomberg.com/news/articles/2016-06-17/why-can-t-you-get-your-300-000-supercar-with-a-stick-shift https://www.bloomberg.com/news/articles/2016-06-17/why-can-t... Or perhaps it’s entirely apt.

dreamcompiler 7y ago
I know. Likewise the German cars (at least in the US). And we are poorer for it.

jjtheblunt 7y ago

"See Dylan" : so well said!

jplayer01 7y ago

I don't understand the deal with parens. Or significant whitespace. Or other similar "issues". Surely people have bigger issues when writing applications than where you put your god damned brackets or if they're curved or braces or whatever else.

jhbadger 7y ago
Particularly when the "solution" to parens always seems to be significant whitespace, which is disliked by many as much as parens are by others. Both are just conventions that people get used to. I didn't care for significant whitespace when I first learned Python, but eventually I stopped seeing the problem, just as I stopped seeing the issue with parens in Lisps.
breck 7y ago
For me the obsession is with simplicity and theory, perhaps as much as the pragmatic effects. Things become a little bit simpler (fewer pieces), with indentation syntax. I find that really beautiful. As far as I can tell it can’t get any simpler than that. https://github.com/breck7/jtree/blob/master/papers/paper3/countingComplexity.pdf https://github.com/breck7/jtree/blob/master/papers/paper3/co...
- jplayer01 7y ago
  Sorry, I meant I don't get why people complain about them so much.

pjmlp 7y ago

Dylan was a victim of political wars with the competing C++ group at Apple. The team even implemented Newton OS ahead of the C++ team just to prove a point, even knowing that they would be out anyway. Search for entries from wrs and mikelevins. https://news.ycombinator.com/item?id=15106802 https://news.ycombinator.com/item?id=15106802

albanread 7y ago
I also thought about Dylan when I heard of this racket direction; and took another look at it; Open Dylan has tremendous documentation (a very enjoyable read.) The compiler has been updated relatively recently to use LLVM; the command line programs run fine on Linux; I ran it on WSL2 and it seemed to work well there; it is a very nice and interesting language. I suspect luck, timing and fashion have a lot to do with language adoption; perhaps more than technical merit.
- pjmlp 7y ago
  Thanks for the heads up, I thought that the effort to re-birth Dylan had died.

schpaencoder 7y ago

I agree, and Data and code is the same in a lisp.

slaymaker1907 7y ago

I was at Racketcon when Matthew first brought this up publicly. While it is a good way to kill a LISP, it is important to keep in mind that Racket is really an amazing workbench for creating new languages which interact with each other and being a LISP is mostly for the sake of making this easier. In addition to that goal, Racket was originally created as a teaching language and continues to be used as such. Some people in the community see the odd syntax of LISP as a barrier to entry and would like to see if it would be possible to use a more Algol-like syntax for ease of learning while also preserving the properties which make it easy to extend and define new languages in. Currently, there is already a distinction between parsing into s-exp and module-begin (i.e. all the interesting parts of your language) and this tech is already used to support languages which are based on s-exp and those which do fancier parsing such as the Datalog language. Personally, I would rather keep Racket with s-exp and focus on cleaning up the weird stuff that is a holdover from scheme such as not having a consistent interface for comparators like there is for equal?, adding in growable arrays as part of the standard library, and not insisting upon an enormous block of end parents all on the same line (this is largely a product of the API for extending DrRacket being somewhat obtuse for indentation).

neilv 7y ago
Regarding Racket being a teaching language, I'd like to make what I think is an important distinction... I don't consider Racket a teaching language. It was created (when it was called PLT Scheme) as a very practical and powerful implementation of Scheme, for at least 3 purposes: * implement multiple teaching languages (for incrementally introducing language complexity as a beginner learns); * implement an in-some-ways powerful IDE that would run on all desktop/laptop computers students might have access to; * be a programming languages research platform. I have an interest in education, but am not interested in using educational languages myself. I've always used Racket as a practical language, for industry production, university research, and personal techie learning/experimenting.