Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Just use SBCL - https://www.sbcl.org/

Pick an editor: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

Good enough for games (and other commercial offerings) - https://kandria.com/



>Pick and editor

Well, Emacs, SBCL and SLIME are like bread and butter for obvious reasons.


I’ve recently been enjoying using Alive with vscode(and copilot). Everyone suggests emacs+slime but it always felt like too many things to learn at once. Being able to use my usual ide has made it so much more pleasant. Recommend it to newcomers.

https://github.com/nobody-famous/alive


And you’ll get a pile of UNIX tools that are approximately nothing like Genera in actual use.


Yes, in that you can actually use such tools to rapidly develop and ship software that runs on consumer machines (even Windows). Or did you have a more interesting point?


The request was for an environment similar to Genera, not an optimal environment for deploying to consumer systems. While it may work quite well for the latter, it fails at the former.


I don't see how you read that from behnamoh's comment. The 'request' or rather confusion was that the only way to do Lisp, historically and now, is with proprietary stuff like Genera or more modernly LispWorks, so what's there to do if someone wants to get into it now. On the contrary, I pointed out if anyone wants to get into Lisp now, in 2023, there is also amazing free tooling that's very capable just like many other languages for building and doing the sorts of things people typically want to do in 2023. The only other part of the comment I didn't address was just my agreement that proprietary emphasis did hurt Lisp adoption, though not getting Quicklisp until as late as 2010 hurt it more. (But maybe you could argue that was an extension of proprietary focus.) Things don't seem so gloomy now these last several years at least.



Realistically, "good enough for Google" is probably largely an accident of acquisition. QPX, the low airfare search engine, is not exactly a small piece of software. In c. 2007, it consisted of about 1 million lines of code divided unevenly between Common Lisp and C++, which, by then, had been developed for roughly a decade for the airline industry. Rewriting it would have been a non-trivial task.

Furthermore, Carl de Marcken, chief scientist/co-founder of ITA, had chosen Lisp because it was what he was most familiar with. He had told me in 2007 that if he had to choose a language again, he probably would have chosen Java, a choice Google would likely favor over Lisp.

I say this not to disparage Lisp—I enjoy Lisps, and I use Lisp professionally—but to contextualize this particular use of Lisp at Google.

EDIT: Just saw your reply to a sibling comment explaining that you meant SBCL, not Lisp per se.


See my other comment in this subthread.


ITA software is an acquisition, and I’m sure most of the Lisp development at Google is just done by engineers tweaking their .emacs files.

The problem of parsing data from airlines is fiendishly hard. There are a ton of different rules for how to calculate prices, and all sorts of deals and promotions that may affect a particular route on a particular day. If you have a system which can parse this data, then you wouldn’t want to rewrite it. I’ve read a number of articles about ITA Software’s Lisp code and it’s really interesting.

Lisp may be a critical part of ITA’s success, but “good enough for Google” is probably the wrong take here—Google, I’m sure, purchased a company to add its working product to their portfolio. I doubt that Google’s processes would allow someone to ale a new product in Lisp.


I meant SBCL specifically, not Common Lisp in general. They could have been using LispWorks or Allegro CL instead, but they aren't.


Can you share some of the articles you mentioned about ITA Software's Lisp code?


Keep in mind that the information is old.

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

I’ve read other stories, and seen presentations, but the information is getting harder to find.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: