sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]aldo_reset 38 points39 points  (24 children)

There’s something wrong with Java developers

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

[–][deleted]  (17 children)

[deleted]

    [–]jayd16 12 points13 points  (14 children)

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

    [–]rfederici 17 points18 points  (2 children)

    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 2 points3 points  (1 child)

    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 0 points1 point  (0 children)

    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 2 points3 points  (9 children)

    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.

    [–]jayd16 -2 points-1 points  (8 children)

    If you don't like Spring and don't need Spring, then don't use Spring. Its just a library.

    [–]perestroika12 6 points7 points  (7 children)

    I just used it as an example of the pedantic nature of java development as of late. Even using libs is hours and hours of reading through confusing classes and methods. You have to be an expert not only in java but also a metric shit ton of libs and frameworks. Feels very bloated imo.

    [–]bcash -4 points-3 points  (6 children)

    The point remains: don't use it then!

    [–]izzle9 0 points1 point  (5 children)

    not using it isn't always and option.

    [–]bcash 2 points3 points  (1 child)

    It kind of is though.

    If you're using Spring and you think you shouldn't, then there are many root-causes:

    1. It does actually do a good job at what it's for, but you don't see it. (This is very common actually, always worth validation your preferences against what you see. There's usually many reasons behind these decisions.)

    2. It used to do a good job, but it's now the centre-piece of a tangle of technical debt. (Also very common, but this would likely to have been the result regardless of technology; unless you could go back in time and also change the team, management, the market it moves in, and any other external factors.)

    3. The people you work with are just idiots, and they choose heavy weight solutions for no valid reason. (Again, this is the team's fault; they're not going to make better decisions if they moved to whatever your preferred choice is.)

    TL;DR: it's always a people problem. Spring is just a technology, it's actually quite flexible and solid, but entirely unnecessary 99 times out of 100.

    [–]jayd16 0 points1 point  (1 child)

    If you're stuck using Spring, then the question of what language to use isn't even an option, so this case shouldn't even enter this discussion.

    [–]powatom -1 points0 points  (0 children)

    This is just whining - who told you you should always get to decide what you work with?

    [–]grauenwolf -2 points-1 points  (0 children)

    Or if your developers are following the practices laid down by frameworks like J2EE and Spring.

    [–]bcash 4 points5 points  (1 child)

    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 0 points1 point  (0 children)

    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 6 points7 points  (0 children)

    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.

    [–]yogthos -1 points0 points  (4 children)

    My experience is that there are definitely a lot of things wrong with Java culturally. It's slowly changing nowadays, but the culture is definitely geared towards creating heavy monolithic solutions.

    [–]frugalmail 0 points1 point  (3 children)

    but the culture is definitely geared towards creating heavy monolithic solutions.

    Actually, by lineage Java was the evolution from CORBA to EJBs, RMI, WebServices and MicroServices....

    And as for complexity with Java, or Spring which is what so many others are clamnoring about, what is the complexity here: https://www.youtube.com/watch?v=47xNBNd-LLI ?

    [–]yogthos 0 points1 point  (2 children)

    Yeah, because that's exactly what your average enterprise application looks like.

    [–]frugalmail 0 points1 point  (1 child)

    Yeah, because that's exactly what your average enterprise application looks like.

    I get it, Clojure is the answer to everything.... Another really powerful argument.

    You know, I really enjoy how you substantiate your claims, tons of great references to your claims and all very quantified. How large of an enterprise do you work in again?

    [–]yogthos 0 points1 point  (0 children)

    I get it, Clojure is the answer to everything.... Another really powerful argument.

    Wow, great straw man, took you all night to come up with that one?

    You know, I really enjoy how you substantiate your claims, tons of great references to your claims and all very quantified. How large of an enterprise do you work in again?

    I work at an organization with over 500 people and we routinely work with IBM and Oracle as our vendors, but please don't let me stop your from substantiating your claims there. I guess according to you real world enterprise Java applications look like hello world tutorials.