Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java: Real or Not?

java.metagno.me

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Java: Real or Not?

#31

Post by mooreds »

smoyer wrote: post #26
vbezhenar wrote: post #18

Earlier quoted context omitted.

I use Spring and I'm not agree that it's a mess. It has a lot of functionality but good architecture allows to keep it under control and easily enhance when needed. Spring is one of the best open source frameworks I've ever seen.

Both Spring and JavaEE (as compared to J2EE) have gotten a lot better by using annotations for meta-programming. I was about to give up on enterprise Java programming when the clutter/over-engineering started to get better. Curiously, I'm going to at least partially credit Ruby for introducing the idea of convention over configuration.

Why curiously? RoR hit hit java web development like a ton of bricks, with its convention over configuration and quick start. The end result are java projects like Play and Spring Boot.

I am not really a ruby guy, but I'm very thankful RoR came along and shook things up.

Re: Java: Real or Not?

#32

Post by tomjen3 »

aikah wrote: post #25
gfodor wrote: post #10

Earlier quoted context omitted.

This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.

SOLID are not rules but guidelines. Design patterns allow the code to be written in a reusable manner by decoupling some responsibilities. But YAGNI, no code should be written until it is needed. That's why TDD is absolutely fundamental. In theory TDD can help fight over-engineering, and keep focus on relevant code. SOLID and design patterns are then here to help refactor code when a spec changes. They are recipes. O…

TDD means you write code that is easy to test, rather than easy to adapt to your use case. Find the use case for your code, code that (and now more), add tests as desired/needed.

In your example we can observe that we still only have one action: print $VARIABLE if $COUNTER mod $VALUE. This doesn't call for anything like a chain of responsibility, since it can be solved by a collection of tuples and a for loop.

My personal guess about the difference between an average programmer and a good one is that the good one knows when to add space for more features (because he can anticipate the customers needs).

Re: Java: Real or Not?

#34

Post by tsotha »

tomjen3 wrote: post #32
aikah wrote: post #25

Earlier quoted context omitted.

SOLID are not rules but guidelines. Design patterns allow the code to be written in a reusable manner by decoupling some responsibilities. But YAGNI, no code should be written until it is needed. That's why TDD is absolutely fundamental. In theory TDD can help fight over-engineering, and keep focus on relevant code. SOLID and design patterns are then here to help refactor code when a spec changes. They are recipes. O…

TDD means you write code that is easy to test, rather than easy to adapt to your use case. Find the use case for your code, code that (and now more), add tests as desired/needed. In your example we can observe that we still only have one action: print $VARIABLE if $COUNTER mod $VALUE. This doesn't call for anything like a chain of responsibility, since it can be solved by a collection of tuples and a for loop. My per…

I think there's a lot of truth to this. Adding flexibility on one dimension almost invariably makes other kinds of changes more difficult, so you come out far ahead if you can correctly anticipate the direction in which your application is likely to grow.

Re: Java: Real or Not?

#35

Post by ignoramous »

gfodor wrote: post #10
overgard wrote: post #4

It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.

It is fancy around these parts to bash OOP and other things that aren't JavaScript/Clojure/Haskell/Rust/etc;

DRY, SRP, LSP, OCP are very valuable. There's a reason there's a score of enterprise-grade software being written with exactly those principles in mind. I am not discounting Functional Programming in anyway. But to dismiss OOP and the design patterns is a fool's errand. It has its place, and rightly so.

Look at what the programming Lords (Ken Thompson! Rob Pike! Lars Bak!) at Google came up with when they sat down to design a language-- Go (which is part-OO, part-imperative [1]), or Dart (OO again). OO detractors often point out that "popular opinion isn't always right" and that "people are afraid of change" and there's some level of truth to that, but the fact is, a lot of developers out there are proficient with OO, and see it as a good way to develop massive programs (1 million plus SLOC) unless some radical shift happens in the coming years [2].

[1] https://golang.org/doc/faq#Is_Go_an_object-oriented_language

[2] http://worrydream.com/LearnableProgramming/

Re: Java: Real or Not?

#36

Post by Gibbon1 »

Nitramp wrote: post #14

The names are extremely predictable (as shown by this Markov chain), which is actually a Good Thing (tm). The bad thing is that things got complex enough to warrant these names. It's the knee jerk reflex of decoupling everything, to the point that you have 80% configuration/wiring/setup vs 20% of code that actually does something useful. Each extension point in the framework is represented by a couple of these classe…

What struck me is it looks seriously like Hungarian notation applied to function naming.

Re: Java: Real or Not?

#37

Post by the8472 »

parasubvert wrote: post #29

This is sort of like making fun of German for using long combinations of smaller words to denote a concept. Or making fun of medical jargon. (ha ha, you said subdermal hematoma not bruise) Once you know what the individual words mean, you can use them in different places, and know right away what the class does. Do you need to use 80% of these? No, but they're there, like parts in a car, in case you need to tinker.

And it's not like anyone is typing these words out. IDEs have auto-completion for that purpose.

Re: Java: Real or Not?

#38

Post by gutnor »

gfodor wrote: post #10
overgard wrote: post #4

It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.

There is always a time when you go too far and a time when you don't get far enough. If you can, you refactor when it becomes clear.

In the case of Spring though, they have a tough problem to solve. They are gluing technologies together, so they are always going to have factories of factories, adapter of adapter, and that kind of things. And if in the bunch of tech they glue there is an outlier that behaves unlike the other, or a poorly designed one, they will need to handle it somehow.

Another feature that weights on Spring design is that almost the whole framework is public. Generally you would have a core architecture and well defined key extension points. Not with Spring, and that means more "useless" abstraction and therefore more mess.

Re: Java: Real or Not?

#39

Post by grayrest »

gfodor wrote: post #10
overgard wrote: post #4

It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.

I believe that humans are terrible at predicting the outcomes of complex systems over time and that software you get paid to write is always a complex system. Therefore, the best way to make your software better is to choose the option that produces less state. This has been my guiding principle of software development for about 6 years. The main problem I ran into is that going too far results in software that's hard to maintain because control flow jumps around.

My solution has been to think of code locality as being valuable. I start off writing something the straightforward way. When I go to implement something similar, I decide whether to abstract the code or not based on how much easier/harder it will be to naively trace the code. If I've done this thing 3 or 4 times, it's a concern and should be separated. If I'm just making something shorter/"nicer"/DRYer I should probably just write stupid code.

Re: Java: Real or Not?

#40

Post by impostervt »

Spring is not the only framework with bad names; look at this class name from aspectj:

org.aspectj.weaver.patterns .HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor

Post reply on HN