3 ms·

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

artemonster 4y ago
What a strange critique point. Do you have to pay in gold for each dependency?
- paskozdilar 4y ago
  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.
  - crabbygrabby 4y ago
    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...
    - teddyh 4y ago
      Those programming languages are presumably not as minimal, and give features in exchange for this large dependency.
  - stinkytaco 4y ago
    > 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?
    - paskozdilar 4y ago
      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.
      - freemint 4y ago
        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.
- JonChesterfield 4y ago
  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.
paskozdilar 4y ago
> 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.
- JonChesterfield 4y ago
  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.
  - freemint 4y ago
    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.
    - JonChesterfield 4y ago
      I was missing that there are implementations other than the llvm one, just went looking and found https://software-lab.de/doc64/README https://software-lab.de/doc64/README which I am delighted by, thank you for the hint!
freemint 4y ago
It doesn't actually seem LLVM based but have an LLVM binding it uses build a self hosting compiler of the base system.
cardanome 4y ago
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 https://software-lab.de/doc64/README Haven't yet found any rationale on the LLVM rewrite.
- freemint 4y ago
  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.
  - cardanome 4y ago
    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.

artemonster 4y ago

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

paskozdilar 4y ago
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.
- crabbygrabby 4y ago
  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...
  - teddyh 4y ago
    Those programming languages are presumably not as minimal, and give features in exchange for this large dependency.
- stinkytaco 4y ago
  > 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?
  - paskozdilar 4y ago
    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.
    - freemint 4y ago
      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.
JonChesterfield 4y ago
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.

paskozdilar 4y ago

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

JonChesterfield 4y ago
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.
- freemint 4y ago
  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.
  - JonChesterfield 4y ago
    I was missing that there are implementations other than the llvm one, just went looking and found https://software-lab.de/doc64/README https://software-lab.de/doc64/README which I am delighted by, thank you for the hint!

freemint 4y ago

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

cardanome 4y ago

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 https://software-lab.de/doc64/README Haven't yet found any rationale on the LLVM rewrite.

freemint 4y ago
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.
- cardanome 4y ago
  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.