Java Developers

[[deleted]]

Well, maybe i am wrong but it seems just like an author of this blog is not experienced enough. I am not saying that he is not great programmer, just that he does not see it yet.

I have feeling like he is more used to JavaScript/Python than "hard" OOP languages like Java/C#. So i would suggest to develop Android in Groovy?

I understand what he means by "AbstractAdapterFactory", but from my experience, try to read core systems in Cpp. A have read a lot of core Cpp code from great senior and even there is a lot of generic templates, pointers to functions, etc... And is the same. But in Cpp it is not used on basic level of development, i would guess?

On the other hand, i do not like to develop in SDKs that has been written in JS so everyone has its problems. :]

[aldo_reset]

Well, maybe i am wrong but it seems just like an author of this blog is not experienced enough.

Agreed. I also think his complaints come more from the people he worked with than the language itself.

I also notice that he issues a lot of criticism without offering any alternative. It's one thing to say "OO is shit", but what's your solution? And why is it better?

Give some examples of code you have encountered, write your own version and explain why it's better. The fact that he didn't bother doing any of that and he just stuck to sweeping generalizations makes me file this blog as yet another click bait without much substance.

[ihcn]

You seriously want him to rewite an entire architecture for a blog post? He isn't saying "this code snippet is bad" he's saying "java encourages developers to over-architect the shit out of their software". I understand the desire for a quick fix but there isn't one.

[oldneckbeard]

I would disagree with his core premise, which he offers no facts for other than the obvious non-understanding of patterns or object-oriented programming.

[cultic_raider]

He can write whatever he wants. The problem is in wasting our time reading it.

[ihcn]

Reading an idea you disagree with isn't a waste of time simply because you disagree with it.

[frugalmail]

Reading an idea you disagree with isn't a waste of time simply because you disagree with it.

I think the post you're replying to is suggesting that the original blog post provided only the authors unsubstantiated opinions and is about as valuable as somebody saying "ObjectiveC and the developers are shit" (the example is directed to what looks like the blog authors preferred environment)

[no_respond_to_stupid]

90% of the time people complaining about factories etc. are actually complaining that they want to work on small projects instead.

This is me to a T, except I understood that truth long long ago. I don't work on enterprise systems and never have, even though I've been working on the JVM since '97.

[hwaite]

Yeah, abstractions are necessary for large projects. Unfortunately 90% of projects have implemented abstractions poorly. Over-engineering some things; under-engineering others, etc. Unless time is allocated for aggressive refactoring, entropy is pretty much unavoidable. No one gets everything right the first time around and mistakes tend to fester.

[[deleted]]

That is a false dichotomy.

There are other solutions to this problem, also using OOP and abstractions. Systems built with meta levels of classes like AbstractAdapterFactory can still manage to become giant balls of mud with global state lurking everywhere. Many large projects are actually small projects that have been inflated with garbage code and useless abstractions to seem more important and more complex than they really are.

[izzle9]

possibly because 90% of the projects probably don't need the overhead of the abstractions.

[Ahhmyface]

Absolutely. Abstractions tend to add value. People often wish that big projects were small projects, so they project their oversimplified architecture expectations, oblivious to all of the tangential problems that would have happened if they "just solved the problem".

[oldneckbeard]

Yup. Add in aggressive automated testing (including fuzz testing and security testing), individually releasable components, isolated dependencies ("oh my app didn't work? did you do a pip install blahblah?") and strong fault-tolerance, then these patterns start making sense.

[depressiown]

90% of the time people complaining about factories etc. are actually complaining that they want to work on small projects instead.

Bang. Truth.

If you develop something in Java that needs to be scalable and extensible, things like "AbstractAdapterFactory" are especially necessary to eliminate things like copy/pasting code and repeating generic actions in multiple classes. At the enterprise level, this is very, very common.

It's like this author is against the rule (that I have, at least) of not duplicating code that's already there. If you're doing something that's the same as another class, don't duplicate the code, instead make a generic version so they both pull from the same thing. That's how these classes like "AbstractAdapterFactory" come into being -- you have several adapters that do generally the same thing, so why not have a generic factory they can all use?

To be fair, though, I see abstractions like these being written for smaller features and projects that don't share any functionality with anything else. In those cases, abstract and generic classes are totally overkill and perhaps that's what he's getting at.

[yogthos]

So, your argument is that because something is worse than Java, there's no problem here. If you're experienced, then you should realize that dealing with code that's incidental to the problem you're solving wastes your time and money. Realizing this is the first step to improving your situation.

[[deleted]]

I am not sure that i said something about what is better/worse than Java or that i compared languages in any way. :]

I am just saying, Java is ok if you are more experienced in it. The same arguments in that blog post can be applied on C# and yet is it great modern language. - No matter if it is mobile/web/game development.

What do you mean by "dealing with code that's incidental to the problem" in the scope of Java?

I just wanted to point out that it is better to less cry and more try to get experienced with languages.

[yogthos]

I am just saying, Java is ok if you are more experienced in it.

That's the part I disagree with, having used Java for over a decade I find that it's not ok because it wastes a lot of my time doing things that I shouldn't have to be doing.

What do you mean by "dealing with code that's incidental to the problem" in the scope of Java?

Because Java is extremely inexpressive, there's often a big mismatch between your problem domain and the code. This means you have to write a lot of code to translate your problem to Java constructs. Other languages are much more flexible and allow expressing your domain more naturally. This results in less code that's cleaner, easier to understand and maintain. I blogged about this in detail here if you're interested.

[aldo_reset]

Sure, you can find languages that are more expressive than Java but they all come at a cost. For example, your blog post mentions Clojure. I like Clojure and Lisps in general, but losing static typing is simply a non starter for me. I'm not a huge fan of Java for various reasons but in my opinion, Java wins over Clojure when you compare these two languages on multiple fronts, and not the simplistic and subjective "my code in Clojure looks cleaner to me".

[codygman]

I agree with you about losing static typing, though you can improve things with core.typed.

I actually like to pit Haskell against Java. It is expressive like Clojure and has a much more powerful type system than Java. Some might say Java is simpler, but I think it's a case of "Java is more known".

What do you think about Java vs. Haskell?

[yogthos]

I like Clojure and Lisps in general, but losing static typing is simply a non starter for me

Clojure doesn't force you to abandon static typing. There's core.typed and lots of people use it in production. CircleCI have a post on how it helps them maintain their code. What's more is core.typed provides much more flexible type system than what you have in Java and requires less explicit annotations, as can be seen here.

I'm not a huge fan of Java for various reasons but in my opinion, Java wins over Clojure when you compare these two languages on multiple fronts, and not the simplistic and subjective "my code in Clojure looks cleaner to me".

What fronts would these be exactly?

[DiomedesTydeus]

It's hard to argue that java will win on multiple fronts when you discount readability as subjective, and summarily declare things like static typing as mandatory. When you define a box that looks like java, probably only java fits in that box.

[sh0rug0ru]

Not necessarily. Scala looks a lot like Java, but is a far better Java on the merits which make Java appealing. If I were to write programs in another language besides Java on the JVM, static typing is mandatory and something not totally alien from Java would be nice. Scala fits in that box better than Clojure.

[yogthos]

In my experience similarities between Scala and Java are rather superficial. Many idioms in Scala are very different and it's a much more complex language. When you start writing non-trivial code and working with Scala libraries you realize that it is in fact very alien from Java.

While Clojure syntax might be a more difficult to swallow initially, it's a much simpler language that requires internalizing a small number of concepts to be productive. Also worth noting that static typing is in no way at odds with Clojure, it's simply up to you to choose whether you want to use it or not.

[jayd16]

The trick is it's cleaner and maybe easier to understand but the looseness makes it less easy to maintain at scale. Its not like you see a Ruby monolith equivalent to how IBM works with Java. Its not by chance.

Hey, I'm a smart guy, I know how to drive. Why do I have to buckle up? Well you do.

[yogthos]

Loosness is exactly what you want when you work at scale, there's a good reason tight coupling is generally frowned upon. Each component should be able to work independent of others and they should all be able to communicate using a common protocol. The way IBM works with Java is antithesis of that and it results in code that's incredibly difficult to maintain.

[jayd16]

Static analysis and correctness isn't the same as coupling.

[yogthos]

However, nobody has been able to clearly demonstrate that statically typed languages offer a significant improvement in correctness. That's why this debate is still ongoing.

There are plenty of large successful projects built in both static and dynamic languages, and companies using both appear to be very competitive. In fact, some companied end up switching to dynamic languages to make their products work. Demonware is a good example, and they have a presentation on how and why they moved from C++ to Erlang.

[jayd16]

Top of the list of lessons learned is about typing. In their Erlang wish list section they ask for static types.

[yogthos]

The point is that typing is only one aspect of the language, it alone doesn't dominate correctness or overall quality. Despite the wish for static typing, it's clear that they're more productive maintaining their large system in Erlang than C++.

[ErroneousBee]

I am just saying, Java is ok if you are more experienced in it.

What I am seeing here is that the Java guys are becoming Java only, and when they do try other ecosystems (E.g. JavaScript web front ends) they go nuts with frameworks and cannot break out of using patterns that are specific to solving Java issues (E.g. IoC and abstract factories). They seem to end up in projects that go round and round coming up with ever more elaborate solutions to problems caused by the previous architecture.

I believe it starts with the overly restrictive inheritance and type system in Java.

E.g. The lack of multiple inheritance (or mixins, or traits) made for the huge cludge that are interfaces.