This sounds kind of like an absolutely miserable experience. Can someone point out why a company would choose lisp over some other language which is just as fast performance wise?
Running Lisp in Production (2015)
21–30 of 62 posts
Re: Running Lisp in Production (2015)
#22This sounds kind of like an absolutely miserable experience. Can someone point out why a company would choose lisp over some other language which is just as fast performance wise?
There aren’t many dynamic languages with that level of performance and maturity.
Their problem wasn’t choosing Lisp, but not paying for ACL :)
Re: Running Lisp in Production (2015)
#23At Amazon I’ve seen Clojure used successfully as a DSL in a larger service. The scaffolding is Java and the DSL parts are Clojure.
Re: Running Lisp in Production (2015)
#24This sounds kind of like an absolutely miserable experience. Can someone point out why a company would choose lisp over some other language which is just as fast performance wise?
Dealing with a bug in the language implementation is almost always a miserable experience, and all implementations have them; SBCL isn't unique or even unusual in this respect. Where it, and other Common Lisp implementations with similarly mature tooling, are indeed unusual and exceptional is in the unparalleled flexibility they offer to inspect, introspect, and instrument running code in real time, without having to so much as restart the system under inspection, and also without the constant headaches of something like gdb and its often flaky translation of byte slaw into symbolic structures.
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.
Re: Running Lisp in Production (2015)
#25Does anyone in the HN crowd know of any other brand-name orgs using Lisp?
When I was there, the A/B framework developed at LinkedIn was in Closure, and you you could even download your segment as a sexpr.
Re: Running Lisp in Production (2015)
#26This sounds kind of like an absolutely miserable experience. Can someone point out why a company would choose lisp over some other language which is just as fast performance wise?
There aren’t many dynamic languages with that level of performance and maturity. Their problem wasn’t choosing Lisp, but not paying for ACL :)
Allegro is nice. It’s fast, and has a great development environment. I used it all the time years ago.
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.
Re: Running Lisp in Production (2015)
#27Earlier quoted context omitted.
Thanks for the lists. Aside from ITA and Northwestern University, most of those were new to me. I was kinda hoping for some big commonly-known brands. I'm trying to convince my boss to let me learn Lisp on company time.
It would seem as too much of a shot in the dark with questionable ROI for a non-technical (and probably even a technical) manager. From their perspective it would seem as the equivalent of introducing an inexperienced programmer into the team (as your Lisp experience will initially be understandably zero), and there wouldn't be anyone in the immediate vicinity to help with peer review or mentoring. Perhaps it would b…
I think it's worth a try. The company is organized into small teams, and the HR department places a big emphasis on people learning new skills. We have a big catalog of in-house classes that are scheduled and taught every month (or quarter, depending on the complexity) with the purpose of promoting personal and professional growth.
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.
Re: Running Lisp in Production (2015)
#28Does anyone in the HN crowd know of any other brand-name orgs using Lisp?
It has been said that HN itself runs on Arc, based on Racket, a scheme/lisp. Paul Graham is a big lisp head.
Re: Running Lisp in Production (2015)
#29Earlier quoted context omitted.
It's easy to argue against, and many companies' higher ups successfully do and thus can mandate a monolanguage policy. For Grammarly, I still see them posting occasionally in the monthly who's-hiring threads for Lisp roles, I think they're doing fine. 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 don't know what they are doing currently , but the article from a few years ago said, "We run them on stock Linux images deployed to AWS. We use SBCL for production deployment and CCL on most of the developers’ machines." 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 alr…
Right, but you at least need to experiment with the other runtimes first before you can even determine whether there might be a good reason (like not having to mess with tuning a bunch of GC flags anymore, one of the sells for Azul's proprietary JVM) apart from a forcing situation (like Oracle shedding updates and support contracts on their Java8 VM, forcing people to OpenJDK / Azul's OpenJDK build + cheaper support contract). In many cases it doesn't take much effort to spin up a mirror environment and see if the alternative "just works" and what its characteristics are apart from that.
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.
Re: Running Lisp in Production (2015)
#30Earlier quoted context omitted.
There aren’t many dynamic languages with that level of performance and maturity. Their problem wasn’t choosing Lisp, but not paying for ACL :)
Allegro is nice. It’s fast, and has a great development environment. I used it all the time years ago. 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.
Assuming you don't want emacs, so...
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.