Live data from Hacker News

Running Lisp in Production (2015)

tech.grammarly.com

11–20 of 62 posts

Re: Running Lisp in Production (2015)

#11
post #7

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.

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.

Re: Running Lisp in Production (2015)

#14

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

The lispwork page http://www.lispworks.com/success-stories/ has some that are specific to lispworks. Some also (with possible overlap) at https://lisp-lang.org/success/. Allegro Common Lisp success stories: https://franz.com/success/. ITA (now part of Google) https://www.itasoftware.com/

Re: Running Lisp in Production (2015)

#15
post #4

Earlier 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…

That has not been my experience. Companies can and should develop a set of technologies that they as an organization feel comfortable with, but this list should be dynamic and should have some diversity in it. Don’t allow every technology under the sun without any vetting, but also don’t force everyone to use the one true programming language, Java.

Re: Running Lisp in Production (2015)

#16
post #4

Earlier 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…

I don't really agree that it's a matter of time. There's a pressure, sure, but a stronger counter-pressure is simply having wider product categories and to a lesser extent enough employees to allow for some specialization.

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.

Re: Running Lisp in Production (2015)

#17
post #14

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

The lispwork page http://www.lispworks.com/success-stories/ has some that are specific to lispworks. Some also (with possible overlap) at https://lisp-lang.org/success/ . Allegro Common Lisp success stories: https://franz.com/success/ . ITA (now part of Google) https://www.itasoftware.com/

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.

Re: Running Lisp in Production (2015)

#19

Earlier quoted context omitted.

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…

That has not been my experience. Companies can and should develop a set of technologies that they as an organization feel comfortable with, but this list should be dynamic and should have some diversity in it. Don’t allow every technology under the sun without any vetting, but also don’t force everyone to use the one true programming language, Java.

But that's what I meant by top-down controlling of the language stack: Which in the context of the blog post, would be the contrary of "valuing choice and freedom over rules and processes."

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.

Re: Running Lisp in Production (2015)

#20
post #14

Earlier quoted context omitted.

The lispwork page http://www.lispworks.com/success-stories/ has some that are specific to lispworks. Some also (with possible overlap) at https://lisp-lang.org/success/ . Allegro Common Lisp success stories: https://franz.com/success/ . ITA (now part of Google) https://www.itasoftware.com/

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 be more effective to learn Lisp on your own through a few hobby projects, and then gradually (and gently) introduce it as a potential solution for work projects? This does depend on your team's structure, though,

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.

Post reply on HN