
Running Lisp in Production (2015) - wglb
https://tech.grammarly.com/blog/running-lisp-in-production
======
gilesgate
Previous discussions from last year:
[https://news.ycombinator.com/item?id=16860646](https://news.ycombinator.com/item?id=16860646)
[https://news.ycombinator.com/item?id=16679963](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.

~~~
jammygit
I did not realize common lisp was still in use and was therefore planning on
learning Clojure instead. Which is better to learn then?

~~~
billsix
[http://www.paulgraham.com/onlisp.html](http://www.paulgraham.com/onlisp.html)

~~~
gilesgate
"On Lisp" is a good book but perhaps too advanced for an introduction, whereas
his "ANSI Common Lisp"[0] is better suited to the purpose. Barski's "Land of
Lisp" has also received positive feedback.[1]

I'd be interested to see what others consider a suitable general learning path
for Lisp.

[0] [http://www.paulgraham.com/acl.html](http://www.paulgraham.com/acl.html)

[1]
[http://shop.oreilly.com/product/9781593272814.do](http://shop.oreilly.com/product/9781593272814.do)

~~~
lispm
The usual starting book is 'Practical Common Lisp' by Peter Seibel. Some
advanced stuff then in 'Common Lisp Recipes' by Edi Weitz. Some older advanced
stuff with examples: Paradigms of Artificial Intelligence Programming, Cases
Studies in Common Lisp (PAIP) by Peter Norvig.

------
AlexMoffat
“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.

~~~
Jach
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.

~~~
TurboHaskal
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_.

~~~
jcadam
> 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.

~~~
hhas01
Indeed. Pick the right tool for the job.

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.

------
RodgerTheGreat
Grammarly 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!

~~~
ebiester
While true, I believe the whole intent is to use machine learning on real text
to improve the customer's experience. For the customer, this is a feature
rather than the bug. It is not how I would prefer to interface with grammar
checking, mind you, but I think they have been transparent.

------
beastcoast
At Amazon I’ve seen Clojure used successfully as a DSL in a larger service.
The scaffolding is Java and the DSL parts are Clojure.

------
fsloth
Is grammarly still using Lisp? How's it going?

~~~
ngcc_hk
Want to know as well.

------
reaperducer
Does anyone in the HN crowd know of any other brand-name orgs using Lisp?

~~~
sli
Apple, eBay, Intuit, Oracle, and Red Hat (among many large and smaller-but-
still-largish companies) use Clojure according to the Clojure site.

[https://clojure.org/community/companies](https://clojure.org/community/companies)

~~~
chrisperkins
Another related link -
[https://clojure.org/community/success_stories](https://clojure.org/community/success_stories)

------
chrisperkins
> Being a client-server application, it allows to run its backend on the
> remote machine and connect to it from your local Emacs (or Vim, if you must,
> with SLIMV).

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?

------
xvilka
They 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.

~~~
mises
You could probably just crack open the browser extension, prettify it, and
send a few sample requests to get the hang of whatever API is used pretty
quickly. I doubt it will provide one, as there aren't many users demanding it.

------
Exuma
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?

~~~
TurboHaskal
There aren’t many dynamic languages with that level of performance and
maturity.

Their problem wasn’t choosing Lisp, but not paying for ACL :)

~~~
jonathankoren
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.

~~~
Jach
Are you using the right slime plugin? I haven't tried it yet (I'm happy with
vim+slimv) but I saw a thread on the CL subreddit last month that stated
"atom-slime is now replaced by Slima which is more complete".

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](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. ;)

~~~
lispm
> Windows XP screenshot

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.

[http://www.lispworks.com/documentation/lw71/RNIG/html/readme...](http://www.lispworks.com/documentation/lw71/RNIG/html/readme.htm)

[http://www.lispworks.com/documentation/lw70/RNIG/html/readme...](http://www.lispworks.com/documentation/lw70/RNIG/html/readme-131.htm)

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...

