The Nature of Lisp (2006)(defmacro.org)
defmacro.org
The Nature of Lisp (2006)
http://www.defmacro.org/ramblings/lisp.html
94 comments
I don't really mind the parens, but the whole attitude feels indicative of a problem. Like - it's 2018 and people are still using 'cdr' and 'cons' as terminology and happily expecting other people to learn those words and not even feeling bad about it.
If the person justifying Lisp doesn't mind that the word 'cons' is terrible, why should I trust their aesthetic sense about anything? If I have to have "miserable notations" to get "coding nirvana", and coding nirvana is so great, why not fix the notations? do you just think everyone should have to struggle because you did?
I guess it feels like trying to determine which of these statements are true: (1) "Lisp is coding nirvana" (2) "Lisp is weird regressive nostalgia for a simpler era where nothing was typed and everyone used Emacs and memorized arcane terminology and shared macros on Usenet", and there are way too many signs that it's a lot of (2).
[edited to be less abrasive]
If the person justifying Lisp doesn't mind that the word 'cons' is terrible, why should I trust their aesthetic sense about anything? If I have to have "miserable notations" to get "coding nirvana", and coding nirvana is so great, why not fix the notations? do you just think everyone should have to struggle because you did?
I guess it feels like trying to determine which of these statements are true: (1) "Lisp is coding nirvana" (2) "Lisp is weird regressive nostalgia for a simpler era where nothing was typed and everyone used Emacs and memorized arcane terminology and shared macros on Usenet", and there are way too many signs that it's a lot of (2).
[edited to be less abrasive]
"Like - it's 2018 and people are still using 'cdr' and 'cons'"
Like they're really not. "first" and "rest" work just as well as car and cdr.
https://stackoverflow.com/questions/29907440/difference-betw...
"[edited to be less abrasive]"
Keep editing.
Like they're really not. "first" and "rest" work just as well as car and cdr.
https://stackoverflow.com/questions/29907440/difference-betw...
"[edited to be less abrasive]"
Keep editing.
"Keep editing"
It's tricky online to find the right place in between "having opinions" and "never contributing". I have opinions about the Lisp world that aren't that nice but weren't represented in the comment section, so I wanted to throw them in. The opinions are dismissive, so they had to sound a bit dismissive. My first pass was overly dismissive so I edited it but I don't think I want to go more "o please teach me!" than I did because then I'm lying about how I (and I think other people!) feel. Which is, basically, frustrated.
It's tricky online to find the right place in between "having opinions" and "never contributing". I have opinions about the Lisp world that aren't that nice but weren't represented in the comment section, so I wanted to throw them in. The opinions are dismissive, so they had to sound a bit dismissive. My first pass was overly dismissive so I edited it but I don't think I want to go more "o please teach me!" than I did because then I'm lying about how I (and I think other people!) feel. Which is, basically, frustrated.
> If the person justifying Lisp doesn't mind that the word 'cons' is terrible, why should I trust their aesthetic sense about anything?
This is not about aesthetics, unless you are arguing that the symbols should be replaced by square brackets or emoji.
And this has been tried before. S-Expressions are not the only way to express lisp. There are M-Expressions and many other notations. Even significant whitespace has been tried.
And yet people keep coming back to parentheses. Don't you think there is a reason for that?
Also: almost all other languages use the exact same convention for lists that Lisp uses (except they tend to use square brackets as their symbol).
This is not about aesthetics, unless you are arguing that the symbols should be replaced by square brackets or emoji.
And this has been tried before. S-Expressions are not the only way to express lisp. There are M-Expressions and many other notations. Even significant whitespace has been tried.
And yet people keep coming back to parentheses. Don't you think there is a reason for that?
Also: almost all other languages use the exact same convention for lists that Lisp uses (except they tend to use square brackets as their symbol).
Conventions exist in every language. `car', `cons', and `cdr' are also part of certain standards (e.g. RnRS). And, honestly, they compose a bit better than `first', and `rest' for combinations like `caddr' and `caaddr'. I suspect that you're going to be even more unhappy with those constructions.
The same can be said about older languages like C, which also have standardized notations.
Why fix what isn't broken?
The same can be said about older languages like C, which also have standardized notations.
Why fix what isn't broken?
> for combinations like `caddr' and `caaddr'
Right...because `caddr' and `caaddr' are good because??? And when is the last time you consciously used any of those primitives?
Right...because `caddr' and `caaddr' are good because??? And when is the last time you consciously used any of those primitives?
I use them frequently. Having to write something like `(car (car (cdr foo)))` is common (`caadr`).
Because it is broken. It's not broken if you've already learned it and internalized the terminology; it's broken for everyone else because it's needlessly difficult to learn (and actively dissuades people from wanting to learn it, hence all the articles evangelizing Lisp).
Old communties have old words. Check some UNIX command names sometimes. C doesn't rename its operators either.
Renaming stuff every few years dosn't make it easier to learn.
Renaming stuff every few years dosn't make it easier to learn.
By that rationale every foreign language is broken, and, maybe more pointedly, every language but Chinese (or possibly Spanish) is broken and needlessly difficult to learn.
The trend of history since babel seems to be going in this direction. If there is eventually a universal common tongue this rational will be proven right.
It's not like that everywhere in the lispverse. I was overjoyed when Racket offered functions like 'first', 'rest', and 'second' to use in place of 'car', 'cdr' and 'cadr'. (Though it still retains the gross names, for backward compatibility.) Clojure does similar, with a hefty dose of additional pragmatism.
TBH, though, as someone who used to love Scheme (and has yet to spend any real time with Clojure), I agree that there's a hefty amount of nostalgia involved. 2 or 3 decades ago, lisp felt like a total sea change compared to what else was out there, which was mostly just a bunch of C and BASIC dialects. Nowadays even the C dialects have adopted most of what made lisp feel great, and I just don't feel that great a need to go back to living a world where (almost) everything is a linked list.
TBH, though, as someone who used to love Scheme (and has yet to spend any real time with Clojure), I agree that there's a hefty amount of nostalgia involved. 2 or 3 decades ago, lisp felt like a total sea change compared to what else was out there, which was mostly just a bunch of C and BASIC dialects. Nowadays even the C dialects have adopted most of what made lisp feel great, and I just don't feel that great a need to go back to living a world where (almost) everything is a linked list.
I think that there is a utility to the odd names. 'cons' is really just a pair while 'car' and 'cdr' are just the first and second member of that pair respectively, but this pair is a specific kind of pair for a specific kind of purpose so it makes sense to have a special jargon for it. It makes sense not to pollute the global namespace by reserving such common words and it helps to know immediately that one is talking about specifics of the Lisp list implementation. I suppose that some might prefer to not have to worry about the specifics of Lisp list implementation at all (Clojure manages this pretty well), but I think that having that kind or relatively low-level access has its uses.
(All things considered, I don't think that 'for' or 'switch' are any clearer, anyway.)
(All things considered, I don't think that 'for' or 'switch' are any clearer, anyway.)
> Like - it's 2018 and people are still using 'cdr' and 'cons' as terminology and happily expecting other people to learn those words
Ok, so what do you think are better names for those operators and why would they be better?
Ok, so what do you think are better names for those operators and why would they be better?
'first' and 'rest' for 'car' and 'cdr' are obviously better, because they say what's going on, and that's why some people are already using them. I'm not sure if there's a good term that's not already used for 'cons'. Maybe 'Join' or something.
Do I even need to justify why these are better names? The problem is not that people don't know about better names. Everyone does [0]. My issue is that this doesn't seem to bother people.
[0]: https://www.gnu.org/software/emacs/manual/html_node/eintr/St...
Do I even need to justify why these are better names? The problem is not that people don't know about better names. Everyone does [0]. My issue is that this doesn't seem to bother people.
[0]: https://www.gnu.org/software/emacs/manual/html_node/eintr/St...
The problem is that FIRST and REST doesn't cover the whole idea of cons cells. That's why the old names still exist.
The Lisp practice for 40 years is to use FIRST, REST, LIST, APPEND, LIST*, ... when we speak about List Processing.
CONS, CAR and CDR are used when cons cells are used for things like trees, graphs and other data structures. It's an indicator that the code is very low-level and used for assembling other data structures from cons cells.
The Lisp practice for 40 years is to use FIRST, REST, LIST, APPEND, LIST*, ... when we speak about List Processing.
CONS, CAR and CDR are used when cons cells are used for things like trees, graphs and other data structures. It's an indicator that the code is very low-level and used for assembling other data structures from cons cells.
> 'first' and 'rest' for 'car' and 'cdr' are obviously better, because they say what's going on
I sometimes use cons cells for binary trees - first and rest are misleading in that case. I very often use cons cells to define things - the car is some object and the cdr is some property or definition that applies to the object. first and rest are misleading for that use case.
What you are proposing is to use domain-specific names for operations on an abstract data structure. Any names with pre-existing meaning will become misleading as soon as the data structure is applied to a different application. Coming up with new terminology to unambiguously refer to new technical concepts is not a "problem," it is a means of effective communication.
I sometimes use cons cells for binary trees - first and rest are misleading in that case. I very often use cons cells to define things - the car is some object and the cdr is some property or definition that applies to the object. first and rest are misleading for that use case.
What you are proposing is to use domain-specific names for operations on an abstract data structure. Any names with pre-existing meaning will become misleading as soon as the data structure is applied to a different application. Coming up with new terminology to unambiguously refer to new technical concepts is not a "problem," it is a means of effective communication.
I read:
whyknow thing like word"and"sentence to write and plural and capitalization comma dot semicolon space question mark need write spaces between them wordamabobs
why don't fix notation???
whyknow thing like word"and"sentence to write and plural and capitalization comma dot semicolon space question mark need write spaces between them wordamabobs
why don't fix notation???
> Like - it's 2018 and people are still using 'cdr' and 'cons' as terminology and happily expecting other people to learn those words and not even feeling bad about it.
Oh please, cry me a river. Like monads, promises, or props are any better.
> If the person justifying Lisp doesn't mind that the word 'cons' is terrible, why should I trust their aesthetic sense about anything? If I have to have "miserable notations" to get "coding nirvana", and coding nirvana is so great, why not fix the notations? do you just think everyone should have to struggle because you did?
Your ignorance is baffling. The notation is a feature, not a bug. If you want the feature, then yes, you will have to struggle.
While cons and cdr as concepts are necessary to learning what goes underneath the hood, idiomatic lisp is rarely written in terms of cons and cdr.
Oh please, cry me a river. Like monads, promises, or props are any better.
> If the person justifying Lisp doesn't mind that the word 'cons' is terrible, why should I trust their aesthetic sense about anything? If I have to have "miserable notations" to get "coding nirvana", and coding nirvana is so great, why not fix the notations? do you just think everyone should have to struggle because you did?
Your ignorance is baffling. The notation is a feature, not a bug. If you want the feature, then yes, you will have to struggle.
While cons and cdr as concepts are necessary to learning what goes underneath the hood, idiomatic lisp is rarely written in terms of cons and cdr.
[deleted]
I know that. My point is that the antiquated terminology's survival seems to be a symptom of a culture that values the wrong things: like pointless historical names instead of clear modernized ones.
(Monads and props are definitely not better. You won't find me defending them! 'Promise' is a much better name, though.)
(Monads and props are definitely not better. You won't find me defending them! 'Promise' is a much better name, though.)
FIRST and REST as names for list operations have been added 40 years ago. Pattern destructuring and list templates are as old.
Naming is important, but the core Lisp names can be learned in a day.
Naming is important, but the core Lisp names can be learned in a day.
Yes, and yet the names Cons and Cdr still exist and come up in introductory documentation and are still used in discussions constantly -- why?
Because people like bikeshedding.
Cons is a little bit weird, but it is par with C's "typedef", it could have been named better.
car and cdr are weirder, but there are reasons people use them over first and rest: 1- they are shorter and 2- they can be combined (caadr, cadr, cddr, instead for (first (rest x)) etc).
It is still bikeshedding. You learn that stuff in less time than what it takes to create an angry post.
And if you really hate them, you don't have to use them. Just define a macro and you can stop complaining. Your coworkers may not like this though.
car and cdr are weirder, but there are reasons people use them over first and rest: 1- they are shorter and 2- they can be combined (caadr, cadr, cddr, instead for (first (rest x)) etc).
It is still bikeshedding. You learn that stuff in less time than what it takes to create an angry post.
And if you really hate them, you don't have to use them. Just define a macro and you can stop complaining. Your coworkers may not like this though.
There is actually a good reason: it's precisely because they bring in no semantic baggage. Although conses are usually used to build list structure, they don't have to be used that way; you can make binary trees or even arbitrary graphs with cycles out of them (creating directed cycles requires side effects, of course). The accessors 'first' and 'rest' are appropriate only for conses used as list structure. Even 'left' and 'right', which are less semantically loaded than 'first' and 'rest', wouldn't be appropriate in all cases.
So, what would be a better name than 'cons'? 'List' is not right; the empty list is not a cons. Scheme uses 'pair', which is admittedly not too bad, but I think it would be more appropriate for an immutable pair than a mutable two-element struct. (I actually think there should be two types, immutable pairs and mutable conses. In such a Lisp, conses would probably be fairly rarely used, and much more of a historical relic.)
And to echo what outworlder says, it really just isn't that big a deal. Yes, Common Lisp has some historical baggage, and a lot of things we would change if were designing our own Lisp from scratch — I assure you every Lisper has their own list. But CL rationalization projects, of which there have been several over the years (and, no doubt, more that I'm not aware of), don't catch on. The reason is clear: the CL community is already "small yet remarkably fragmented" as I recall someone putting it (Eric Raymond?); a rationalized CL would just fork off another sub-community, if it caught on at all.
So, what would be a better name than 'cons'? 'List' is not right; the empty list is not a cons. Scheme uses 'pair', which is admittedly not too bad, but I think it would be more appropriate for an immutable pair than a mutable two-element struct. (I actually think there should be two types, immutable pairs and mutable conses. In such a Lisp, conses would probably be fairly rarely used, and much more of a historical relic.)
And to echo what outworlder says, it really just isn't that big a deal. Yes, Common Lisp has some historical baggage, and a lot of things we would change if were designing our own Lisp from scratch — I assure you every Lisper has their own list. But CL rationalization projects, of which there have been several over the years (and, no doubt, more that I'm not aware of), don't catch on. The reason is clear: the CL community is already "small yet remarkably fragmented" as I recall someone putting it (Eric Raymond?); a rationalized CL would just fork off another sub-community, if it caught on at all.
Because introductory material tends to live long.
It is also used for non-list data structures.
Sometimes in CS education Lisp is/was used to teach new stuff, making sure that students were challenged beyond their comfort zones, for example by reinventing the basic machineries from a few abstract principles. Typically Lisp was not used as a programming language, but as a device to teach new ways to think about computation: algorithms, some basic data structures, control structures, functional programming, ... Today you'll see other langages in CS education, with other goals.
See SICP and others...
It is also used for non-list data structures.
Sometimes in CS education Lisp is/was used to teach new stuff, making sure that students were challenged beyond their comfort zones, for example by reinventing the basic machineries from a few abstract principles. Typically Lisp was not used as a programming language, but as a device to teach new ways to think about computation: algorithms, some basic data structures, control structures, functional programming, ... Today you'll see other langages in CS education, with other goals.
See SICP and others...
> Oh please, cry me a river
> Your ignorance is baffling.
That is not acceptable on HN and will get you banned. Please read https://news.ycombinator.com/newsguidelines.html and only post with respect for others.
I agree with you about car, cdr, and Lisp notation—and that strengthens the sentence above. The last thing we want is people arguing for correct positions by being a jerk. By doing so you discredit what's correct and/or legitimize being a jerk—two dreadful outcomes that matter more than someone being wrong (in your view or mine) about car and cdr.
> Your ignorance is baffling.
That is not acceptable on HN and will get you banned. Please read https://news.ycombinator.com/newsguidelines.html and only post with respect for others.
I agree with you about car, cdr, and Lisp notation—and that strengthens the sentence above. The last thing we want is people arguing for correct positions by being a jerk. By doing so you discredit what's correct and/or legitimize being a jerk—two dreadful outcomes that matter more than someone being wrong (in your view or mine) about car and cdr.
That said, it would be nice if lisp used square brackets for this instead. Easier to type on boring old US QWERTY.
Parentheses are so much more frequently typed than square brackets in almost every context that you are better off following the Lisp Machine keyboard layout and swapping them on your keyboard even if you do not program in Lisp:
https://news.ycombinator.com/item?id=14985932
https://news.ycombinator.com/item?id=14985932
Yes, agreed. From your previous comment:
> Apple does not provide a way to do these remappings on OS X
Run Emacs (or XEmacs) under XQuartz and you can do whatever remapping you want. This is how I deal with it.
Another choice is a fully programmable keyboard, though these also tend to have nonstandard layouts that require some retraining.
> Apple does not provide a way to do these remappings on OS X
Run Emacs (or XEmacs) under XQuartz and you can do whatever remapping you want. This is how I deal with it.
Another choice is a fully programmable keyboard, though these also tend to have nonstandard layouts that require some retraining.
There is no need for X, you can just use elisp, i.e.: (keyboard-translate ?\[ ?\()
And unless you do need X, I suggest using Emacs-Mac-Port instead of of the official Emacs: https://bitbucket.org/mituharu/emacs-mac/overview
And unless you do need X, I suggest using Emacs-Mac-Port instead of of the official Emacs: https://bitbucket.org/mituharu/emacs-mac/overview
Rebol and Red are very Lisp like and use square brackets instead of paren's.
No problem, just a couple reader macros!
(Adapted from an answer on https://stackoverflow.com/questions/1988/how-far-can-lisp-ma...)
;; Make [] == ()
(set-syntax-from-char #\[ #\( )
(defun lbrace-reader (stream inchar)
(declare (ignore inchar))
(read-delimited-list #\] stream t))
(set-macro-character #\[ #'lbrace-reader)
(set-macro-character #\] (get-macro-character #\) ))
(set-syntax-from-char #\] #\) )Some lisps use parenthesis and brackets interchangeably. Some people prefer to strategically alternate them, but you're free to use them exclusively.
Guile Scheme, for example:
Guile Scheme, for example:
scheme@(guile-user)> [list 1 2 3]
$1 = (1 2 3)
scheme@(guile-user)> (list 1 2 3)
$2 = (1 2 3)
scheme@(guile-user)> [car '[1 2 3]]
$3 = 1While true, this is not officially supported as part of the RnRS standard I believe. They set these characters aside as reserved for future use.
Yes, you're correct. R7RS at least explicitly reserves brackets and braces, and only acknowledges parenthesis in its syntax.
Racket can use either. They are syntactically equivalent, but there are some community norms around when to use each. Racket’s included editor DrRacket takes the [ and ] keys and figures out which to use using those conventions, inserting either [ or ( as appropriate
I'd like to see square brackets replace the backtick.
I only have a cursory familiarity with lisps but I constantly find that too easy to miss.
I only have a cursory familiarity with lisps but I constantly find that too easy to miss.
Square brackets are AltGr-8 and AltGr-9 on German T2, but Parens are Shift-8 and Shift-9, which is much nicer on the hands.
So I’m going to be against this.
So I’m going to be against this.
$ setxkbmap -option parens:swap_bracketsA language’s syntax is the very first thing you encounter. And if you are not familiar with it, it will be a major sore point when trying to learn the language.
So yes, while complaints about syntax are largely irrelevant once you already know the language, the complaints will be there for any new user.
So yes, while complaints about syntax are largely irrelevant once you already know the language, the complaints will be there for any new user.
I can handle parentheses.
What really gets me? Semicolons. Most useless character in programming language history. Every time I switch from a language that doesn't require them to one that does, the pirates run away from me.
What really gets me? Semicolons. Most useless character in programming language history. Every time I switch from a language that doesn't require them to one that does, the pirates run away from me.
Well, what are the options for detecting the end of a statement? You can have a language where all possible statements are clear about where the end is from just the statement alone. You can have a language where each statement has to be on a separate line, and only on one line (or where you specially mark a continuation of a statement from the previous line). Or you can have a termination marker. As far as I can tell, that's pretty much the list of possible options.
Note that Lisp has taken the first approach: It's clear (by closing the opening paren) when you're done with a statement.
Note that Lisp has taken the first approach: It's clear (by closing the opening paren) when you're done with a statement.
Technically, of course, there are no statements in Lisp; there are only expressions (forms, Lisp calls them).
The artificial distinction between statements and expressions is a source of endless annoyance to me when I'm working (as I do, for my day job) in a language that has it. In Lisp I can say things like
The point is, I think this complaint, about the statement/expression distinction, has a lot more substance than complaints about either parentheses or semicolons.
The artificial distinction between statements and expressions is a source of endless annoyance to me when I'm working (as I do, for my day job) in a language that has it. In Lisp I can say things like
(when (some (lambda (x) ...) some-list)
(do-something))
The point is, I think this complaint, about the statement/expression distinction, has a lot more substance than complaints about either parentheses or semicolons.
Python handles this really well.
A statement can span multiple lines. And it has no termination marker.
A statement can span multiple lines. And it has no termination marker.
This.
At least parentheses have a useful purpose and can even help you when writing code (paredit and the like). Semicolons are only there to help compiler writers.
It would be ok if they were allowed, but optional. How many times do you really have to write more than one statement per line?
At least parentheses have a useful purpose and can even help you when writing code (paredit and the like). Semicolons are only there to help compiler writers.
It would be ok if they were allowed, but optional. How many times do you really have to write more than one statement per line?
The issue is these days everytime I hear optional I think of semicolons in JavaScript where they are optional except for one or two edge cases I can't remember off the top of my head. Optional is good as long as its a complete you can do it this way or that way like gradual typing in some languages.
Indeed. I meant really optional, not something like automatic semicolon insertion, where they are there, they are required by the grammar, but you are allowed to omit them in some cases.
> the pirates run away from me
Nice expression. Is it a pop culture reference I have missed?
Nice expression. Is it a pop culture reference I have missed?
I suspect (but do not know) that the reference is "swearing like a pirate". BeetleB is (I think) saying that semicolons lead to swearing that even the pirates are offended/appalled. (It took me reading it a few times to get that, and I'm still not certain it's right.)
Yep. Maybe I should have said the pirates around me start blushing.
It is a true statement, lisp syntax is wierd.
You spend years learning that 2 + 2 = 4, seeing (+ 2 2) for the first time is a bit of a shock.
The point is overused but its a good point and he doesnt dwell on it. Arguments shouldnt be evaluated just by how interesting they are.
You spend years learning that 2 + 2 = 4, seeing (+ 2 2) for the first time is a bit of a shock.
The point is overused but its a good point and he doesnt dwell on it. Arguments shouldnt be evaluated just by how interesting they are.
Algol syntax is weird.
Tell me, what does this mean?
My point is, there is no such thing as a natural syntax. They're all weird. They all have to be learned. Some provide more benefits than others after they've been learned.
(Also: You're only a newbie once. Optimizing for that one-time thing is a bit odd, when you'll spend far more of your life as an experienced programmer.)
Tell me, what does this mean?
x = x + 5
My point is, there is no such thing as a natural syntax. They're all weird. They all have to be learned. Some provide more benefits than others after they've been learned.
(Also: You're only a newbie once. Optimizing for that one-time thing is a bit odd, when you'll spend far more of your life as an experienced programmer.)
That's precisely why Algol used ':=' for assignment ;-}
Eh, C/Java is an Algol, too.
You know, like how Scala/Scheme is a Lisp.
You know, like how Scala/Scheme is a Lisp.
I think it was Fortran that first used plain "=" for assignment; and C is a descendant of Fortran as much as of Algol. So that might have been a more appropriate reference.
The parent post shouldn't be interpreted as dismissing the argument because it isn't interesting but because it has been beaten to death. It's the kind of argument that has been had from every meaningful angle and the programming community has, unless I'm wildly mistaken, settled on a few conclusions regarding it. Like a lot of things, one conclusion is simply that Lisp syntax being good, bad, easy or difficult to read comes down in part to preference of the individual. Of course there are other conclusions as well, but the point is that dwelling on the subject is generally not a productive use of time. It's so old and popular to discuss that very little of value comes from discussing it further, and repeating the arguments is both distracting and potentially even discouraging for some less experienced programmers.
> but please, advocates and enemies of Lisp, just give up on picking on the parens
Each non-lisper will reinvent the argument from scratch, so advocates can't profitably ignore it. It's a shame. You get past that so quickly after using lisp.
Each non-lisper will reinvent the argument from scratch, so advocates can't profitably ignore it. It's a shame. You get past that so quickly after using lisp.
(It (is :wonder (we can (read :text without (as much :brackets as) LISP)))). Well, "as _ as" is technically bracketing, but you get the idea.
So I tried once to use a dot as list terminator, which didn't work well. I found myself adding different terminators for each level of depth. Because, at some point the encapsulation over multiple levels leads to ambiguity, if outfix notation isn't used (as for the encapsulation in this sentence). A common wisdom is to avoid deep indentation. 3rd normal form schemes are enough for most cases, thank Codd.
By the way: I've been hugely interested in historical linguistics recently and came to conclude counting must have been a huge boost for the development of language facility. Basic phrases are just enumerations. Which reminded me of list processing. Many old languages actually tend to follow VSO word order, too. Plural is often enough expressed as reduplication. But I don't have deeper insights to offer from this on how to avoid the parens, except that zeroth order logic is fundamental and a linguistic approach to programming languages might prove fruitful (grammar, not syntax). And by the by the way: Isn't "everything is an object" similar in power to homoiconicity?
So I tried once to use a dot as list terminator, which didn't work well. I found myself adding different terminators for each level of depth. Because, at some point the encapsulation over multiple levels leads to ambiguity, if outfix notation isn't used (as for the encapsulation in this sentence). A common wisdom is to avoid deep indentation. 3rd normal form schemes are enough for most cases, thank Codd.
By the way: I've been hugely interested in historical linguistics recently and came to conclude counting must have been a huge boost for the development of language facility. Basic phrases are just enumerations. Which reminded me of list processing. Many old languages actually tend to follow VSO word order, too. Plural is often enough expressed as reduplication. But I don't have deeper insights to offer from this on how to avoid the parens, except that zeroth order logic is fundamental and a linguistic approach to programming languages might prove fruitful (grammar, not syntax). And by the by the way: Isn't "everything is an object" similar in power to homoiconicity?
>And by the by the way: Isn't "everything is an object" similar in power to homoiconicity?
This is the only part of your (very interesting) comment I feel qualified to talk about.
I think there may be something there, but you'd have to be extreme about it, making methods into objects, and proabably even keywords like "if." This is a high bar---but macros clear it.
This is the only part of your (very interesting) comment I feel qualified to talk about.
I think there may be something there, but you'd have to be extreme about it, making methods into objects, and proabably even keywords like "if." This is a high bar---but macros clear it.
Previous discussions:
https://news.ycombinator.com/item?id=4765067
https://news.ycombinator.com/item?id=9575786
https://news.ycombinator.com/item?id=1319034
https://news.ycombinator.com/item?id=4765067
https://news.ycombinator.com/item?id=9575786
https://news.ycombinator.com/item?id=1319034
In case you or anyone reading this were unaware, there is a link underneath stories called "past," which provides the service nathell did in parent.
Huh I never knew that. Have I been completely oblivious of it, or has that been added recently ?
Woah, I've been reading hackers news for years and never noticed that.
I would suggest it be an expanded list by default. It would really cut down on dupes and encourage everybody to build on the old conversation instead of rehashing it.
I would suggest it be an expanded list by default. It would really cut down on dupes and encourage everybody to build on the old conversation instead of rehashing it.
LISP is great, but the problem with making programs in it is that one invariably ends up trying to answer the meaning of life, the universe, and everything.
(just kidding
(sardonicly?
(isn't it obvious?
(depends on how one writes it
(like with what editor?
(we all know there is only one editor
(emacs?
(Stallman's own
(not to imply ownership
(as editors should be free
(along with all software
(like knowledge
(which are just ideas with proven value
(requiring recognition
(implying awareness of self
(assumed when using LISP)
)))))))))))))))Back in 2009, when I first learned Common Lisp, I had the hope Lisp would one day become mainstream. Then in 2012 I had the same hope for Scala.
... I got older and I'm not anymore a dreamer
Legacy code and imperative thinking is heavy.
... I got older and I'm not anymore a dreamer
Legacy code and imperative thinking is heavy.
> I'm not anymore a dreamer
Perhaps it's time to start dreaming again?
Rewriting the world for VR/AR is coming up. And unlike the rewrite for mobile, this time our software development environments will be transformed as well (mobile wasn't a place for writing code). And while we're perhaps running out of time for new compiler targets and languages, there seems a lot of potential for changing infrastructure.
For example, a talk went by, which I recall as someone dropping linux instances on google lambda, and setting up deterministic C compilation, for massive parallelism and caching. So push a button, and some seconds later a linux kernel has been recompiled (from empty cache). Which rather changes the constraint space on "our language or type system can't provide nice-thing X, because it would take too long to compile". Golang's story of runs fast on a couple of local cores, may shortly sound like "my IDE runs on a PDP-11!", sort of "that's cute - nice art piece". Is it ok to take two days to run some proof obligation? ... well, is it cached now, so no one ever has to do that again?
Eye tracking; hand/finger tracking; escaping from 2D's crippling real-estate constraints; speech recognition; fine-grain code sharing; rich compilation frameworks ... there's a lot of fun incoming.
Perhaps it's time to start dreaming again?
Rewriting the world for VR/AR is coming up. And unlike the rewrite for mobile, this time our software development environments will be transformed as well (mobile wasn't a place for writing code). And while we're perhaps running out of time for new compiler targets and languages, there seems a lot of potential for changing infrastructure.
For example, a talk went by, which I recall as someone dropping linux instances on google lambda, and setting up deterministic C compilation, for massive parallelism and caching. So push a button, and some seconds later a linux kernel has been recompiled (from empty cache). Which rather changes the constraint space on "our language or type system can't provide nice-thing X, because it would take too long to compile". Golang's story of runs fast on a couple of local cores, may shortly sound like "my IDE runs on a PDP-11!", sort of "that's cute - nice art piece". Is it ok to take two days to run some proof obligation? ... well, is it cached now, so no one ever has to do that again?
Eye tracking; hand/finger tracking; escaping from 2D's crippling real-estate constraints; speech recognition; fine-grain code sharing; rich compilation frameworks ... there's a lot of fun incoming.
Similar experience, dream. Started playing with XLisp in late 1986. Common Lisp in 1989 to 1993. Loved it. Was greatly influenced by it. But never used it commercially.
Now I dabble with Clojure on the side.
Now I dabble with Clojure on the side.
Am I the only one who finds it hilarious that there are complaints about Lisp syntax, when the language itself is almost infinitely modifiable?
You can replace parens with reader macros. You can replace built in names with ordinary macros(in some dialects, even reassign the built-in functions altogether). Don't like the let syntax? Modify it yourself to something completely different.
You could modify Lisp to look like json if you were so inclined.
You have access to the compiler at compile time and runtime. Do whatever you want.
If anything, people should be complaining about other languages that don't allow for syntax modification. Want to not type semicolons in C? You are essentially out of luck, unless you want to make your own preprocessor (I don't think the standard one has enough expressive power to do so, but I'd love to be proved wrong).
Complaining about parentheses takes zero effort though. You don't have to spend a single second trying to understand why it looks weird like that...
You can replace parens with reader macros. You can replace built in names with ordinary macros(in some dialects, even reassign the built-in functions altogether). Don't like the let syntax? Modify it yourself to something completely different.
You could modify Lisp to look like json if you were so inclined.
You have access to the compiler at compile time and runtime. Do whatever you want.
If anything, people should be complaining about other languages that don't allow for syntax modification. Want to not type semicolons in C? You are essentially out of luck, unless you want to make your own preprocessor (I don't think the standard one has enough expressive power to do so, but I'd love to be proved wrong).
Complaining about parentheses takes zero effort though. You don't have to spend a single second trying to understand why it looks weird like that...
I'm a lisp fan, but to be fair, I don't think I know anybody who wants to live in a world in which everybody has created their own personal language syntax. Reader macros should be used very judiciously unless you don't care about anybody else being able to understand your code.
I agree.
But if you care that strongly, you can do something about it.
(I am also kind of hoping that, by the time one gets to reader macros, they will be experienced enough, and will understand why the parentheses exist so that they will no longer care about them)
But if you care that strongly, you can do something about it.
(I am also kind of hoping that, by the time one gets to reader macros, they will be experienced enough, and will understand why the parentheses exist so that they will no longer care about them)
But for many people "caring that strongly" and "doing something about it" means choosing another option. As opposed to essentially writing a new language.
Good defaults do matter, and I would also echo the feeling that the parentheses get in the way, and that a non-small component of my thinking or polishing process is how to responsibly reduce parentheses. I find that it's generally a modest but palpable boost to visual ease. I do wonder whether there's a better way to denote nested lists?
Good defaults do matter, and I would also echo the feeling that the parentheses get in the way, and that a non-small component of my thinking or polishing process is how to responsibly reduce parentheses. I find that it's generally a modest but palpable boost to visual ease. I do wonder whether there's a better way to denote nested lists?
The surface problem of LISP are the parenthesis. The deeper problem is that its a very potent NIH enabler: most of us are not really that talented or have the time to properly invent things; those that are tend to not quite like other people's things (and are good at spotting flaws in them) so they work on their own "better" things (e.g. see arc).
The biggest problem, related to the NIH or not, is that other language ecosystems every month race ahead with new libraries, features, and compelling reasons to use them. The best arguments for lisp are 12 years old, in comparison.
Over time the advantages of lisp have gotten smaller and smaller, assuming they were ever anything more than the rationalizations of happy users. When the options were Python, Ruby, PHP, C++ 03, and Java, this held much more weight.
Over time the advantages of lisp have gotten smaller and smaller, assuming they were ever anything more than the rationalizations of happy users. When the options were Python, Ruby, PHP, C++ 03, and Java, this held much more weight.
If you are just gluing code together, Lisp is not necessarily the best choice.
If you are working on difficult problems where you actually have to devise non-trivial algorithms, then Lisp is a good choice. The problem then becomes feeding that algorithm – when there are so many great libraries everywhere else to retrieve data from and send to other places, it becomes cumbersome to do it in Lisp.
There is also value in restricting programmer flexibility. I suspect Golang got popular precisely because of its straighjacket (and I say this while staring at Golang code in another monitor).
Turns out most people want Legos. Real artists are fewer in number, but those will want clay instead.
Edit: typo. Edit2: everywhere else
If you are working on difficult problems where you actually have to devise non-trivial algorithms, then Lisp is a good choice. The problem then becomes feeding that algorithm – when there are so many great libraries everywhere else to retrieve data from and send to other places, it becomes cumbersome to do it in Lisp.
There is also value in restricting programmer flexibility. I suspect Golang got popular precisely because of its straighjacket (and I say this while staring at Golang code in another monitor).
Turns out most people want Legos. Real artists are fewer in number, but those will want clay instead.
Edit: typo. Edit2: everywhere else
This.
I had a task to write a code generator from JSON to an internal language, and here lisp really showed its strength. It's just so convenient to first describe your data, then write a function to output a string representation of this data in another language and finally adding small functions and macros to make the DSL look beautiful. Took about three weeks from start to production, and already another developer who was new to lisps jumped in and wrote an extension to the generator.
I could've done this with other languages, especially looking at you OCaml and Haskell, but just grabbing lisp, getting results during the first days and having tremendous amount of fun made the deal.
I had a task to write a code generator from JSON to an internal language, and here lisp really showed its strength. It's just so convenient to first describe your data, then write a function to output a string representation of this data in another language and finally adding small functions and macros to make the DSL look beautiful. Took about three weeks from start to production, and already another developer who was new to lisps jumped in and wrote an extension to the generator.
I could've done this with other languages, especially looking at you OCaml and Haskell, but just grabbing lisp, getting results during the first days and having tremendous amount of fun made the deal.
IDK, I feel like this is the kind of slightly smug reasoning that's seen lisp get passed by. Just because I believe the factory-made, cheap, and standardized building blocks are a better medium than your artisan homemade clay blocks doesn't mean I'm just a dumb pleb churning out junk. I just have different values than you.
I've spent lots of time crafting the greatest macros and trying to deal with missing/half finished/supported libraries in lots of languages, but at this point I just want to build and spending time on those details isn't worth my time, it doesn't help me make a better product.
It turns out that declaring yourself the greatest and resting on those laurels can lead to myopic overconfidence. There's very little at this time that lisp is actually the best choice for, unless you have very limited reliance on outside libraries, and even then, other languages have different tradeoffs.
Real artists are fewer in number, but those will want clay instead.
This is incredibly pretentious and might not match reality.
I've spent lots of time crafting the greatest macros and trying to deal with missing/half finished/supported libraries in lots of languages, but at this point I just want to build and spending time on those details isn't worth my time, it doesn't help me make a better product.
It turns out that declaring yourself the greatest and resting on those laurels can lead to myopic overconfidence. There's very little at this time that lisp is actually the best choice for, unless you have very limited reliance on outside libraries, and even then, other languages have different tradeoffs.
Real artists are fewer in number, but those will want clay instead.
This is incredibly pretentious and might not match reality.
> doesn't mean I'm just a dumb pleb churning out junk
I do not see how what I wrote would support this claim
The actual underlying theme was: if you really need a medium to express yourself(or in this case, your thoughts), Lisp is great. The comparison to clay was because: it is mold-able, it is not easy to work with, most people do not want to get their hands dirty with it, they may not even be interested on it. And what most people will make with clay will not look good. This is not a limitation on their part, they may not even be interested.
I am one of those churning out prefabs and gluing stuff together. This is what I get paid for.
I do not see how what I wrote would support this claim
The actual underlying theme was: if you really need a medium to express yourself(or in this case, your thoughts), Lisp is great. The comparison to clay was because: it is mold-able, it is not easy to work with, most people do not want to get their hands dirty with it, they may not even be interested on it. And what most people will make with clay will not look good. This is not a limitation on their part, they may not even be interested.
I am one of those churning out prefabs and gluing stuff together. This is what I get paid for.
You know, I did misread what you said. The rest of your post is entirely true.
I saw the kind of argument that I'm used to hearing lispers make and overreacted. My issue is I'm not really sure that lisp is actually better at doing things at a lower level. You have more freedom with syntax, sure, but I'm not at all convinced that's the same thing as building things up from the bottom. Rust, for example, will let you do low level things that lisp really can't, and Ocaml will let you build up typologies in ways lisp isn't made to.
At the end of the day, languages really aren't that different, especially modern ones, you're mostly working with the same abstractions, and the question becomes is syntactic freedom more important or is a growing community more important? That actually is my biggest issue with lisp (and most other language) evangelism. It's a bunch of claims that aren't really rooted in any kind of evidence.
I saw the kind of argument that I'm used to hearing lispers make and overreacted. My issue is I'm not really sure that lisp is actually better at doing things at a lower level. You have more freedom with syntax, sure, but I'm not at all convinced that's the same thing as building things up from the bottom. Rust, for example, will let you do low level things that lisp really can't, and Ocaml will let you build up typologies in ways lisp isn't made to.
At the end of the day, languages really aren't that different, especially modern ones, you're mostly working with the same abstractions, and the question becomes is syntactic freedom more important or is a growing community more important? That actually is my biggest issue with lisp (and most other language) evangelism. It's a bunch of claims that aren't really rooted in any kind of evidence.
JavaScript library space is basically pure NIH - maybe it's a Lisp, too?
It does have a surprising amount of Lisp DNA, despite the horrible semantics.
You can bet that every day Javascript users reinvent Lisp stuff from 50 years ago. Javascript on the language level is like Lisp from the end 70s minus better numerics and minus macros and minus using JSON as a syntax for programs. The prototype stuff is straight from Actors in Lisp, mid 70s.
It's missing key pieces, though. Even with Babel it's very painful to extend the language, so important features like async/await arrive after years instead of hours.
What is it with statements like this? It just sounds like a 'meme' to me, that everyone hears (even from advocates like this one) at first that the 'syntax' (of which there is a lot less than most languages in a Lisp) is 'horrible'?
Of course, we, the learn-ed of Lisp, say that after a while the 'parens just disappear', which they don't, but they sure help (when combined with Paredit) in defining code like structures that can be manipulated with ease in your editor.
I know the author is just trying to do a bit of a 'sandwich' with the article, but please, advocates and enemies of Lisp, just give up on picking on the parens. It's stupid and been done a million times. It's like 'why do we have to type so much to enter programs! such a pain!'.
Boring.