But with some continuity and a carefully crafted own little world, everybody on the team soon chooses voluntarily to speak in the terms of that world, because it is a world well suited to the problem at hand.
Also they don't apply to online open source projects and tutorials.
https://news.ycombinator.com/item?id=17128977
I don't know what's the worst. That you can't help it or that you won't ever recognize you have a problem.
Unfortunaly there is no Lisp Anonymous, so people leave the language. Shame since it's a fantastic tech.
> I don't know what's the worst. That you can't help it or that you won't ever recognize you have a problem.
Anyone can write bad code. Lisp certainly makes it easier, I won't deny it. And no, I don't have a problem, thank you.
> I don't have a problem
If only people were homoiconic like LISP, they might be better at reflection.
> This is why after 50 years it is still a niche language
where "This" is either the REPL or macros, which they do not specify.
It's just as easy for me to speculate that Lisp isn't popular because money talks:
- You have an idea for a piece of software and create a start-up.
-You hire competent Lisp programmers to write that software. Since they're rare, they're expensive.
-The start-up grows because the idea was good and the software works, and somewhere along the line someone sees that more money can be made by cutting expenses on development.
- They shop around and find some outsourcing party that claims to write Lisp cheaper.
- They outsource development, but the software goes down the drain. "Lisp" is now the problem, according to the new developers. But costs are down, growth is still continuing, and they got rid of the weird people who made fun of their Gucci tie.
- People cash out, and on advice of the new developers stuff gets rewritten in the popular language of the day.
- Stuff muddles on for some time, until everything comes crashing down. The cycle starts anew, except now it's clear for everyone involved: don't bother with the software, focus on growth, and in case of doubt:
Blame Lisp!
So yeah, that's my "Why isn't Lisp more popular?" hypothesis: modern software for start-ups is about enabling growth, not quality.
And without further substantiating it's just as valid as blaming it on the "ability to self-modify."
> It makes lisp a terrible experience for beginers.
That might be true.
Gucci ties will always try to outsource, and it will often lead to this, lisp or not.
replace it with Haskell, Ocaml, probably Erlang, and it would probably work:
Why is language X still not popular after Y years?
Because quality and good practice are expensive.
Disregarding its arrogance, the statement is just false :)
It implies nothing of the sort.
> quality and good practice are expensive.
That's the statement. If that implies to you that it's impossible to achieve quality and good practice in any but the aforementioned languages, feel free to do so.
> :)
:)
> a terrible experience for beginers.
Start with your own stuff ;)
Lisp makes it easy to shape a sub-language to fit your own head well. The problem is, few others can figure out YOUR head. Communication conventions are not always pretty or efficient, but they work because they are conventions. If you place parsimony (compact abstractions) above inter-human communication, then all you get is isolated parsimony.
The better embedded languages in Lisp often follow conventions: see for example CLOS and the various conventions it follows from naming to integration.
The actual problem is that defining sublanguages for most developers is not something they have learned. The result is a multitude of languages for similar tasks with their own infrastructure. For many programmers it is normal to wait for new language constructs for several years - while they work around this by combining language built-in constructs (extreme: creating lots of bloat - see Java), by using preprocessors (upto transpilers of different languages - see Java and Javascript for languages transpiling to those).
There is some complexity in Lisp providing features for embedding languages.
But there is also complexity in working around that with languages not very good in embedding. See for example Clojure, a language which provides functional programming idioms on top of Java - the integration is great - but many developers are not satisfied about the integration when it comes to debugging - see the complexity for example of stack traces in a layered language design.
Now you encounter custom syntax. It will not be clear it's custom first as you have no import path. Maybe it's a variant you didn't know about. Maybe it's part of this particular lisp flavor, after all there are so many.
You google it, but it's hard to google syntax so you are not quite sure that no result mean it's custom, impossible to search or just an obscure feature of lisp. After all there are many too.
So you try to decypher the syntax. But there is no contract for it like for a function. No unique entry point and output. It could be doing anything.
Now wihtout an import path you are on a fun hunt for its possible definition with grep.
When you are finally reaching it, it will be 50+ lines of dark magic you now have to decipher because syntax is hard and not trivial code makes awesome features.
In some lisp shops it works because you have three 10x programmers with years of lisp experience working in the same office. In that particular configuration, lisp is cataliser to this great potential, with xp and communication compensating the rest.
But the world is not solely revolving around this perfect combo.
In Slime, use M-. and go to the definition of the thing at point.
"without an import path" ? In CL at least we can very well do the equivalent of "from foo import bar".
Actually, in the case of CLOS all kinds of magical things can be happening in what looks like a simple function call.
This can be wonderful or terrible depending on your perspective.