Live data from Hacker News

The Nature of Lisp (2006)

defmacro.org

41–50 of 95 posts

Re: The Nature of Lisp (2006)

#41
post #21
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 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?

Re: The Nature of Lisp (2006)

#42
post #30

Earlier quoted context omitted.

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?

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.

Re: The Nature of Lisp (2006)

#43

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…

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.

Re: The Nature of Lisp (2006)

#44
post #30

Earlier quoted context omitted.

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?

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

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.

Re: The Nature of Lisp (2006)

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

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.

Re: The Nature of Lisp (2006)

#46
post #21
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 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.

> the pirates run away from me

Nice expression. Is it a pop culture reference I have missed?

Re: The Nature of Lisp (2006)

#47
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…

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

Re: The Nature of Lisp (2006)

#48
post #40
post #33

Earlier quoted context omitted.

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

'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 bo…

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.

Re: The Nature of Lisp (2006)

#49
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…

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

Re: The Nature of Lisp (2006)

#50

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…

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.

Post reply on HN