Hacker News Reader

Comment by JonChesterfield | Hacker News Reader

Minimalist and based on llvm is a dubious combination. If your dependency set is massive, you should probably have an extensive feature set. If your language is minimalist, it probably shouldn't depend on llvm

View on HN

Interesting enough the LLVM version is a new rewrite from 2021 (hence pil21).

There have been multiple rewrites but the last version I remember was written in pure generic 64 bit assembly without any dependency on C. See: https://software-lab.de/doc64/README

Haven't yet found any rationale on the LLVM rewrite.

If you look into the code they do use LLVM exactly where they previously has their own generic assembly thing. It is probably to allow targeting more CPU platforms.

Oh, that is actually be quite sensible. I thought the would use LLVM to compile picolisp code but that makes more sense.

LLVM would only be a dev dependency for developing or compiling picolisp then, which is fine.

> If your dependency set is massive, you should probably have an extensive feature set.

Assuming that having a huge feature set is a desirable quality. Sometimes minimalism is a useful goal in itself - languages with few features usually make those features composable, leading to a combinatorial explosion of the ways those features can be used.

That being said, a small independent compiler/interpreter for PicoLisp would still be nice, though.

A minimal set of composable features is by far my preference for language design, hence reading about PicoLisp. I suppose a large and complicated set of dependencies could form the foundation for a minimal language - something like building a Forth on the JVM - but somehow that feels wrong. Misapplied priors in my reasoning perhaps.

The picolisp language doesn't differ between the custom assembly language implementation, the llvm implementation pil21 or the Java implementation Ersatz. Saying that picolisp has become less minimalistic because one implementation has a library attached which you think is heavy weight makes me think you misunderstood something important somewhere.

I was missing that there are implementations other than the llvm one, just went looking and found https://software-lab.de/doc64/README which I am delighted by, thank you for the hint!

It doesn't actually seem LLVM based but have an LLVM binding it uses build a self hosting compiler of the base system.

What a strange critique point. Do you have to pay in gold for each dependency?

I don't think it's a strange critique point - dependencies are a necessary evil, but still an evil. Minimizing dependencies is always a good thing, and I can't think of a scenario where maximizing dependencies would be desirable, given the same amount of features.

It's a pretty weird critique, llvm is becoming ubiquitous for these tasks. Can rattle off probably a dozen programming languages using it and no one is grousing...

Those programming languages are presumably not as minimal, and give features in exchange for this large dependency.

> dependencies are a necessary evil, but still an evil

I'm curious about this assertation. I've also heard that "do one thing and do it well" is a desirable goal and one should offload tasks to other pieces that specialize in that task (e.g. don't write your own crypto, use existing libraries), is there something that makes a programming language different?

Compile time/runtime dependencies often increase maintainence needs and resource usage.

In the context of programming languages, dependencies are a property of a programming language implementation. LLVM is not a small system, yet PicoLisp is a small language, which is why it might be considered a heavy dependency. There are scenarios like embedded where having a tiny implementation with little dependency pays off.

Ordinary programs can be very easily maintained by using only the language's standard library, as standard library is often maintained substantially longer than many third-party libraries.

PicoLisp does not depend on LLVM. The PicoLisp implementation pil21 uses LLVM in it's build process of the interpreter. There are multiple implementation of PicoLisp for different use cases. miniPicoLisp targets embedded. pil64 uses some meta assembly that can has an x86_64 and ARM64 port. pil32 is implemented in just C + Variable length arrays. Ersatz runs on the JVM.

It depends on the dependency. Linking sqlite.c doesn't bother me much as it's self contained and more likely to be correct than whatever I'm linking it into.

LLVM is pretty close to internally self contained as it DIY or vendors things in traditional C++ fashion (has optional deps on zlib and ncurses), especially if you use libc++ with it. However it is enormous and continually in flux. Building on LLVM also means picking up C++-like semantics regarding aliasing/undef/poison/freeze which are themselves somewhat in flux.

So in this case if PicoLisp emitted aarch64/x64 directly I'd consider that smaller/simpler than depending on LLVM, despite the increase in complexity in PicoLisp's own codebase from DIY'ing the machine code generation.

Fundamentally moving a load of complexity into a library can be a win but is not intrinsically cheaper than keeping it internal. You don't pay for it in gold - you move dev time and failure modes around, possibly for a net win and possibly for a net loss.

Reply on news.ycombinator.com