Running Lisp in Production (2020)

Re:Running Lisp in Production (2020) by dreamcompiler on Wednesday February 02, 2022 @12:03PM (#30180320)

This has been exactly my experience too. It's easy to bring good programmers up to speed in Lisp. It's sometimes harder to bring existing Lisp programmers onto a team. Let me explain: Some Lisp programmers (not the majority, but some) learned it on their own and it became their personal hobby-project language because it's so powerful. When those programmers join a team they bring bad habits with them. Bad habits like using lists for every data structure, overusing reader macros, not using packages properly, writing their own functions for things covered by well-tested cross-platform quicklisp libraries, etc.

Programming in Lisp is very different than software engineering in Lisp. Of course that's true in any language, but Lisp has a lot more "shoot your team in the foot" possibilities than C, and you absolutely need to learn to avoid those patterns or formally communicate your use of them in order to make Lisp effective on a software engineering team. Rather than depending on the language itself to enforce good software engineering discipline, with Lisp you must create out-of-band agreements with your team about how to write good software. This is not a bad thing; it's something all SWE teams should do anyway. But Lisp is especially intolerant of neglecting this aspect of SWE.

[ Parent | on HN ]

Re:Running Lisp in Production (2020) by xedrac on Wednesday February 02, 2022 @12:41PM (#30180990)

> Lisp has a lot more "shoot your team in the foot" possibilities than C, and you absolutely need to learn to avoid those patterns or formally communicate your use of them in order to make Lisp effective on a software engineering team.

I love Lisp for its adventurous and fun nature, but the above statement is a huge negative for real engineering work on a team. Any time you can rely on your tools or language prevent these types of issues, that's a win. This became especially evident to me when my team started using Rust. Code reviews are now almost purely about logic and design.

[ Parent | on HN ]

Re:Running Lisp in Production (2020) by reikonomusha on Wednesday February 02, 2022 @12:53PM (#30181175)

You don't shoot yourself in the foot in the same way one does in C. With carelessness, you more... suffocate yourself with your own towers of (probably useless) abstractions. It's like having a power drill when all you knew was a screw driver... and then drilling holes and driving screws every chance you get without regard to a larger structure.

Unlike C, the powerful (and safe) language features are a boon to software engineering projects, as long as you're doing was dreamcompiler said: software engineering and not "just programming".

I disagree with the thesis that the more restrictive one is, the better it is for software engineering. We've empirically disproved this time and time again with every supposedly "simple" language evolving way, way past its original design goals. Python, Go, and even Scheme are great examples.

[ Parent | on HN ]

Re:Running Lisp in Production (2020) by dreamcompiler on Wednesday February 02, 2022 @04:26PM (#30184272)

That's a great way to put it. With C you can build a car. With Lisp you can build a better car but it's also very tempting to build a car factory, and a motor factory to supply that, and an iron ore mine to supply the motor factory, and just for grins let's go ahead and reinvent physics in a way that suits our purposes and hey, faster-than-light spaceships are probably a good idea too so let's build those, and pretty soon you've completely forgotten about the car.

Lisp: With great power comes great responsibility.

[ Parent | on HN ]

Re:Running Lisp in Production (2020) by xedrac on Thursday February 03, 2022 @02:26PM (#30197435)

I am not trying to extol the virtues of C. I find C a low bar to improve upon, and I'd prefer Common Lisp over it in many cases.

What I am talking about is having to rely on people to do the "right" things when your toolset could be enforcing many of those things. We've empirically shown time and time again that people are poor at consistently avoiding pitfalls. This is especially true as the size and complexity of a project grows.

[ Parent | on HN ]