3 ms·
Lisp is not a problem. Lisp is fine. So are Scala, Ocaml, and Haskell, under most use patterns. Python's not perfect, but I'll gladly use that. It works. Actual
by michaelochurch 14y ago
Lisp is not a problem. Lisp is fine. So are Scala, Ocaml, and Haskell, under most use patterns. Python's not perfect, but I'll gladly use that. It works. Actually, I like Clojure better than CL, but that's irrelevant. I had one experience of being burned by "Lisp's power". I was in a company where I had to work with a programmer who used Lisp in ways the rest of us found to be irresponsible (poor documentation).
He actually wasn't a bad programmer. He was actually a pretty good one, but management had been riding him with unreasonable feature requests and ridiculous deadlines, so no one ever got to do anything right in that company. My code was better, not because I'm inherently better but because I fought back and simply padded the shit out of estimates so I knew I'd have the time to do things right.
These problems that get blamed on languages are usually the result of terrible management.
Even bad code is not pure evil. Bad code is just logic, poorly fashioned and presented, often because of shitty business practices rather than poor programmers. The evil is the manager who forces you to use bad code (instead of letting you replace it) because "we can't afford" doing things right, even though you're in a rich company that pays managers extremely well. That's the enemy. Let's stop warring about cosmetic differences among good languages and focus on that guy.
- bitcracker 14y agoLisp is too powerful only for unexperienced developers because the way of programming in Lisp is totally different from all other languages. Actually many modern languages (Python, Ruby, Java, even C++11) copy more and more features from Lisp since the language designers suddenly realized how useful these features are. Lisp was never "too powerful" but simply far ahead.
- michaelochurch 14y agoLisp makes it really easy to build infrastructure and multiplier-level (Level 2) contributions that affect the whole shop. When you have 1.3-1.4 programmers (scale here: http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/ http://michaelochurch.wordpress.com/2012/01/26/the-trajector... ) who aren't ready to take on projects that will affect other people in such a major way, you can get bad results. That's a management problem, though. Inexperienced developers need to have opportunities to experiment, but if others are forced to sit downwind of their work, then management is behaving badly.