Re:Running Lisp in Production (2020)
by medo-bear on Thursday February 03, 2022 @10:36PM
(#30202545)
hi. thanks for sharing your experience. i just saw in your profile that your domain is security. if i may ask, do you have experience with lisp in this field, particularly as far as networking and encryption is concerned?
as regards this 10x business, i actually wasn't being very serious. it was just a playful response to the parent's claim that lisp is not suitable for large teams
No, oddly my security work (mostly application security and a bit of compliance work) is not with Lisp. Although I do use Lisp to generate my documentation.
I have toyed with the idea of using Lisp to take apart binaries.
Also, Lisp wouldn't be very good with encryption, as it doesn't do constant time very well.
To confess, I am probably, on a good day, 0.8x programmer. (I have known a handful of 10x programmers. And more than a few 0.1x programmers.)
My first big project was in FORTRAN II. The way that IF statements worked was really horrific, what with three statement labels. Next up was a massive project in Sigma5 assembler with interrupt driven tasks. Once we implemented co-routines, co-operative inter-process communication was a breeze, with very few multi-thread errors. I cringe when I see folks struggling with async-await hell. Prior to go, the only language that I saw that did co-routines well was Bliss-36.
Later I did a lot of C (pre-web). When I picked up C++, I ended up with fewer crashes, as I found it easier to deal with pointers to objects.
I came to Lisp later on, and am still working with it. It is a lot better than other languages for me in several ways. First, it is quite expressive. Secondly, with a slime, it is trivial to debug using break statements, ability to instantly navigate to the source of a function, be it yours or deep in the heart of e.g. SBCL. I use Lisp exclusively now (with an embarrassing amount of bash mixed in), but not because it is 10x for me. I am likely several X more productive, but in part due to the debug ability plus the repl.
Also, sbcl is really fast, even if you don't resort to hackish tricks like was done for sbcl to intimidate other languages in the mandelbrot benchmark game. Or log4cl compared with the speed of log4j.
Where some real leverage comes in with Lisp is the ability to express things that are significantly more difficult in other languages. There are things done in Lisp that are just plain impractical in other languages.
But there are some things that the programs are just about as annoying as in any other language. Look at the code dealing with http in either of the libraries drakma or dexador. Lisp ain't much help making that awful protocol go away.
And often in larger projects, minor advantages of a language compound to end up with a 2x or better result.
So this argument about a language being a miracle productivity tool is a pretty old one. I had a boss, a PhD fellow much smarter than I claim that higher-level assembler languages would make writing an operating system trivially easy. I was a bit suspicious of that then, and am quite certain of it now.