Hacker News new | ask | show | jobs
by rakpol 3660 days ago
Hoping for a little advice: I'm trying to push for some development culture changes at work, one of which is doing more local, incremental refactors rather than large, all-at-once changes (i.e. the sort of thing for which one books 'architecture meetings'). Since we'll hopefully be massaging large parts of the codebase, there's an opportunity to jump into something new with both feet.

Question: what do you think of the thesis of pure4j [1] vis. frege [2]? Namely, are the advantages gained by switching to a haskell-like language far above those attained by simply forcing effects into a small part of the codebase?

[1]: https://github.com/pure4j/pure4j

[2]: https://github.com/Frege/frege

4 comments

Scala is an obvious option as well. I haven't used Scala but it's surely more palatable to Haskellers than plain Java.

Also. There is work underway to enable GHC to compile for the JVM.

To expand on this suggestion: Scala isn't big on purity (AFAIK the language has no concept of pure functions out of the box) but it is big on immutable data types, and mostly-pure functions arise naturally when you're working with immutable types.

Immutable types happen to be something that is familiar and comfortable to Java developers. I would therefore expect to meet a lot less resistance to "syntactic sugar and immutable classes" than "functional programming with pure functions" even if the end result is 80 percent the same.

This was the compromise our team made. Our team was having a bad time dealing with Spring. Our lead dev is a functional buff who really likes Haskell, and got us all hype about trying something new. We picked scala in lieu of Haskell because the learning curve with Haskell was a much harder sell. We avoid mutable data types unless there's a compelling reason (interop with Java libraries, for example), and most of our functions are implicitly pure. ScalaZ might have some purity constraint, idk.

5 months in with Scala and it has been a wonderful experience. Now I just have to convince our front end dev to switch over to Scala.js...

We tried the same thing, but it did not go well at all. We picked scala because people should be able to learn it easier and more gradually. But we found as people learned FP using scala, they realized how much scala held them back. We ended up redoing a PHP project in scala, then as it was 80% done redoing it again in haskell. And then from there out using haskell for everything.
Do you have any specific examples of how scala would hold y'all back in relation to haskell? I actually have trouble imagining how one could justify, in a business, scrapping an 80% complete rewrite to rewrite it again in a different language. I wonder what would be so compelling.
Scala is an OO language with FP tacked on, so it basically defaults to "make everything a pain". It was easy to justify rewriting it again because it only took two weeks to do it. A re-write is much faster than initially writing it, you're just copying yourself.
Scala is a mess of a language, with pretty much any language feature ever invented under the sun.

If you want real and well designed FP, pick Haskell.

If you want a pragmatic JVM language that doesn't make your eyes bleed like Java does, pick Kotlin.

On the latter front that jvm work is a summer of code student. So on one hand it's definitely exciting work, there's definitely a bit of work between that .. Working and it being a tier one backend for ghc.

I've been haskellin at a large Megacorp environment for the past 1.5 years, with lots of smaller freelance before that.

There's a lot of different value props one can make for different tools. One pragmatic case I make is that in Haskell land it's super easy and rewarding to to engage with upstream to resolve any problems I hit. One other angle that the imvu article and I think a lot of the comments over look is that using Haskell as a shared concrete specification / engineering design substrate for communicating actually makes it much much easier to collab with colleagues on pretty crazy projects. Even if the deployed system isn't ultimately written in Haskell.

That said, with the right colleagues, having the freedom / trust to choose tools that help you best deliver is always the ideal. :)

Personally, I think you'll have more success with something more gradual than a complete syntactic overhaul. I've never used pure4j or frege but it sounds like pure4j is something you could try out incrementally, which could be quite immediately useful for your team.

Best of luck!

The idea behind both would be to introduce it incrementally, carving out parts of the codebase to be rewritten one section at a time.

You're right, though; pure4j offers an immediate and easily obtainable win, so it'd definitely be an easier pill to swallow. Thanks :)

I can't speak for pure4j, but I would be very wary about suggesting Frege at my workplace to (what I'm assuming are) Java programmers.

I feel like some Java programmers would have almost as much culture shock with something like Haskell as some of the php programmers at IMVU apparently did.

Fair point, but it might almost be worth it just to suggest it just to see what the opposition is like -- if there isn't much, or any, go with Frege; otherwise, fall back to pure4j. I'd imagine framing the decision as picking from two choices would improve the odds of at least one being selected.
You may want to consider http://www.ocamljava.org/ instead of Frege.
That definitely made the short list! I picked up ocaml for a side project and enjoyed the language quite a bit. However, ocamljava is either dead or dormant at this point (last commit to master in June of last year) and it seemed to only have had one major contributor -- it would seem irresponsible to adopt such a solution in light of that.
In that case, it's almost as irresponsible to adopt Frege... It's not like it's got any real traction, either.
Aah, fair point, it is pretty niche. Still, merely going off of their comparative contribution graphs [1] [2] and issue trackers [3] [4], it seems like Frege has a fair bit more throughput: for better or for worse, it seems like more _things_ are happening. Although I'll be the first to admit it's a misleading metric for determining the maturity of a project, it's still something. Imagine finding a bug in Frege: it seems like they merge even small patches from contributors, whereas ocamljava is essentially a one man show. Adopting ocamljava would probably mean forking and maintaining it too, whereas there's a possibility of just contributing to Frege.

That's all just my opinion, of course, and I hardly have enough industry experience to back up its validity! 'Just sanity checking my reasoning :)

[1]: https://github.com/Frege/frege/graphs/contributors

[2]: https://github.com/xclerc/ocamljava/graphs/contributors

[3]: https://github.com/Frege/frege/issues

[4]: https://github.com/xclerc/ocamljava/issues

Did you consider Scala? I think it has great support for the kinds of changes you're pushing for.
Yes, but I have ... reservations. Same as with OCaml, I took on a small project with Scala and enjoyed the language, but only after carving out a subset of it that was palatable. Although it fits the bill, I'd be worried that enforcing conventions would become a large burden.

Unlike Frege where I (might? Frege's the only language of the three that I haven't investigated thoroughly) can point learners to essentially any Haskell tutorial and have them vaguely do 'the right thing', there exists a subset of Scala developers who use the language like Java with type inference. With Frege I could, for example, merely enforce the minimal usage of IO or State, but doing so with Scala is more complicated (maybe force the usage of cats/scalaz and their equivalent monads? It's still very easy to not use them, however). If there were an equivalent to F# on the JVM I'd settle on it in a heartbeat, but the dearth of well supported, pure functional languages makes this a tough choice. All in all, I'll probably go with pure4j, but it would be nice to stop writing Java at some point in my career.