Running Lisp in Production (2015)
tech.grammarly.com
Running Lisp in Production (2015)
1–10 of 62 posts
Re: Running Lisp in Production (2015)
#2“but we value choice and freedom over rules and processes.” Who could argue with that? It can sound pretty defensive though, like we know we have a bunch of nearly random stuff that few people can really understand and manage but, hey, freedom. Lisp has always been interesting and there’s always one or two companies in any time interval that are successful, and wildly so, using it. It could also be as much skill, great execution and a market.
Re: Running Lisp in Production (2015)
#3Is grammarly still using Lisp? How's it going?
Re: Running Lisp in Production (2015)
#4“but we value choice and freedom over rules and processes.” Who could argue with that? It can sound pretty defensive though, like we know we have a bunch of nearly random stuff that few people can really understand and manage but, hey, freedom. Lisp has always been interesting and there’s always one or two companies in any time interval that are successful, and wildly so, using it. It could also be as much skill, gre…
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.
Re: Running Lisp in Production (2015)
#5“but we value choice and freedom over rules and processes.” Who could argue with that? It can sound pretty defensive though, like we know we have a bunch of nearly random stuff that few people can really understand and manage but, hey, freedom. Lisp has always been interesting and there’s always one or two companies in any time interval that are successful, and wildly so, using it. It could also be as much skill, gre…
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.
My experience is that mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature.
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_.
Re: Running Lisp in Production (2015)
#6Previous discussions from last year:
https://news.ycombinator.com/item?id=16860646
https://news.ycombinator.com/item?id=16679963
(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.
Re: Running Lisp in Production (2015)
#7They still do not provide a per-subscription API for integration, which is plain stupid for 2019. It would be awesome to have it integrated with Vim, Emacs, whatever you like.
Re: Running Lisp in Production (2015)
#8Grammarly is essentially an opt-in keylogger for your browser. To put it generously, it is hilariously insecure by design. Furthermore, I don't believe that most of their users understand that the plugin "phones home" continuously to function.
Hey, at least the developers get to tinker with fun languages while spying on people!
Re: Running Lisp in Production (2015)
#9Earlier 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.
My experience is that mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature. 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 re…
> mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature.
Yea, that would be my cue to leave.
Re: Running Lisp in Production (2015)
#10“but we value choice and freedom over rules and processes.” Who could argue with that? It can sound pretty defensive though, like we know we have a bunch of nearly random stuff that few people can really understand and manage but, hey, freedom. Lisp has always been interesting and there’s always one or two companies in any time interval that are successful, and wildly so, using it. It could also be as much skill, gre…
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 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.