Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why didn't Common Lisp fix the world?

quora.com

Post reply on HN
Print view View original

31–40 of 127 posts

Re: Why didn't Common Lisp fix the world?

#31

Post by sklogic »

mtrycz wrote: post #13

While i do like the the idea of DSLs and they certainly do have a place, what I would love to have is to be able to enforce a strict subset of a language in a piece of code. Where first there was discipline and hardly passed on conventions, there now would be statically enforced rule coerction. I deeply believe that the utility of language is not in what it enables, but in what it forbids. For example Clojure and Rus…

You can have both a flexibility of DSLs and strict rule enforcement. Just write a restricted DSL.

Re: Why didn't Common Lisp fix the world?

#32

Post by sklogic »

euske wrote: post #10

Common Lisp doesn't have type checking and well defined namespace. And it has eval. That's certainly a no go for people like me. Most programmers in the world don't have to invent/implement a radical new idea in five minutes.

I don't even remember when was the last time I saw eval being used outside of the macros. And the latter is also quite a specific and rare use case.

Re: Why didn't Common Lisp fix the world?

#33

Post by hga »

mdpopescu wrote: post #19
jordigh wrote: post #18

I'm pretty sure the biggest reason it hasn't caught on is the syntax. http://jordi.platinum.linux.pl/piccies/lisp.png It's the most frequent complaint uttered against Lisp for a reason. All of the other things mentioned in the top responses are addressed by modern Lisp variants. If Rust or Swift were implemented with sexps and everything else about them were equal, they would have a lot of difficulty winning hearts a…

Agreed, but it's not just the parentheses - "car-or-zero"? Really? If you have a language where you can say "at least it's not APL", that's not a feature...

That's where Common Lisp's roots that go back to the first version that ran as subroutines to punched card FORTRAN on a vacuum tube IBM computer show. Contents of Address and Decrement Registers -> car and cdr, for normal list processing they're often renamed or aliased first and rest.

BUT, they hang around because of old code, and they're composable, e.g. the 2nd Lisp Machine design and first to be semi-mass produced was the CADR, as in (car (cdr list)), or (first (rest *list)), is in the 2nd item in the list.

So, yeah, if you don't want to have to learn a lot of arcane stuff that's incidental complexity purely because of history, go for newer dialects like Scheme and Clojure which had the opportunity to rationalize a lot of this (but Scheme at least still has cadr and company because they're too useful).

Re: Why didn't Common Lisp fix the world?

#34

Post by weavie »

chvid wrote: post #16

Yes. I have. People with gray beard, strong views on programming languages, politics and UFOs. I always assumed that were dressed up for the occasion and not really real; like someone doing a role playing game or maybe being Santa for the kids during Christmas.

Hmm.. my beard isn't fully grey yet.

Re: Why didn't Common Lisp fix the world?

#35

Post by hga »

adwf wrote: post #12

I often think it's because Common Lisp was one of the last pre-web languages to be designed (or standardised anyway). Newer languages like Java/Javascript/Clojure/etc. had the advantage of being able to build a strong community on the web. Whereas Lisp was just on its way out as the web was rising. The hardware and the long standardisation process didn't help either. That, combined with it being both an old and a new…

There's also the factor that the over promising of what expert systems and AI in general could do that lead to the AI Winter were conveniently blamed on Lisp, seeing as how it couldn't have been simple failures to execute, or execute the impossible.

Or so goes one version of the Official Story, I wasn't really a witness to more than the beginning of that, when they were grossly over-hyped. Or solved the wrong problem, my favorite example there being DEC's configuration -> part numbers to order expert system. Sun made it simple, at the lowest level of a workstation, the major choices of the sort DEC was optimizing came down to which keyboard and power cord you ordered to fix your country's standards.

Re: Why didn't Common Lisp fix the world?

#36

Post by arethuza »

nabla9 wrote: post #29
keymone wrote: post #23

i feel like a lot of lisps are trying to drag this "everything is a list" abstraction way too far than they should. clojure takes more practical and pragmatic approach of giving native residency in a language for useful data structures like arrays, maps and sets and it (along with many other features) has totally won me over. it's incredibly important for a language to be convenient. edit: and not only me it seems: h…

>i feel like a lot of lisps are trying to drag this "everything is a list" I think you are speaking out of ignorance here. "everything is a list" is just a metaphor. Everything is either list or atom and almost everything is atom.

Common Lisp has a fairly rich set of standard data types - including hashtables, streams, arrays and the ability to define structures and then there is the exciting world of CLOS on top of all of that...

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node15.html

Re: Why didn't Common Lisp fix the world?

#37

Post by adwf »

paddy_m wrote: post #25
adwf wrote: post #12

I often think it's because Common Lisp was one of the last pre-web languages to be designed (or standardised anyway). Newer languages like Java/Javascript/Clojure/etc. had the advantage of being able to build a strong community on the web. Whereas Lisp was just on its way out as the web was rising. The hardware and the long standardisation process didn't help either. That, combined with it being both an old and a new…

Perl and python, and c++. Perl especially was influenced by newsgroups, so maybe that doesn't count.

Yeah, but they arose as the web was starting in the 90s. Whereas Lisp had been around since the 50's. The standardisation effort wasn't the development of an exciting new language, just the finalisation of an old one.

Re: Why didn't Common Lisp fix the world?

#38

Post by thiht »

pjmlp wrote: post #27
jordigh wrote: post #18

I'm pretty sure the biggest reason it hasn't caught on is the syntax. http://jordi.platinum.linux.pl/piccies/lisp.png It's the most frequent complaint uttered against Lisp for a reason. All of the other things mentioned in the top responses are addressed by modern Lisp variants. If Rust or Swift were implemented with sexps and everything else about them were equal, they would have a lot of difficulty winning hearts a…

Usually people that complain, don't spend time counting the amount of times () [] {} appear on their beloved programming languages. print(args) => (print args) if (cond) { exp1} else {exp2 } => (if (cond) (exp1) (exp2)) array[index] => (index array) And so on. On average there is probably the same amount, but visually it kind of appears to be more.

You took the examples where the number of parentheses is the same. Here is a more honest example:

    if (a && !b) {expr} => (if (and (a) (not b)) (expr))
That's a simple expression and I'm not even sure I managed to match the () correctly

Re: Why didn't Common Lisp fix the world?

#39

Post by apetrovic »

pjmlp wrote: post #27
jordigh wrote: post #18

I'm pretty sure the biggest reason it hasn't caught on is the syntax. http://jordi.platinum.linux.pl/piccies/lisp.png It's the most frequent complaint uttered against Lisp for a reason. All of the other things mentioned in the top responses are addressed by modern Lisp variants. If Rust or Swift were implemented with sexps and everything else about them were equal, they would have a lot of difficulty winning hearts a…

Usually people that complain, don't spend time counting the amount of times () [] {} appear on their beloved programming languages. print(args) => (print args) if (cond) { exp1} else {exp2 } => (if (cond) (exp1) (exp2)) array[index] => (index array) And so on. On average there is probably the same amount, but visually it kind of appears to be more.

I think it's not just the number of special symbols, syntax matter. When the eye see array[index], the brain can make some assumptions - 'array' is some sort of, well, array or something else indexable, and index is most probably some simple type. With (array index) one must pause and think is array a function? array? something else? Is index another some simple type? Or another function? Something else entirely?

I know that at the end there's no distinction (lisp syntax is AST, and every other source code ends up as AST), and the idea that someone would accept syntax restrictions as a good thing is probably strange to the true lisper, but people care about the syntax. By eliminating syntax and forcing the programmer to write AST directly lisp gave enormous power to the user, but at the end not enough programmers were willing to give up on comfort to acquire all that power.

Re: Why didn't Common Lisp fix the world?

#40

Post by sklogic »

dunkelheit wrote: post #21
chvid wrote: post #8

Why on earth would it fix the world? It was a step forward in the history of programming languages; but somehow the end of it, the final fix? Why would anyone expect that? Programming languages are about providing a useful way for humans to formulate and implement their ideas. Starting by turning things on their head reverse polish notation style is bad start as it is counter intuitive to nearly everyone.

My theory is that because programming is mostly about fighting incidental complexity, it is very easy to believe that if there were some way of getting rid of it, programs would write itself and programming would be reduced to sipping daiquiris on a beach. Lisp (especially compared to C) indeed helps to reduce incidental complexity to some extent. So it is easy fall into almost religious belief that Lisp is the way t…

> helps to reduce incidental complexity to some extent

This extend stays untapped. You cannot even imagine how far this ability to eliminate complexity extends.

Of course, it's not just Lisp, it's Lisp (or any other meta-language) combined with a certain design methodology.

A methodology which pretty much boils down to a notion that "everything is a compiler". And, since compilers are trivial and there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms, this way you can eliminate all possible complexity, no matter what your domain is.

Yet, I find it amusing that only a handful of people are even aware of this ultimate methodology.

Post reply on HN