[edit: While I was typing this the title was changed. It was previously Why Lisp isn't (and shouldn't be) widely used in industry, which colors my comment.]
This points out some very real potential dangers of large-scale collaboration with Clojure (and presumably some or many other Lisps/Lisp-likes).
However, I think the conclusion is overstated. Yes, based on what's provided, it may take more discipline and better, more explicit processes for a team to effectively collaborate in Clojure than in Python (using the author's running comparison). Yes, if we take this at face value, it does appear that people who depend on static analysis might find Lisp lacking.
But does this tell us why Lisp isn't widely used in industry? If we assume that "widely" means "as widely as Java or Python," which seems to be the statement made here, I don't think it's valid to cite the provided complaints as most or even a large portion of the explanation. The fact that there are no or almost no mainstream educational institutions teaching new students Lisp seems to me a far more likely candidate for front-runner on this issue.
That it shouldn't be widely used is a little easier for me to agree with, only because I'm on board with some of the points here about the discipline and extra work it would take for a large team to effectively cooperate given the malleability of Lisp. I've worked with enough other programmers to know that kind of care and attention to process are very rare (and this isn't "all of you suck;" I know I have and will again cut corners and ignore protocol in situations where time or resources make it hard to do things perfectly every time).
Also, I think the author's last point is important to mention, because it'd be easy to miss it: He's not arguing that Lisp sucks. He states explicitly that it's great in at least some ways. I just don't think the black and white claims being made about its practicality are quite supported.
Although I love lisps, I'd rather jump in a very large Python project than a lisp one. Jumping into someone else Lisp code feels like a jungle to me. Jumping into someone else's Python code feels like my old good slipper. Part of it is due to the very strict Python standard of coding. But I think it's primarily because of the "One good way to do it" mentality. On the other hand, I feel telling a lisp programmer "This is the right way to do this" would be like an insult to their creativity. Obviously, it's not as much black and white, but hopefully you understand what I mean.
"Part of it is due to the very strict Python standard of coding."
I don't know about that. Good code is good code. It's sort of one of those, "I'll know it when I see it" things.
The ease of which you can code classes for the sake of classes in Python can make some really hairy code out of what should be simple programs. Was that necessarily the 'one right way to do it'? Who's to say. And all the static analysis tools and syntactic aren't going to undo those hairballs anytime soon.
You might just feel more comfortable with languages with lower code density. 'brandonbloom made a good blog about that[1]. I think it can be doubly applied to any situation where meta-programming is employed.
Take Javascript, if you want to iterate over a list, you have dozen of ways. One could hardly argue that one is better. Some prefer using built-in foreach, some .map, some underscore, some the native for(). As you say, great code is great code and as long as it's well written and understandable, it's good Javascript.
In python things are a bit different. There are agreed-on ways to do certain patterns. If someone uses a different method, I.e. [1,2,3].foreach(lambda x: something(x)) pythonist will all agree that this is no pep-8 standard and that for readability and maintenability's sake it should be changed to for x in [1,2,3]: something(x).
Another way to say that.. very good pythonists will agree on a "best way to do it", whereas in Lisp, very good lispers will agree that "both ways are very good and clean".
With all that being said, that's why I prefer to jump into a large python project (considering that pep 8 is strictly being used).
How does static typing help you to tame the use of classes, reflection, configurations, rest interfaces, db interfaces, ...?
Just on friday I was talking to someone, where he said that his developers don't like the code and feel the constant urge to rewrite it... with the core functionality being a huge mess.
Comments
[edit: While I was typing this the title was changed. It was previously Why Lisp isn't (and shouldn't be) widely used in industry, which colors my comment.]
This points out some very real potential dangers of large-scale collaboration with Clojure (and presumably some or many other Lisps/Lisp-likes).
However, I think the conclusion is overstated. Yes, based on what's provided, it may take more discipline and better, more explicit processes for a team to effectively collaborate in Clojure than in Python (using the author's running comparison). Yes, if we take this at face value, it does appear that people who depend on static analysis might find Lisp lacking.
But does this tell us why Lisp isn't widely used in industry? If we assume that "widely" means "as widely as Java or Python," which seems to be the statement made here, I don't think it's valid to cite the provided complaints as most or even a large portion of the explanation. The fact that there are no or almost no mainstream educational institutions teaching new students Lisp seems to me a far more likely candidate for front-runner on this issue.
That it shouldn't be widely used is a little easier for me to agree with, only because I'm on board with some of the points here about the discipline and extra work it would take for a large team to effectively cooperate given the malleability of Lisp. I've worked with enough other programmers to know that kind of care and attention to process are very rare (and this isn't "all of you suck;" I know I have and will again cut corners and ignore protocol in situations where time or resources make it hard to do things perfectly every time).
Also, I think the author's last point is important to mention, because it'd be easy to miss it: He's not arguing that Lisp sucks. He states explicitly that it's great in at least some ways. I just don't think the black and white claims being made about its practicality are quite supported.
Although I love lisps, I'd rather jump in a very large Python project than a lisp one. Jumping into someone else Lisp code feels like a jungle to me. Jumping into someone else's Python code feels like my old good slipper. Part of it is due to the very strict Python standard of coding. But I think it's primarily because of the "One good way to do it" mentality. On the other hand, I feel telling a lisp programmer "This is the right way to do this" would be like an insult to their creativity. Obviously, it's not as much black and white, but hopefully you understand what I mean.
"Part of it is due to the very strict Python standard of coding."
I don't know about that. Good code is good code. It's sort of one of those, "I'll know it when I see it" things.
The ease of which you can code classes for the sake of classes in Python can make some really hairy code out of what should be simple programs. Was that necessarily the 'one right way to do it'? Who's to say. And all the static analysis tools and syntactic aren't going to undo those hairballs anytime soon.
You might just feel more comfortable with languages with lower code density. 'brandonbloom made a good blog about that[1]. I think it can be doubly applied to any situation where meta-programming is employed.
1: http://www.brandonbloom.name/blog/2013/06/24/code-density/
Take Javascript, if you want to iterate over a list, you have dozen of ways. One could hardly argue that one is better. Some prefer using built-in foreach, some .map, some underscore, some the native for(). As you say, great code is great code and as long as it's well written and understandable, it's good Javascript.
In python things are a bit different. There are agreed-on ways to do certain patterns. If someone uses a different method, I.e. [1,2,3].foreach(lambda x: something(x)) pythonist will all agree that this is no pep-8 standard and that for readability and maintenability's sake it should be changed to for x in [1,2,3]: something(x).
Another way to say that.. very good pythonists will agree on a "best way to do it", whereas in Lisp, very good lispers will agree that "both ways are very good and clean".
With all that being said, that's why I prefer to jump into a large python project (considering that pep 8 is strictly being used).
I hear a lot of bad things about large Java code bases.
I can imagine, but the strong typing does help keeping a bit of order.
How does static typing help you to tame the use of classes, reflection, configurations, rest interfaces, db interfaces, ...?
Just on friday I was talking to someone, where he said that his developers don't like the code and feel the constant urge to rewrite it... with the core functionality being a huge mess.
Most of the enterprise projects I work on, developers tend to "forget" about unit tests after the first few sprints.
Never coming back to them unless ordered to do so by management.
Without static typing the chaos would be even bigger.
s/strong/static/