4 ms·

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.

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.