11 ms·

Clojure's machine learning ecosystem

135 points by kmclean 2y ago

kleiba 2y ago
I remember there used to be so much excitement about Clojure - it certainly was the "tech du jour" for a long while, also on the HN front page. It was the "...in Rust" of its day. But is it just me or has it gotten awfully quiet around Clojure? I mean, it is of course expected that no novelty can stay in the lime light forever. But what has become of all of the excitement? My impression is that Clojure failed to live up to the hype, but has found its niche - but it is a rather small niche. In the end, despite its attempts to differentiate itself from Lisp pitfalls, it has gone the way of all Lisps: it's this cool, intellectually stimulating language that in practice almost nobody uses. Is that view wrong? Please feel free to correct me, and sorry if this post is about Clojure in general and not specifically about its machine learning ecosystem.
- zelphirkalt 2y ago
  I think there is a lack of companies willing to hire for it, and also a lack of qualified people to hire. I would like to learn it and probably would like to work with it. Only downsides I see is reliance on JVM (which is also a strength) and not as good ways of recursion as other Lisps or Schemes (simply call the function, duh, because it just works and doesn't need extra keywords or syntax). But I liked the talks and that is seems to have the functional datastructured one needs, if one wants to avoid mutation.
- nextos 2y ago
  I would not say it is such a small niche. There are job openings here and there. It is much easier to find a Clojure job than a F# or a Haskell job in my experience. This may be of course different depending on your location. The problem is that an entire ecosystem is more than just a new language. Clojure has some really interesting libraries, but the rest relies on Java. It is a good ecosystem nonetheless. Julia is having the same issue. It has grown a very respectable ecosystem, but it is hard to grow further to catch up with Python in some fronts without massive corporate funding. It is interesting to note that, at some point circa 2010, it looked like Clojure could revive Lisp-Stat with Incanter. But, eventually, the project declined in popularity and died. Reaching mainstream relies on getting a critical mass of developers at the right time and for the right domain.
  - actionfromafar 2y ago
    And imagine if F# had an alternative native "runtime" (i.e. not married CLR and dotnet) grafted onto Fortran. Resistance is futile, indeed.
    - Capricorn2481 2y ago
      I don't even care about the runtime, imagine if F# devs made anything that wasn't on top of Asp.net. The small community coupled with breaking changes from Asp.net leads to a lot of issues, and the interop story of F#/C# and Clojure/Java is night and day I like Asp.net, but the thing I've run into several times in F# is there are breaking changes in libraries that the developers of F# can't keep up with. - Giraffe doesn't support swagger docs, you have to use Asp.net directly, because the swagger generation isn't compatible with the way Giraffe does routing - Microsoft Identity uses EF core by default. The EFcore.FSharp library doesn't support past .NET 6. You could use your own backend, but at this point, it's easier to just use C# interop You could use C# for the routing of your app and F# for the business logic. But then there's the C#/F# interop story. Lots of little finicky type differences you have to convert. Whereas using Java from Clojure feels easy and natural to me. And even if you use Asp.net directly and do interop correctly, you're basically using C# at that point. You're missing a lot of benefits of a functional language. It's not worth it in my opinion, even though F# is a wonderful language to me. It's tough to learn the ecosystem in Clojure. But once you do, I've found the "small libraries" approach much better than the whole ecosystem tying itself to one web framework it can't even keep up with.
      - throw868788 2y ago
        Its funny because I've found the opposite; the fact that the smaller community (and lets face it - most FP langs have a much smaller community than needed to get the scale you are after) the more it needs to piggy back on the army of engineers in the mainstream language target and stick to only its value add as a technology. There were web frameworks in F# that were written from scratch, but fundamentally ASP.NET is quite good and fast enough at least from my evaluations and these frameworks are now out of favor. I personally don't have much issues using ASP.NET directly from F# (don't bother with Giraffe or anything like that); its not too hard. The routing layer is only a few classes/functions anyway - it isn't the majority of your program. I guess maybe I'm in a different position to you - I find for the few bits of ASP.NET config it isn't worth switching to C#. A few rules you need to follow but I would say that is a lot less than the Clojure learning curve and you get static typing still - that is just my opinion however. My experience is that both languages have their pros/cons and tbh both have their challenges w.r.t adoption. My personal view is most of these challenges are not technical. The issues we complain about with the language as developers are IMO minor (i.e. things are still possible or decent compared to some other languages) and probably aren't the major factor in the wide scale technology choice away from FP in general. For better or worse developers are often "languages takers" not "language deciders" in most big shops and this is where most of the jobs are - its only in niche elements/problem spaces (i.e small shops, dedicated niche teams, etc) where niche technologies can be worth it. This means not a lot of jobs; but when there is a job it can be higher paying. Big employers drive the market for technologies though when it comes to large scale usage and they want commodity fungible developers (i.e. resources), and are happy using a mediocre tech that gets the job done to do it. Unless there is a "killer app" where the language must be used to unlock the value most managements will stay clear of better tech - predictable, boring, commodity tech that I can get anyone in for (contractor, offshore person, etc) wins for them every time especially for the MBA/product manager/etc types. In the current economic climate developers are trying to meet the jobs that are being advertised as well (higher interest rates, less startup's, etc etc).
- gorjusborg 2y ago
  I feel like Clojure did live up to the hype, but is different enough that there was little chance that it would dominate in the mainstream. The language ecosystem reflects the smaller numbers of contributors.
- synthc 2y ago
  I think the language has indeed reached a stable point and found its niche, which is small, but there are certainly domains where Clojure is the best fit. The ideas behind Clojure (functional, immutable datastructures, homoiconic syntax, focus on simplicity, JVM interop) still stand strong IMO. There are still some exciting projects done in Clojure: Electric Clojure and Rama come to mind.
  - yawn 2y ago
    > but there are certainly domains where Clojure is the best fit Honest question: what domains?
    - yayitswei 2y ago
      Financial services for one. Might be the Nubank influence.
    - dustingetz 2y ago
      clojure is everywhere in fintech - nubank, guaranteed rate, kroo bank, griffin, pennymac, two sigma, dividend finance, treasury prime, gravie. Other big areas are healthcare and midmarket adtech. And of course startups outside of SF/NYC with smaller seed rounds looking for tech advantage - midwest USA, Europe/UK, Latin america The further you get from silicon valley the more clojure you see — anyone with a network at FANG spent the last 10 years trying to break in and get that huge salary, which means conforming to the recruiting process, i.e. spending your time off grinding leetcode instead of learning new PLs
      - agumonkey 2y ago
        is clojure market still growing ? i'd love to work in a clojure shop one day
      - jimberlage 2y ago
        Speaking from past experience at Guaranteed Rate, management (probably not developers) regrets that experiment. They’ve laid off most of the clojure devs I know of there (I’m sure one or two remain for legacy services.)
- lgrapenthin 2y ago
  Clojure focuses on quality over hype, at great success. Its hypesters never really understood Clojure, and have long moved on. So will the hypesters of Rust and other hyped languages, unless they get a chance to ruin them.
- cess11 2y ago
  Aren't they having problems with new Java versions? Heard someone say something along those lines a while ago, or I misunderstood. It also seems Rich Hickey kind of stopped doing interesting talks, and some big bank bought into it and no one really likes banks.
  - yayitswei 2y ago
    Interesting is subjective, but Rich gave a talk at the most recent Clojure Conj.
    - cess11 2y ago
      I looked at ClojureTV and that's all I saw from recent years.
      - kmclean 2y ago
        There was a bit of a conference hiatus worldwide due to the pandemic, but the Clojure community (including Rich) is definitely still active.
  - lgrapenthin 2y ago
    None of this is true.
    - cess11 2y ago
      Sure, nothing is true, everything is permitted.
  - armed 2y ago
    It is not true, currently I'm maintaining a desktop app which is shipped to 3 different platforms and 3 architectures (x86, x86-64, arm64) and runs various versions of JRE (from jre8 to jre22). Most (90%) of the libraries are fully compatible, only some are using latest features such as virtual threads, but it is easy to avoid.
- lispisok 2y ago
  I think Clojure absolutely does live up to the hype but during Clojure's peak HN hype days all the people upvoting the posts and commenting in the threads never actually gave Clojure a proper try or a try at all. Rust on HN might be in a similar boat.
- deadghost 2y ago
  I've been using clojure as my main language for a decade. Few things can stay hyped that long. My last few jobs were in clojure so jobs do exist, moreso than in Common Lisp and Haskell at least (probably). There aren't very many companies that use it relative to the programming world at large, so I'd say you're right on that front. I'm happy using it and will continue using it. Sometimes I encounter interesting ideas and libraries that I end up using. At the end of the day, it's a programming language. You can write interesting things on uninteresting or even subjectively awful languages and boring things on interesting languages. Here's something I've been working on for the last two weeks: https://keyboards.justbuythisthing.com/ https://keyboards.justbuythisthing.com/. If I didn't tell you I wrote it in clojure, no one would know. It could very well be PHP.
BaculumMeumEst 2y ago
For web server stuff, I still think Clojure is extremely solid. But I’ve come to really prefer Racket for general purpose programming. I really like the package manager, I like that there’s an IDE with a visual step debugger (seriously, why do almost no lisp people value this?), that it’s multi paradigm, and that the language continues to improve and evolve. Clojure just has so many finicky or annoying things about it. The design of deps.edn/clojure CLI and the lack of user friendly tooling is forever frustrating. Laziness and its implications being invisibly core to the language is annoying as well.
- lgrapenthin 2y ago
  Most Clojure devs I know already have lots of experience and can debug faster in their head, with the occasional help of printing a value. But check out this cool Clojure debugger, it even has time travel https://www.flow-storm.org/ https://www.flow-storm.org/ We also have a debugger in Emacs/CIDER. Your other complaints read like you haven't dug really far, or they are outdated.
  - BaculumMeumEst 2y ago
    > The easiest way to run and learn FlowStorm with ClojureStorm is by running the repl tutorial, like this : ;; on Linux and OSX clj -Sforce -Sdeps '{:deps {} :aliases {:dev {:classpath-overrides {org.clojure/clojure nil} :extra-deps {com.github.flow-storm/clojure {:mvn/version "RELEASE"} com.github.flow-storm/flow-storm-dbg {:mvn/version "RELEASE"}} :jvm-opts ["-Dclojure.storm.instrumentEnable=true" "-Dclojure.storm.instrumentOnlyPrefixes=user"]}}}' -A:dev ;; on Windows clj -Sforce -Sdeps '{:deps {} :aliases {:dev {:classpath-overrides {org.clojure/clojure nil} :extra-deps {com.github.flow-storm/clojure {:mvn/version """RELEASE"""} com.github.flow-storm/flow-storm-dbg {:mvn/version """RELEASE"""}} :jvm-opts ["""-Dclojure.storm.instrumentEnable=true""" """-Dclojure.storm.instrumentOnlyPrefixes=user"""]}}}' -A:dev ———— I hate this so much
    - lgrapenthin 2y ago
      You can just copy paste this and replace RELEASE with the version number. If you want to dig deeper, the CLI and deps options used here are well documented under https://clojure.org/reference/deps_and_cli https://clojure.org/reference/deps_and_cli
j13n 2y ago
It’s great to see reports of the excellent work Daniel Slutsky and others are doing to make data science more straightforward for everyone. I'm grateful that I get to benefit from these community efforts.
- bmitc 2y ago
  Good luck getting academics to adopt anything they don't know about, and all they know about is Python.
  - sokoloff 2y ago
    Academics is much older than Python. At some point, they adopted that.
    - Y_Y 2y ago
      Academics (the mass noun, meaning something similar to "academia") does indeed learn and progress. Academics (the worker bees in the academic hive) can be super intransigent and in my experience learn a couple of tools in their younger days and never again. As they say, science advances one funeral at a time. I've found that new ideas and technologies are almost always brought in by new students, and not old academic dogs learning new technological tricks.
      - bmitc 2y ago
        > can be super intransigent I learned a new word today. And I agree, but the end might be a bit optimistic at how often or efficiently that happens. In my experience, most are all too willing to accept the institutionalized choices.
  - bachmeier 2y ago
    This is a strange comment that probably reflects the sliver of academics you're familiar with. Who do you think wrote and continues to develop R and all those packages? There are actually many types of software in use by academics.
Lyngbakr 2y ago
Something I really like in the Clojure data science stack that isn't mentioned is Clerk* — an interesting take on notebooks. I think it's a good gateway into Clojure for those coming from a Python or R background. *https://clerk.vision/ https://clerk.vision/
- kmclean 2y ago
  The literate programming story is great in Clojure. Clay (https://github.com/scicloj/clay https://github.com/scicloj/clay) is also a great option and supports rendering to quarto notebooks, which are IMO one of the best publishing options out there for technical books etc.
xedrac 2y ago
If Clojure compiled to native code by default, instead of relying on the JVM, it'd be much more attractive to me. I know many people don't care about this...
- giancarlostoro 2y ago
  You could probably achieve that via GraalVM I would think.
  - TheFreim 2y ago
    You definitely can. One example of a large project that does this is babashka, a fast native Clojure scripting runtime. https://babashka.org/ https://babashka.org/
  - kmclean 2y ago
    This is correct, you can compile Clojure to native code using GraalVM. There are many heavily used projects that do this.
  - pjmlp 2y ago
    And OpenJ9. Eventually ART, although here the process would be more convuluted. And if one is willing to give away a couple a big piles of money, PTC and Aicas are still in Java town.
esrh 2y ago
> Smile 3.x Avoided due to licensing > Smile 3.x is GPL-licensed, which poses some potential conflicts for some end users...The community consensus is converging around moving away from Smile due to the GPL-relicensing issue, focusing instead on Tribuo... (tribuo is developed by oracle) It's a really great thing that the java community has a high performance and well accepted (~5x stars than tribuo) ML package that's GPL. CF python where the top two libraries are developed by google and facebook. The GPL protects individual, independent developers. I don't think it's right to recommend that new users move away from the package because of licensing issues; the fact that it's GPL now is a good thing for everyone except corporate users (probably a great part of readers). The people who might have GPL problems already know themselves when they'll have a problem.
- kmclean 2y ago
  I don't disagree at all, but unfortunately it's mostly out of the hands of any community to recommend or enforce usage of a given library. There are many valid concerns around GPL licensing (not that I necessarily agree with them), but ultimately ignoring the requirement of many orgs to not use GPL-licensed code would just harm the ecosystem.
- zmmmmm 2y ago
  > I don't think it's right to recommend that new users move away from the package because of licensing issues I was going to chime in to agree but then I saw how this was done - a completely innocuous looking commit: https://github.com/haifengl/smile/commit/6f22097b233a343651900dece2c46ef217c41bd7 https://github.com/haifengl/smile/commit/6f22097b233a3436519... And literally no mention in the release notes: https://github.com/haifengl/smile/releases/tag/v3.0.0 https://github.com/haifengl/smile/releases/tag/v3.0.0 I think if you are going to change license, especially in a way that makes it less permissive, you need to be super open and clear about both the fact you are doing it and your reasons for that. This is done so silently as to look like it is intentionally trying to mislead and trick people. So maybe I wouldn't say to move away because of the specific license, but it's legitimate to avoid something when it's so clearly driven by a single entity and that entity acts in a way that isn't trustworthy.

135 points by kmclean 2y ago

I remember there used to be so much excitement about Clojure - it certainly was the "tech du jour" for a long while, also on the HN front page. It was the "...in Rust" of its day. But is it just me or has it gotten awfully quiet around Clojure? I mean, it is of course expected that no novelty can stay in the lime light forever. But what has become of all of the excitement? My impression is that Clojure failed to live up to the hype, but has found its niche - but it is a rather small niche. In the end, despite its attempts to differentiate itself from Lisp pitfalls, it has gone the way of all Lisps: it's this cool, intellectually stimulating language that in practice almost nobody uses. Is that view wrong? Please feel free to correct me, and sorry if this post is about Clojure in general and not specifically about its machine learning ecosystem.

zelphirkalt 2y ago
I think there is a lack of companies willing to hire for it, and also a lack of qualified people to hire. I would like to learn it and probably would like to work with it. Only downsides I see is reliance on JVM (which is also a strength) and not as good ways of recursion as other Lisps or Schemes (simply call the function, duh, because it just works and doesn't need extra keywords or syntax). But I liked the talks and that is seems to have the functional datastructured one needs, if one wants to avoid mutation.
nextos 2y ago
I would not say it is such a small niche. There are job openings here and there. It is much easier to find a Clojure job than a F# or a Haskell job in my experience. This may be of course different depending on your location. The problem is that an entire ecosystem is more than just a new language. Clojure has some really interesting libraries, but the rest relies on Java. It is a good ecosystem nonetheless. Julia is having the same issue. It has grown a very respectable ecosystem, but it is hard to grow further to catch up with Python in some fronts without massive corporate funding. It is interesting to note that, at some point circa 2010, it looked like Clojure could revive Lisp-Stat with Incanter. But, eventually, the project declined in popularity and died. Reaching mainstream relies on getting a critical mass of developers at the right time and for the right domain.
- actionfromafar 2y ago
  And imagine if F# had an alternative native "runtime" (i.e. not married CLR and dotnet) grafted onto Fortran. Resistance is futile, indeed.
  - Capricorn2481 2y ago
    I don't even care about the runtime, imagine if F# devs made anything that wasn't on top of Asp.net. The small community coupled with breaking changes from Asp.net leads to a lot of issues, and the interop story of F#/C# and Clojure/Java is night and day I like Asp.net, but the thing I've run into several times in F# is there are breaking changes in libraries that the developers of F# can't keep up with. - Giraffe doesn't support swagger docs, you have to use Asp.net directly, because the swagger generation isn't compatible with the way Giraffe does routing - Microsoft Identity uses EF core by default. The EFcore.FSharp library doesn't support past .NET 6. You could use your own backend, but at this point, it's easier to just use C# interop You could use C# for the routing of your app and F# for the business logic. But then there's the C#/F# interop story. Lots of little finicky type differences you have to convert. Whereas using Java from Clojure feels easy and natural to me. And even if you use Asp.net directly and do interop correctly, you're basically using C# at that point. You're missing a lot of benefits of a functional language. It's not worth it in my opinion, even though F# is a wonderful language to me. It's tough to learn the ecosystem in Clojure. But once you do, I've found the "small libraries" approach much better than the whole ecosystem tying itself to one web framework it can't even keep up with.
    - throw868788 2y ago
      Its funny because I've found the opposite; the fact that the smaller community (and lets face it - most FP langs have a much smaller community than needed to get the scale you are after) the more it needs to piggy back on the army of engineers in the mainstream language target and stick to only its value add as a technology. There were web frameworks in F# that were written from scratch, but fundamentally ASP.NET is quite good and fast enough at least from my evaluations and these frameworks are now out of favor. I personally don't have much issues using ASP.NET directly from F# (don't bother with Giraffe or anything like that); its not too hard. The routing layer is only a few classes/functions anyway - it isn't the majority of your program. I guess maybe I'm in a different position to you - I find for the few bits of ASP.NET config it isn't worth switching to C#. A few rules you need to follow but I would say that is a lot less than the Clojure learning curve and you get static typing still - that is just my opinion however. My experience is that both languages have their pros/cons and tbh both have their challenges w.r.t adoption. My personal view is most of these challenges are not technical. The issues we complain about with the language as developers are IMO minor (i.e. things are still possible or decent compared to some other languages) and probably aren't the major factor in the wide scale technology choice away from FP in general. For better or worse developers are often "languages takers" not "language deciders" in most big shops and this is where most of the jobs are - its only in niche elements/problem spaces (i.e small shops, dedicated niche teams, etc) where niche technologies can be worth it. This means not a lot of jobs; but when there is a job it can be higher paying. Big employers drive the market for technologies though when it comes to large scale usage and they want commodity fungible developers (i.e. resources), and are happy using a mediocre tech that gets the job done to do it. Unless there is a "killer app" where the language must be used to unlock the value most managements will stay clear of better tech - predictable, boring, commodity tech that I can get anyone in for (contractor, offshore person, etc) wins for them every time especially for the MBA/product manager/etc types. In the current economic climate developers are trying to meet the jobs that are being advertised as well (higher interest rates, less startup's, etc etc).
gorjusborg 2y ago
I feel like Clojure did live up to the hype, but is different enough that there was little chance that it would dominate in the mainstream. The language ecosystem reflects the smaller numbers of contributors.
synthc 2y ago
I think the language has indeed reached a stable point and found its niche, which is small, but there are certainly domains where Clojure is the best fit. The ideas behind Clojure (functional, immutable datastructures, homoiconic syntax, focus on simplicity, JVM interop) still stand strong IMO. There are still some exciting projects done in Clojure: Electric Clojure and Rama come to mind.
- yawn 2y ago
  > but there are certainly domains where Clojure is the best fit Honest question: what domains?
  - yayitswei 2y ago
    Financial services for one. Might be the Nubank influence.
  - dustingetz 2y ago
    clojure is everywhere in fintech - nubank, guaranteed rate, kroo bank, griffin, pennymac, two sigma, dividend finance, treasury prime, gravie. Other big areas are healthcare and midmarket adtech. And of course startups outside of SF/NYC with smaller seed rounds looking for tech advantage - midwest USA, Europe/UK, Latin america The further you get from silicon valley the more clojure you see — anyone with a network at FANG spent the last 10 years trying to break in and get that huge salary, which means conforming to the recruiting process, i.e. spending your time off grinding leetcode instead of learning new PLs
    - agumonkey 2y ago
      is clojure market still growing ? i'd love to work in a clojure shop one day
    - jimberlage 2y ago
      Speaking from past experience at Guaranteed Rate, management (probably not developers) regrets that experiment. They’ve laid off most of the clojure devs I know of there (I’m sure one or two remain for legacy services.)
lgrapenthin 2y ago
Clojure focuses on quality over hype, at great success. Its hypesters never really understood Clojure, and have long moved on. So will the hypesters of Rust and other hyped languages, unless they get a chance to ruin them.
cess11 2y ago
Aren't they having problems with new Java versions? Heard someone say something along those lines a while ago, or I misunderstood. It also seems Rich Hickey kind of stopped doing interesting talks, and some big bank bought into it and no one really likes banks.
- yayitswei 2y ago
  Interesting is subjective, but Rich gave a talk at the most recent Clojure Conj.
  - cess11 2y ago
    I looked at ClojureTV and that's all I saw from recent years.
    - kmclean 2y ago
      There was a bit of a conference hiatus worldwide due to the pandemic, but the Clojure community (including Rich) is definitely still active.
- lgrapenthin 2y ago
  None of this is true.
  - cess11 2y ago
    Sure, nothing is true, everything is permitted.
- armed 2y ago
  It is not true, currently I'm maintaining a desktop app which is shipped to 3 different platforms and 3 architectures (x86, x86-64, arm64) and runs various versions of JRE (from jre8 to jre22). Most (90%) of the libraries are fully compatible, only some are using latest features such as virtual threads, but it is easy to avoid.
lispisok 2y ago
I think Clojure absolutely does live up to the hype but during Clojure's peak HN hype days all the people upvoting the posts and commenting in the threads never actually gave Clojure a proper try or a try at all. Rust on HN might be in a similar boat.
deadghost 2y ago
I've been using clojure as my main language for a decade. Few things can stay hyped that long. My last few jobs were in clojure so jobs do exist, moreso than in Common Lisp and Haskell at least (probably). There aren't very many companies that use it relative to the programming world at large, so I'd say you're right on that front. I'm happy using it and will continue using it. Sometimes I encounter interesting ideas and libraries that I end up using. At the end of the day, it's a programming language. You can write interesting things on uninteresting or even subjectively awful languages and boring things on interesting languages. Here's something I've been working on for the last two weeks: https://keyboards.justbuythisthing.com/ https://keyboards.justbuythisthing.com/. If I didn't tell you I wrote it in clojure, no one would know. It could very well be PHP.

BaculumMeumEst 2y ago

For web server stuff, I still think Clojure is extremely solid. But I’ve come to really prefer Racket for general purpose programming. I really like the package manager, I like that there’s an IDE with a visual step debugger (seriously, why do almost no lisp people value this?), that it’s multi paradigm, and that the language continues to improve and evolve. Clojure just has so many finicky or annoying things about it. The design of deps.edn/clojure CLI and the lack of user friendly tooling is forever frustrating. Laziness and its implications being invisibly core to the language is annoying as well.

lgrapenthin 2y ago
Most Clojure devs I know already have lots of experience and can debug faster in their head, with the occasional help of printing a value. But check out this cool Clojure debugger, it even has time travel https://www.flow-storm.org/ https://www.flow-storm.org/ We also have a debugger in Emacs/CIDER. Your other complaints read like you haven't dug really far, or they are outdated.
- BaculumMeumEst 2y ago
  > The easiest way to run and learn FlowStorm with ClojureStorm is by running the repl tutorial, like this : ;; on Linux and OSX clj -Sforce -Sdeps '{:deps {} :aliases {:dev {:classpath-overrides {org.clojure/clojure nil} :extra-deps {com.github.flow-storm/clojure {:mvn/version "RELEASE"} com.github.flow-storm/flow-storm-dbg {:mvn/version "RELEASE"}} :jvm-opts ["-Dclojure.storm.instrumentEnable=true" "-Dclojure.storm.instrumentOnlyPrefixes=user"]}}}' -A:dev ;; on Windows clj -Sforce -Sdeps '{:deps {} :aliases {:dev {:classpath-overrides {org.clojure/clojure nil} :extra-deps {com.github.flow-storm/clojure {:mvn/version """RELEASE"""} com.github.flow-storm/flow-storm-dbg {:mvn/version """RELEASE"""}} :jvm-opts ["""-Dclojure.storm.instrumentEnable=true""" """-Dclojure.storm.instrumentOnlyPrefixes=user"""]}}}' -A:dev ———— I hate this so much
  - lgrapenthin 2y ago
    You can just copy paste this and replace RELEASE with the version number. If you want to dig deeper, the CLI and deps options used here are well documented under https://clojure.org/reference/deps_and_cli https://clojure.org/reference/deps_and_cli

j13n 2y ago

It’s great to see reports of the excellent work Daniel Slutsky and others are doing to make data science more straightforward for everyone. I'm grateful that I get to benefit from these community efforts.

bmitc 2y ago
Good luck getting academics to adopt anything they don't know about, and all they know about is Python.
- sokoloff 2y ago
  Academics is much older than Python. At some point, they adopted that.
  - Y_Y 2y ago
    Academics (the mass noun, meaning something similar to "academia") does indeed learn and progress. Academics (the worker bees in the academic hive) can be super intransigent and in my experience learn a couple of tools in their younger days and never again. As they say, science advances one funeral at a time. I've found that new ideas and technologies are almost always brought in by new students, and not old academic dogs learning new technological tricks.
    - bmitc 2y ago
      > can be super intransigent I learned a new word today. And I agree, but the end might be a bit optimistic at how often or efficiently that happens. In my experience, most are all too willing to accept the institutionalized choices.
- bachmeier 2y ago
  This is a strange comment that probably reflects the sliver of academics you're familiar with. Who do you think wrote and continues to develop R and all those packages? There are actually many types of software in use by academics.

Lyngbakr 2y ago

Something I really like in the Clojure data science stack that isn't mentioned is Clerk* — an interesting take on notebooks. I think it's a good gateway into Clojure for those coming from a Python or R background. *https://clerk.vision/ https://clerk.vision/

kmclean 2y ago
The literate programming story is great in Clojure. Clay (https://github.com/scicloj/clay https://github.com/scicloj/clay) is also a great option and supports rendering to quarto notebooks, which are IMO one of the best publishing options out there for technical books etc.

xedrac 2y ago

If Clojure compiled to native code by default, instead of relying on the JVM, it'd be much more attractive to me. I know many people don't care about this...

giancarlostoro 2y ago
You could probably achieve that via GraalVM I would think.
- TheFreim 2y ago
  You definitely can. One example of a large project that does this is babashka, a fast native Clojure scripting runtime. https://babashka.org/ https://babashka.org/
- kmclean 2y ago
  This is correct, you can compile Clojure to native code using GraalVM. There are many heavily used projects that do this.
- pjmlp 2y ago
  And OpenJ9. Eventually ART, although here the process would be more convuluted. And if one is willing to give away a couple a big piles of money, PTC and Aicas are still in Java town.

esrh 2y ago

> Smile 3.x Avoided due to licensing > Smile 3.x is GPL-licensed, which poses some potential conflicts for some end users...The community consensus is converging around moving away from Smile due to the GPL-relicensing issue, focusing instead on Tribuo... (tribuo is developed by oracle) It's a really great thing that the java community has a high performance and well accepted (~5x stars than tribuo) ML package that's GPL. CF python where the top two libraries are developed by google and facebook. The GPL protects individual, independent developers. I don't think it's right to recommend that new users move away from the package because of licensing issues; the fact that it's GPL now is a good thing for everyone except corporate users (probably a great part of readers). The people who might have GPL problems already know themselves when they'll have a problem.

kmclean 2y ago
I don't disagree at all, but unfortunately it's mostly out of the hands of any community to recommend or enforce usage of a given library. There are many valid concerns around GPL licensing (not that I necessarily agree with them), but ultimately ignoring the requirement of many orgs to not use GPL-licensed code would just harm the ecosystem.
zmmmmm 2y ago
> I don't think it's right to recommend that new users move away from the package because of licensing issues I was going to chime in to agree but then I saw how this was done - a completely innocuous looking commit: https://github.com/haifengl/smile/commit/6f22097b233a343651900dece2c46ef217c41bd7 https://github.com/haifengl/smile/commit/6f22097b233a3436519... And literally no mention in the release notes: https://github.com/haifengl/smile/releases/tag/v3.0.0 https://github.com/haifengl/smile/releases/tag/v3.0.0 I think if you are going to change license, especially in a way that makes it less permissive, you need to be super open and clear about both the fact you are doing it and your reasons for that. This is done so silently as to look like it is intentionally trying to mislead and trick people. So maybe I wouldn't say to move away because of the specific license, but it's legitimate to avoid something when it's so clearly driven by a single entity and that entity acts in a way that isn't trustworthy.