4 ms·

I agree that there are plenty of warts to be found in various well-known Java libraries, and that there is a shocking amount of poorly architected Java out ther

I agree that there are plenty of warts to be found in various well-known Java libraries, and that there is a shocking amount of poorly architected Java out there, but I can't agree that it's the language's fault. Java has become the language of "the noob." For a very large percentage of programmers, it's the first language that's presented to them. As such, there are endless examples of Java projects written by people who are still struggling with basic flow control, let alone project architecture. Some of these projects are written by smart people, and they're genuinely useful. As an example, think of the research biologist who's writing code for her thesis - code for which there's probably no measurable market. Because it's the language of the noob, it's really easy to gain the kind of experience this author is describing. The kind where you just glide along, "turning the crank" not really learning anything for a long, long time. People come away honestly believing that because they've worked with the language for so long they're experts. That there's nothing left which will surprise them, or change the way they work in this language. I've seen a lot of cases where these people bump up against some really cool things and never realize it. Because they don't understand it they quickly write it off as bad code/architecture/naming. One of the most common examples I've seen of this is when people pull class names from the Spring application framework core, parading them around with no context and no knowledge of why they exist or why they might be incredibly useful, let alone why they sometimes make Java a joy to work with. "AbstractSingletonProxyFactoryBean??! I don't care what it is, that's just stupid!" [1] How ignorant. > After all, you produced 576 classes that contain 10,000 lines of Java code, all of it seemingly essential, so you were doing your job. I can agree that Java is a verbose language, and sometimes it's really difficult to express an abstraction succinctly as compared to some other languages. I can agree that it's also easy for people to run wild and over abstract. However, I think it's just as likely for people to mistake well abstracted code for needlessly verbose code. > And nobody can glare at you and demand to know why you used 576 classes when you should have used 50... Without a specific case, it's hard to figure out what's really going on here, but if this is a primary target metric, I'd say you're prioritizing the wrong things. > ... because in Java doing it with only 50 classes is probably impossible. Just throw separation of concerns out the window and you can write just about anything in one class. 1: http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...

ahomescu1 13y ago
> Java has become the language of "the noob." Along with PHP (for different purposes, though).
Daishiman 13y ago
> I can agree that Java is a verbose language, and sometimes it's really difficult to express an abstraction succinctly as compared to some other languages. I can agree that it's also easy for people to run wild and over abstract. However, I think it's just as likely for people to mistake well abstracted code for needlessly verbose code. See, this is a mistake. Abstraction is not an end in itself; it's there to make life easier and to make things easier to undestand. Bloat is one of the many things abstraction is supposed to reduce; if an abstraction is increasing cognitive overhead and reducing the signal-to-noise ratio, then we've got ourselves a problem. For reasons that I cannot comprehend, Java seems to be the only language that seems to have excessive abstraction as a requirement. Not as a convenience, not as a nicety, but as a requirement to do things like Dependency Injection, Inversion of Control, Unit Testing, Mocks, logging, etc. The fact that you need to use entire frameworks to accomplish the functionality that in many languages is covered by a couple functions in a built-in module is a mystery to me. I'm not the wisest expert, but I have over a decade in a field and I've worked in all sorts of different software, and Java (along with some very badly written .NET systems) seems to be the only technology that requires me to grok a dozen files to understand basic workings of MVC systems with the most elementary of logic. And the thing is, 90% of that code is absolutely useless to the extent of the use cases proposed by the system, and none of its potential extensibility is actually used. You have to ask yourself how come neither Python nor Haskell have these monstruous frameworks. Sure, it's a lot better now, after having caught up 8 years behind the rest of technologies, but the foundations are notoriously complicated for things that are effortless with other tools. This points to me towards the idea that Java abstractions have simply been poorly chosen.
- benjamincburns 13y ago
  > See, this is a mistake. Abstraction is not an end in itself; it's there to make life easier and to make things easier to undestand. > Bloat is one of the many things abstraction is supposed to reduce; if an abstraction is increasing cognitive overhead and reducing the signal-to-noise ratio, then we've got ourselves a problem. I whole-heartedly agree, but I'd caution readers not to conflate abstraction with bloat. If it's bloat, chances are you're abstracting the wrong details, and working on a system suffering from poor cohesion. > For reasons that I cannot comprehend, Java seems to be the only language that seems to have excessive abstraction as a requirement. Not as a convenience, not as a nicety, but as a requirement to do things like Dependency Injection, Inversion of Control, Unit Testing, Mocks, logging, etc. The fact that you need to use entire frameworks to accomplish the functionality that in many languages is covered by a couple functions in a built-in module is a mystery to me. I'm not sure I follow. Are you saying that you think it's wrong or inconvenient that these features aren't somehow natively supported by the language? That is, that you'd like to have a grammar/syntax around each one of these things which ultimately boils down to a bunch of hidden runtime anyway? Maybe it might help to clarify that I'm defending Java the language, not Java the runtime library. > Java ... seems to be the only technology that requires me to grok a dozen files to understand basic workings of MVC systems with the most elementary of logic I do agree that web frameworks in Java are one area where there's just tons of bloat, but I still don't think that has anything to do with how the language is designed. My advice: get a better MVC. There's nothing about MVC that says you must use a framework. (Edit: if it's the container that you're fighting with, there are tons of other options out there aside from the mainstream few). Also, check out the network code in the Linux kernel sometime. Beautiful code, but holy shit do you need to shave a whole heard of yaks the first time you go to read it. The cognitive overhead is high, but each one of those abstractions is there for a reason. > This points to me towards the idea that Java abstractions have simply been poorly chosen. Again, given that I'm talking about the language alone, not the runtime library, if you still uphold your response I'd ask you to consider who's fault it might be that the abstractions used in your program(s) are poorly chosen. It's quite rare that it's the fault of the language.

ahomescu1 13y ago

> Java has become the language of "the noob." Along with PHP (for different purposes, though).

Daishiman 13y ago

> I can agree that Java is a verbose language, and sometimes it's really difficult to express an abstraction succinctly as compared to some other languages. I can agree that it's also easy for people to run wild and over abstract. However, I think it's just as likely for people to mistake well abstracted code for needlessly verbose code. See, this is a mistake. Abstraction is not an end in itself; it's there to make life easier and to make things easier to undestand. Bloat is one of the many things abstraction is supposed to reduce; if an abstraction is increasing cognitive overhead and reducing the signal-to-noise ratio, then we've got ourselves a problem. For reasons that I cannot comprehend, Java seems to be the only language that seems to have excessive abstraction as a requirement. Not as a convenience, not as a nicety, but as a requirement to do things like Dependency Injection, Inversion of Control, Unit Testing, Mocks, logging, etc. The fact that you need to use entire frameworks to accomplish the functionality that in many languages is covered by a couple functions in a built-in module is a mystery to me. I'm not the wisest expert, but I have over a decade in a field and I've worked in all sorts of different software, and Java (along with some very badly written .NET systems) seems to be the only technology that requires me to grok a dozen files to understand basic workings of MVC systems with the most elementary of logic. And the thing is, 90% of that code is absolutely useless to the extent of the use cases proposed by the system, and none of its potential extensibility is actually used. You have to ask yourself how come neither Python nor Haskell have these monstruous frameworks. Sure, it's a lot better now, after having caught up 8 years behind the rest of technologies, but the foundations are notoriously complicated for things that are effortless with other tools. This points to me towards the idea that Java abstractions have simply been poorly chosen.

benjamincburns 13y ago
> See, this is a mistake. Abstraction is not an end in itself; it's there to make life easier and to make things easier to undestand. > Bloat is one of the many things abstraction is supposed to reduce; if an abstraction is increasing cognitive overhead and reducing the signal-to-noise ratio, then we've got ourselves a problem. I whole-heartedly agree, but I'd caution readers not to conflate abstraction with bloat. If it's bloat, chances are you're abstracting the wrong details, and working on a system suffering from poor cohesion. > For reasons that I cannot comprehend, Java seems to be the only language that seems to have excessive abstraction as a requirement. Not as a convenience, not as a nicety, but as a requirement to do things like Dependency Injection, Inversion of Control, Unit Testing, Mocks, logging, etc. The fact that you need to use entire frameworks to accomplish the functionality that in many languages is covered by a couple functions in a built-in module is a mystery to me. I'm not sure I follow. Are you saying that you think it's wrong or inconvenient that these features aren't somehow natively supported by the language? That is, that you'd like to have a grammar/syntax around each one of these things which ultimately boils down to a bunch of hidden runtime anyway? Maybe it might help to clarify that I'm defending Java the language, not Java the runtime library. > Java ... seems to be the only technology that requires me to grok a dozen files to understand basic workings of MVC systems with the most elementary of logic I do agree that web frameworks in Java are one area where there's just tons of bloat, but I still don't think that has anything to do with how the language is designed. My advice: get a better MVC. There's nothing about MVC that says you must use a framework. (Edit: if it's the container that you're fighting with, there are tons of other options out there aside from the mainstream few). Also, check out the network code in the Linux kernel sometime. Beautiful code, but holy shit do you need to shave a whole heard of yaks the first time you go to read it. The cognitive overhead is high, but each one of those abstractions is there for a reason. > This points to me towards the idea that Java abstractions have simply been poorly chosen. Again, given that I'm talking about the language alone, not the runtime library, if you still uphold your response I'd ask you to consider who's fault it might be that the abstractions used in your program(s) are poorly chosen. It's quite rare that it's the fault of the language.