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…
Why didn't Common Lisp fix the world?
51–60 of 127 posts
Re: Why didn't Common Lisp fix the world?
#52Norvig 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.
Re: Why didn't Common Lisp fix the world?
#53Common 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.
What do you mean with “well defined namespace”?
Re: Why didn't Common Lisp fix the world?
#54Lisp 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?
#55Earlier 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…
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?
#56I'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 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?
#57Earlier 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
(when (and a (not b))
expr
...
expr)Re: Why didn't Common Lisp fix the world?
#58I 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?
#59Earlier 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.
--
Re: Why didn't Common Lisp fix the world?
#60Earlier 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
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).