3 ms·

I disagree with the core premise of this article. By this logic, the most developed language ecosystems should be those built from languages which are the most

I disagree with the core premise of this article. By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for. Python is a clear counterexample with a comparably low barrier, and tons of existing modules with ~80% capability hacked together by random individuals. In practice, many of those partially complete projects are picked up and improved by others, or serve as direct inspiration for more rigorous implementations. I would argue the language and community are stronger because of this. Lisp has been around for over half a century. It's had plenty of opportunity to demonstrate its worth in helping people solve real world problems in production. I agree with the author there is probably a fundamental reason lisp doesn't see this kind of use (maybe with the exception of clojure), but I seriously doubt that reason is that it's "too powerful."

jerf 7y ago
"By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for." It only implies that the relationship between difficulty of development and developed ecosystem is not monotonic. It's actually fairly normal for two parameters to be highly correlated to each other along most of their range & domain, but for the correlation to suddenly fall apart at the extreme. (I think there's a term for this, and I'm wishing I could remember it, so I could to pages I've seen discussing it. If anyone knows, links solicited.) Of course, the real problem is that there's almost certainly a lot of such parameters, and having what may be merely a "just-so" story for Lisp's general failure to set the world on fire and it's excessive power may not be particularly determinative of anything. It does at least fit the facts. Most of the other possible answers have at least had the seed of a solution created (e.g., package manager solutions), and it still hasn't taken off, suggesting that wasn't the problem. (Though we can't eliminate the possibility it needs multiple such things.) The fact that Clojure seems to be settling into a C-list language position after its push also is suggestive of it not being any of the things that it fixed.
ddragon 7y ago
On the other hand, a lot of the most popular Python libraries became effectively standard and lots of people agglomerated around them instead of creating competing standards because it would be hard for any smaller team to replicate even their base functionality. Creating a numpy, scipy, sklearn, pandas, tensorflow or pytorch would involve lots of optimized C/C++ code and python wrappers, which is a considerably high barrier. If anyone could make an equally high performance 80% functionality/use cases coverage version of those libraries using high level python in maybe a month, would that cause a fragmentation in a way that we would get a lot of 80% libraries (with different 80%) instead of one 95% library that is supported everywhere?
coldtea 7y ago
>I disagree with the core premise of this article. By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for. Python is a clear counterexample with a comparably low barrier, and tons of existing modules with ~80% capability hacked together by random individuals. His argument is not about difficulty to develop on, but about difficulty to shape the language and its idioms. All those packages you mention are libraries, and you use them with the same pythonic idioms you code with. Even Python's metaprogramming facilities hardly change the semantics much...

jerf 7y ago

"By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for." It only implies that the relationship between difficulty of development and developed ecosystem is not monotonic. It's actually fairly normal for two parameters to be highly correlated to each other along most of their range & domain, but for the correlation to suddenly fall apart at the extreme. (I think there's a term for this, and I'm wishing I could remember it, so I could to pages I've seen discussing it. If anyone knows, links solicited.) Of course, the real problem is that there's almost certainly a lot of such parameters, and having what may be merely a "just-so" story for Lisp's general failure to set the world on fire and it's excessive power may not be particularly determinative of anything. It does at least fit the facts. Most of the other possible answers have at least had the seed of a solution created (e.g., package manager solutions), and it still hasn't taken off, suggesting that wasn't the problem. (Though we can't eliminate the possibility it needs multiple such things.) The fact that Clojure seems to be settling into a C-list language position after its push also is suggestive of it not being any of the things that it fixed.

ddragon 7y ago

On the other hand, a lot of the most popular Python libraries became effectively standard and lots of people agglomerated around them instead of creating competing standards because it would be hard for any smaller team to replicate even their base functionality. Creating a numpy, scipy, sklearn, pandas, tensorflow or pytorch would involve lots of optimized C/C++ code and python wrappers, which is a considerably high barrier. If anyone could make an equally high performance 80% functionality/use cases coverage version of those libraries using high level python in maybe a month, would that cause a fragmentation in a way that we would get a lot of 80% libraries (with different 80%) instead of one 95% library that is supported everywhere?

coldtea 7y ago

>I disagree with the core premise of this article. By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for. Python is a clear counterexample with a comparably low barrier, and tons of existing modules with ~80% capability hacked together by random individuals. His argument is not about difficulty to develop on, but about difficulty to shape the language and its idioms. All those packages you mention are libraries, and you use them with the same pythonic idioms you code with. Even Python's metaprogramming facilities hardly change the semantics much...