3 ms·
As someone who works with a ton of Common Lisp and a bit of Haskell, sure Common Lisp may seem easier to read at a surface level but my god am I a lot more hesi
by weavie 7y ago
As someone who works with a ton of Common Lisp and a bit of Haskell, sure Common Lisp may seem easier to read at a surface level but my god am I a lot more hesitant to make any changes to our code base. Unintended side effects are everywhere.
It takes a lot of discipline to write good Common Lisp code.
With Haskell, some of the code may be a bit harder to read at first, but I always have the type signatures to help me. Quite often I dont even need to read the code because the types give me enough of the story.
I am a lot more comfortable to modify code knowing that it just isnt going to break something I wasnt aware of. Far less discipline is required to write good Haskell code. As long as the project is set up so that you don't write everything in IO, you are pretty much good to go.
I would be a lot more confident throwing a junior at a Haskell code base than a Common Lisp one knowing that they would be far less likely to break things.
It does take a bit longer to learn Haskell, but in my opinion, once you get over the hump it is oh so worth it!
- reikonomusha 7y agoI think good mentorship, good code review, and good tests are critical to anything, including Common Lisp. We are very strict about that and we’ve had excellent results. Non-sense and language game-playing is quickly and earnestly called out, and everybody lives a better developer life. I’ve been on Lisp teams where that wasn’t the case and it was a free-for-all with macros and other things. That was a disaster and the code base was a gigantic Rube Goldberg contraption. But bad hygiene is possible in any environment, though Lisp has the capacity to amplify it.