I agree with much of the article (also as being a java developer for the last 17 years).
However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem:
Frameworks.
Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is at an all time high), and often code following 'best practices' handed down from academia/conferences/books that promote large abstractions which are often un-necessary.
It's similar to how C code would end up having pointers-to-pointers-to-pointers-to-pointers...
A whole generation (generalising/stereotyping, I know) is now coding, who have never grown up and learnt with basic logic gates and low-level code. The framework is the obvious choice because 'why would you want to write it yourself, if it exists' ?
(Ironically, many Javascript developers seem to be intent on re-inventing everything that's gone before, and it's somehow seen as innovation - go figure)
Grumpy old man ? Sure, I am. I'm also gladdened to see a recent upsurge in assembly language and other low-level coding, as this is what the world actually needs - less super-business-entrepreneurial startups, and more people able to actually solve real problems and not just hipster entertainment.
I think most of the problems are caused by enterprise, enterprise frameworks, and the sheer age of Java. There's a lot of technical debt built up and a lot of enterprisey frameworks that are way over engineered.
I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc.
I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competitive market. So pluggable drivers for everything. Rather than build in say, one XML parser, instead let's build in a whole system to allow you to plug in any XML parser. As a result, it takes 4 lines of code to do what should work in 1 line. On other platforms, Python, Ruby, Go, et al, there is no such assumption that one needs an abstract interface to allow multiple implementation providers. You have an opinionated built-in implementation, or you use third party APIs.
This is why you have stuff like DocumentBuilderFactory/DocumentBuilder/etc.
When really, you want to write: Document doc = XML.parse(...)
Enterprise developers copied the basic design of having provider lookup/locators. This is why we have AbstractFactoryLocatorServiceLocator stuff.
Where I part company with the author is the total trashing of OO and the language. There are certainly lots of warts and things to complain about, but I haven't used a single language where I didn't have a boatload of things to bitch about.
I think you fall in love and there's a honey moon period with most languages, and then the beer goggles wear off after daily use and you see all the flaws.
It reminds me of the opposite take that we've seen in browsers as of late. Eg. innovate with webkit specific extensions then standardize what works. Java meanwhile standardized conceptually useful concepts (Swing, Java Server Faces, etc), but the markets for pluggable Swing or JSF components never took off.
I think it's that under Sun's direction the intent was to create markets, e.g. a market for GUI components or web components, a market for server components (EJBs). At least in the case of server components, Sun made a lot of money by licensing J2EE servers. I suppose that was their motivation all along for forcing DocumentBuilderFactory's on developers.
+1 for the DocumentBuilderFactory. I was trying to figure out why such an idea was implemented. I saw it sort of like having multiple implementations of DEFLATE on the same system. Seems like you really only need one...
There is also a lot of Java stuff dealing with dependency management. Not all of the principles are unsound, but they do have more long-term effects and make the code clutterly in the interim.
Java is not designed to solve programming problems, it's designed to solve organizational problems. And it does a pretty good job. That's why you see lean startups shunning it then slowly migrating when their company gets too big.
> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit.
Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do.
> Even today you’ll still find a strong bias towards OO courses being taught at the university level using Java, and the bias was certainly stronger 5 - 10 years ago.
Because that's what people use to write real programs.
> The engineers at Google working on Android are too busy architecting grand frameworks for solutions and not busy enough solving actual problems.
Because we all know, Google is known for hiring flakes who can't code or design real systems.
Worse is better means getting things done even if your tools kind of suck or your understanding of the problem isn't yet great. It leads to architecting and less than ideal solutions, but at least you ship!
> OO actually works well for scaling complexity, much better than toy immutable functions do.
Sure, but the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled.
A low-hanging example of this is the singleton pattern, and the Wikipedia section titled "Example of use with the Abstract Factory pattern" saves me from having to bother making the point any further: http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_us...
It is my fervent hope and wish that all programmers someday accept that there is no universal methodology, that FP and imperative and OO all have their place and their faults, and that it is OK to sometimes not use one of them somewhere.
> Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do.
Seems like we are working on very different kinds of systems. Right now I'm working on Hadoop-based data pipeline. While Hadoop itself is mostly written in Java, many recent tools like Spark or Kafka are created in Scala instead. Yes, they still use some kind of OOP where necessary, but it works as a helper tool, not as principal paradigm. At the same time, ideas from FP are used extensively.
Do you consider Hadoop-based systems not "real"?
But ok, let's take something different. Python for example. Python with its main web framework - Django - is really shiny. I would say, it is one of the best web frameworks ever. What about OOP in Django? Controllers are just functions on module level, models are just "poor" records for storing data (no behaviour), ORM is singleton-based. So I would say it's procedural, not object-oriented, at least, not in Java sense. And still sites like Instagram or Washington Post use Django.
Do you consider Instagram not a "real" system?
Ok, maybe it's just web. Java was never good for web, actually. Let's take one another example area, say, scientific computations. Science is something that is really complex, right? Even simple statistical algorithm involves tricky numerical computations, optimization methods, probability models, etc. Matlab is good at these. R is good at these. Python (SciPy) and Julia are good at these. C and Fortran are not very convenient, but fast and thus used extensively. What about Java? Is Parallel Colt best possible choice? Not very impressive. Ok, maybe Matlab, Python, C, etc. are really good only for little experiments and are not really scalable? Hmm, have you ever wondering what software Mars Curiosity is using? It's 2.5 million lines of C code with tests in Python [1]. And nothing about Java or OOP.
So, do you consider Curiosity software not a "real" system?
I'm pretty sure Java is good for some sort of applications. I've heard a lot of good things about using OOP for UIs. But Java is not the only language used for complex systems, and UIs are not the only "real" kind of systems.
Actually there are "real systems" being written in FP e.g. Clojure @ SoundCloud.
They just aren't architected the same way. Instead of a monolithic WAR you end up with a series of micro services. FP is actually more suited than OO for micro services since it naturally forces developers down the "do one thing well" approach.
So I would stop with the "OO is what real people use" nonsense if I were you. Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space and you may find yourself on the wrong side of history.
> Because we all know, Google is known for hiring flakes who can't code or design real systems.
The primary reason Java is the language used for Android is the very same reason that Android is used so much in enterprises: it is easy to learn, and easy to get developers for. But the language's primary redeeming quality has become an economic one, and not that the language itself is so rewarding.
+1 for the "toy immutable functions". Immutability everywhere is the current hype, but like mutability it has its advantages/disadvantages. The main consideration is the tradeof between performance(best for mutability) vs ease of use of development (best for immutability).
However on HN, the war is dogmatic whereas reality is not that black and white. As a Java developer, I find immutable String and primitives very convenient. For the rest, the liberty left to the developer is sufficient for high performance applications.
What I find quite amusing is that all these posters bashing OOP, end up using languages that actually do offer some form of OOP, as they seem to lack the understanding that Java OOP is not the only way of doing OOP.
As all modern languages, even functional ones, have OOP support.
> Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do.
FP wasn't mentioned in the article. Criticism of OO doesn't necessarily mean embracing FP, as far as I know.
A lot of these bloated patterns that got popular in the Java world have shorter, simpler alternatives when programming in a functional style. You often don't need multiple child classes to implement a template method if you can just pass a function to the constructor. You don't need a BananaFactory if you can just inject a createBanana function.
Remarkably many Gang of Four design patterns are unneeded once you can pass functions around. The C# world is now learning this: when C# 1 and 2 were popular, the ecosystem went right after Java in the kinds of boilerplate that the author describes. Now, many years of Func and Action goodness later, there's a large part of the community that codes way more to the point, and this part is growing. People who release C# libraries in 2014 with factories adapters and multiple layer inheritance hierarchies are laughed at.
Since Java 8, Java too has an accessible way to pass functions around. Not really functions, because Java, but in practice it works the same way. This means that there's nothing technologically that's holding the Java community from making these improvements, too.
I like your comment. Do you have any examples of C# libraries that use the ideas you're talking about? Or even better - do you know of a tutorial or something where I can clearly see the two approaches compared and contrasted?
I've always found that the people who write the AbstractFactoryFactorySomethingVisitor patterns are the people who read about design patterns and want to use them for the sake of using them, because they think it makes them better developers.
Instead they should learn about design principles, and instead of thinking "which pattern should I apply here", they should be thinking, "what is the best way to create this code so that the basic design principles are upheld". You can start with SOLID principles and go from there.
The same happens with language features; when generics were introduced, everyone wanted a generic class for some reason when it's almost never needed outside of the Collections framework (bit of a sweeping statement but I hope you see what I mean).
In fairness, I don't think it's really Java's fault, only that it's been around long enough for there to be many more examples of this kind of thing. I've been working in Java for 15 years and C# as my day job for the last 3 - you can easily pick out examples in C# where the langauge has been abused: dreadful LINQ expressions where a simple for-loop would suffice (and be quicker), or multiple Events added to a class, ALL of which need to be hooked up by calling classes for it to be usable, so an Observer really would, actually, have been a better solution.
I've played around with functional programming and there are a lot of claims around how it forces programmers to write better code. I'm not sure how it's going to stop programmers abusing language features or the language characteristics, though. I may well be wrong about that and am happy to be put right by a knowledgable FP dude.
I've been using Java for about 15 years and largely agree with the article. The verbosity of the Java language is definitely part of the problem, although that aspect is downplayed in his blog post. I agree with the author about the culture. Java programmers in general seem to be on some sort of design pattern frenzy, especially in the better known frameworks. It doesn't matter if you're writing a fancy framework or writing a trivial app to process a file, chances are you're going to see layer upon layer of over-engineering.
I switched to Scala a couple of years back and have never been happier. Only part of the improvement is due to the language the other part is not having to deal with Spring, builder patterns, and madness like AbstractSingletonProxyFactoryBean [1]. My impression has been that the typical Scala developer has had lots of Java exposure and has learned from their experiences.
I disagree with this, as a part time Java developer (I do C# most of the time). The points I disagree with:
1. OO is bad. Every paradigm is bad if you misuse it. If you build deep abstractions then you will hang yourself regardless. Some very elegant and simple designs can emerge from OO code, but only if you think about the problems first. The majority of pain consists of forgetting to do that step. There is no magic bullet - FP has its own pitfalls as well as does simple procedural programming.
2. Everything looks like it's written by an architect. Well that's a broad generalisation and I'm sure some people titled architect would be sick at the association (considering they usually reduce complexity) but the problem here is that people aren't using the frameworks properly. Not joking but the last two or three Java web applications I've put together have virtually no code in them. It's just the domain model, the views and query encapsulations. Nothing else. The abstract factory factory factory factory crap isn't your problem. If you make it your problem, then you're just doing it wrong or not using the tools provided efficiently.
3. Android. Android is abysmal (I've written a couple of things for it so far), but that's not because of Java but the fact that the Android API and versioning mess is a pile of unstable crap. It'd be nice if there were't so many exceptions.
If you're going to pick on Java, at least jump on: Idiotic code on the web, Glassfish being a right pile, view technology being foul, servlet container reloading, Swing/JavaFX or Eclipse...
Some of the complaints about the over-formal language is a matter of taste, perhaps, but it does grate and is not a new complaint (see also: the Kingdom of Nouns rant). However Java developers are learning (or migrating to Scala/Groovy/Clojure). And there is hope -- the Play framework, for example, is an example of Java done right (imho). Spring 4 is moving in the right direction.
What's your beef with JavaFX? I've been using it recently and it's a surprisingly well designed and nice UI framework. Parts of it are kind of immature and there are occasional surprising holes in its functionality, but that's because the current generation (after dropping the scripting language) is only a couple of versions old.
As the author said its not the languages fault. And if you know what you are doing then Java is clean, mature, performant, dare I say it enjoyable platform to use.
I think there also a generational conflict here. Java is a development environment that was born in the big architecture and 'development as enginerring' era of the late 90s. Spring was a reaction to the over engineered J2EE and now even Spring, the early liberator is considered over engineered.
Its our dad's language.
There is still a certain mindset from that era that was conditioned by the GOF and Universities and amaeteurs churning out developers but it is increasingly rare.
In fact I find Java is amongst the most interally introspective and disciplined in terms of coding taste and style.
I can almost guarantee if I look at another Java developers codebase that I can follow their code structure and style without too much effort. I'm not sure that would be the case for the large amount of very individualistic FP code being generated currently.
I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either.
I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past.
When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.
I can say the same re your experience, but I kind of experience the same thing he links to with Gradle and really despise it. Handling the constant Groovy errors and Gradle errors, and spending my life digging through their docs for a language and a build system I couldn't care less about really depresses me when I'm a Java expert. Give me a stack trace and I'll have the problem fixed in five minutes with unit tests and UI automation tests done later that day.
But give me a gradle error and I'm stuck in their docs all day, you might have a solution this week. And by the way it breaks automatically all the time as Android Studio and the android tools plugins and all the rest version up. I wish we could have just stuck with Ant and Eclipse for Android, which are known evils. Instead every update of Studio and Gradle someone on the team has to draw the short straw and try, then either give everyone else the OK or tell them to stay the hell away from that version.
Java hits a sweet spot of simplicity, platform stability, safety and performance.
Also, its popularity in the enterprise is partly because interchangeable, cog-in-the-machine low quality developers can be productive in it and not cause too many meltdowns. Thats an economic advantage! If you need lots of cheap developers for your IT department, good luck finding 15 Clojure and Haskell gurus.
There is a lot of Cargo Cult programming going on among Java developers.
Why using a simple constructor when you can use the factory design pattern?
Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?
Your statement sounds like a reverse cargo cult. The problem is not that people use these constructs that you mention. The problem is that people use the wrong constructs at the wrong time, don't seem particularly good at judging which to use when and just use the most convoluted one by default.
There are many contexts in which the factory pattern is the best choice (although not the majority) and in which configuring logging externally is the best choice (almost always).
Actually, configuring logger with values stored in a separate file instead of hardcoded ones is a good thing. Logging configuration is configuration, after all.
You wouldn't want paths to documents be hardcoded in your office suite, would you? Or target address of VPN gateway in VPN client?
Hard coded logger instantiation in a library is anti-pattern. Whoever is using your library usually has his own opinions on how much of your stuff he wants in logs.
While I have seen what you describe, I am not sure if it is only specific to Java, and I have to admit that I enjoy working with the Java platform. There are things in the ecosystem that annoy me more.
We use Java in a non-standard environment: products built on a enterprise Linux distribution, and therefore built using the same infrastructure and conventions: everything is built from source as a dependency chain, so that you can patch it and provide support, and ship those patched components back as packages. Everything is built in a repeatable environment, jailed in a VM, no network, that only contains the dependencies you declared.
So there were those nice times where building a Java library meant packaging 2 or 3 dependencies, then packaging the library was as simple as unpacking, apply any patches, set the classpath to the dependencies and run ant. Then install the resulting jar. It played well with the environment.
Java build tools are insane.
To build most libraries I now need Maven. Maven needs like a hundred dependencies to build, plus some plugins that need those dependencies, and those plugins build with Maven, the dependencies too.
At the end, to build Maven, you need to have all components which are the reason you are building Maven in the first place.
So this makes me thing Java developers don't think in terms of layers, and they pull dependencies without balancing the costs (writing one function vs depending on 20 more jars).
A build tool should have almost no dependencies outside of the base system (in this case the JDK) and the compiler.
But no, they added even a Dependency Injection container. And now they realized that the one from Google is better, so they switch to it, but without removing the old. So now they may be depend on 150 packages instead of 100. Great. Lets add more stuff.
Imagine if to build make you need to have Gtk, and a library that builds with cmake and another library that builds with scons.
And all the noise with this advanced nuclear engines and frameworks to power something as simple as a build tools is at the end useless. At some point the project still declares technical bankruptcy and dies. Java has a lot of "choice" in terms of libraries, but a good percentage of them are dead projects.
Programmers rarely see how their software is built and shipped. Those who have
this opportunity rarely have their taste developed to see that external
dependencies have cost associated. And it's not something specific to Java:
I see the same in Ruby and Python.
It could give the perspective to programmers requiring from them that they
always build their software on a freshly installed machine with no network
connection.
Are you really generalising to an entire industry from the build procedure for a build tool? Why are you even building Maven in the first place? My experience with Maven has been:
1) Download and unzip
2) Run it
and that's all that was necessary. Meanwhile on the fly dependency resolution is very nice and a feature of most modern platforms.
Java is not the problem, enterprise architects are.
If anything, Java allowed the so called architects a much easier path to such crazy skyscrapper designs than any enterprise language before it.
So of course they went crazy with Java, and later on C#, because it was so easy to do so, without being caught in core dumps and similar issues.
Anyone complaining about enterprise Java, just needs to go back a few decades to see what was being done in C, C++ with CORBA/DCOM, VB/Delphi, CLIPPER and tons of wannabe 4GL languages.
Any language that wins the hearts of enterprise architects will suffer the same pains that Java is known for.
I can already imagine a "Enterprise Functional Design Patterns" and similar books.
Ah yes, DCOM. That was truly the domain of the C++ enterprise architect! Today's AbstractProxyFactoryBean was yesterday's IDispatchProxy, IRPCProxyBuffer and so on.
What's scary is that big chunks of heavy industry are all standardised on it via OLE for Process Control (OPC).
At this moment I have an interface open with the following signature:
public interface ClientBenefitOrder extends Internationalizable<ClientBenefitOrderDisplay>, CBMEntity, Enableable<OfferCategories>, Deletable, Comparable<ClientBenefitOrder>, ClientOwned
This is entire application suffers from Enterprise Architechtitus, and like OP I have encountered that far too often for it to be a simple mistake. There is a cultural tendency in Java land towards overengineered solutions. It's pervasive. It also makes for bad code.
Disclosure: Long time Java programmer here (since 1996, previously worked many years with Smalltalk). Java Language and Java Virtual Machine are great, but Java Libraries are in many cases too complicated (using too much of "Gang of Four" patterns).
Java combines OO with strict typing (unlike Ruby which has OO without the strict typing). As such, that particular combination leads to bloat and verboseness. See:
What did Rich Hickey mean when he said, “All that specificity kills your reuse!”
"If you have two entities { "name":"John" } of type Person, and { "name": "Rover" } of type Dog, in Java-land they probably cannot interoperate unless they share a common interface or ancestor (like Mammal, which means writing more code). So the interfaces/types here are "killing your reuse": even though Person and Dog look the same, one cannot be used interchangeably with the other, unless you write additional code to support that. Note Hickey also jokes about projects in Java needing lots of classes ("Who here has written a Java application using just 20 classes?"), which seems one consequence of the above."
The proliferation of factories is not an indication of over-architecting something. It is a direct consequence of finding a balance between maintainability and the lack of first class functions (or constructors as first class functions).
If you have never had the need to introduce factories, I claim that you have not worked with a truly polymorphic system.
I agree with the general sentiment of the article. I have used Java since the beginning and I have written many books using Java for the examples in the books.
I mostly use Haskell and Clojure (with little text utilities in Ruby) now, but I still do find that Java is sometimes the best language for some projects. Off topic, but Java 8 streams and inline functions made the language better.
That said, I no longer use Java in any sort of "standard" way. I stopped using getters/setters years ago in favor of public instance variables. I also write a lot of static methods ("functions"). Basically, I try to make my Java code as concise as possible.
I also have turned my back on large server side frameworks. For web services, embedded Jetty and a JSON library is often all the library support that I need.
Blame the 90s : the Gang of Four design patterns book, UML, et al.
If you wrote code that did not abstract enough, such as not using factories, it was jaw-droppingly obvious to your colleagues that you were not good enough. FP and Scala owe the sheer verbosity of Java a lot for their current success :-)
Java has been round long enough to have been influenced by whatever was the coding fashion of the time. You can see it in the core java libraries and the supporting frameworks. OO and GoF where probably the biggest fashions and you can document when a core library was written by the approach to it.
Wow there is a lot of bashing of the GoF patterns going on here. It seems like lots of people have a misconception about what patterns are. Patterns aren't a goal to meet with your software. They are common emergent solutions to standard design problems. The GoF didn't invent them, they just cataloged and provided a standard name for them.
So once we have a common name, shouldn't we use it? If I see a FooFactory, I have a pretty good idea what to expect in that class. So the problem with a FooFactoryFactoryAdaptor isn't that it is following GoF patterns or in it's silly name, it's that you have a solution that has at least 3 levels of abstraction. The patterns didn't cause that.
The problem is not the language itself, rather who uses and whats the culture associated with it.
Java is mostly used in the enterprises, where unfortunately thest "architects" exists. Architects are nothing but people have grown out of the roles and in a way of organization recognizing the peoples talent. Most of the times the Architects are redundant.
Most of the cases use of Java is nothing but writing your business logic into the Java code.
Unfortunately, architect to justify himself would try to engineer a solution, which never needed engineering itself. and down you go in the rabbit-hole of oops and abstraction.
Unfortunately it will be pretty hard for Java to shake up this image.
[+] [-] mobiuscog|11 years ago|reply
However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem:
Frameworks.
Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is at an all time high), and often code following 'best practices' handed down from academia/conferences/books that promote large abstractions which are often un-necessary.
It's similar to how C code would end up having pointers-to-pointers-to-pointers-to-pointers...
A whole generation (generalising/stereotyping, I know) is now coding, who have never grown up and learnt with basic logic gates and low-level code. The framework is the obvious choice because 'why would you want to write it yourself, if it exists' ?
(Ironically, many Javascript developers seem to be intent on re-inventing everything that's gone before, and it's somehow seen as innovation - go figure)
Grumpy old man ? Sure, I am. I'm also gladdened to see a recent upsurge in assembly language and other low-level coding, as this is what the world actually needs - less super-business-entrepreneurial startups, and more people able to actually solve real problems and not just hipster entertainment.
[+] [-] cromwellian|11 years ago|reply
I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc.
I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competitive market. So pluggable drivers for everything. Rather than build in say, one XML parser, instead let's build in a whole system to allow you to plug in any XML parser. As a result, it takes 4 lines of code to do what should work in 1 line. On other platforms, Python, Ruby, Go, et al, there is no such assumption that one needs an abstract interface to allow multiple implementation providers. You have an opinionated built-in implementation, or you use third party APIs.
This is why you have stuff like DocumentBuilderFactory/DocumentBuilder/etc.
When really, you want to write: Document doc = XML.parse(...)
Enterprise developers copied the basic design of having provider lookup/locators. This is why we have AbstractFactoryLocatorServiceLocator stuff.
Where I part company with the author is the total trashing of OO and the language. There are certainly lots of warts and things to complain about, but I haven't used a single language where I didn't have a boatload of things to bitch about.
I think you fall in love and there's a honey moon period with most languages, and then the beer goggles wear off after daily use and you see all the flaws.
[+] [-] josho|11 years ago|reply
It reminds me of the opposite take that we've seen in browsers as of late. Eg. innovate with webkit specific extensions then standardize what works. Java meanwhile standardized conceptually useful concepts (Swing, Java Server Faces, etc), but the markets for pluggable Swing or JSF components never took off.
I think it's that under Sun's direction the intent was to create markets, e.g. a market for GUI components or web components, a market for server components (EJBs). At least in the case of server components, Sun made a lot of money by licensing J2EE servers. I suppose that was their motivation all along for forcing DocumentBuilderFactory's on developers.
[+] [-] figglesonrails|11 years ago|reply
There is also a lot of Java stuff dealing with dependency management. Not all of the principles are unsound, but they do have more long-term effects and make the code clutterly in the interim.
[+] [-] tootie|11 years ago|reply
[+] [-] seanmcdirmid|11 years ago|reply
Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do.
> Even today you’ll still find a strong bias towards OO courses being taught at the university level using Java, and the bias was certainly stronger 5 - 10 years ago.
Because that's what people use to write real programs.
> The engineers at Google working on Android are too busy architecting grand frameworks for solutions and not busy enough solving actual problems.
Because we all know, Google is known for hiring flakes who can't code or design real systems.
Worse is better means getting things done even if your tools kind of suck or your understanding of the problem isn't yet great. It leads to architecting and less than ideal solutions, but at least you ship!
[+] [-] thaumaturgy|11 years ago|reply
Sure, but the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled.
A low-hanging example of this is the singleton pattern, and the Wikipedia section titled "Example of use with the Abstract Factory pattern" saves me from having to bother making the point any further: http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_us...
It is my fervent hope and wish that all programmers someday accept that there is no universal methodology, that FP and imperative and OO all have their place and their faults, and that it is OK to sometimes not use one of them somewhere.
[+] [-] ffriend|11 years ago|reply
Seems like we are working on very different kinds of systems. Right now I'm working on Hadoop-based data pipeline. While Hadoop itself is mostly written in Java, many recent tools like Spark or Kafka are created in Scala instead. Yes, they still use some kind of OOP where necessary, but it works as a helper tool, not as principal paradigm. At the same time, ideas from FP are used extensively.
Do you consider Hadoop-based systems not "real"?
But ok, let's take something different. Python for example. Python with its main web framework - Django - is really shiny. I would say, it is one of the best web frameworks ever. What about OOP in Django? Controllers are just functions on module level, models are just "poor" records for storing data (no behaviour), ORM is singleton-based. So I would say it's procedural, not object-oriented, at least, not in Java sense. And still sites like Instagram or Washington Post use Django.
Do you consider Instagram not a "real" system?
Ok, maybe it's just web. Java was never good for web, actually. Let's take one another example area, say, scientific computations. Science is something that is really complex, right? Even simple statistical algorithm involves tricky numerical computations, optimization methods, probability models, etc. Matlab is good at these. R is good at these. Python (SciPy) and Julia are good at these. C and Fortran are not very convenient, but fast and thus used extensively. What about Java? Is Parallel Colt best possible choice? Not very impressive. Ok, maybe Matlab, Python, C, etc. are really good only for little experiments and are not really scalable? Hmm, have you ever wondering what software Mars Curiosity is using? It's 2.5 million lines of C code with tests in Python [1]. And nothing about Java or OOP.
So, do you consider Curiosity software not a "real" system?
I'm pretty sure Java is good for some sort of applications. I've heard a lot of good things about using OOP for UIs. But Java is not the only language used for complex systems, and UIs are not the only "real" kind of systems.
[1]: http://programmers.stackexchange.com/questions/159637/what-i...
[+] [-] threeseed|11 years ago|reply
They just aren't architected the same way. Instead of a monolithic WAR you end up with a series of micro services. FP is actually more suited than OO for micro services since it naturally forces developers down the "do one thing well" approach.
So I would stop with the "OO is what real people use" nonsense if I were you. Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space and you may find yourself on the wrong side of history.
[+] [-] xiaoma|11 years ago|reply
Many people said the same of GOTO statements a generation ago.
[+] [-] coldtea|11 years ago|reply
They have some nice scallable backend systems, but a lot of their output is ho-hum, especially when it comes to their Java inspired teams (GTW etc).
[+] [-] DCKing|11 years ago|reply
The primary reason Java is the language used for Android is the very same reason that Android is used so much in enterprises: it is easy to learn, and easy to get developers for. But the language's primary redeeming quality has become an economic one, and not that the language itself is so rewarding.
[+] [-] djulius|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
As all modern languages, even functional ones, have OOP support.
[+] [-] vrotaru|11 years ago|reply
[+] [-] Dewie|11 years ago|reply
FP wasn't mentioned in the article. Criticism of OO doesn't necessarily mean embracing FP, as far as I know.
[+] [-] DCKing|11 years ago|reply
[+] [-] skrebbel|11 years ago|reply
Remarkably many Gang of Four design patterns are unneeded once you can pass functions around. The C# world is now learning this: when C# 1 and 2 were popular, the ecosystem went right after Java in the kinds of boilerplate that the author describes. Now, many years of Func and Action goodness later, there's a large part of the community that codes way more to the point, and this part is growing. People who release C# libraries in 2014 with factories adapters and multiple layer inheritance hierarchies are laughed at.
Since Java 8, Java too has an accessible way to pass functions around. Not really functions, because Java, but in practice it works the same way. This means that there's nothing technologically that's holding the Java community from making these improvements, too.
I hope it happens.
[+] [-] icebraining|11 years ago|reply
[+] [-] ivanlubenko|11 years ago|reply
[+] [-] philbarr|11 years ago|reply
Instead they should learn about design principles, and instead of thinking "which pattern should I apply here", they should be thinking, "what is the best way to create this code so that the basic design principles are upheld". You can start with SOLID principles and go from there.
The same happens with language features; when generics were introduced, everyone wanted a generic class for some reason when it's almost never needed outside of the Collections framework (bit of a sweeping statement but I hope you see what I mean).
In fairness, I don't think it's really Java's fault, only that it's been around long enough for there to be many more examples of this kind of thing. I've been working in Java for 15 years and C# as my day job for the last 3 - you can easily pick out examples in C# where the langauge has been abused: dreadful LINQ expressions where a simple for-loop would suffice (and be quicker), or multiple Events added to a class, ALL of which need to be hooked up by calling classes for it to be usable, so an Observer really would, actually, have been a better solution.
I've played around with functional programming and there are a lot of claims around how it forces programmers to write better code. I'm not sure how it's going to stop programmers abusing language features or the language characteristics, though. I may well be wrong about that and am happy to be put right by a knowledgable FP dude.
[+] [-] thescrewdriver|11 years ago|reply
I switched to Scala a couple of years back and have never been happier. Only part of the improvement is due to the language the other part is not having to deal with Spring, builder patterns, and madness like AbstractSingletonProxyFactoryBean [1]. My impression has been that the typical Scala developer has had lots of Java exposure and has learned from their experiences.
[1] http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...
[+] [-] nick_riviera|11 years ago|reply
1. OO is bad. Every paradigm is bad if you misuse it. If you build deep abstractions then you will hang yourself regardless. Some very elegant and simple designs can emerge from OO code, but only if you think about the problems first. The majority of pain consists of forgetting to do that step. There is no magic bullet - FP has its own pitfalls as well as does simple procedural programming.
2. Everything looks like it's written by an architect. Well that's a broad generalisation and I'm sure some people titled architect would be sick at the association (considering they usually reduce complexity) but the problem here is that people aren't using the frameworks properly. Not joking but the last two or three Java web applications I've put together have virtually no code in them. It's just the domain model, the views and query encapsulations. Nothing else. The abstract factory factory factory factory crap isn't your problem. If you make it your problem, then you're just doing it wrong or not using the tools provided efficiently.
3. Android. Android is abysmal (I've written a couple of things for it so far), but that's not because of Java but the fact that the Android API and versioning mess is a pile of unstable crap. It'd be nice if there were't so many exceptions.
If you're going to pick on Java, at least jump on: Idiotic code on the web, Glassfish being a right pile, view technology being foul, servlet container reloading, Swing/JavaFX or Eclipse...
[+] [-] signal11|11 years ago|reply
[+] [-] mike_hearn|11 years ago|reply
[+] [-] arel|11 years ago|reply
I think there also a generational conflict here. Java is a development environment that was born in the big architecture and 'development as enginerring' era of the late 90s. Spring was a reaction to the over engineered J2EE and now even Spring, the early liberator is considered over engineered.
Its our dad's language.
There is still a certain mindset from that era that was conditioned by the GOF and Universities and amaeteurs churning out developers but it is increasingly rare.
In fact I find Java is amongst the most interally introspective and disciplined in terms of coding taste and style.
I can almost guarantee if I look at another Java developers codebase that I can follow their code structure and style without too much effort. I'm not sure that would be the case for the large amount of very individualistic FP code being generated currently.
[+] [-] larsmak|11 years ago|reply
I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past.
When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.
[+] [-] lnanek2|11 years ago|reply
But give me a gradle error and I'm stuck in their docs all day, you might have a solution this week. And by the way it breaks automatically all the time as Android Studio and the android tools plugins and all the rest version up. I wish we could have just stuck with Ant and Eclipse for Android, which are known evils. Instead every update of Studio and Gradle someone on the team has to draw the short straw and try, then either give everyone else the OK or tell them to stay the hell away from that version.
[+] [-] MrBuddyCasino|11 years ago|reply
I say that as a Java developer, btw.
[+] [-] Hermel|11 years ago|reply
Why using a simple constructor when you can use the factory design pattern? Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?
[+] [-] DCKing|11 years ago|reply
There are many contexts in which the factory pattern is the best choice (although not the majority) and in which configuring logging externally is the best choice (almost always).
[+] [-] dozzie|11 years ago|reply
You wouldn't want paths to documents be hardcoded in your office suite, would you? Or target address of VPN gateway in VPN client?
[+] [-] watwut|11 years ago|reply
[+] [-] malka|11 years ago|reply
[+] [-] dmacvicar|11 years ago|reply
We use Java in a non-standard environment: products built on a enterprise Linux distribution, and therefore built using the same infrastructure and conventions: everything is built from source as a dependency chain, so that you can patch it and provide support, and ship those patched components back as packages. Everything is built in a repeatable environment, jailed in a VM, no network, that only contains the dependencies you declared.
So there were those nice times where building a Java library meant packaging 2 or 3 dependencies, then packaging the library was as simple as unpacking, apply any patches, set the classpath to the dependencies and run ant. Then install the resulting jar. It played well with the environment.
Java build tools are insane.
To build most libraries I now need Maven. Maven needs like a hundred dependencies to build, plus some plugins that need those dependencies, and those plugins build with Maven, the dependencies too. At the end, to build Maven, you need to have all components which are the reason you are building Maven in the first place.
So this makes me thing Java developers don't think in terms of layers, and they pull dependencies without balancing the costs (writing one function vs depending on 20 more jars).
A build tool should have almost no dependencies outside of the base system (in this case the JDK) and the compiler.
But no, they added even a Dependency Injection container. And now they realized that the one from Google is better, so they switch to it, but without removing the old. So now they may be depend on 150 packages instead of 100. Great. Lets add more stuff.
Imagine if to build make you need to have Gtk, and a library that builds with cmake and another library that builds with scons.
And all the noise with this advanced nuclear engines and frameworks to power something as simple as a build tools is at the end useless. At some point the project still declares technical bankruptcy and dies. Java has a lot of "choice" in terms of libraries, but a good percentage of them are dead projects.
[+] [-] dozzie|11 years ago|reply
It could give the perspective to programmers requiring from them that they always build their software on a freshly installed machine with no network connection.
[+] [-] mike_hearn|11 years ago|reply
1) Download and unzip
2) Run it
and that's all that was necessary. Meanwhile on the fly dependency resolution is very nice and a feature of most modern platforms.
[+] [-] pjmlp|11 years ago|reply
If anything, Java allowed the so called architects a much easier path to such crazy skyscrapper designs than any enterprise language before it.
So of course they went crazy with Java, and later on C#, because it was so easy to do so, without being caught in core dumps and similar issues.
Anyone complaining about enterprise Java, just needs to go back a few decades to see what was being done in C, C++ with CORBA/DCOM, VB/Delphi, CLIPPER and tons of wannabe 4GL languages.
Any language that wins the hearts of enterprise architects will suffer the same pains that Java is known for.
I can already imagine a "Enterprise Functional Design Patterns" and similar books.
[+] [-] mike_hearn|11 years ago|reply
What's scary is that big chunks of heavy industry are all standardised on it via OLE for Process Control (OPC).
[+] [-] revscat|11 years ago|reply
At this moment I have an interface open with the following signature:
This is entire application suffers from Enterprise Architechtitus, and like OP I have encountered that far too often for it to be a simple mistake. There is a cultural tendency in Java land towards overengineered solutions. It's pervasive. It also makes for bad code.[+] [-] markokrajnc|11 years ago|reply
[+] [-] lkrubner|11 years ago|reply
What did Rich Hickey mean when he said, “All that specificity kills your reuse!”
http://programmers.stackexchange.com/questions/199217/what-d...
Part of the answer given:
"If you have two entities { "name":"John" } of type Person, and { "name": "Rover" } of type Dog, in Java-land they probably cannot interoperate unless they share a common interface or ancestor (like Mammal, which means writing more code). So the interfaces/types here are "killing your reuse": even though Person and Dog look the same, one cannot be used interchangeably with the other, unless you write additional code to support that. Note Hickey also jokes about projects in Java needing lots of classes ("Who here has written a Java application using just 20 classes?"), which seems one consequence of the above."
[+] [-] _pmf_|11 years ago|reply
If you have never had the need to introduce factories, I claim that you have not worked with a truly polymorphic system.
[+] [-] mark_l_watson|11 years ago|reply
I mostly use Haskell and Clojure (with little text utilities in Ruby) now, but I still do find that Java is sometimes the best language for some projects. Off topic, but Java 8 streams and inline functions made the language better.
That said, I no longer use Java in any sort of "standard" way. I stopped using getters/setters years ago in favor of public instance variables. I also write a lot of static methods ("functions"). Basically, I try to make my Java code as concise as possible.
I also have turned my back on large server side frameworks. For web services, embedded Jetty and a JSON library is often all the library support that I need.
[+] [-] vijucat|11 years ago|reply
If you wrote code that did not abstract enough, such as not using factories, it was jaw-droppingly obvious to your colleagues that you were not good enough. FP and Scala owe the sheer verbosity of Java a lot for their current success :-)
[+] [-] cam-|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
[+] [-] tormeh|11 years ago|reply
[+] [-] kasey_junk|11 years ago|reply
So once we have a common name, shouldn't we use it? If I see a FooFactory, I have a pretty good idea what to expect in that class. So the problem with a FooFactoryFactoryAdaptor isn't that it is following GoF patterns or in it's silly name, it's that you have a solution that has at least 3 levels of abstraction. The patterns didn't cause that.
[+] [-] __Joker|11 years ago|reply
The problem is not the language itself, rather who uses and whats the culture associated with it.
Java is mostly used in the enterprises, where unfortunately thest "architects" exists. Architects are nothing but people have grown out of the roles and in a way of organization recognizing the peoples talent. Most of the times the Architects are redundant.
Most of the cases use of Java is nothing but writing your business logic into the Java code.
Unfortunately, architect to justify himself would try to engineer a solution, which never needed engineering itself. and down you go in the rabbit-hole of oops and abstraction.
Unfortunately it will be pretty hard for Java to shake up this image.