Lisp in Web-Based Applications (2001) | Hacker News Reader

Lisp in Web-Based Applications (2001)

lib.store.yahoo.net

92 pointstosh35 comments

Many years back, at a movie studio, I was working on an application that would enable users to mine historical release data for planning. I started off with a proof of concept in RoR (v0.2ish) days and on a flight home read 'Hackers and Painters'.

After the trip came back and dropped RoR and prototyped the app in CL (CMUCL IIRC). The users loved it, so to deploy it with a UI, ended up with Lisplets [1] (checkout who wrote it!)

Fast forward a year or so, the users were happily mining the data with a clear impact on bottom line. Then I came across NLP in CL and extended the app with NLP functionality so users could do kind of google search for their queries ("show me all movies which were directed by X and starred Y, Z and made N dollars in A, B, C territories). Writing NLP app in non ML hype phase was fun, note that there was some simple query syntax for users to learn.

Last I heard, after I left, a year or so later, they did a rewrite of the app in Java land; most Lispers here can predict how that story ended :-(. One of the most enjoyable phases in my career and don't even ask me how I pulled off writing CL in corporate for 4+ years, because frankly I don't remember (side effect of coding in CL being fun!) but I think my manager had failingly invested a lot in getting this app developed prior to giving me a chance to prototype 'quickly' and I think the prior pressure of not-shipping helped me.

[1] http://lisplets.sourceforge.net

[2] https://www.aclweb.org/anthology/J90-2005

I've worked on a couple large Web-involved projects that would not have been viable, had they not used a Lisp (one Scheme, one CL). (The Scheme one, some advanced ancient astronaut before me had single-handedly made an architecture that did every complicated thing needed, and I'd say wouldn't have been viable to do in a non-Lisp.)

It's easier in the last few years to see why startups aren't using a Lisp, despite PG's early advocacy of that -- they want a very polished-looking Web/app frontend, and everyone is pushing you to buy into their frameworks and SDKs for that.

But I'd still like to see some students who played with Racket/Scheme/CL in college spin out to do a startup with a Lisp for prototyping/beta, and once they have real funding (when they should probably be rewriting prototype code in any case, or even pivoting) decide whether to keep going with a Lisp. (If they keep going with a Lisp, a bonus is that they have special access to a disproportionately high-skilled labor pool, like in other niches that attract nerdy enthusiasts.)

The order-processing system behind my site [1] is written in Common Lisp. It interfaces with Stripe for credit card processing and Easypost for generating mailing labels. The whole thing took me about two days to write and it has been working without a hitch for several years. It has more than paid for itself just in the time it has saved me in preparing international shipping labels manually.

I also have a prototype of a server-mediated version of the SC4 secure communications system [2] [3] written in CL. The code for this is a bit of a mess so it's not publicly released but if you're interested drop me a line. Contact info is in my HN profile.

[1] http://sc4.us/hsm

[2] https://github.com/Spark-Innovations/SC4

[3] https://stage.sc4.us/sc4/sc4tk.html

”In fact it turned out that Web consultants didn't like Viaweb. Consultants, as a general rule, like to use products that are too hard for their clients to use, because it guarantees them ongoing employment.”

A useful reminder of why much of web development is the way it is.

Is this really true? Genuine question, I'm not being snarky. When I think about common complaints about web dev, they all seem to be caused by something else. JS's non-existent standard library and mournfully inconsistent semantics were caused by Brendan Eich writing it in a weekend and never getting a chance to fix it because it got standardized too quickly. Framework churn is caused by the fact that the web browser and all its primitives were unlike any platform that came before it and we didn't (and still don't) know what the right abstractions are even for any given kind of web app. UI design to a good extent is just inherently hard and requires accounting for many details that HTML and CSS must therefore expose to you, etc.

Most sites just don’t need JavaScript. But “SPA everything!” certainly has kept the consultants happy.

I'd like to try Lisp for a personal web project I'm working on. What's the Lisp equivalent of a LAMP stack? What is the recommended process for an Ubuntu server?

Racket can probably do everything you want (i.e. serve as its own 'LAMP stack').

Clojure with whatever the standard libraries are nowadays is easy to get setup and running.

I'm sure there's a common Common Lisp set of libraries for web apps too.

And there's a variety of smaller Lisp projects for various other runtime environments, e.g. various Lisp-to-JavaScript transpilers that you could run on top of Node.js.

> Racket can probably do everything you want (i.e. serve as its own 'LAMP stack').

Here's a quick tutorial on web applications in Racket: https://docs.racket-lang.org/web-server/index.html

Here's a run through a simple Clojure web app http://www.luminusweb.net/docs

and here is some documentation on deployment http://www.luminusweb.net/docs/deployment.html

To add to this, I have found the source code of 'grumpy.website' a nice example project: https://github.com/tonsky/grumpy

For Common Lisp you have a lot of options. I think https://lisp-journey.gitlab.io/web-dev/ serves as a good overview of entry points for them. There's also a short and relatively recent pay-what-you-want ebook available that might be useful: https://leanpub.com/lispweb (And while I'm at it I appreciated this ebook https://www.darkchestnut.com/book-common-lisp-application-de... for its relevance to the professional programmer who is used to how things are done in JavaLand; it also briefly covers server-side app development and deployment)

The closest to literally LAMP would just be LAML. Configure Apache to reverse-proxy to your Lisp application running its own web server (Hunchentoot is a popular base choice to get up and running) on some local port and use CLSQL to talk to MySQL.

I fondly remember the a-ha moment I had when I realized Ruby on Rails & Symfony are relying heavily on passing hashmaps around, instead of positional parameters.

Is this related to a particular paragraph in the article? I've found this style interesting as well and would enjoy reading about others experiences with it.

Not directly re passing hashmaps but related:

He writes how keyword parameters helped evolve the code. Today we might say “anti-fragile”.

> Rtml even depended heavily on keyword parameters, which up to that time I had always considered one of the more dubious features of Common Lisp. Because of the way Web-based software gets released, you have to design the software so that it's easy to change. And Rtml itself had to be easy to change, just like any other part of the software. Most of the operators in Rtml were designed to take keyword parameters, and what a help that turned out to be. If I wanted to add another dimension to the behavior of one of the operators, I could just add a new keyword parameter, and everyone's existing templates would continue to work. A few of the Rtml operators didn't take keyword parameters, because I didn't think I'd ever need to change them, and almost every one I ended up kicking myself about later. If I could go back and start over from scratch, one of the things I'd change would be that I'd make every Rtml operator take keyword parameters.

Objective C and SmallTalk use named parameters as well

Well, most of the big airlines pay ITA software for their Lisp written QPX engine so that it searches their insane pricing data structure to display on that airline's own website.

Paid, in the past tense, as they were acquired by Google/Alphabet a few years ago, IIRC.

Does someone know if they rewrote QPX with one of their internal approved languages (Java?) or if they continued to use CL? The Wikipedia page mentions that they offered a simplified API but was discontinued April last year.

I would dare to say they canned the product for good... ^__^;

The carriers and OTAs are still using QPX the same way after the Google takeover. That was actually part of the agreement to let Google buy ITA.

It is still Common Lisp. Among other things you can tell by their contributions to open source Lisp projects.

This is one of those things like "In the Beginning Was the Command Line" that sounded profound in its day, but didn't take into account the inexorable march of time. In 2019, there is a strong bias to write Web service applications in the same language as the client. If you're doing greenfield development and do not choose JavaScript as your implementation language, someone will tell you you're being impractical.

> In 2019, there is a strong bias to write Web service applications in the same language as the client.

Really? One would have thought that this was true a couple of years ago. Now? Does it really matter which languages your backend is written in, since you are going to interact using APIs anyway? And the backend is going to be composed of containerized microservices, so not even runtime installation is an issue now.

Not sure who in the right mind is still advocating for writing backend code exclusively in NodeJS in 2019.

Not sure who in the right mind is still advocating for writing backend code exclusively in NodeJS in 2019.

Millions of node.js developers? ;)

Also, paypal, netflix, ebay, linkedin, uber,...

Not to mention coding bootcamps. For those with short memories, Java didn't achieve its dominance based on Sun's marketing alone. Sure, that played a role, but Java was also convenient for universities to roll out as a language for instruction, usually displacing the likes of C++ and Pascal. It became the first language for millions of developers, many of whom wouldn't have much exposure to anything else.

For a while, it looked like Python had a shot at becoming the next dominant teaching language. Then the coding bootcamps realized they could save money and retain more students if they pitched JavaScript as the language for client and server. And so millions more developers are emerging with little exposure to anything outside JavaScript.

> the inexorable march of time

I think it's more like pendulum swings. Those biases come and go. The Lisp world is mostly uncorrelated with them.

My pet theory is that each swing is kicked off by a new generation pushing against the previous bias, which by then has been around long enough for its weaknesses to show. It's exciting the first two or three times you go through this, but after a while there's a curious feeling of nothing much ever changing. At that point Lisp looks pretty good again.

I don't think you can be accused of being impractical if your lisp compiles to JavaScript with access to npm

Every Node app I've ever worked on has had a high-ranking team member who advocated for adherence to idiomatic JS, and particularly against the use of functional concepts as expressed by libraries like Sanctuary and Fluture, so as to be readable and maintainable by "ordinary" JS developers (who are apparently assumed to be incapable of learning such concepts).

Lisp -- even transpiled to JS for ingestion by Node -- is patently out of consideration on such a project.

> high-ranking team member

Is there a connection between their opinion and how they came to be high-ranking?

Is it Java Shop Politics[0] at play?

I find their opinion frustrating.

[0] http://sasamat.xen.prgmr.com/michaelochurch/wp/2012/04/13/ja...

Or worse, Typescript.

Nothing but class files, many with one or two public func^H^H^H^H methods in each file, as far as the eye can see :-(

To me, idiomatic JS is FP oriented, but I guess that’s just me. Most of my work has been on the front end, with the Java guys largely staying out of the way, rather than on node.

By 2019, aren't we figuring WASM (besides generated JS) into our prognostications of what tech we'll want to be using?

(JS being considered poor for new work could happen. Look at how quickly even some of the hottest Web frameworks in just the last few years have suddenly become frowned-upon.)

The bias is caused by a glut of junior developers who don't have the experience to feel comfortable using more than one language.

It's one of those ideas that sounds good until you realise the single-language stack you've chosen is based on JavaScript, Node and npm.

> In 2019, there is a strong bias to write Web service applications in the same language as the client.

where is this bias? The majority of enterprise development still happens in Java and C#.

Worth remembering that Yahoo's first major decision after buying Viaweb was to rewrite it so it was not in Lisp.

https://discuss.fogcreek.com/joelonsoftware1/31402.html

Reddit also started out as lisp https://redditblog.com/2005/12/05/on-lisp/

Lisp really is the Wankel engine of programming languages. Everybody loves it until it's time to put it into production.

ClojureScript and Node.js now even a junior JavaScript can do that without learning obscure syntaxes from Lisp.

Reply on news.ycombinator.com