3 ms·
I dislike this notion that Lisp (or Haskell or OCaml or ...) owe it to everyone else to explain and enunciate why it can be more productive to use Lisp. """ Th
by reikonomusha 12y ago
I dislike this notion that Lisp (or Haskell or OCaml or ...) owe it to everyone else to explain and enunciate why it can be more productive to use Lisp.
"""
That’s asking too much. If Lisp languages are so great, then it should be possible to summarize their benefits in concise, practical terms. If Lisp advocates refuse to do this, then we shouldn’t be surprised when these languages remain stuck near the bottom of the charts.
"""
What?? Why? The problem is not and has never been communication of Lisp features. No one made a concise list of why C and Java are so great that people rushed to use them. Instead, they were pervasively used and taught in universities, and they are pervasively used in the development of most applications for e.g. Windows and Linux, and they are relatively simple languages (in theory) whose semantics most people "get". No wacko high order crap, no weight curried things, no arrows or morphisms or monads or macros.
Programmers of such languages don't owe the rest of the world anything. Everyone has a choice about what to use, and it's each individual programmer's responsibility to choose them wisely. There is plenty of material about Lisp and Scheme out there. Unfortunately, we are in this TL;DR culture where no one has the time to spend a few hours every week to learn something new, since somehow that's too big a risk on their precious time.
Now, for some comments:
1. Everything is an expression.
He says this is a boon, but it's also confusing for "expressions" which are side effectful. Too bad he did not talk about that, nor did he talk about how the expression-oriented way of thinking is really best for purely functional languages that allow for substitution semantics.
2. Every expression is either a single value or a list.
This is wrong, unless we devolve "single value" into the 1950's idea of an "atom". What about vectors or other literal composite representations of things? What about read-time things that aren't really lists or values?
3. Functional programming.
Functional programming is indeed great, but why don't we talk about how in Lisps, we don't get efficient functional programming? Lisp has tended to prefer non-functional ways of doing things because Lisp will allocate so much memory during functional programming tasks that for many objectives, FP is far to inefficient. Haskell solves this to some extent with things like efficient persistent structures and compilation algorithms such as loop fusion. Lisp doesn't really have any of this, and the data structures that do exist, many people don't know about or use.
4 and 5 don't really have to do with Lisp but particular implementations. That's fine I guess.
6. X-pressions.
What the hell is an X-pression?
7. Racket documentation tools.
Okay.
8. Syntax transformations.
He made the same mistake as he so baroquely outlined at the start. What in the world are these "macros" and "syntax transformations" good for? You're just telling me they're more powerful C preprocessor macros that can call arbitrary functions. But I was taught that fancy CPP code is a Bad Idea, so boosting them is a Worse Idea.
9. New languages.
Same problem as 8. You say it's useful but you don't say why. Just that it's "easier".
10. Opportunities to participate.
Nothing to do with Lisp again.
* * *
Instead of all this glorifying of Lisp and etc, why don't we spend time increasing that library count from 2727 to 2728? Or do we need to go through an entire exercise about whether that time spent is worth it or not?
"""
Rather, you are—because a Lisp language offers you the chance to discover your potential as a programmer and a thinker, and thereby raise your expectations for what you can accomplish.
"""
You're repeating everyone else. Notice how difficult it is to convey such things without being hugely abstract and unhelpful? Why don't other programmers see this huge productivity benefit from these Lisp wizards in their day-to-day life? Where are the huge, useful applications? They all seem to be written in C or C++.
"""
It’s mind-bendingly great, and accessible to anyone with a mild curiosity about software.
"""
It is accessible to those who are intently curious about theoretical aspects of software development, especially abstraction, and who can take exercises which require mathematical reasoning. A "mild curiosity" in my experience with others will not suffice.
* * *
This post may sound somewhat cynical and negative, but Lisp enlightenment articles are almost as bad as Haskell monad tutorials. They're everywhere and by the end, still no one gets it. And I don't like the attitude that because a group G doesn't understand it, and group H does, that H owes it to G to spoonfeed the information. That's not the case.
- yayitswei 12y agoIt benefits both groups to to enlighten G. Since G is so much larger, that's how we would increase the library count from 2727 to 27280.
- reikonomusha 12y agoThe best way to demonstrate it is to write interesting software, not to flounder on some abstract explanation about the greatness of G's favorite language.
- mschaef 12y agoThe original author of the blog post _did_ write some interesting software in Lisp, used it to write a book, and then he wrote his blog post. To me this is a good example of something languages have to have to make progress: users and evangelists/educators, with a large overlap between the two.
- ScottBurson 12y ago> Lisp doesn't really have [efficient persistent data structures] It does now: http://www.ergy.com/FSet.html http://www.ergy.com/FSet.html
- einhverfr 12y agoOn the syntax transformation side.... I have started to get really into what you can do with closures and coderefs in Perl. It isn't a macro in the lisp sense but it really works well and you can do some incredible things with it, and with closures and lexically scoped variables.... I suppose I should probably at some point blog about it. I think a big part of the problem is that these are not tools you had to a beginner. They are things which take a lot of time to really master.
- innguest 12y agoGreat post. > It is accessible to those who are intently curious about theoretical aspects of software development, especially abstraction Agreed. That's why I think it's disingenuous when people complain that Haskell folks are in an "ivory tower" or they think they're the elite. I just think they're more curious and that's why they learned it. > And I don't like the attitude that because a group G doesn't understand it, and group H does, that H owes it to G to spoonfeed the information. That's not the case. Exactly. I always think 'I should write this and that tutorial and then people will finally see why FP is so much easier and then perhaps...' but then immediately I think 'but I learned fine with the existing tutorials, why can't others?'. The answer is, because most people don't care or aren't curious enough. The moment I learned of Lisp and Haskell and people gushing about it I knew I had to learn them just to see what the fuss is all about, and whether people are right in their praise. And they are right in their praise. It takes time to learn but so does everything (for me, at least), but in the end you invariably get there, and it's more than worth it.