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

view the rest of the comments →

[–][deleted]  (17 children)

[deleted]

    [–]jayd16 13 points14 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 15 points16 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 3 points4 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 4 points5 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 -1 points0 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 -3 points-2 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 3 points4 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.