Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running Lisp in Production (2015)

tech.grammarly.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Running Lisp in Production (2015)

#41

Post by lispm »

Jach wrote: post #33
jonathankoren wrote: post #26

Earlier quoted context omitted.

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.

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

> 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/lw70/RNIG/html/readme...

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

Re: Running Lisp in Production (2015)

#42

Post by p_l »

sli wrote: post #18
reaperducer wrote: post #12

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

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

OSX sandboxing uses Scheme48 under the hood.

Re: Running Lisp in Production (2015)

#43

Post by 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?

Re: Running Lisp in Production (2015)

#44

Post by prometheus76 »

jonathankoren wrote: post #26
TurboHaskal wrote: post #22

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

I am definitely a Lisp noob, but portacle has been a pretty great "intro to lisp programming" environment. (I'm in a Windows environment, as the context to this comment.) Portacle is basically emacs with SLIME and a Common Lisp REPL integrated. What I just wrote might actually be nonsense because, again, I am noob af.

Re: Running Lisp in Production (2015)

#45

Post by jonathankoren »

methehack wrote: post #36
methehack wrote: post #30

Earlier quoted context omitted.

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.

Oh I guess my "assuming you don't want emacs, so..." was interpreted as a ding against emacs so I was downvoted... 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. F…

FTR the reason why i don't use emacs is because it frustratingly has too many degrees of freedom, and thus is perpetually misconfigured, and I find it has atrocious UX.

The last emacs I used with any regularity was XEmacs.

Re: Running Lisp in Production (2015)

#46

Post by mnemonicsloth »

Exuma wrote: post #21

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?

The long and the short of it is that lisp, for all its faults, is superior to commonly used programming languages in most cases.

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.

Re: Running Lisp in Production (2015)

#47

Post by jammygit »

gilesgate wrote: post #6

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

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

Re: Running Lisp in Production (2015)

#48

Post by eschaton »

jammygit wrote: post #47
gilesgate wrote: post #6

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

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

What made you think it was “no longer in use?” It’s a very big world. Just because something isn’t mentioned regularly in headlines doesn’t mean it’s not out there.

Re: Running Lisp in Production (2015)

#49

Post by billsix »

jammygit wrote: post #47
gilesgate wrote: post #6

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

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

http://www.paulgraham.com/onlisp.html

Re: Running Lisp in Production (2015)

#50

Post by hhas01 »

jcadam wrote: post #9
TurboHaskal wrote: post #5

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…

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

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.

Post reply on HN