(Common) Lisp usually gets more use than exposure, so it's nice to see large-scale Lisp success stories. Makes me feel warm and fuzzy inside, as it's one of my two favourite languages (the other one being, of course, C).
Edit: APL is a close third, but let's be realistic.
I'd be interested to see what others consider a suitable general learning path for Lisp.
What? It gets exposure on the Internet all the time, while seemingly nearly no one uses it in production.
Edit: Just look at the end of . They have exactly three examples.
Edit 2: They have more example in , but it is still pretty little.
I wonder if they've since run into more implementation specific issues and have shelled out for one of the proprietary Lisps. SBCL is always improving, though.
I have been working for two companies that adopted Clojure and Scala early on. They all have, within a period of two to three years, enforced a Java only monoculture with no new projects being written in the aforementioned languages.
The reasons were key engineers leaving for greener pastures and experiencing difficulties with staffing: Not being able to find (cheap) experienced developers, or failing to do in house training due to the lack of interest.
This might be hard to believe, considering that the average HN user would jump of excitement at the chance to learn something new, but then again, those languages were introduced with the JVM as the main selling point, meaning working mostly with Java developers, who are notorious for their resistance to learn _anything_.
Yea, that would be my cue to leave.
Picking the tool just because it gets you lots of cheap disposable developers simply means you end up with lots of cheap disposable code.
Good for the current quarter’s C-suite bonuses, no doubt; maybe not so much for long-term business continuity when that code is critical to continuing business operations.
Something something price of everything and value of nothing.
It doesn't have to be a single language, of course. The typical "use / ask / forbidden" matrix for new projects would suffice.
I don't have a problem with that, personally. It is only when programming languages are _exclusively_ being chosen out of non technical reasons that the fun ends and I'm out. Sadly, it happens too often.
The moment you do web application development, chances are you're using at least two languages if not more. There are some all-JS web companies, there are also some all-Clojure/ClojureScript companies, but neither are very common. Add a database, you might have another language (or not). Add a mobile application, and you're looking at potentially 6 languages just for that product category depending on how you set it up. DevOps? Take your pick, probably at least two used at the typical company that has such specific roles. Survive long enough (many companies don't even last a decade) and maybe make some acquisitions, now you've got acquired product X in some other language -- do you do a rewrite? Another aspect of surviving long enough is the language you picked might have changed a lot. Modern Java, JS, Python, and C++ are all significantly different now than they were not too long ago. Companies with big code bases can't afford a rewrite or mass update, so they have a mix, and developers need to be aware of the conventions of the old versions that may as well be called old languages. Of course some companies will insist on banning the modern styles and idioms even if they begrudgingly update the tooling, for much the same reasons they ban different languages.
Some companies do end up being long-lived and monolanguage though. And where I would agree with you is that individual products will tend to single language policies even if technically they can intermingle (i.e. all the JVM mingling). (Edit: and seeing your other clarifying comment, yeah, top-down control over letting teams make most of their own decisions probably is inevitable with time, this expands far beyond just language choice though.) Sometimes that language is Common Lisp! There are things that can be done to influence what it's likely to be, if it is to be. The "simplest" is probably just having a big enough, complex enough, and important enough product that no one's going to authorize a rewrite for even if the will and expertise to do so appeared. Then the monolanguage will be that language -- whatever a company starts with has a good chance of becoming The Language, but if you're starting with a not so popular language you're in danger of having it changed at some point and will need to protect against that if you care. (This to me explains Reddit's rewrite off of Lisp early on, the code that was written wasn't that big or complex yet, and also explains Facebook's lack of move off PHP and herculean efforts with Hack to compensate. But as companies Reddit seems much closer to the monolanguage endpoint than Facebook -- Facebook simply has way more engineers and a lot more projects going on.)
Another driver is what you highlighted, lack of interest, or indifference, and is probably the main one until you reach a "too big to change" tipping point. You need to have someone who loves the particular stack, or (also?) who hates the alternative stacks, because if you don't someone else will eventually come along with enough ambition and motivation (either from hatred of current stack or love for a new/alternate/more familiar stack) and the stronger passions will win the day with the indifferent employees just going along with it.
Once a large application works in some environment, you usually need a good reason (such as lower overall cost or inability to keep it working) to switch. They hit a few unlikely bugs and have already developed solutions for them. If they switched, the odds are excellent that they'd hit new unlikely bugs that they haven't found solutions for, and it's hard to have a smaller cost than SBCL or Linux. So while they may have changed, there's a reasonable chance they haven't.
So my curiosity is really whether they found further issues with SBCL later, or if it's been a champ since, and if at any time they investigated developing with SBCL/CCL and deploying with (maybe developing sometimes with) Allegro or LispWorks (which at least if they hit new bugs with, they have a support contract to help). The thread from last year includes one report from another individual about swapping deploying with SBCL to deploy with CCL because of resource savings. I'm just curious in hearing about what trajectories people have taken.
If you really must go comparing apples to pears, a marginally less worthless metric might be the percentage of each that has worms in.
Hey, at least the developers get to tinker with fun languages while spying on people!
I'm trying to convince my boss to let me learn Lisp on company time.
If anyone here has introduced Lisp into their workplace, I too would love to know their approach, be it successful or not. Although I'd be more interested in proper Lisp (OK, and Scheme) than Clojure, the latter wouldn't hurt either.
While Lisp is not core to what I do, neither is cooking, yet the company gives us classes in that, too. So I think I have a shot.
The world always needs more good Lisp programmers.
If I was your boss, I’d demand to know your projected ROI calculations up-front too. That includes the near-term risks and costs of change management when phasing in your new technologies and practices, and long-term business continuity implications after you’ve personally buggered off to pastures new.
I have used Slimv and found it quite enjoyable on Vim. Has anyone here tried Vlime? Has anyone tried both? Which one of the two do you recommend?
There's a goodly number of reasons not to choose Common Lisp for production, not least of which is that engineers skilled and familiar with the language can be hard to find. Debuggability, though, is not among them.
It's almost as fast and way, way more expressive than C, C++ and Java.
It's still more expressive and 100x faster than Perl, Python, Ruby.
It's the expressivity that hooks you in, in my experience. Once you've gotten used to programming with macros (code rewriting programs), the thought of programming without them seems almost as bad as programming without functions.
Their problem wasn’t choosing Lisp, but not paying for ACL :)
I recently decided to screw around with Lisp again and have been using SBCL with Atom via the Slime plugin, but it’s not very good. I can’t evaluate functions from the editor, nor can I copy-paste multiline functions into the repl. It’s very frustrating.
I've given Allegro a spin, and LispWorks too. I liked Allegro's UI better, but both just give off the "We designed our UI in the 90s, updated to the WinXP plastic chrome at one point in the early 2000s, and haven't touched it since!" vibe. It's just not very pleasant, especially with a big screen... I use Eclipse at work for my Java day job (IntelliJ is also an option but Eclipse is fine for me) and it makes me sad that its UX with all its clunkiness and compromises to be a mega plugin-extendable open source IDE still feels better than the IDEs that just need to support Lisp. If either Lisp company would offer a subscription license model similar to IntelliJ's along with even vague promises of modernizing the UX (like it's not a good sign when your product landing page literally still has a Windows XP screenshot http://www.lispworks.com/products/lispworks.html ) I'd start paying immediately, but I suspect most of their revenue is from the core Lisp image, their side products (I've heard AllegroGraph is amazing if you need that sort of thing), and various customer support contracts for not just the products but bespoke extensions / feature requests. That is to say, very little from the editor itself. Yeah you can always use their Lisp with emacs/slime but then part of the point is lost. ;)
There are a bunch of oldish things in it, but the backend is relatively native - so the application has a newer look on new systems.
They also improve the CAPI GUI layer with releases with new features.
There are a bunch of new IDE features, like visual profiler output, Code Coverage tool, support for remote debugging, ...
You'd have to read the release notes to find all that stuff. All in all it is a very feature-rich system...
It might not look as trendy as IntelliJ or VScode, but compared to stuff like Eclipse I'd say it does quite well.
Here's a screenshot on macOS https://i.imgur.com/ml4jlYB.png browsing some example code.
EDIT: A similar screenshot on Windows https://i.imgur.com/qkgIXhE.png
If you don't mind branching out Racket w/Dr Racket is zero setup and great fun w/great docs. If you go Clojure, many options that don't require setup (LightTable, maybe, e.g). If you want to stay common lisp, Lisp Works has a "personal" and "hobby" version of their IDE and that's free, zero setup, and a mature IDE.
I don't care about the downvote, but ftr, I a have been using emacs daily for about 25 years, spacemacs now, and love it. So there.
All I meant was that the OP I assumed knew about emacs and it's lisp history and was choosing Atom instead. The reason to do that would be learning curve, which I respect. Fair enough; I judge not. Just... you, know, for clarity.
The last emacs I used with any regularity was XEmacs.
SBCL (the implementation they use) was(is?) known to have a pretty bad GC situation.