3 ms·

[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.] Th

[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.

d0m 13y ago
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.
- lispm 13y ago
  I hear a lot of bad things about large Java code bases.
  - pjmlp 13y ago
    I can imagine, but the strong typing does help keeping a bit of order.
    - lispm 13y ago
      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.
      - pjmlp 13y ago
        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.
    - mattfenwick 13y ago
      s/strong/static/
- Myk267 13y ago
  "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/ http://www.brandonbloom.name/blog/2013/06/24/code-density/

d0m 13y ago

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.

lispm 13y ago
I hear a lot of bad things about large Java code bases.
- pjmlp 13y ago
  I can imagine, but the strong typing does help keeping a bit of order.
  - lispm 13y ago
    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.
    - pjmlp 13y ago
      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.
  - mattfenwick 13y ago
    s/strong/static/
Myk267 13y ago
"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/ http://www.brandonbloom.name/blog/2013/06/24/code-density/