6 ms·

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

> 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.
- ashtonkem 5y ago
  > 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. This interpretation of GP’s comments strains credulity. As for the rest, I edited and expanded my unnecessarily glib response. The technical ability you mentioned is nice, but I will remain unimpressed until it sees wider use. This is a shortcoming in the CL community, not a shortcoming in the CL language. I’ll change my opinion once I see evidence of the CL community coming together to value shared, reusable code to accomplish common tasks.
  - jhgb 5y ago
    I guess I'm just a very credulous person, then. Regarding asdf-system-connections, it would probably help if this were core functionality of ASDF. I don't get why it isn't yet, since it perfectly fits Lisp's overarching concept of independently defined things cooperating (cf. classes and generic functions, or multimethods). I might want to ask some people about that.
    - ashtonkem 5y ago
      It might, but I doubt it will. “Roll your own libraries” is so core to the CL community’s self identity, that I doubt it will ever change within my lifetime. Honestly, if you want a modern Lisp experience, I’d recommend Clojure. Clojure doesn’t philosophically align with my own preferences, but that community is very active and very invested in solving common problems as a community.
      - jhgb 5y ago
        I find Clojure awful both conceptually and implementation-wise (the imposition of lowest common denominators by JVM dependency really sucks here, starting with lack of tail calls, but not ending there), so that's most likely not going to happen. I don't see why the good things in Clojure should be impossible to achieve in CL as libraries. You might argue that CL community should be working on those, and you'd be completely right.
Jach 5y ago
> I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place. How do you think those Java libraries got made? Java has also long had a culture of roll your own libraries -- and you had to, because the base language and standard library were quite deficient. (That's a snarky point, admittedly, but there are a lot of libraries in various languages that are just built-in functions in Lisp or Python or whatever, and there's a scale of effort there between built-in functions, built-in standard library, etc. that influences the pressure to make and share libraries. Like, I once wanted to get an approximate fraction, like Python's fractional's Fraction.limit_denominator, but in JS I had to bring in Google's Long.js and then steal a hundred lines of code from Python's implementation and elsewhere. There might be a library now.) Where Java won out was copying Perl et al. of having a centralized place anyone could upload open source, and then having armies of programmers forced to use it who inevitably end up making and sharing libraries and frameworks to make their lives better and eventually a desirable place to be for lots of things. J2EE and the JCP/JSRs were also masterclass social innovations to improve the ecosystem and take over enterprise and allow groups to agree on specifications if not implementations. Lisp's version of that is still absent. At best there's functionality that implementations add beyond the ANSI spec, and differences papered over with trivial-blah libraries, and occasionally some informal lobbying will get a feature implemented with the same protocol across each active implementation (package-local nicknames coming to mind as a recent one). Of course this situation isn't that different to a lot of other language ecosystems. CL got quicklisp, much too late, but it's here now and provides a baseline experience to beat if someone wanted to try like has happened in Java with ant/maven/ivy/gradle/etc. CL is then just missing hordes of programmers, and is unlikely to get them without either big company backing, many more small companies using it (this seems to be the way it's slowly been improving in popularity in the last several years), or an unexpectedly popular application domain (perhaps with accompanying hardware) where using it and its tools provides the clear best-in-class experience, or even the only experience, good or not, as is the case for many things involving other languages. The culture now seems to be "check quicklisp, if it's not there, roll your own, and share to quicklisp". Maybe some more effort needs to be made on "try to collaborate and improve if something is on quicklisp and not quite what you want but close" rather than making something brand new, but collaboration exists on quite a few projects, and Java has lots of overlapping libraries too, it's not that big a problem. If Lispers lost any of their "roll your own" enthusiasm, the logical endpoint when something's not in the quicklisp set is to give up and search for a library in another language. And if it doesn't exist there either? Your only option is to program it yourself or pay someone. It really seems like you just want CL to get the libraries and tooling you expect from the Java world, especially stuff mostly used by big companies with big deployments. And that's totally fair, Java's a great ecosystem despite annoyances with the language (which a big IDE helps paper over). I just think painting the lack of an equivalent ecosystem as a consequence of "roll your own libraries!" culture is mistaken.

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.

ashtonkem 5y ago
> 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. This interpretation of GP’s comments strains credulity. As for the rest, I edited and expanded my unnecessarily glib response. The technical ability you mentioned is nice, but I will remain unimpressed until it sees wider use. This is a shortcoming in the CL community, not a shortcoming in the CL language. I’ll change my opinion once I see evidence of the CL community coming together to value shared, reusable code to accomplish common tasks.
- jhgb 5y ago
  I guess I'm just a very credulous person, then. Regarding asdf-system-connections, it would probably help if this were core functionality of ASDF. I don't get why it isn't yet, since it perfectly fits Lisp's overarching concept of independently defined things cooperating (cf. classes and generic functions, or multimethods). I might want to ask some people about that.
  - ashtonkem 5y ago
    It might, but I doubt it will. “Roll your own libraries” is so core to the CL community’s self identity, that I doubt it will ever change within my lifetime. Honestly, if you want a modern Lisp experience, I’d recommend Clojure. Clojure doesn’t philosophically align with my own preferences, but that community is very active and very invested in solving common problems as a community.
    - jhgb 5y ago
      I find Clojure awful both conceptually and implementation-wise (the imposition of lowest common denominators by JVM dependency really sucks here, starting with lack of tail calls, but not ending there), so that's most likely not going to happen. I don't see why the good things in Clojure should be impossible to achieve in CL as libraries. You might argue that CL community should be working on those, and you'd be completely right.

Jach 5y ago

> I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place. How do you think those Java libraries got made? Java has also long had a culture of roll your own libraries -- and you had to, because the base language and standard library were quite deficient. (That's a snarky point, admittedly, but there are a lot of libraries in various languages that are just built-in functions in Lisp or Python or whatever, and there's a scale of effort there between built-in functions, built-in standard library, etc. that influences the pressure to make and share libraries. Like, I once wanted to get an approximate fraction, like Python's fractional's Fraction.limit_denominator, but in JS I had to bring in Google's Long.js and then steal a hundred lines of code from Python's implementation and elsewhere. There might be a library now.) Where Java won out was copying Perl et al. of having a centralized place anyone could upload open source, and then having armies of programmers forced to use it who inevitably end up making and sharing libraries and frameworks to make their lives better and eventually a desirable place to be for lots of things. J2EE and the JCP/JSRs were also masterclass social innovations to improve the ecosystem and take over enterprise and allow groups to agree on specifications if not implementations. Lisp's version of that is still absent. At best there's functionality that implementations add beyond the ANSI spec, and differences papered over with trivial-blah libraries, and occasionally some informal lobbying will get a feature implemented with the same protocol across each active implementation (package-local nicknames coming to mind as a recent one). Of course this situation isn't that different to a lot of other language ecosystems. CL got quicklisp, much too late, but it's here now and provides a baseline experience to beat if someone wanted to try like has happened in Java with ant/maven/ivy/gradle/etc. CL is then just missing hordes of programmers, and is unlikely to get them without either big company backing, many more small companies using it (this seems to be the way it's slowly been improving in popularity in the last several years), or an unexpectedly popular application domain (perhaps with accompanying hardware) where using it and its tools provides the clear best-in-class experience, or even the only experience, good or not, as is the case for many things involving other languages. The culture now seems to be "check quicklisp, if it's not there, roll your own, and share to quicklisp". Maybe some more effort needs to be made on "try to collaborate and improve if something is on quicklisp and not quite what you want but close" rather than making something brand new, but collaboration exists on quite a few projects, and Java has lots of overlapping libraries too, it's not that big a problem. If Lispers lost any of their "roll your own" enthusiasm, the logical endpoint when something's not in the quicklisp set is to give up and search for a library in another language. And if it doesn't exist there either? Your only option is to program it yourself or pay someone. It really seems like you just want CL to get the libraries and tooling you expect from the Java world, especially stuff mostly used by big companies with big deployments. And that's totally fair, Java's a great ecosystem despite annoyances with the language (which a big IDE helps paper over). I just think painting the lack of an equivalent ecosystem as a consequence of "roll your own libraries!" culture is mistaken.