4 ms·
I agree with you about the upfront costs. As a functional programming fan (F# in particular), I can’t deny that it sometimes feels like puzzle solving. Fun, but
by munchler 3y ago
I agree with you about the upfront costs. As a functional programming fan (F# in particular), I can’t deny that it sometimes feels like puzzle solving. Fun, but not easy at first.
On the other hand, you can quickly throw together some crappy Python code to do the same thing, but you end up paying 10x the cost over the long run in debugging and rewriting.
So my advice for people who care about the code they write is to pay the upfront cost to do it well. The good news is that the learning curve does get less steep eventually, and at that point you feel like a goddamn ninja.
- doug_durham 3y agoPython != Crappy code. Lisp != good code. You can write crappy code in any language. My experience is that it is much less expensive to maintain Python in a team environment in the long run. People aren't tempted to create their own personal "domain specific languages" in Python. Lisp kind of encourages that.
- munchler 3y agoI'm not saying Python is always crappy. It's just easier to create crappy code in Python, due to dynamic typing, rampant side effects, null values, OO madness, etc. If your team has the discipline not to do that, great.
- erik_seaberg 3y ago> dynamic typing, rampant side effects, null values I’m afraid these are also problems in Common Lisp.
- munchler 3y agoYeah, I’m not a Lisp fan myself. I was comparing Python to functional languages, like Haskell or F#.
- vindarel 3y agomuch, much, much less than Python. CL compilers (looking at SBCL) get you many type checks, at compile time, instantly (you compile the function at point), or you can send computation to compile time yourself, and the OO is different, etc.