Nice one.

“Show it, don’t tell it” in itself can go a long way towards convincing people. If you line up a Java example with a Clojure example and a Haskell example and just make note of the different things that the languages focus on, this should in itself be quite convincing.

Obviously, you have to be ready for people immediately going “omg no static type checking wtf is this shit”, but that’s a good way to segway into talking about data-oriented design and interactive programming IMO. Trade-offs and all.

I‘m not sure I want to convince people per se. There were a lot of talks and articles in the gist of „Java can do FP now“, and I want to set a soft counterpoint. The obvious lever against FP in Java is that there are almost no immutable data structures, and that the default collections have to use the very verbose stream API

And I will include Haskell to hedge against the „OMG no static type checking“ crowd

The suggestion to put data oriented programming at the center is a good one. Most Java devs will immediately say „but that‘s not idiomatic“, and they would be right

I’ve been out of Java for so long that I’m actually curious as to how “bad” it would be to transition back, given free hands to do FP as much as possible in Java.

I have to work with Java quite a lot, and I don’t think the language is bad. I think the common design patterns with the big two Frameworks are bad, but that’s a whole different rant

That’s the thing, right. Maybe you could be fine if you were working on your own, outside of the context of other people’s world views and Frameworks and whatnot, but if that was the case, would you not also be free to choose something other than Java? idk what the zeitgeist is in the Java world currently, maybe people are generally reasonable to work with 😄

Yup, you can do a lot of FP in Java these days using basic data structures. Java 8 and 9 brought a lot of helpful stuff. But navigating existing Java code is a maze of complex class hierarchies…

There are some libraries in the Java world I enjoy very much, because they are not frameworks and you can just compose your applications, a little how we are used to in Clojure. vert.x and jOOQ come to mind, and both really use the type system in clever ways.

i barely touch java these days, except for interop, but i was reading the vert.x source a little while back and thinking it was really nice, despite being java

I think the Java team is trying to make Data Oriented Programming more idiomatic with things like immutable records

So you can make the point that the core Java team is setting up a beacon signaling the world that the right way is functional and data oriented

That’s also the impression I get from the Brian Goetz interviews, talking a lot about algebraic data types. On the other hand, most idiomatic Java usecases will need proper classes instead of records, so you have records as some kind of second-class citizen in the codebase, and a lot of language features you can only use with them.

That’s what’s nice about a thoughtfully designed language like Clojure. It’s opinionated from the get-go, making it easier to find “the right way” to do things. Java might have been thoughtfully designed from the beginning, but is now accreting features, making it overall more complex and directionless. Javascript also suffers from similar feature accretion. idk know much of a problem that is in the real world, though. I only do JS for solo hobby stuff, and there, I mostly get to choose what features to use myself 🙂 (ie I generally avoid objects as anything other than data containers)

Maybe that‘s why the Java frameworks are so very opinionated, because the language isn‘t

Interesting angle!

An aside; I think one of the things I enjoy most about immutable data structures is how simple it makes =. I skate through comparisons in Clojure multiple times a day where I in Javascript have to think much more about how to compare.

maybe not “convincing people”, but rather more like a retrospective and “aspirational” talk? In an ideal case, the Java folks would already know that FP in a specialized FP language is better than (backported?) FP in an OOP language, and they’d accept that as a tradeoff for continuing to work inside Java and not be offended. After all, work is work and it is not a “whose language is better” contest.

Instead of framing it either as an overhyped “See? Now we can do all those cool FP stuff too, we no longer need to switch” or as a prickly “No matter how hard you try, you’re just never gonna catch up”, perhaps a middle road can be attained. “Thanks to diffusion of innovation and exchange of idea, now some FPs are finally getting accepted in Java too. Now due to some of the underlying fundamentals of Java the language, it might be difficult to go all the way. But changing mindset and adopting certain idioms/patterns can help you extract more benefit from the FP features that are currently in Java…”

I guess all I want to say is “a certain empathetic mutual understanding would go a long way”. 😅

Another way is to just take the "saying mean things about java" to an absurd degree which will be clear to all listeners you're joking (they should laugh) Sort of like the Linux Sucks talks

Oh, I plan to be empathetic, @U6L5FFL95 . There is an audience of people eager to learn about FP, I don‘t want to discourage them by telling them it‘s no use in their preferred language. I guess I will create a nice example, once done in the OOP way, once done functional

@UK0810AQ2 nice idea, done something similar in the past (antipattern talks), but I don‘t want to take the risk. In oop-land, there is the cliche of the elitist-FP people, don‘t really want to play with that, even in jest

On the contrary, it gives you a trope to play into, with the conclusion being "Java isn't that bad after all"

you get your very own redemption arc 🙂

just don't mention the m word 😬

@U0524B4UW ooooh that might be a good joke, too. „First, let‘s start with the basics of FP. A monad is just a monoid in the category of endofunctors…“

and then you pull out a very worn out, yellow cover, Springer GTM “Category for the Working Mathematician”

on an unrelated note, over here the yellow color also contains a connotation of illicit materials

ooo where are you @U6L5FFL95 - I'm not familiar with UTC+8

oh I’m in Hong Kong

(bonus point for remembering the exact page number in the book for that phrase… or having a bookmark)

what are the new FP features in java @U0N9SJHCH?

They now have immutable data types with records and sealed classes which you can use to create algebraic data types. Also, on records you can now do simple destructuring and pattern matching

(Pattern matching in switch statements and instanceof, so far)

so immutable lists, maps, sets &c ?

Yyyyyno. That’s one of the issues. There is an ImmutableList, but it implements List, and so it still has the put or remove methods, they just throw a runtime exception if you call them. Super weird choice 😐

If you convert the lists into Streams, these are immutable and can only be processed once. On those you can call map, filter, reduce, apply, collect… but the API is quite verbose

I remember when a bunch of stuff got added to Java 8, I wrote a blog post about how it made Java less awful from my p.o.v. (I'd pretty much stopped using Java when 5 came out). It certainly is nice to see these FP-ish things getting added and I can almost imagine doing some completely green field project in "modern Java now"... but how often do you get to do that I wonder?

that seems distinctly mixed @U0N9SJHCH

I looked at a Java codebase recently that was parsing files. It read them in as strings, mapped them into types - in a hierarchy - and emitted them as JSON. They only two "real" types in the input were Date and Interval. Point is that Java sometimes is a hammer and not all file content is a nail. They're mostly strings. And they are hard to hammer into the wall. OK I'm taking this too far now

And this was a modern Java codebase - and it was proposed to be rewritten in Clojure because it was too complex for the goal.

@U0524B4UW It’s a bunch, but there is a plan behind it. That article explains it way better than I can https://www.infoq.com/articles/data-oriented-programming-java/

It’s interesting, that they relate “data oriented programming” with “smaller programs”

@U04V5V0V4 Creating class hierarchies for everything it touches is quite common. There are well-designed libraries to read and write JSON from and into dynamic data structures like JSON-P (https://javaee.github.io/jsonp/), but most Java devs I know would think if it as “too dynamic” and “lacking type safety”

indeed

make every slide a variation on [ data in ... functions ... data out ] with functions in Java | Clojure | Haskell 🙂

it's the most common use case on the server

That’s a good plan, I think. Most backend developers today seem to write HTTP services, anyway, that should be relatable

the only thing is that there needs to be an establishing shot of what is around the functions in Java and that's simply not present in Clojure or Haskell where functions rule

it's not snark to show the extras needed even if it's elided in general

One could make the Java methods static, in this case the enclosing class almost acts as a kind of namespace, containing only static methods

yes - I was always a big fan of that

it's not idiomatic but it's a generous approach to show how minimal the boilerplate can be trimmed down to

that infoq article made me think: "the OO related stockholm syndrome is strong"

Another thought which might help is to contrast the interactive development options

I’ve never used the Java shell but I’m aware of its existence

I don’t know enough about Haskell tooling to compare the situation

So it’s a thought with very little content 😂

But maybe it will trigger something useful for you

OTOH Java debugging in ie IntelliJ is pretty good, I think. I haven’t seen something similar in Clojure. I guess some would argue that it’s not needed 🙂 I certainly don’t feel I’m missing it, but perhaps it’d speed up some debugging that currently takes place in my meat compiler.

intellij java debugging is great (it's been a while, but even way back when i remember it being good) - but clojure's excellent literal data (so trivial print -> parse) gets rid of most of the need for GUI object inspectors, making REPL debugging practical, and while i have occasionally wanted to reach for breakpoints, it's been very rare for me to want them enough to go and look up how to configure clojure breakpoints (vs adding a log or catch and log to the codebase) ... so i'm agreeing with @U04V5V0V4 that there is something special in the clojure REPL

Interactive development is also a good idea, but I only have 40 minutes. Held a “Clojure and the REPL” interactive talk at the same conference last year, and it barely fit into this timeslot. Also, JSHell is just not good. You can’t even redefine classes dynamically 😞

@U0524B4UW Just to add to that… I find that debuggers only really make sense when your program is dependent on building a universe of stateful objects before it can do anything, i.e. it has strong coupling. I don’t see the point to using debuggers when you can isolate the problem to a single, stateless function.

sometimes it gets more complex but yeah

Suggestion: Emphasize heavily the advantage of building on foundations you know. You're going to speak to functional curious people. The "you can do this in Java" part is going to be directly useful to them for about zero cost. Leaping into a new language is more risky!

Unless the conference is over now? If yes, how did it go?

Sorry for digging out this ancient thread, but: