Live data from Hacker News

The Nature of Lisp (2006)

defmacro.org

61–70 of 95 posts

Re: The Nature of Lisp (2006)

#61
post #21

Earlier quoted context omitted.

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.

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?

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.

Re: The Nature of Lisp (2006)

#62
post #53

Earlier quoted context omitted.

While true, this is not officially supported as part of the RnRS standard I believe. They set these characters aside as reserved for future use.

I think this depends on which RnRS you look at.

Do some of the older ones just completely omit reserving them?

Re: The Nature of Lisp (2006)

#63

Earlier quoted context omitted.

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 i…

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 finis…

> 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.

Re: The Nature of Lisp (2006)

#64

Earlier quoted context omitted.

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…

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 i…

> If you are working on difficult problems where you actually have to devise non-trivial algorithms, then Lisp is a good choice.

Been hearing this nugget of Lisp elitism for 20 years.

> Turns out most people want Legos. Real artists are fewer in number, but those will want clay instead.

Oh, ffs. Spare me.

Re: The Nature of Lisp (2006)

#65
post #12

Earlier quoted context omitted.

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 nota…

"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.

"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.

Re: The Nature of Lisp (2006)

#66

Earlier quoted context omitted.

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?

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.

Re: The Nature of Lisp (2006)

#67
post #2

"Why on Earth would anyone want to use a language with such horrific syntax?!" 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, b…

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.

Algol syntax is weird.

Tell me, what does this mean?

    x = x + 5
Obviously, it's a null statement. It's nonsense. x cannot equal x + 5 because that means 0 = 5 and, therefore, 0 = 1 and, therefore, all mathematics is broken. However, most Algols are completely happy to accept that statement, something we learned was nonsensical way back in our childhoods, as not only valid but as the only way of doing things.

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.)

Re: The Nature of Lisp (2006)

#68

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.

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.

Re: The Nature of Lisp (2006)

#69
post #37
post #35

Earlier quoted context omitted.

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.

Yes, and yet the names Cons and Cdr still exist and come up in introductory documentation and are still used in discussions constantly -- why?

https://www.google.co.in/search?q=meaning+of+car+and+cdr+in+...

--->

https://en.wikipedia.org/wiki/CAR_and_CDR

Re: The Nature of Lisp (2006)

#70
post #12
post #2

"Why on Earth would anyone want to use a language with such horrific syntax?!" 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, b…

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 nota…

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.)

Post reply on HN