undefined | Better HN

0 pointsTloewald11y ago0 comments

I wouldn't say "lies" so much as overly optimistic opinions.

The idea that you can write a useful program in Lisp faster than in other languages is pretty unsupportable. For most users, the time and effort spent getting Lisp up-and-running on their machine of choice will already have lost. Incidentally, I played with the interactive REPL and it wouldn't advance beyond the second page.

And, if you do write a useful program in Lisp, you run into the deployment problem. The deployment problem is pretty bad. Apple's Advanced Technology Group at one point had one of the highest concentrations of Lisp-heads in the world and produced a bunch of stuff like Dylan, Sk8, etc. that was intimately tied to their Lisp implementation. Not only was this not cross-platform, and pretty hard to distribute and deploy even on the platform it was created for (680x0 Macs) it was killed by the transition to PowerPC.

This isn't as big a problem if you're writing server software, but it's absolutely disastrous if you're writing desktop or mobile software.

One could show someone how to do something useful and deployable in Python, PHP, Perl, Javascript, or whatever in a few minutes and chances are they could have a usable dev environment set up in a few minutes.

0 comments

5 comments · 1 top-level

ScottBurson11y ago· 4 in thread

The only thing that makes programs easy to deploy is the popularity of the language/environment they're written for. If the language you're using is popular enough that you can download the implementation using your system's package manager, deployment is easy. If not, it's harder.

And for any language that's popular now, there was a time that it wasn't yet popular, and deployment was a pain.

So I think you have it backwards: Lisp is not unpopular because it's hard to deploy; it's hard to deploy because it's never cracked the popularity threshold.

TloewaldOP11y ago

The old joke with Common Lisp used to be if you've developed a program for one version of Common Lisp, you've developed a program for one version of Common Lisp.

Lisp is notoriously hard to deploy. Code is not portable between different lisp implementations. Apple's ATG ended up axing many projects because they had so much trouble moving their lisp from 680x0 to PowerPC.

The fact you talk about "your system's package manager" ignores my point -- I'm not saying Lisp is especially hard to deploy to servers (although it is -- but this is, as you say, a popularity issue; and it would be far worse if the world of servers hadn't converged on a small number of very similar platforms). I'm saying it's hard to deploy to desktops and mobile, which is where most of the "useful" programs people might want to write still live.

A huge part of Lisp's problem is fragmentation. Which Lisp? Aside from fragmentation in Common Lisp itself, there's all the not-quite-Lisps around, ranging from Arc to Scheme to Clojure to sheesh-I-really-have-no-idea. And of course this is because once you start coding in Lisp there's an overwhelming urge to abstract away difficult things in your own clever way, perhaps even hacking the language itself, and pretty soon your little world is utterly unique.

Another great, simple language in the exact same boat is Forth.

Blackthorn11y ago

This is only telling half the story. It is perfectly true for, say, Python (still a pain to deploy on Windows, or at least it was the last time I tried), but newer languages that are less popular like Go do not have this problem. Even Rust, a language that is only in alpha, does not have this problem!

Why is this? It's because they can live in, and interact with, the common linking and loading ecosystem that the rest of the world lives in: the C ABI. If you can link your output into something that respects the C ABI, you can deploy it[1].

Common Lisp implementations could immediately solve their deployment problem by living in this ABI. So far, the only one that has done so is ECL (which is an excellent project).

[1] A few alternatives exist. The Java and .NET ecosystems are also viable link targets (as I think Clojure has proved).

lispm11y ago

If you want to create something that you can link into C program, there are several options:

Lisp systems like LispWorks can generate typical platform shared libraries.

Many can easy embed C-code.

Some compile to C, which than can be embedded. ECL is only one example. Others are mocl or the ECL-related systems.

ScottBurson11y ago

Well, sure, if all your programs need is the OS and common libraries, deployment is easy.

But this only restates the point. It's easy because those things are popular. Try deploying an executable that requires a shared library that you can't download with your package manager, and you're pretty much back into the same pain.

Using the C ABI helps if you want to link against other code that uses it, though it isn't strictly necessary (pretty much all these language implementations have foreign call mechanisms). But this is a development issue, not a deployment issue.

ECL does make it convenient to build standalone executables, but most CL implementations can also do this.

j / k navigate · click thread line to collapse