Live data from Hacker News

Why didn't Common Lisp fix the world?

quora.com

51–60 of 127 posts

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

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

Some languages have this. For example, SPARK is a subset of Ada that can guarantee certain properties about your code. Similarly D has a subset that the compiler will verify is type and memory safe.

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

#52
post #5

Norvig nailed it - instead of being sissy about macros altogether the mainstream languages must rather enforce a certain discipline. And the rules for the macros done right are very simple and well known.

Honestly, I don't get the fuss about macros. I haven't seen many (any?) use cases for them, where they don't make the code harder to understand while doing something that isn't already straightforward in the base language.

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

#53
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 take it, you don't use JavaScript, then?

What do you mean with “well defined namespace”?

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

#54
Lisp is only a general idea about syntax and macros. If you want numerical computations you want a big library like blas, and the problem is about efficient memory allocation, cache and garbage collection. If you want deep learning you want a big library.

Lisp is like arithmetic, without more concepts or libraries it doesn't work, you have to reinvent the wheel.

R provides near 8000 useful packages, that's what makes a language a useful tool to solve a problem, and it can call routines in C, fortran or use C with armadillo. To sum up, a language without a great community and specific libraries is not a way to fix the world, on top of that there are few jobs using Lisp. Clojure is trying to take advantage of all those java libraries, that is a good step in the right direction. Clasp is another idea trying to use C++.

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

#55
post #40

Earlier quoted context omitted.

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…

since compilers are trivial

No.

and there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms

Any complexity? Really?

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

#56
post #27
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 in terms of adoption it might be much more important than it is made out to be. A lot of potential new users are people who have many other choices and very little free time. If the language is such that they cannot immediately recognise a fundamental pattern like a function call then they are going to stop reading. Even if they keep reading for a couple of days and still find it hard to relax and read fluently then by that time they are probably going to give up because they simply don't have the time. So s-expressions are what gives the language part of its power and lisp should not change but don't be surprised if it has less users because 80% of the usual first time users of a language get discarded at the start. It is very hard to make it back up from there.

I think the reason people find it hard to adjust to the new pattern is that they have been trained all their lives to recognise the pattern where the name of something is distinct and outside of the thing itself. In mathematics obviously people have been used to expressing functions using f(x) since an early age (10?). But physically also. Think of these things:

- The name of a shop or a village tends to be on a sign on the outside.

- The name of a book is on the cover.

- The title of a folder is on the outside.

- The name of an OS file etc.

Naming things is very important. Its the basis of a lot of communication, understanding and abstraction and people are used to the name of something being fundamentally distinct and outside of the thing itself.

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

#57
post #38
post #27

Earlier quoted context omitted.

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

Don't put parenthesis around "a", this is a function call.

   (when (and a (not b)) 
     expr
     ...
     expr)

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

#58
Having recently been introduced to the lisp world (~1 year) it has been a revelation to me. It really changed the way I see programming and my expectations of it.

I do not understand how it has not taken over the world.

Background: I have ~15 years of experience in programming. In my spare time I learn new languages.

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

#59
post #38

Earlier quoted context omitted.

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

I agree it's hard to write lisp without a proper editor. Having seen the light I just can't go back now. The power, ease, and simplicity are not something I've experienced with non lisps.

I don't know much about Lisp, but at ILC 2014 [1] there were about 40 participants. In a show of hands, absolutely all of them used Emacs to write their Lisp. I've never seen Emacs unanimity anywhere else.

--

http://ilc2014.iro.umontreal.ca/

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

#60
post #38
post #27

Earlier quoted context omitted.

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

Your example is also misleading. The `a` and `expr` are written as variables in the left example, but as function calls in the Lisp version. More correctly it would be either

  if (a && !b) { expr } => (if (and a (not b)) expr)
Or

  if (a() && !b) { expr() } => (if (and (a) (not b)) (expr))
Now the amount of parentheses is either 4/6 or 8/10 which is not a very big difference (and caused only by the syntactic sugar for `not`), especially considering that the left example uses `!`, `&&` and two kinds of parentheses (perhaps a `;` as well).
Post reply on HN