Does anyone here use Common Lisp for their day job? I'd like to try it out some time (and am currently working through Paradigms of AI Programming by Norvig) but it feels like the language is so bendable that it'd be a minefield for a large team.
You want at least one experienced Lisper who can mentor the less experienced and build guard rails where needed. The good news is that it's unusually easy to build guard rails with Lisp because of that same "bendable" quality you mentioned.
Another thing that is unusually easy with Lisp is building code-analysis tools. The source code is made of standard Lisp data structures that you can operate on with standard Lisp functions, and you can do it all interaactively in the live environment. That makes it much easier to build linters and other analysis tools than it is in most other languages.
You need someone on the team who is experienced enough to know how to do these things, and team-oriented enough to want to do it.
You also need to be aware that you probably don't know what guard rails and analysis tools you need when you're starting out. You'll discover them along the way. So you need project management with enough foresight to invest in prevention up front in order to save on cures down the road.
I'm not the only or primary author of all of these; only a few of them.
- Panels [Apple, circa 1988]: an experimental graphical UI framework with a built-in constraint solver and extensible event-handling system
- GATE [Apple, circa 1989]: a knowledge-based, distributed, automated testing system used to discover and report thousands of application-compatibility bugs in Mac system software before release
- bauhaus [Apple, circa 1991-1994]: an experimental Lisp OS for Newton. The Newton OS (except the microkernel) was written in Dylan back when it was basically Scheme+CLOS; the Dylan compiler and development tools were written in Common Lisp.
- SK8 [Apple, circa 1995-1997]: rapid-application-development system sometimes referred to as "HyperCard on Steroids".
- Reactivity Application Firewall [Reactivity, circa 1998-2004; later Cisco]: Reactivity's product was a complex application-in-a-box that provided rule-based application-level security and integrity for networks. Cisco bought our company and folded it into their product line. I used Common Lisp for several code-analysis and documentation tools used in development of the product.
- Clozure Common Lisp [Clozure Associates, circa 2006-present]: I wrote documentation and code for Clozure Common Lisp and some associated tools
- Secure Outcomes LS1100 [Secure Outcomes, circa 2010]: I wrote the bulk of the control system and GUI for the Secure Outcomes fingerprint livescanner product, using Lispworks.
- Delectus [my own product, circa 2010-present]: Delectus 1, a simple personal data manager, was written mostly in Scheme. Delectus 2, a more capable, flexible, and portable version, is still under development and is written entirely in Common Lisp.
- Confidential project [Confidential client; 2020-present]: a knowledge-based, reasoning-based neurosymbolic machine-control system. As I mentioned, it's confidential, but I can say that it's designed to monitor and orchestrate a variety of different kinds of robots with human supervision in real time.
I've omitted several free libraries and other open-source Lisp software that I've written over the years.
Do you find Lispworks superior to SBCL / Emacs?
Any tips for other programmers on what to do / what not to do when it comes to production level lisp programs?
I use both.
As for tips, there are probably a lot, but I have to take a break from HN right now to attend a work meeting. :-)
SBCL is better in the sense that almost everyone who writes an open-source library for Quicklisp distribution is going to test it with SBCL, so most of the time Quicklisp libraries just work with SBCL.
Testing with other Lisps, including Lispworks, is not quite so automatic, so there's a little greater likelihood that something might fail to work.
That being said, most libraries I've tried with Lispworks have worked without any trouble.
I also left out a bunch of library projects that live on Github.
(If you want me to see if I can help, send me mail at mikel@evins.net and we can talk it over.)
In most of the cases on my list of past projects, the people who organized the projects were Lispers themselves or had contacts in the Lisp community, and recruiting from that community was part of the early project setup.
The bad news is that the community of Lispers is small compared to those of more popular languages. The good news is that Lispers are generally eager to work in Lisp, which can be helpful in recruiting. For example, I prioritize Lisp opportunities over others, and I'll work for less money if I like the people and I get to work in Lisp.
I have been part of hiring and mentoring some programmers that were not experienced with Lisp. In all but one case, they were interested in learning it, and made quick progress.
I've worked on a few teams of mixed Lispers and non-Lispers, ranging in size from about three to about sixty. I've found that you want one or more experienced Lispers who are willing and able to take on a mentorship role. With mentors, good programmers can pick up Lisp and its style and idioms pretty quickly (assuming they want to). Without mentors it can be rough going.
edit: i adjusted my answer because i thought i was answering to parent
Also so cool that you worked in AI! That’s my dream field :)
You have a function (defun my-val () "a string")
Referentially transparent, easy to reason about right? Wrong. Lisp strings are mutable, and everything is a reference. So if you do something like this
(replace (my-val) "b" :start1 0 :end1 1)
(my-val) => "b string"
I appreciate that CL doesn't force everything to be immutable, but it seems like at least strings would benefit from being treated as immutable values.
I thought I could do (string "a string") to prevent it, but that didn't work.
(concatenate 'string "a string") worked, though ...
[0] http://www.lispworks.com/documentation/HyperSpec/Body/03_aba...
Sounds about like most large codebases. Languages can't save you from this, it seems, only discipline can.