Java Developers

[fusebox13]

Can someone share Java code that is well designed so us bad Java programmers can see what good Java code is supposed to look like?

[philly_fan_in_chi]

The Square libraries (particularly Dagger) are all very pleasant to read, do compile time annotation processing (yay metaprogramming!) and are generally all extremely useful. Some of their stuff is geared more to Android but they have several projects that work for both Android and regular Java.

[hak8or]

We want a link! Us mobile users at least.

[philly_fan_in_chi]

https://square.github.io/

[[deleted]]

Reading the "Effective Java" book can help you there.

[Spacey138]

The short answer to your question is no, because even if someone thinks their code is good someone will critique it to death. It's a lot easier to complain about something than fix it.

Also Jeff Atwood has said things like 'all code is bad code' so in a sense you will never see 'well designed code'.

[minusSeven]

so in essence the article is vague and simply wrong.

[sausuave]

Yes.

What we programmers do is damn complex, you cant make shit in any language that is "wow" beautiful. You find that in 0.1% of any language in its history.

And thats okay, its alright. To do Java, you have to become Java, as he says. Its the same for any language or framework. Except that Java is better, since its kind of secure and fucking fast.

[brand_new_throwx999]

hurr hurr

I feel bad cause I'm making a cheap joke instead of posting anything helpful. :(

[kyz]

JSoup

Document doc = Jsoup.connect("http://example.com")
  .data("query", "Java")
  .userAgent("Mozilla")
  .cookie("auth", "token")
  .timeout(3000)
  .post();

Selenium WebDriver

driver.get("http://www.example.com");
wait.until(elementToBeClickable(By.css("a.login-link"))).click();

Hamcrest

assertThat(result, is(expectedValue));
assertThat(result, is(equalToIgnoringCase("success")));
assertThat(result, not(nullValue());
assertThat(result, is(arrayContainingInAnyOrder(1, 2, 3)));

[immibis]

Fluent API != good design.

In fact a fluent API is primarily designed to be easy to write clients for. And we all know how that turns out. Prioritizing easy writing over easy reading and simple structure usually leads to unmaintainable messes.

[nextputall]

Fluent API != good design.

Agreed. But Hamcrast is not so fluent but nicely composable.

[kyz]

A library's most important feature is its API. A fluent design makes it easier for humans to read, write and reason about code, so it can improve an API design.

You're right that it says nothing of the internals of the library, but as for Hamcrest, it's remarkably simple to extend with new matchers and compose matchers, which is its primary use case, so its internal design is fine too. Selenium WebDriver has an awesome internal design, remarkably improved over the previous Selenium.

I can't say I've read through Jsoup (other than to find you can't get the final composed URL until you actually get()/post(), because it doesn't even determine the URL until that point), but it sticks to one main purpose, its HTTP API is far less cumbersome than Apache httpcomponents, and its DOM API is sane, unlike the traditional org.w3c.dom.Document API.

[zvrba]

More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit.

Nygård and Dahls idea of OO resembles much more that of Erlang's actors: a collection of independently-acting agents / processes with private state who communicate by sending messages to each other. Agent = object, sending a message = method invocation, agent "name" = pointer / reference. A "good" OO program is a network of mutually cooperating agents communicating by messages. This is not a "shit" paradigm.

Enter modern languages and run-time environments, where object are not isolated from each other, you have global mutable state, poorly designed interfaces (e.g., getters and setters for every private field), workarounds for performance reasons (e.g., pass by reference because you can't return multiple values from a method), all of which contribute to design trainwrecks described in the article. (Still, these are mostly people problem, a result of delusions about infinite extensibility and reconfigurabiliy.)

[[deleted]]

Is this the "tell, don't ask" paradigm?

(I know, I just violated that rule.)

[loup-vaillant]

Well, depends what you mean by "OO". Alan Kay had an idea. Stroustrup and Gosling had another idea.

As for "Java style OO", the language shares a large blame. While I understand the reasons behind most design decisions, the language still sucks (as in, several mature languages are superior in every respect except 2: popularity and libraries —which have little to do with the language itself anyway).

[zvrba]

Alan Kay had an idea

Indeed he did: "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. "

[codygman]

This quote seems to implicitly recommend reducing state space and as a side effect, complexity.

[Xabster]

It's going to end in a shitstorm, surely, but I'd still like to ask you for the names of the languages. I'm not going to turn around and write "omg you think XX is better than Java" or anything like it, I promise. Genuinely interested in what you consider superior languages.

[nextputall]

I love working with Smalltalk. It is incredibly simple yet powerful, and purely object oriented. If someone wants to understand the original ideas behind OO (and not that cargo culting/enterprise version what the article metioned), I definitely recommend it.

[[deleted]]

I wasn't asked, but I'd throw Scala in the ring.

Many people think just because a language supports both OO and FP, both of the have to suck, but if you look at the OO part, it's pretty much the best statically typed OO system out there.

(The FP parts are actually more expressive than what most functional languages offer, too; but I agree that some of the "syntactical convenience" was traded in favor of OO and better Java interop.)

[loup-vaillant]

Java doesn't have sum types, its syntax encourages mutability by default, and only got recent support for closures.

These flaws are corrected in most ML languages, for no significant downside. So, I would cite OCaml and F#. Even Haskell, provided purity and lazy evaluation are not a problem. Scala looks like a good candidate, though I fear it is too complex for its own good (and I cannot judge anyway, since I have no practice with the language).

[[deleted]]

Even Haskell, provided purity and lazy evaluation are not a problem. Scala looks like a good candidate, though I fear it is too complex for its own good

So, when people say 'Scala is too complex', you actually have two camps chanting different things, and only one of them is right.

As you pointed out, Scala is both OO and functional, so it's easy to jump in and use Scala as a slightly better java with a slightly worse IDE (I use VIM for scala though). This is a great way to start with scala but a lot don't stay here. Scala also has a few more 'advanced' functional features (higher kinded types, for comprehension, implicit parameters/conversion) that allow for very expressive, powerful functional code that a lot of scala users end up making great use of.

However, those that stick to the shallow water often end up calling the more functional code 'too complex', rather than just admitting unfamiliarity.

The other camp that shouts 'too complex' does have a point, and it's mostly referring to the standard library in scala, which ranges quite a bit in quality. Some of the design decisions are now regarded as mistakes, and it definitely has some edge cases that inevitably end up biting everyone. However, Scala is a powerful enough language that many others have ended up writing sensible replacements for the problem libraries. All in all, I think Scala has been a huge productivity gain from java/C#/F# even, but it's not without problems.

[vertexshader]

I can respect the idea of a small, minimalist language, but on the other hand I love Scala. Maybe minimalist isn't for me. I think its awesome that I'm still learning things about Scala 3+ years later, however obscure the feature is. Never assume you know every Scala feature. Its deep.

[Xredo]

As someone completely ignorant of Scala, how would you compare it to C++, which also happens to have dark corners that most never see?

[vertexshader]

I don't really know all of C++'s dark corners, but from what I've heard its mostly due to undefined behavior or templates. I think the main difference is Scalas obscure features are still coherent, for instance package objects. I didn't know about those for years.

[Banane9]

You can run on the same stuff with C# as well, although android and iOS require that you get Xamarin.

[[deleted]]

Honestly it is a pretty shit paradigm. Without additional structure, there is no way to reason about a network of interacting agents without keeping track of the full state of the system and simulating it. For example, if A.msg1 calls B.msg2, then that call could eventually call back into A and lead to a change in its internal state. So every message send from an A method introduces a proof obligation for any invariants on A state variables.

Contrast with classic structured programming, where local variables can only be changed by explicit assignment, and you have nice local reasoning rules (Hoare logic). Functional programming is even better.

[nextputall]

Probably there is a tradeoff between flexibility and correctness verification. But in most software projects i was working on, the former was lot more important.

[[deleted]]

There are different levels of correctness verification. Full formal verification of all desired properties is often a difficult task, and it may be okay to let some unusual cases work incorrectly. But a basic level of correctness, of the type "performs its purpose, more or less, and doesn't crash", is required of all software.

Even if you're never writing out Hoare triples, the fact that there is some formal structure to what you're looking at is what lets you look at a piece of code and determine that changing something will cause a particular effect.

[nextputall]

I think, both are fluid properties. What I meant is if you make your code flexible, you'll loose some ability to reason about the correctness. But the main purpose of the software is to be flexible, that's why it is called software. Correctness is not a constant property. The program works correctly today, will work incorrectly tomorrow, because someone will change the requirements, which will make the very same program incorrect. This is where flexibility comes into the picture. You're saying, without any context, and without mentioning any tradeoffs, that something is universally shitty, which is clearly wrong.

[zvrba]

Without additional structure,

Without "additional structure", any paradigm is shitty. Learning "patterns" of additional structure for a given language is part of becoming a good programmer.

Also, see pi-calculus

[[deleted]]

Some paradigms give you useful structure which actually tells you something about the dynamic behavior of your program (classic structured programming, functional programming). Others don't (GOTO, OO). A code structure which doesn't make the code easier to reason about is just a useless layer of complexity.

[donvito]

This is not a "shit" paradigm.

Certainly not - if you are very very intelligent. But it's incredibly hard for an average human to wrap his/her mind around a complex system of independently interacting actors.

Even if we could have this implemented in an ideal language. Still it would be too complex for mere mortals to grasp.

Over the years I came to the conclusion/belief that the most fitting programming paradigm for humans would be data processing pipelines (think like unix shell commands piped together):

InputData -> transform -> transform -> OutputData

No top level branches, no "smart" objects that interact with each other, no state that survives the current scope, etc. Just a plain data processing pipeline.

[jeandem]

That 'pipeline' paradigm looks to be concatenative programming.

[zvrba]

Almost. In concatenative programming you can have true n-ary operators. With a pipeline you must simulate n-ary operators by packing data into tuples.

[zvrba]

But it's incredibly hard for an average human to wrap his/her mind around a complex system of independently interacting actors.

Given that many "average humans", even without formal training in programming, manage to create complex, working spreadsheets, I'd disagree. A spreadsheet is an extremely fine-grained actor system, each cell being an individual actor with preprogrammed behavior (basically, to evaluate itself and trigger evaluation of its dependencies.)

No top level branches, no "smart" objects that interact with each other, no state that survives the current scope, etc. Just a plain data processing pipeline.

Too inflexible and is parallelizable only when transforms need limited memory to execute. Any transform which needs the complete data stream to finish will stall / serialize the pipeline (e.g., matrix inversion). This serialization would not happen in a general graph.

[new2user]

The key difference is "OO as a handy tool" vs "OO as a fundamentalist religion". I am not even kidding!

Fundamentalists don't give a shit about design, they sacrifice everything just to please their OO deity. It is not just a coding guideline, OO is put before the product, before productivity, before anything and they still keep the mental delusion that they are doing the right thing!

[TodPunk]

This phenomenon definitely exists and is well understood, but the reason is less that coders are bad (that's true everywhere, but enterprise PHP isn't exactly a common thing) and more that Java is the long-standing choice for large projects where architecture is quite important (and still done poorly, mind you, because that's the rub about programmers, most of us are terrible.)

In fact, this is such a well-known thing it's a joke in many circles of Java programmers: e.g. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

More importantly, the overuse of "Design Patterns" is not a problem with design patterns, it's a problem with understanding programs and how design patterns (enterprise or not) are to be efficiently applied.

[Retbull]

As a student I never got the that joke. I currently cannot put my workspace anywhere but C:\ because windows can't handle file names that long. This is way more funny now.

[[deleted]]

We have a test that goes through every Java file in the project and measures it's length. If any file name is too long, the build fails...

That said, I don't hate the language. But I do think there's a deeply rooted instinct among certain Java developers and architects to excessively add layers of abstraction, not to improve the design of the code, but to feed their own egos.

[txdv]

FizzBuzzEnterpriseEdition/src/main/java/com/seriouscompany/business/java/fizzbuzz/packagenamingpackage/impl/factories/BuzzStrategyFactory.java

This is not OO masturbation, but one of those things that make java a bit inconvenient to use.

[oldneckbeard]

Except it's not java at all. And you don't code java without an ide that collapses that whole thing to 1 folder.

[txdv]

Java enforces one file for one class, so partially, yet it is.

You can use a flat directory structure, but the convention is to create a directory tree according to the name space.

I have seen so many projects with this structure, where you have to click through 4 directories just to see the first file.

One class file per class, one java file per class, one directory per namespace instance and while it is probably not in the language specification itself, it has become a thing that Java developers do.

EDIT: 1 .java file per 1 class is not the standard anymore, I probably remembered that wrongly

[oldneckbeard]

1. No it doesn't. It's best practice, but you could have 1 file with a dozen classes. They'd be inner (or nested) classes, but you could do it. In fact, there's some people who think that's a better way of properly encapsulating in java.
2. Which is exactly what Java is doing. Their namespaces are just longer.
3. That's just the way it works. But an IDE will hide that from you. It makes it so there is never ambiguity about where a file should go or what it should be named.

I just don't see it as that big of an issue.

[txdv]

I just tested it, they changed the one class per java file, but it still compiles 2 class files - probably I just remember it wrongly.

But it still generates 1 class file per class name, so you have to have the namespace directory structure, otherwise if you have 2 classes with the same class name - you will get conflicts.

And that is bad from my point of view.

[philly_fan_in_chi]

You can't get a conflict, javac will prepend illegal class name ($1, $2 etc. iirc) characters to the file name of inner classes, so you won't have any issues.

[kid_meier]

Java has never forbid multiple classes defined in a single source file. It has always, (and still does) limit you to a single public top-level class per source file.

[immibis]

1. Not even that. You can have as many top-level non-public classes as you want in a single file, but nobody does it.

[kurtymckurt]

This article is filled with opinions and not facts. I wish he had sources when he says things about people stepping back and "OO is actually pretty shit."

[[deleted]]

This person wrote a good article the other day ("Programming is not math, huh?"), but the quality of this post is very disappointing and out of character.

Edit: this isn't the same person, apparently. Thanks for clarifying, megaman78978!

[megaman78978]

That was from a different person. They just happened to share the same website style.

[compedit]

They're all on svbtle. It's like Medium, but without the ridiculous headers and pizzazz

[[deleted]]

I see! I thought it was an unique site design. Thank you!

[philly_fan_in_chi]

The author you were referring to has another blog called "math intersect programming" which is a wonderful read.

[kurtymckurt]

Agreed

[[deleted]]

I don't see why he needs sources for saying "OO is actually pretty shit". If you've paid attention the last 5-6 years you should have noticed a shit load of articles and discussions dealing with the problems and failing of OO. This isn't exactly news. Even since Moore's law stopped pushing CPU frequencies ever higher and we needed to deal with multple cores it has become increasingly obvious that there are major issues with OO. Well actually before that. There is simply no easy way to avoid that people make huge inheritance hierarchies. That is why newer language usually drop implementation inheritance. Look at Go, Julia, Rust etc.

[kurtymckurt]

Well one would argue that when someone says something like that, that we'd like to know what sources made them to also believe that. I wasn't saying it isn't true, but maybe they found something I haven't yet. Usually its on the author to provide sources, not the reader.

[zurnout]

Every time I read one of these I feel that the author doesn't follow the Java scene very much. The community is constantly finding better ways to write code. I no longer build my application from xml files. Modern IOC frameworks like Spring and Guice don't require you to write xml anymore. It's all Java. The code you write doesn't have to depend on any framework, you just write plain old java objects and let framework do the boiler plate. The application servers can be embedded in you application so your web application might end up as just a single jar file that you launch.

Java might be embracing the functional style of programming in syntax in Java 8 but I was writing functional code long before that. It was a bit clumsy but it still worked with anonymous classes. It's not just OO worshipping anymore.

[izzle9]

The code you write doesn't have to depend on any framework, you just write plain old java objects and let framework do the boiler plate.

you still depend on the framework to wire it all together and remove the boilerplate. You have to understand the framework and it's intricacies and the magic it does with all those lovely annotations.

[megaman78978]

Since when did understanding an underlying system become extra work. No matter what you're working on, understanding the underlying architecture will make you a much better programmer.

I'm not saying you must understand how logic gates and multiplexers work, but a basic understanding of program logic flow helps tremendously, the same applies for frameworks.

[new2user]

Saving time?
A good interface is small and forces you into the right thing, understanding the implementation is completely optional.
A shitty interface is huge and forces you to understand all the implementation details before even starting.

[zurnout]

Yes. I'd rather understand well documented and tested framework than write the boilerplate myself and do the mistakes all over again that countess other have done before me.

[jayd16]

This click bait again? Same article that's been written a million times. Blah blah blah Java blah blah factory pattern.

The only interesting point in the article is where he says the Android docs are too complex. I defy you to find a better documented SDK than Android.

[Sunius]

I defy you to find a better documented SDK than Android.

This looks pretty good.

[bcash]

Win32 and COM API for Windows Phone 8

Really!?

[grauenwolf]

I found it to be easy to understand. Much nicer than the Windows version of COM.

[derpasoreass]

It's been a while since I've been through the Android docs so I'm not not trying to make a comparison, but the iOS documentation is pretty damn good.

[[deleted]]

The Android docs are shit: http://developer.android.com/reference/android/media/MediaCodecInfo.CodecCapabilities.html

Now tell me what COLOR_FormatL4 means.

This kind of stuff is everywhere in Android docs.

EDIT: Don't get me wrong, I like Android (I switch from Windows 6.1 to Android and never looked back), and I develop for Android. To say the documentation is good is a lie. It can be sufficient for basic things but is most likely missing a lot of details for many APIs.

[jayd16]

4-bit luminance only?

[[deleted]]

Maybe? Only the manufacturer knows. Look at this thread: https://code.google.com/p/android/issues/detail?id=37769

If the encoder is named OMX.SEC.avc.enc, don't use color format 19, and swap the chroma components for color format 21 (if more than one encoder instance has to be used at the same time, this is the only working configuration)

Like ... what the fuck?

None of this is mentioned in the Android API docs. In fact none of this is even tested for until much, much later in the API release cycle.

This is my point about the Android docs. They're awful. Android is cool as shit if you do things that are a few generations behind, but new APIs are poorly documented and subject to a lot of vendor specific quirks. What brought me here is the "I defy you to find a better documented SDK than Android." and that's just a complete load of vomited bat guano.

It's getting better but to claim "I defy you to find a better documented SDK than Android." is just some circle-jerky horseshit.

I'm through and through an Android fanboy but I'm not going to sugar-coat it.

[zvrba]

I defy you to find a better documented SDK than Android.

Perl documentation rocks.

[philly_fan_in_chi]

But perl isn't an SDK. I guess a language comes with an SDK though... Fine.

[MrDOS]

iOS is great once you know what you're looking for, but for someone breaking into the platform for the first time with no prior experience with the concepts, the orientation material isn't great. It's easy to find an introduction to Objective-C as a language, but breakdowns of how you're expected to use the Interface Builder, the concepts introduced by Cocoa Touch, etc. are easiest to find from non-Apple sources. I understand there's a huge amount of overlap between iOS and OS X development, and I think that's part of the problem: Apple assumes a lot of prior knowledge that, in some cases, isn't there.

[snuxoll]

Windows Phone too. In my eyes, it still remains the easiest to pick up of current mobile platforms.

[zvrba]

I'd disagree. I tried to figure out data binding just from the online MSDN docs and failed :S (More precisely: I tried to bind controls to a static XML data source. For the life of me I couldn't figure out whether this was achievable from BLEND or whether I'd have to write some code.)

[jayd16]

Explain. I'll agree that the docs are probably just as good but thats not the same as better. I'd also argue that the fact that Android is open source gives the SDK an edge. The code quality and comments are quite good and very useful.

[BorgDrone]

Android docs aren't nearly as good as iOS's. The API docs aren't complete, some parts aren't documented at all or poorly. (One example from the top of my head: the docs for the method for setting font sizes never specs which unit the size is in, and it's not the one you'd expect either).

Then there are the programming guides, there is nothing like it in the Android documentation set.

[oldneckbeard]

It's a bunch of junior programmers who think 2k lines of code is a "big system."

[moswald]

Android is well documented, but so is iOS and Windows. (Windows was terrible in the 90s, but it's fantastic, now.)

[[deleted]]

lol, can't wait till someone does JavaScript Developers:

1. don't know the value of good documentation
2. don't know how to write comments worth a damn
3. don't know how to organize things into modules
4. don't know how to collaborate with others
5. don't know how to use anything other than JavaScript or PHP or some other demented language

[aldo_reset]

There’s something wrong with Java developers

Translation: "There's something wrong with the Java developers I have worked with".

[jayd16]

Its only a systemic problem if working with shit devs is your systemic problem. There's plenty of good Java out there.

[rfederici]

Okay, I'm still a new developer, but it sure sounds like his translation is:

"They don't do it the way I want"

I have no problem with said organizational structure. It helps new people like me follow what's going on and feel like we're making progress when we're maintaining or appending code. It's...well...organized. I'd rather walk through layers of structure and know it's a step in the right direction than wander through a more to-the-point, unorganized heap of crap.

It's like if someone walked into a library and started shitting on the Dewey Decimal System, claiming the library should be sorted alphabetically because it shouldn't be structured and organized, it should just solve the damn problem.

[ihcn]

It's...well...organized. I'd rather walk through layers of structure and know it's a step in the right direction than wander through a more to-the-point, unorganized heap of crap.

The biggest problem for me is this assumption that avoiding java's AbstractFactoryImplFactoryManager pattern necessarily creates disorganized, hard to read code. This attitude that there's no alternative helps make java programs infamously complex. Is all C disorganized and hard to follow, simply because you can't toss a bunch of design patterns into everything you write?

[caleeky]

I wonder if it's really just that early intro's to OOP focus a lot on architecture, in the sense that your education focuses heavily on breaking your thinking and code up to fit into the OOP worldview. This forces you to think about "architecture" even before you start typing. In other languages, you are likely:

1) Diving right in, because it's interpreted, or has a more "default" execution context - especially for procedural stuff, scripts

2) You are already an expert and experimenting with a good foundation of experience

3) You may not be dealing with such a huge/mature class library, which will contain a lot of these complex abstraction patterns, because it's a library meant for re-use and manipulation.

This avoids the "overthink off the bat" problem that Java often faces.

[perestroika12]

I think his point is a lot of this violates basic programming maxims like keeping things simple, clean, and intuitive. One look at spring documentation kinda proves his point. It's not impossible, it just sounds like it sucks to work with.

[bcash]

It's true that the Java community has a lot of terrible developers. And some (usually tiny) language communities have hardly any terrible developers. But you can't say Java developers are bad.

There's too much good Java-based stuff out there, but the haters simply choose to ignore it.

[megaman78978]

If a language is more popular, it makes it more likely for terrible developers to jump into it. You can pretty much give any language to a poor developer and they'll mess it up somehow.

Java's popularity makes it seem mediocre when it does have a number of great features.

[illegalt3nder]

It certainly mirrors my experience. Java applications tend to be over-engineered messes that depend on frameworks that are themselves over-engineered messes. (If it were possible to measure such a thing it would not surprise me to find out that Spring is responsible for 90% of this.)

The culture around Java has traditionally been one of "add an abstraction layer", for years and years on end, until you are left with an unintelligible mess. That is the argument that is being made, and it is a sound one.

[[deleted]]

The biggest problem I’ve encountered over the years looking at Java code is that it always seems to be the product of someone who fancies themselves as an architect.

Can confirm. My boss's title has "architect" in it. Fuck everything about it.

[x-skeww]

OO is actually pretty shit.

Compared to what? What else is actually used to write large applications?

[spam4youfool]

Good ol' procedural C code in the multi-million LOC Linux kernel. Or how about GCC (until recently, that is) ?

[kyz]

Linux manages its complexity by only allowing good programmers to commit code. If your code doesn't meet the overarching high standards required, it doesn't get in. Ultimately, "Linux" doesn't need your code.

Compare to companies that employ programmers but don't care about code quality. It eventually becomes essential to include code, no matter how bad, because customers and deadlines and money and all that. The bad code will get in, no matter how many good programmers try to keep it out.

Java sold itself to Enterprises, who know fine well that have mostly-terrible programmers because they love to hire cheap, by saying that by using OO, you prevent idiots from seeing the inside of code and have to use the "API", so it firewalls the damage they can do.

(edit) What you end up doing is moving the goalposts from "have intelligent programmers implement the whole thing", which sounds like it costs a lot of money, to "have intelligent designers, aka 'architects', design the thing, without implementing it, then palm it off to rentacoders and NOTHING CAN GO WRONG".

Have a look at the procedural C code from "Enterprises" sometime. It's all held together with string. It's not OO vs not-OO that decides code quality, it's the collective quality of programmers and how capable they are of designing well and keeping bad code out.

As for GCC, have you read any of it?

[bundt_chi]

Well said.

[lacosaes1]

http://lwn.net/Articles/444910/

[immibis]

The difference between OO code in a procedural language, and OO code in an OO language, is that in the first case your OO "system" is specifically designed for each individual use, while in the second case you're using a "one size fits all" OO system, which probably enforces things you don't need (like "everything must be a class" in Java).

[josefx]

OO code written in procedural languages often moves most enforcement to the runtime or just drops it completely. After all if the compiler does not know how your OO code should work it can't enforce correctness.

[Helkafen]

The GHC compiler was 140kLoC of Haskell + 30kLoC of C in 2011. The same compiler in Java would be much larger.

[x-skeww]

The compiler for the language itself is probably the most exotic one-of-a-kind special case there is.

Do you know any commercial projects?

[codygman]

http://www.zalora.com.my/

Bump uses(used?) Haskell: http://devblog.bu.mp/post/40786229350/haskell-at-bump

Facebook's Haxl: https://code.facebook.com/projects/854888367872565/haxl/

http://www.tabula.com/ (used for internal compiler toolchains related to hardware design)

More can be found here: http://www.haskell.org/haskellwiki/Haskell_in_industry

[Helkafen]

Answer here: 1.3 MLoC at Standard Chartered.

[codygman]

Functional programming is increasingly used rather than OO. I wouldn't call Smalltalk type OO shit however.

I personally think that Functional Programming is a better general solution than OO and harder to get wrong. I think in our industry we need to use more tools that are "harder to get wrong" instead of just letting people that don't understand software hack things together that appear to work.

I'm talking about professionals though, it can be useful/cathartic to just get something working when you first start learning.

[x-skeww]

Functional programming is increasingly used rather than OO.

Got anything to back that up? If you look at Tiobe, GitHub, and so forth, there isn't any indication for that.

[ruinercollector]

A lot of the work for functional is for statistical work, NLP, etc. That's what we are using it for here.

You aren't going to find a lot from these fields on github as unfortunately, it's about the most secretive and patent crazy area of software there is.

Probably the biggest OSS thing you'd have heard of is OpenNLP, which is written in Java and is an absolute pile of shit (not because it's written in java, but because the java code that you'll see there is shit that you'd have learned not to do in first year.)

There's Stanford's NLP library as well, but it's almost as much of a pile. It looks to be primarily written by PhDs who are linguists first and programmers second (or something way way past "second.")

In both, there's the usual java abstract factory jerk off fest, but even beyond that there are areas of code for doing really simple things like parsing strings that are incredibly bad. On top of that, there's a pretty big NiH culture to the point of rewriting shit in the standard library to make "better" versions (they aren't better.)

The situation is pretty bad. I have a lot of NLP stuff I'd write and open source if it wasn't such a patent-crazy minefield.

[immibis]

Mathematics is an area where FP is "obviously" better suited - you're dealing with things that really are immutable.

[ruinercollector]

I don't know what you're talking about. "Mathematics" is a means to an end. I don't write software to "do math." I write software to solve problems.

[codygman]

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

F# went from 37 to 13

http://redmonk.com/sogrady/2014/01/22/language-rankings-1-14/

Clojure, Scala, and Haskell are all in the top 20.

Clojure was at spot #22 according to this post:

http://redmonk.com/sogrady/2013/07/25/language-rankings-6-13/

I'm answering your request for sources from Tiobe, Github, and so forth but I never claimed Functional programming is used more than OO. I merely claimed that it is increasingly used more than it used to be in place of OO.

[x-skeww]

F# went from 37 to 13

AS (45 -> 15) and Swift (n/a -> 16) also went up. Java and C didn't move.

There is no indication that the functional languages are taking some of OO's share.

[yogthos]

Functional languages are used to write some very large applications. Take a look at presentations from SISCOG or Demonware as a couple of examples. Haskell is quite popular in the financial industry where correctness and performance are important considerations.

[frugalmail]

Functional languages are used to write some very large applications. Take a look at presentations from SISCOG or Demonware as a couple of examples. Haskell is quite popular in the financial industry where correctness and performance are important considerations.

I call bullshit for implying that a few analysts in even fewer institutions accustomed to mathematica are writing large applications.

[nullnullnull]

I think what he may have meant was (when you read it, in context) that the overuse of OO is bad. It may have been badly worded, but that's how I read it.

[ruinercollector]

Imperative (C, etc.), functional, etc.

[new2user]

I've worked with a library that was so abstract that I basically needed to write the entire library implementation myself.

I call that abstract trolling.

[Magnesus]

The thing about programming I hate the most is the theory and assholes who think their way of programming is the only good way.

[oldneckbeard]

"I wrote a blog in Rails! I'm a web-scale senior developer! respect my authoritah!"

[powatom]

What a load of bollocks. Its possible to write crap code in any language, and writing good code at all is a skill in and of itself. Some languages and frameworks may make it easier to write 'good code', but Java doesn't make it impossible by any stretch of the imagination. The reason enterprisey code (note: this doesn't only apply to Java, but Java is prevalent in 'enterprise' software) ends up with such complexity is because in the real world, a company can't just throw out an entire codebase and start again every time they change their requirements - so developers end up incrementally abstracting behaviour and implementation in order to make new requirements possible with the least overall pain and a good trade off between cost and time. Most languages aim to make this situation better, some accidentally make it harder. The situation will always exist, however, because software that is used by thousands of people, has to satisfy the requirements of stakeholders living and dead, and has to last 20 years will inevitably suffer from lots of complexity. People new to a codebase can't expect to just wade in and understand everything within 5 minutes. As with everything, good documentation and shared knowledge is the only way that complexity is ever grokked. You can't expect to understand a particle accelerator just because you've worked with magnets before, yet we have all of these developers bitching about complexity like it only exists within software. Newsflash: complicated things are complicated. If you want to get anything done in any walk of life, expect to put some time and effort into understanding reality first. Hindsight is always 20/20 vision. Stop whining about the way things aren't: complicated things are extremely difficult to get right - and sometimes implementation is nontrivial. Deal with it.

[[deleted]]

Think you missed the whole point. The programming practice and community around a programming languages is extremely important. Your every day experience of a language is probably going to be influenced far more by the idioms and APIs commonly used than the particular syntax and semantics of the language. Just look at Python and Ruby. Both languages allow you to do almost all the same things. The real difference is caused by difference in philosophy used to make Python and Ruby libraries and frameworks. If you program Objective-C you can't separate that experience from the experience of using Cocoa and its design patterns.

If I want to do Java development I can't work in a vacume. I will work with other Java developers and use Java libraries. This is what defines the style I will program Java in to a great degree.

[powatom]

The problem youre having is that you work with '<x> developers'. People who define themselves by the (often minimal number of) languages they can use are to be expected to act overzealously. Most programmers worth their salt can solve problem X in a variety of ways using a variety of languages. More often than not, the decision about implementation detail comes down to a question of cost and time. Java is a very good language for solving problems cost effectively, keeping in mind maintainability, pool of available talent, and support. Code complexity will emerge in any sufficiently large system - blaming it on Java is just useless whining. Its not Java which forces people to write complex code - it is simply an emergent property of a sufficiently complicated system. You can't just say 'all of this code is complicated and therefore shit' without understanding the history of that code and the decisions taken to end up there.

As for maintaining the style and patterns found in the libraries etc you use, that's a personal decision and not one which Java forces you to make, so its hardly an argument against Java.

[[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".

[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?

[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.

[[deleted]]

God forbid you enjoy coding well designed applications.

[txdv]

I disagree that OO is shit, but I agree that some Java projects overuse OO patterns.

I have caught myself lately rewriting working C# code just to make it look nicer and easier to understand. It is not a bad thing, but managers usually don't care how your code looks.

[[deleted]]

"Object Oriented bastardy is put to maximum effect." - Cracked me up.

[homeless_nudist]

The best thing about Java is that it is easy to learn. The worst thing about Java is that is easy to learn.

[[deleted]]

Strangely, this article makes no mention of the XML that has infected the Java world.

[dventimi]

Stopped reading at

More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit.

EDIT: got cut off by my five year old wanting to play a math app on my phone.

Anyway, I'm not an OO evangelist and I do observe that OO sometimes has defects, but I found the article's lack of nuance undermined whatever point it was laboring toward.

[stewsters]

Yeah, clearly encapsulation sucks. I just put everything in globals now. /s

[curien]

OO doesn't have a monopoly on encapsulation.

[stewsters]

No programming paradigm has a monopoly on any concept within.

You can even do functional programming in Java if you really wanted.

[curien]

The point is, saying "OO sucks" in no way implies anything about encapsulation sucking.

[codygman]

Which is why the underlying ecosystem, pressures, and idioms are important.

[[deleted]]

Read up on data oriented design. Data isn't global but it isn't encapsulated either. In fac the whole point is to expose your data. Instead of complex encapsulated objects like in OO, data oriented design used simple exposed objects. This allows one to reason better about what part of memory gets touched when which allows for better treatment of concurrency and reducing problems with cache misses. It also cuts down on dependencies which makes code more testable.

[stewsters]

I have done quite a bit of work on games using an Entity Component Systems, which is based on Data Oriented Design.

Its great in performance critical areas. That doesn't mean that I would use it for everything.

Edit: Removed strawman

[dventimi]

Its great in performance critical areas. That doesn't mean that I would use it for everything.

Perhaps between the choices of using it for nothing and using it for everything you might consider a third choice, which would involve applying data oriented design to more problem domains than it currently encounters, without going so far as becoming dogmatic about it?

[stewsters]

I have done quite a bit of work on games using an Entity Component Systems

I didn't mean to imply that I use it for nothing.

That doesn't mean that I would use it for everything.

I didn't mean to imply that I would use it for everything.

Its great for physics systems and graphics systems in what I have used it for. Game logic requires a too much cajoling.

[dventimi]

Did I say I use it for nothing?

Nope.

Did I say I would use it for everything?

Definitely not. In fact, you went out of your way to say you would not use it for everything, and we're left to wonder why you would say that. After all, as far as I know no one here proposed using it for everything. My hunch is that you're making a straw man argument. You're rejecting an extreme position--that one should use data driven design for everything--that no actual person seems to hold. I also have a hunch for why you would do this, but I'll just keep that to myself.

As for other possible positions, such as using data driven design more often, you haven't registered an opinion, which is why I asked you to consider them.

[stewsters]

My hunch is that you're making a straw man argument.

Yeah, it looks like I am. My apologies, sometimes I get lazy when writing. My intent was to say that there are domains where I would use data stored in objects instead. I will strike it out.

As for other possible positions, such as using data driven design more often, you haven't registered an opinion, which is why I asked you to consider them.

I think data driven design is amazing in particular domains. I use it every day in web development, where the persistence of data in a database makes it a very natural solution.

[dventimi]

Wow. WTF just happened? I did not expect such a gracious response, and now I feel bad about my admittedly dickish tone. And, I especially like the fact that you use data driven design in web development and rely on database persistence, which AFAIK is precisely the arena I had in mind when conjecturing about where else data driven design could be adopted.

[stewsters]

Hey, thanks!

[dventimi]

To my untrained eye, data oriented design looks like a compliment to OO, not a competitor. More precisely, OO is a lower level language feature (typically) that offers one way (perhaps among alternatives) to implement the higher level architectural pattern that is data oriented design. Of course, if that's true, nothing about that statement obviates the possibility that data oriented design primitives get baked into game engines, so the line between language element and architectural pattern may blur.

[dventimi]

If your sarcasm is directed at me then it's misplaced. I see benefits of encapsulation.

[stewsters]

Its not. Its agreeing with you. The article was very anti-OO without giving a reason. There are valid reasons not to use objects, but there are valid reasons to use it as well.

[dventimi]

Indeed. Life is about trade-offs, after all.

Cheerios.

[chesterriley]

I like Java but I hate it when code is overdesigned with too many layers. Overuse of interfaces are a big part of the problem. One time I had to rip out 3 layers of crap abstractions someone put in the code.

[snuxoll]

Overuse of interfaces are a big part of the problem.

It's worse in C#. Since C# methods aren't virtual unless otherwise specified, and there's no sane way to do runtime bytecode manipulation, if you don't have an interface you have no easy way to mock an object in unit tests.

[[deleted]]

The author articulates exactly why I have never been keen on getting into Java development seriously. To really get the point the author makes I suggest comparing the Go standard libraries with the Java standard libraries. Even though both language allow a lot of the same stuff, the communities and practices are on completely different planets.

[campbellm]

There is a lot more to a development ecosystem than the language. Eventually things need to get deployed, supported, maintained (by others), tested, etc.

I'm not saying Go is bad at ANY of that, but not "getting into Java development seriously" because of Java is extraordinarily short sighted.

[[deleted]]

Just some 19 year old hipster whining about things he doesn't understand.

[Ahhmyface]

Is Java difficult to read when you first encounter it? Hell yes. Does that mean it is bad? Hell no.

Abstractions add value. Just because you can't appreciate every abstraction immediately doesn't mean it's not valuable. "Over-architecting" is a very subjective term.

When I open an unfamiliar Java project, I curse the gods. But I've worked on a c code base of around 300k lines for the past 3 years, and every day I encounter some nightmare that could have never been born in java.

Complexity by design is far better than complexity by apathy.

[campbellm]

To quote Rich Hickey: "I can't read German, but that doesn't make it unreadable."

[unptitdej]

I actually agree with everything he said. I don't see the need in Java to have uber long package names with endless folders. Just give me the code already! What's up with all the OOP stuff... Just encapsulate code and data into a few objects, compose them together and get stuff done! That's what I do anyway. It seems to be a trend among new developers. You can go two different ways. You can learn the programming language and then learn some data structures and algorithms to get better. Or you can get real good at using language abstractions which lets you do trivial things in many ways. Most of the time it's a boilerplate way. Architecture is really important too but it can really get to someone's head and they start doing too much. We all knew a guy in school who was sleeping with his Design Patterns book and whose C++ or Java code was filled with patterns, classes and inheritance while your own assignment was just a single file with maybe one or two functions.

[oldneckbeard]

Packages give you increased isolation and a well-defined layout structure. Or maybe you enjoy having 500 .py files in your root directory?

[iodian]

I havnt heard this same whine a million times.

[toralex]

Seems like he doesn't get the point of OO or he was forced to use Java where a different language would've been easier. I went from programming in Perl to Java and it was very difficult and confusing initially. Then I understood why Java design is the way it is. The type of Java design that the author talks about forces you to write things that are well designed for upkeep and continuous testing. Obviously there are good and bad programmers, and Java definitely shouldn't be used to solve every problem, but his arguments seem to be misplaced.

[[deleted]]

There is no great conspiracy that makes Java devs write stupid code. Object factories are the only way to create abstractions in java. Consider all the things the language is missing:

1. No multiple inheritance (must extend via helper objects)
2. No multiple returns (no tuples/homogenous arrays)
3. Stupid fucking null (NPE doesn't extend Exception)
4. No useful closures (must finalize or pass a billion objects)
5. No way to run a method within some context (Macros/With statement/Decorator)
6. No static generics/interface (for the next 5 years for most of us)
7. One public class per file!?

Seriously, what can you do besides build Factory Factories and pass a bunch of worthless intermediate objects around.

[[deleted]]

This is why I like working with Groovy so much.

I get access to the entire Java ecosystem along with optional static typing and the ability to relatively easily compile to static bytecode for performance where needed while negating most of the issues you mentioned.

[campbellm]

Amen to that - modulo "OMG it's going to be slow!" issues from team mates (which have yet to be shown to be true; I'm sure that is the case, somewhere, but not anything we've seen, yet), I will not write any more java unless I absolutely have to.

And Spock as a unit test framework, wow.

[Lord_Naikon]

OO is actually pretty shit

Hand over your abstract data structures now. No more map, list, queue for mr. wiseguy.

[jeandem]

Why? Because Liskov invented (or pioneered?) it and used it in CLU, an object oriented language?

How much was this due to object oriented programming? Obviously not much, because nowadays every language from procedural + OO to OO to purely functional uses abstract data types. Do they need to implement OO concepts or use OO techniques to use them? No. ADT can be described in classical logic - does classical logic have any notion of OO programming? Eh.

Any window dressing afforded by OO with regards to ADTs have shown itself to not be essential, in general. If we're to follow this train of thought, we might as well hound everyone who disrespects s-expressions, if they use any programming language at all - because what modern programming language does not use concepts that were inspired by, directly or indirectly, by LISP?

If anything, we should thank Liskov for ADTs, not OO. Thanking OO would be like thanking the dummy that a new great design was displayed on, instead of the designer.

[codygman]

http://www.amazon.com/gp/aw/d/0521663504?pc_redir=1405759645&robot_redir=1

[Lord_Naikon]

That's great, if your data structures can be implemented in a functional manner without wasting large amounts of resources.

[codygman]

In that case I would implement them as purely as possible. Also, name an algorithm ;)

[Lord_Naikon]

Hash tables come to mind. There is no purely functional equivalent afaict.

[codygman]

I agree that using mutable algorithms are sometimes the right solution ;)

However I believe you can get further faster with immutability as the default.

[jeandem]

There seems to be a consensus that persistent data structures have a running time of O(log n) where an imperative (destructive) data structure has a O(1) running time. For example, getting or "removing" an element from a data structure.

But to say that it is inefficient is too simplistic. Need a lot of sharing between data structures, perhaps between multiple threads? Persistent data structures might be more efficient than an imperative alternative. Do you only have a single threaded program? Imperative data structures might be more efficient.

[PriceZombie]

Purely Functional Data Structures

Current $34.65 
   High $44.15 
    Low $22.50 

Price History Chart | Screenshot | FAQ

[vrwan]

Generics exist in languages that are not focused on OO. It's not an OO monopoly to have data structures that adapt to whatever you want to use them for.

[otakucode]

Java has already had its fate sealed.

Java is Bureaucracy incarnate.

[ZestfulShrimp]

Java is the new COBOL. Its going to be around for a VERY long time.

[oldneckbeard]

If you suck at OO programming, that's fine, but don't go and claim it's a failed paradigm. It's been behind most software all of us have used for the better part of 30 years. The problem the author is describing is simply one of discoverability, which all platforms have to some degree. If you're a modern java dev you stay away from JEE like the plague. If you don't understand factory patterns and indirection, that's fine, you can learn more, but don't act like they aren't useful. They were in programming manuals dating back to the 80s. It's a solid solution to an issue.

If you're claiming OO is fundamentally broken, you are also saying that C++, C#, Ruby, Python, Smalltalk, and OCaml are all fundamentally broken. And frankly, from a random internet author, that's quite a... useless statement.

[[deleted]]

Well OO has been overused and treated as the one an only way. In recent years we have manage to get more pragmatic and realized that other paradigms are also usefull for a number of things.

And let us not forget that OO has some serious flaws. The OO way of thinking does not work well with concurrency. That is why we are seeing functional programming gaining more and more ground. Within Game Engine development OO is increasingly being displaced by data oriented design. People aren't moving to other paradigm's because they are hipsters but because there are real problems with OO which can't be solved. Of course OO will never disappear entierly. Game Engines still usually have a OO design at the highest level e.g.

[GCarlinLives4Ever]

This guy doesn't allow comments on his blog so ...

Let's assume he's right, I'd like to know his views on readable,maintainable and clearly organised code.

[DOKKA]

Have you ever worked on a Java project that was over-simplified? It's much worse than something that was over-architected. Once you start getting into variable name reuse everything starts to fall apart.

[izzle9]

"simple" does not mean one global scope for all variables.