If there’s a culture problem it’s the “Look at me. I learned something new and now I’m going to do my best to burn down everyone else”. If you want to program in Haskell or whatever have a great time. Think it’s so great? Prove it by writing great software with it.
"It is my belief that the best direction for evolving Java is to encourage a more functional style of programming. ... We're not going to turn Java into Haskell, nor even into Scala. But the direction is clear."
https://mail.openjdk.org/pipermail/lambda-dev/2011-August/00...
Surely there are terrible examples for unmaintainable software monsters in every language, Java not being exempt. But based on the only relevant, existing evidence on the topic: empirical evidence, Java is probably one of the, if not the best at the software maintainability game.
Clean FP in and of itself doesn’t solve the problem, so it’s not like there is a clear cut answer to the question. I do agree that incorporating more and more immutable elements to java is a worthwhile goal to pursue, but at the same time I also believe that on a local, single-threaded scope mutability can increase understanding, so neither imperative nor pure functional is an answer to every problem in themselves.
We should strive to make both toolkits available and be ready to use the correct one for each case, the pragmatic approach.
Thing is, if I look at most places hiring Java devs, they are prominently places that care a lot about security. Wouldn't it be a self-fulfilling prophecy then, that Java culture cares more about security and tries to maintain higher standards? Especially considering Java was dominant for decades in places willing to pay big for security.
I just don't see why that would also mean it's directly atrributable to the language itself to the point it is 'the most'. C# exists too, it's not that different.
The burden of proof rests on everyone making an argument. There isn’t a privileged stance between Java is ok/awesome/terrible. I think popularity demonstrates it’s not a terrible language like say Brainfuck, but it says little about individual aspects. Individual weaknesses in some aspect could be made up by a strong showing in other areas and being popular alone provides some real advantages.
Every online banking system I've encountered (4+) was built in Java. None of them have been breached.
Please cite a counter reference
Banking software is generally riddled with security issues, if you assume something is secure without having it tested by a 3rd party chances are it’s got issues.
Are there any languages for which this isn't the case? Of those, are any of them in relatively common use for production environments?
The original Java memory model was broken and got fixed. It took C/C++ another 10 years to do the same.
People use Java for server back-ends because it is possible (and not unreasonably difficult) to write correct and high-performance concurrent code with threads.
If the language improves, then frameworks and API can be made less verbose.
A lot of "design patterns" in Java were created simply because of the language lacking expressiveness and are thus obsolete now.
I code a lot of Python also, and I've been pleased to see pattern matching adding to Python by a process that seemed very similar to that in Java, that is, in both cases the feature was developed gradually with a lot of care to make sure it works well with the rest of the language.
Java just made those insane architectures possible due to not segfaulting at every turn, hence it also got associated with them. And indeed, many are “deprecated” by all the “new” features, including generics which is not exactly new.
I imagine it's not that widespread because most people probably switch to a different JVM language like Scala rather than going all in on functional Java. Your functional Java code is going to be just as unreadable to a standard Java dev anyway, so the appeal of it being a widespread language is somewhat lost.
You mean it has Lambdas? Yes that's a start, but there's a lot more it needs to claim good FP support. Programming with lambdas is not sufficient to do "functional programming", which is really about composing pure functions (everything else follows from this, e.g. immutable data). Java's roadmap does look promising though.
final List<Whatever> that
I also think Either and Optional are cancers. Type erasure takes some of the fun away from Either. Before you had Optional you had one problem, you might have a null. With Optional you have two problems, you can get a null AND you can get an empty.
I worked at a place that used Scala and the engineering manager would talk your ear off like an Amway scam person about how much better monads were for error handling than Exceptions. I started working on non-Scala stuff but once they put me on the Scala side I found out that error handling was just missing in most places even though they allegedly did code reviews. It was definitely a frying pan to fire situation relative to Exceptions.
(The time before that whenI coded in Scala I found that people would spend 3 days writing something concurrent with Actors that only used 2 out of 8 cores and was rife with error conditions that could be done in 20 minutes with an Executor in Java.)
In a a parallel universe where LISP was the dominant language, people would be writing essays about how great COBOL and Cold Fusion and PHP are, about what a genius Noam Chomsky was, how recursive descent parsers are a force multiplier, etc.
That's not really the fault of the Optional. That's Java adding null as value to every type. Java also allows lists of nulls, mappings to null etc. An optional is just a container that stores one item at most. I do agree that it makes optionals less useful in Java. In Haskell and OCaml they are used essentially instead of null.
var result = map(x,x=>x.y)
var result = isNull(x) ? null : x.y
An approach which is authentic to some other languages is to consistently used a list with 0 or 1 members instead of optionals.
Sounds like you were working with some folks that were just learning the language/idioms (which is admittedly a big hurdle).
I haven't used actors in a very long time. Simple future composition and reactive streams get you very far, at an absolute fraction of the code size and complexity of the equivalent vanilla Java approach (ie: not using Rx).
For me there was a lot of learning (that often just felt like grinding), and I can confidently say that I'm leagues more productive than trying to mimic this with low level vanilla Java primitives.
I'm sure this would also apply with go channels, async/await, etc. Raising the bar of abstraction in this case can be valuable. As compared to something really high leverage like reactive streams it's just going to take a ton of code and be far less flexible in a naive approach (in most cases).
I've seen this same pattern with others. Is it worth the investment of time to get there? Not sure, maybe Go is a better set of tradeoffs for most, but I wouldn't go back to straight executors, locks, and the rest of the Java 1.5 concurrency offerings (which is what I thought the OP was saying).
And that data/side effect difference, you can easily handle in Java, C# and other OO languages if you just overcome the culture of OO-only thinking. And despite I think the article is not perfect (who says, that a function cannot have a class/interface wrapper (aka strategy)), there is an element of truth in the spirit of the headline.
"Functional Programming" is not a well-defined term. But I would argue that if you are not using pure functions then you have more of a hybrid imperative/functional language, which is fine, especially if you are careful with how you structure your effects. Modern FP languages use monads (Haskell) and/or algebraic effects (Eff) to enable pure functions to describe effects. The pure function is what enables mathematical reasoning and safe function composition.
I’m largely unsure of this. I think the standard Java dev might have difficulty adapting but the ramp up isn’t too hard. A Decent Java shop right now should be adapting functional features from Java into their code already.
In many ways introducing Kotlin was easier because it was clear it was a new language, and they had more openness and excitement for learning a new language.
- Lot of inline methods in stdlib alleviate the performance penalty of using higher order functions for tight loops.
- It is nice to have everything as expression
- Extension functions, it parameter, operator overloading, tuples are all micro-conveniences that coherently add up to a very pleasant experience.
I think the author's experience would have been substantially different if they used ktor/http4k/vertx with kotlin.
In the first section of the interview he specifically points out the merits of C and C-style C++, and explains how Lisp (especially mountains of macros) are hard to maintain in a team.
To give my perspective: Carmack was a latecomer in this, at least for the widespread programming paradigms community, and also remember game programming is a niche (so what worked there was unlikely to permeate to the general community [1]). So whatever Carmack thought (which I appreciate, since I hold him in high regard!) is unlikely to have had any sway in Java, Kotlin, Scala, and other proglangs adopting FP idioms. I distinctly remember back in that era, few people who were not gamers even knew who Carmack was (to my chagrin!).
[1] I remember an experience from my distant past, when interviewing at Vostu (a Zynga-like online game company), the chief engineer told me "we don't use frameworks here, just plain Java. Forget Spring, forget Hibernate, forget everything. We don't use them. Everything we do, we do by hand". (I didn't take the job offer for unrelated reasons). Note this is highly unrepresentative of the Java community at large!
Is there a reference for this?
If you think he is "an AR programmer" you may want to re-read his bio...
I say C# more than scala as it odd a little more mainstream.
Do you mean Self and Smalltalk? Because the Hotspot compiler came out of the work on them, not ML languages.
The example with email validation really hits the homebase really well. Also dependency on old java versions (without records) is really troubling.
Fortunately Spring 6 will depend on JDK 17.
AOP should end at `@Override`, all the rest turns Java into some kind of DSL which makes it unreadable (similar to what some people do to Scala, because it is too easy to make it into a DSL).
Poster child of AOP is logging, you log stuff, don't change the code (e.g. adding validation).
In short, if you want to log certain methods at enter and exit time with AOP (not manually adding it everywhere), you just create a proxy object and do a logEnter(); targetedObj.method(); logExit();
That’s why some people dislike Lombok as that actually changes byte code at compile time.
The article author believes everything should be done with types. But Java has always been able to represent an EmailAddress type. It's not like the Quarkus guys don't know about strong static typing! Bean Validation exists because:
1. Every tool knows what a string is. Very few know what your custom email address type is. In theory you can solve this with sub-typing, or duck typing, etc. But in Java the String class is final, so you can't extend from it. This has definitely had big advantages over the years - there's no proliferation of custom utility string types, and new Java versions could optimize the internal representation aggressively. It's not at all clear that Java would be better if String was an open class.
2. Bean Validation lets you validate every field at once and collect the errors together. This is extremely helpful for user interfaces where you want to be able to copy user data into an object, validate it, and then return all the problems to the UI for rendering next to the form. With the type approach he gives you'd get exactly one problem followed by an exception. The user would fix it, re-submit the form or re-execute the tool, and then get the next problem. Painful! Ditto for APIs where you want to de-serialize JSON into objects, validate them all in one go and return a single error response if there are issues.
3. Bean Validation is designed to be applied to both database entity and GUI model (e.g. config) objects, though it can be used for anything. Immutable types are useless for this use case because the database and GUI are both fundamentally about mutable state. The DB layer can generate far more optimized SQL and thus far more optimal DB resource usage if it can record what's changing (which requires some sort of "clever" stateful object), and for the UI you need to be able to hold invalid data somewhere - ideally in your model object, so the user's data can both be held in the model and also trigger validation errors.
4. It can also be used with parameters and return types on methods (with sufficient framework support from your implementation). This lets you add constraints to implementations in an API compatible way. Changing types wouldn't allow for that.
The author should really just read the intro to the Jakarta Bean Validation spec, which lays out the rationale quite clearly:
https://jakarta.ee/specifications/bean-validation/3.0/jakart...
Does anyone worry about whether reading a value out of a config object will launch rockets? No. The type system could express this, but the value of doing so would be very low. It is obvious from context. The reason it uses interfaces is because, if we check the docs:
"Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application"
If you implement config handling in the FP way he wants then a change to any part of the config requires rebuilding the entire object graph representing the entire configuration, and then re-plumbing that all through the rest of your (presumably immutable) set of objects. What you'd intuit should be a very fast operation with little memory overhead can suddenly require re-initializing large chunks of your app. A functional programmer might simply assert that being able to mutate configuration at runtime is a bad feature, but in the real world we do this sort of thing all the time and being able to handle it well is a useful feature of a config library.
The core disagreement here isn't actually anything to do with Java. More or less any imperative language would attract the ire of this author. What he's upset about is the existence of libraries and frameworks designed for mutability. But, mutability is inherent to the world. You can try to manage and constrain it but you can't remove it and sometimes you have to embrace it. That's not "Java culture", it's just life.
The problem for people, is that they do not like the place where the function is called and side effects are applied. In your typical Java/C#/... OO framework, this function is called two or three stack frames down into the framework. And here the author's point of Java/C# culture has its point.
It's true the documentation initially feels a bit lacking for the Getting Started scenario. But now I really appreciate the Guide format (essentially How-To's). Whenever I need to accomplish something, there's a guide for it.
With that said yes I still wish there was less magic in the Java ecosystem. Some years ago I toyed with Clojure a bit and I had some issue related to sessions with the popular Ring HTTP library. I viewed the source code on Github and was amazed that it was all vanilla Clojure. And even for a novice Clojure dev it was written in such a basic style I immediately understood how the whole library worked and found the solution to my problem.
This seems like an investigation into "How does typical Java code look?", not "What's the best possible way you could write this on the JVM?".