This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (33)
- # asami (1)
- # aws (1)
- # babashka (19)
- # beginners (48)
- # bristol-clojurians (1)
- # calva (5)
- # cider (12)
- # cljdoc (15)
- # cljsrn (7)
- # clojure (151)
- # clojure-europe (19)
- # clojure-losangeles (1)
- # clojure-nl (2)
- # clojure-provo (4)
- # clojure-spec (9)
- # clojure-uk (21)
- # clojuredesign-podcast (28)
- # clojurescript (33)
- # core-typed (1)
- # cryogen (2)
- # css (6)
- # cursive (10)
- # data-science (1)
- # datomic (20)
- # events (3)
- # expound (72)
- # figwheel-main (5)
- # fulcro (43)
- # graalvm (6)
- # helix (1)
- # kaocha (13)
- # leiningen (2)
- # malli (1)
- # meander (93)
- # membrane (4)
- # off-topic (17)
- # pathom (6)
- # portland-or (5)
- # re-frame (25)
- # reagent (6)
- # reitit (7)
- # reveal (30)
- # shadow-cljs (25)
- # vim (2)
A Haskell dev was explaining the benefit of having the type errors such that the function and it's arguments were contained inside a structure as the bubbled up the stack.
I said "like this
(fn arg1 arg2)?"
It's easy to talk past each other to when your world's are inverted. The repl makes lisp manageable, someone without it is used to getting that feedback another way.
Better devs then me have managed to make clojure work without it though. That human brain is really flexible. we shouldn't mistake our differences as weaknesses (not implying anyone was here).
True true. When it comes of claiming one as superior to the other, its a hard sell, the data just isn't there, and even when there is data, its way too contextual. But when talking about trade-offs, I think things are more obvious. Well, at least to me. I find it hard to argue that Clojure does not improve productivity, or that it doesn't allow you to be more expressive, or that it doesn't speed up the feedback loop, etc. Where as I find it harder to argue that Clojure actually ends up having programs with more defects or runtime bugs, but you could claim that it makes certain type of bugs slightly slower to detect. Haskell/Java/etc will definitely fail faster for some type of bugs. And I can't deny that static types make it easier to know the types of things 😛, pretty self obvious. What do these sum up too? That one is crap and the other is the be all end all? Don't think so, there's a delicate balance, and clearly, you can have success with both. That's why for me, in the end, the only argument that trumps is how much enjoyment, pleasure, and fun you personally have with it, that's the deciding factor in the end. P.S.: Well actually, there's also the reach of your chosen eco-system, and for that Haskell loses hard for me, as on a lot of projects, it just doesn't match up to what I'd need to have available. But I'm ignoring this one, since you could use Java, or Kotlin or Scala on JVM if need be as well.
Frege and Eta both attempt to address Haskell-on-the-JVM (and Haskell has an official JS story via
ghcjs, plus you have near-Haskell via PureScript). For a while I was doing quite a bit of hobby work with Frege and I created both a Leiningen plugin for it, and a Leiningen template for mixed Clojure/Frege projects.
Eta hasn't been updated for nearly two years but it was very active -- but Frege predates Eta by five years and Frege is still being worked on (somewhat sporadically). The Eta team were pretty disparaging about Frege but it has outlived them (and received three "emerging language" JVM awards) I think I'll update the Leiningen plugin and template to work with the latest Frege version and then I'll make a Clojure CLI compatible tool for compilation and integration.
@U04V70XH6 re: Frege - a template would be awesome. I'm interested to know more about your experience with the language. Did you find scenarios where it excels? Have you enjoyed it? How rich is the language ecosystem? I mean "native" Frege libs vs having to go with Java interoperability. I'd love to hear more about it.
There's always typed Clojure, although I don't know what its status is at the moment, besides under active development after a hiatus
@UHQ12T97F https://github.com/Frege/frege-lein-plugin -- shows how to use the template as well as how to compile and run standalone Frege or mixed Clojure/Frege code. It uses an older, prerelease build of Frege. I'm going to update it this week I think, to run with Frege 3.24.405 and also make it work with the Clojure CLI (that's more work because, right now, the plugin does quite a bit of work to identify what source files need to be compiled etc -- also Leiningen lets you run multiple tasks which the CLI does not). The Frege language site is your best bet for up-to-date information about the ecosystem as it's been five years since I last worked with it. My interest was mostly academic, as a way to continue to learn Haskell but stay within the JVM ecosystem.
@UK0810AQ2 We've tried to use Typed Clojure at work a couple of times but gave up each time. We actually went back and forth between Schema (Prismatic new Plumatic) and Typed Clojure several times, before abandoning both efforts. Both Schema and Typed Clojure make the code much uglier (IMO) and Schema wasn't catching any bugs that our tests didn't already catch (it's runtime checking, after all) and Typed Clojure was really hard to use effectively because it had very little in the way of type inference -- which meant you needed to explicitly annotate everything in a namespace to shut it up -- and sometimes we had to refactor idiomatic Clojure to less idiomatic code, in order to be able to annotate parts such that Typed Clojure would accept it. I think we got maybe 5% of our codebase annotated and tested with Typed Clojure before we gave up.
That said, Typed Clojure did find a couple of bugs that neither our test suite (nor Schema) had picked up -- but they were mostly edge cases that would never have been triggered in production because the actual data never contained the values that would expose the bug (which was mostly why neither our test suite nor Schema had identified them).
Interesting. How long ago was that? I know its maintainer is back working on it, maybe things improved significantly since then, but I have no personal experience with it
It has improved since we last tried it (a while back) and I talked a lot with Ambrose about the issues we had at the time. He's worked quite a bit on type inference and he's done quite a bit of research on working with codebases that have some portions typed and some portions untyped (based on the work the Typed Racket team have been doing). I get the impression that Typed Clojure is currently back in "research project" mode as opposed to being ready for "production use". This stuff is hard. Back in the early/mid-'80s type inference was part of my PhD work on functional language design and implementation so I have huge appreciation for what Ambrose is doing.
(I was writing Prolog programs to perform type inference on experimental FP language features that I was exploring but a good portion of my research work was around GC algorithms)
Reminds me of a variation on Greenspun's Tenth Rule. "Any sufficiently complicated type system contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Prolog" I just watched https://www.youtube.com/watch?v=XTl7Jn_kmio the other day. It's nice to know things are progressing. Albeit slowly. I hope he'll crack that nut eventually
@U04V70XH6 What would you say of Java, C++ and C#'s type systems? Would you consider those similarly making "code much uglier" and "really hard to use effectively because it had very little in the way of type inference" ? I'm just trying to see what your opinion of Typed Clojure is in comparison to those type systems (versus say against ML like type systems)
Java's type system, definitely -- it is so verbose. I have no experience with C# (but I suspect I'd lump it in with Java). As for C++, it has so much "weird syntax" that its type system -- such as it is -- hardly makes it worse (and remember: I was on the ANSI C++ Standards Committee for eight years! 🙂 ).
Haha, ok. So Typed Clojure is in the same ballpark as Java's type system then? That's good. Cause there's a lot of people who consider that to be totally fine, but I know in FP realms, it seems so archaic haha. Just wanted to gauge if Typed Clojure was even more verbose and requiring more annotation than Java here, or along the same lines.
I'm not sure I'd really put Typed Clojure and Java's type system in the same universe, let alone ballpark, but they both make code harder to read for me. Java's type system rarely requires you to refactor your code to satisfy it -- and they have added a degree of type inference in the last couple of releases. If Typed Clojure's type inference continues to improve, it could become substantially better than what Java offers 🙂 We have a subsystem at work that I would like to have a type system applied to: I recently spent a whole week adding Spec to that subsystem because I needed to make some changes to it and it wasn't code I wrote and I hadn't really looked at it much before (and the original developer moved on a couple of years ago) -- and it had some fairly gnarly data structures. Spec was great for helping me understand the various paths through the code -- much like how Stu Halloway has talked about using Spec to learn how an unfamiliar codebase works -- and I feel much more comfortable working on that code now (despite the Specs being fairly gnarly).
@U0K064KQV Definitely try it out. It's an interesting contrast to "regular" Clojure. Let us know what you think. #core-typed exists here (but I've no idea how active it is).
Ya, I like to check up on the progress, and know about it from reading, but never tried it out. I think a lot of the issues are the ergonomics of it, and the boundary between typed and untyped it seems.
Also, that Clojure seem to allow for code that even the most advanced known type research has yet to figure out how to implement a type checker for.
I am going to try GraalVM with native images for docker… just to see how easy it is… Anyone working with it yet?
There's a few gotchas, and mostly it doesn't support all code that can run on the JVM, so part of it is avoiding using things it can't compile.
one gotcha is making sure you don't have SSL providers compiled on the heap when building the image (so if you're using httpkit make sure to use version 2.4.0 or greater, for example)
so basically try to use the latest version of SSL like we are supposed to be doing anyway? since the hack on Heart Bleed
Not related to SSL version. You might end up with an error like "No instances are allowed in the image heap for a class that is initialized or reinitialized at image runtime: http://javax.net.ssl.SSLContext", which means it was initialized at compile time and not at run time. It's no an issue for java but it is when building an image with native-image. This issue was fixed in httpkit version 2.4. I don't think other libraries had this issue.