6 ms·

> The philosophy of Lisp encourages writing your own libraries because it's so easy to do. Having professionally worked in CL and Java, this is true and comple

> The philosophy of Lisp encourages writing your own libraries because it's so easy to do. Having professionally worked in CL and Java, this is true and completely misses the point. Of course you can write your own libraries, the question isn’t whether you can but whether or not that’s a wise usage of your time and energy. Java gives me a ton of fantastic libraries out of the box that let me focus on my domain, which is a good thing! > You're expected to know how to program if you use Lisp; not to depend on tiny prewritten functions in the npm universe that may or may not solve your problem, that may or may not be written in a secure or efficient fashion, and that possibly pull in a million transitive dependencies you don't need. Sneering at people who use different languages is both a bad look, and a bad way to convince people that you’re right. I’d recommend staying way clear of any suggestion that your peers don’t know how to program. > The most-used stuff that's not in Common Lisp itself like multithreading and sockets are well-covered by external libraries. The lesser-needed stuff is also quite well covered by the quicklisp library infrastructure [0] as well. This is a pretty drastic understatement of how far behind Java CL is. Forget multithreading, think more about metrics, logs, configuration, A/B testing, retries/bulkheads/circuit-breakers, feature flags, and secrets management. All of this stuff I get for free out of Java libraries, often in automatically self configuring ways. Configuring a Kafka reader in my app and seeing that it automatically discovered Micrometer on my class path and started emitting metrics is a lovely experience. Switching metrics servers from InfluxDB to Datadog with a single code change was damn near nirvana. If CL wants to be a compelling alternative to Java for industrial use, it’s got to catch up on all this stuff.

jhgb 5y ago
> Sneering at people who use different languages is both a bad look, and a bad way to convince people that you’re right. I'm pretty sure that this was a criticism of NPM rather than of any language. > Forget multithreading, think more about metrics, logs, configuration, A/B testing, retries/bulkheads/circuit-breakers, feature flags, and secrets management. I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language? Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions. > Configuring a Kafka reader in my app and seeing that it automatically discovered Micrometer on my class path and started emitting metrics is a lovely experience. Is this a thing that something like asdf-system-connections would solve in Lisp? (IMO also much more elegantly than by "discovering X on my class path".)
- ashtonkem 5y ago
  > I'm pretty sure that this was a criticism of NPM rather than of any language. > You’re expected to know how to program if you use lisp. Why would they say this if they weren’t implying that NPM users can’t program? > I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language? They don’t, not directly. But it’s the community for that language that makes and supports these things, and comparisons between these communities (and the libraries they share) is a fair area of analysis. > Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions. They could, but they have not to my knowledge. In my opinion the language’s capability is far less important than a community that values creating and maintaining these libraries. (I also think functional programming aficionados drastically underrate how much Java has changed. There are still issues I personally whine about, but they’ve fixed a lot of warts since the 1.6 days) Retries in particular are one of those things that seem obviously standalone, but are not. Having my retries automatically expose micrometer counters has been a godsend for monitoring. I’d like to see them automatically expose opentracing information too, which is an obvious area of opportunity for r4j. > Is this a thing that something like asdf-system-connections would solve in Lisp? The technical ability to make libraries auto-configure together is meaningless if the community doesn’t have the will to take regular advantage of it. Frankly, Java the language is incredibly weak for this kind of stuff, yet the Java community is busy doing it anyways. I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place.
  - jhgb 5y ago
    > Why would they say this if they weren’t implying that NPM users can’t program? I'm pretty sure that numerous Quicklisp users can't program either, but Quicklisp is manually curated while NPM (AFAIK?) isn't so their code won't end up in Quicklisp. > You tell me. I'm not sure what there is to say. The ASDF extension in question allows you to write systems that get loaded when a specific combination of other systems gets loaded, so when there's some room for collaboration of multiple systems, all such code naturally belongs into that autoloaded system. It can assume the presence of all required systems and hook them up together. Is this something like what you're describing? Except for the "discovered Micrometer on my class path" part of course since you're not concerning yourself with any paths here (that feels a bit brittle to me) but the notion of doing something special when combining specific multiple libraries is supported on system loading level.
dkarl 5y ago
> Of course you can write your own libraries, the question isn’t whether you can but whether or not that’s a wise usage of your time and energy. Java gives me a ton of fantastic libraries out of the box that let me focus on my domain, which is a good thing! This was a bug in the Common Lisp community in the early 2000s when I was getting started with it and looking to the community for help identifying libraries for common functionality. People were friendly and helpful, but they gently pushed me to accept that reaching for libraries was a habit I was bringing from other languages, and in Lisp I could (and should) write my own implementations for things like logging and date formatting. Sharing code was for big hard stuff, not easy stuff. Since then, it seems like a number of people have put a lot of work into moving the community forward from that romantic approach to a more pragmatic one, but if I wanted to use Lisp now, I would scrutinize that aspect of Common Lisp very closely before getting back into it. I would lean heavily towards Clojure instead.
- EdwardDiego 5y ago
  > I could (and should) write my own implementations for things like logging and date formatting. One of my biggest pet peeves when working with Go, is the multitude of logging libraries with disparate interfaces. That can't be configured easily (if at all) or at a desired level of granularity by the end user. One of the things the Java community got right is SLF4J for a standard interface.
  - ashtonkem 5y ago
    The Java community is going further in this direction, with the norm being empty jars to provide interfaces for libraries, with the implementation being brought by the application. Micrometer, opentracing, and Jax work this way.
    - oalae5niMiel7qu 5y ago
      I tried to install I-don't-remember-what Java app years ago. The logging didn't work at all. The docs went on and on about how it used this standard, pluggable logging interface and you can plug any logging implementation into it, but as for how to get it to actually log something somewhere (hopefully to syslog, but that's doubtful), nobody seemed interested in that. I rm -rf'd the app and never allowed anything written in Java into the project again.

jhgb 5y ago

> Sneering at people who use different languages is both a bad look, and a bad way to convince people that you’re right. I'm pretty sure that this was a criticism of NPM rather than of any language. > Forget multithreading, think more about metrics, logs, configuration, A/B testing, retries/bulkheads/circuit-breakers, feature flags, and secrets management. I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language? Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions. > Configuring a Kafka reader in my app and seeing that it automatically discovered Micrometer on my class path and started emitting metrics is a lovely experience. Is this a thing that something like asdf-system-connections would solve in Lisp? (IMO also much more elegantly than by "discovering X on my class path".)

ashtonkem 5y ago
> I'm pretty sure that this was a criticism of NPM rather than of any language. > You’re expected to know how to program if you use lisp. Why would they say this if they weren’t implying that NPM users can’t program? > I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language? They don’t, not directly. But it’s the community for that language that makes and supports these things, and comparisons between these communities (and the libraries they share) is a fair area of analysis. > Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions. They could, but they have not to my knowledge. In my opinion the language’s capability is far less important than a community that values creating and maintaining these libraries. (I also think functional programming aficionados drastically underrate how much Java has changed. There are still issues I personally whine about, but they’ve fixed a lot of warts since the 1.6 days) Retries in particular are one of those things that seem obviously standalone, but are not. Having my retries automatically expose micrometer counters has been a godsend for monitoring. I’d like to see them automatically expose opentracing information too, which is an obvious area of opportunity for r4j. > Is this a thing that something like asdf-system-connections would solve in Lisp? The technical ability to make libraries auto-configure together is meaningless if the community doesn’t have the will to take regular advantage of it. Frankly, Java the language is incredibly weak for this kind of stuff, yet the Java community is busy doing it anyways. I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place.
- jhgb 5y ago
  > Why would they say this if they weren’t implying that NPM users can’t program? I'm pretty sure that numerous Quicklisp users can't program either, but Quicklisp is manually curated while NPM (AFAIK?) isn't so their code won't end up in Quicklisp. > You tell me. I'm not sure what there is to say. The ASDF extension in question allows you to write systems that get loaded when a specific combination of other systems gets loaded, so when there's some room for collaboration of multiple systems, all such code naturally belongs into that autoloaded system. It can assume the presence of all required systems and hook them up together. Is this something like what you're describing? Except for the "discovered Micrometer on my class path" part of course since you're not concerning yourself with any paths here (that feels a bit brittle to me) but the notion of doing something special when combining specific multiple libraries is supported on system loading level.

dkarl 5y ago

> Of course you can write your own libraries, the question isn’t whether you can but whether or not that’s a wise usage of your time and energy. Java gives me a ton of fantastic libraries out of the box that let me focus on my domain, which is a good thing! This was a bug in the Common Lisp community in the early 2000s when I was getting started with it and looking to the community for help identifying libraries for common functionality. People were friendly and helpful, but they gently pushed me to accept that reaching for libraries was a habit I was bringing from other languages, and in Lisp I could (and should) write my own implementations for things like logging and date formatting. Sharing code was for big hard stuff, not easy stuff. Since then, it seems like a number of people have put a lot of work into moving the community forward from that romantic approach to a more pragmatic one, but if I wanted to use Lisp now, I would scrutinize that aspect of Common Lisp very closely before getting back into it. I would lean heavily towards Clojure instead.

EdwardDiego 5y ago
> I could (and should) write my own implementations for things like logging and date formatting. One of my biggest pet peeves when working with Go, is the multitude of logging libraries with disparate interfaces. That can't be configured easily (if at all) or at a desired level of granularity by the end user. One of the things the Java community got right is SLF4J for a standard interface.
- ashtonkem 5y ago
  The Java community is going further in this direction, with the norm being empty jars to provide interfaces for libraries, with the implementation being brought by the application. Micrometer, opentracing, and Jax work this way.
  - oalae5niMiel7qu 5y ago
    I tried to install I-don't-remember-what Java app years ago. The logging didn't work at all. The docs went on and on about how it used this standard, pluggable logging interface and you can plug any logging implementation into it, but as for how to get it to actually log something somewhere (hopefully to syslog, but that's doubtful), nobody seemed interested in that. I rm -rf'd the app and never allowed anything written in Java into the project again.