"Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp."
So true. Lisp was designed to give individual programmers tremendous power. That means Lisp programmers sometimes prefer to reinvent solutions to problems rather than learn to use some existing solution. This tendency can be an absolute nightmare on a software engineering team.
Not that using Lisp on a software engineering team cannot be done, but it requires very strong discipline and leadership. The absence of strong discipline and leadership on a Lisp SWE team can lead to enormous amounts of wheel reinvention and technical debt.
Obviously discipline and leadership are necessary for any SWE team but languages like C don't encourage reinvention nearly as much as Lisp does, and Lisp programmers in general tend to be very resistant to the imposed discipline that SWE requires. (I say this as a diehard Lisp programmer, so I'm talking about myself.)
> So true. Lisp was designed to give individual programmers tremendous power. That means Lisp programmers sometimes prefer to reinvent solutions to problems rather than learn to use some existing solution. This tendency can be an absolute nightmare on a software engineering team.
I've found that there's a world of difference between my tendency to wheel-reinvent when I'm messing around on my own vs. my tendency in an industrial setting. When I'm messing around on my own, Lisp gives me so much more reach it's incredible, and yeah, I kinda do want to reinvent the application server, or the TCP/IP stack, or something sometimes.
But when I'm getting paid and there are milestones and deadlines? Fuck it, I'll just use what's available to build what's needed. The difference is that in a Lisp codebase, some really smart people have come before and built some really cool abstractions. Like a test framework that makes automated testing so much simpler it's ridiculous. Like, two lines of code and you have a test for a new feature. You get access to tools and techniques that let you close the gap between "ticket lands in your lap" and "done" much faster than you would in Java.
Completely agree. If everybody on the team has your attitude it's not a problem. But often, a few people don't. It's so damned tempting to reinvent a testing framework in Lisp, because we have lambdas and code is data right? Lisp is tailor-made for testing frameworks!
Until you're two weeks in to what you expected to be a 2-hour project and you realize you can't meta-dot your tests and you made too many assumptions about which equality functions to support, so you let the user just specify a lambda for the relation function and Poof! Now you can't reason about your tests nearly as well.
And oh yeah I used a macro-centric approach when I should have used CLOS so again, I can't easily grovel my tests. Damn.
Designing a test framework in Lisp looks easy but doing it well is surprisingly hard. So using one of the better ones in Quicklisp is almost always a win.
That's just a mind projection piece written by someone with next to no Lisp experience, let alone in a setting with multiple developers.
Exactly. A post full of bollocks.
"Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp."
So true. Lisp was designed to give individual programmers tremendous power. That means Lisp programmers sometimes prefer to reinvent solutions to problems rather than learn to use some existing solution. This tendency can be an absolute nightmare on a software engineering team.
Not that using Lisp on a software engineering team cannot be done, but it requires very strong discipline and leadership. The absence of strong discipline and leadership on a Lisp SWE team can lead to enormous amounts of wheel reinvention and technical debt.
Obviously discipline and leadership are necessary for any SWE team but languages like C don't encourage reinvention nearly as much as Lisp does, and Lisp programmers in general tend to be very resistant to the imposed discipline that SWE requires. (I say this as a diehard Lisp programmer, so I'm talking about myself.)
> So true. Lisp was designed to give individual programmers tremendous power. That means Lisp programmers sometimes prefer to reinvent solutions to problems rather than learn to use some existing solution. This tendency can be an absolute nightmare on a software engineering team.
I've found that there's a world of difference between my tendency to wheel-reinvent when I'm messing around on my own vs. my tendency in an industrial setting. When I'm messing around on my own, Lisp gives me so much more reach it's incredible, and yeah, I kinda do want to reinvent the application server, or the TCP/IP stack, or something sometimes.
But when I'm getting paid and there are milestones and deadlines? Fuck it, I'll just use what's available to build what's needed. The difference is that in a Lisp codebase, some really smart people have come before and built some really cool abstractions. Like a test framework that makes automated testing so much simpler it's ridiculous. Like, two lines of code and you have a test for a new feature. You get access to tools and techniques that let you close the gap between "ticket lands in your lap" and "done" much faster than you would in Java.
Completely agree. If everybody on the team has your attitude it's not a problem. But often, a few people don't. It's so damned tempting to reinvent a testing framework in Lisp, because we have lambdas and code is data right? Lisp is tailor-made for testing frameworks!
Until you're two weeks in to what you expected to be a 2-hour project and you realize you can't meta-dot your tests and you made too many assumptions about which equality functions to support, so you let the user just specify a lambda for the relation function and Poof! Now you can't reason about your tests nearly as well.
And oh yeah I used a macro-centric approach when I should have used CLOS so again, I can't easily grovel my tests. Damn.
Designing a test framework in Lisp looks easy but doing it well is surprisingly hard. So using one of the better ones in Quicklisp is almost always a win.
Just curious: Which one is your favorite?