Clojurians Log v2
architecture
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).
@seancorfield 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
@jivagoalves 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.
@ben.sless 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
@seancorfield 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).
Interesting. I really ought to try it I guess to get a good sense of it. I just wonder, one could argue Java does require you to refactor code to satisfy its compiler, its just that since it does so from your first line of code to the last, you'll simply never write the code that doesn't satisfy the compiler in the first place. If I take TypeScript for example, it presents itself as a new programming language, not simply an optional type system over JavaScript. In doing so, people understand that you can start a green field project on it, or you need to perform a migration of your current system to it, and as any migration, could involve some refactoring. Typed Clojure though never presented itself as such. So I can understand the different outcome. People thought, ok let me use it to sprinkle some types in my Clojure code, and doing so you hit its limitations and consider it "too painful". But what if you said, Typed Clojure is a new dialect of Clojure. So if I create a new app in Typed Clojure, its now a Typed Clojure app, not a Clojure one. You wouldn't feel the need to "refactor", it be just like Java, in Typed Clojure, some idioms are not allowed and others are favored, in order to satisfy the type checker. And now just like TypeScript, you could say, this new language Typed Clojure has great interop with existing Clojure code. Anyways, all hypothetical, but I feel your mindset as you approach these things can make a difference. If TypedClojure came with its own build tool chain, own IDE, own library eco-system and repositories, etc. And Clojure dependencies were treated more like interop, akin to Java's. I feel that could have succeeded in a whole different way.
@didibus 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).
Oh, you're already a member of that channel...
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.
Also, might have felt I was bashing OO encapsulation a bit, I'm not. Just trying to show the trade-offs of some of the alternatives Clojure has actually have pros/cons. I don't feel its clear that one is always better than the other.
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.
Interesting, I thought ETA was abandoned. Never heard of Frege
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.
I am going to try GraalVM with native images for docker… just to see how easy it is… Anyone working with it yet?
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.
I want to setup Clojure and try some other JVM compatible langs
There's a #graalvm channel and @borkdude should be in there. He's done a lot of work with GraalVM.