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

Java Developers

nsainsbury.svbtle.com

Post reply on HN
Print view View original

141–150 of 321 posts

Re: Java Developers

#141

Post by larsmak »

I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either.

I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past.

When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.

Re: Java Developers

#142

Post by watwut »

godzilla82 wrote: post #52
watwut wrote: post #21

Earlier quoted context omitted.

Hard coded logger instantiation in a library is anti-pattern. Whoever is using your library usually has his own opinions on how much of your stuff he wants in logs.

Why are you assuming that he is writing a library? I have seen people bloat up simple java applications with provision for future requirements which will never happen in the real world.

Logging is still weird example to pick up for it. First, it make sense to have it configurable in production (and yes we ask clients to raise logging level in production we have no access to in case of troubleshooting).

Second, it is not like each java program would be inventing its own super complicated xml like logging configuration. It is pretty much always done the same standard way. Pretty much every java app uses one of two standard logging libraries and those libraries share the same API.

You can configure that standard API in xml, through properties file or in code and all three methods are basically the same thing in three different syntaxes. None of them is easier or harder then the other two and everyone is familiar with both xml and properties file one.

No one normally obsess about logging code too much. It is the least obtrusive easiest to do part of anything you can possibly work at.

Re: Java Developers

#143

Post by seanmcdirmid »

pjmlp wrote: post #134
agumonkey wrote: post #97

Earlier quoted context omitted.

I never found a way to sense the differences between OOP flavours (NPI). Are you thinking of ST/Ruby where it's object and method all the way down ?

There are many models: - OO like in Smalltalk - OO like in SELF - OO like in BETA - OO like in CLOS - OO like in COM - OO like in Haskell - OO like in C++ - OO like in Eiffel - OO like in Ada - OO like in Sather A few more models might exist.

HyperCard and AppleScript. And JavaScript is pretty unique at this point. Scala's OO is also pretty unique with traits and type members.

Re: Java Developers

#145

Post by virmundi »

Having worked in the Java world for the past 8 years, I think the issue with the developers is that the work is boring and they want to solve some problem. Folk who work with Ruby (at least 2-3 years ago) were doing something interesting. It could be a simple CRUD app, but Ruby made it interesting. People wanted to be there. Java is not.

Instead, Java has a history of patterns for the sake of interest. Need to inject something in? Use a FactoryFactory. Most of what Java becomes revolves around having to do tedious CRUD apps for the enterprise that constantly change what they want.

Re: Java Developers

#146

Post by sigmaml »

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

It is sad to see such strongly-worded blanket statements. The author generalises his experiences with Java to entire OO. He doesn't, unfortunately, seem to realise that non-Java OO does exist.

Also, several lean Java frameworks exist, without deep class hierarchies and factories of factories.

Finally, OO is one of several possible ways to modularise and scale code and teams. FP is another. As languages like Scala have been demonstrating, it is possible to selectively blend features of both in fruitful ways.

Re: Java Developers

#147

Post by seanmcdirmid »

sigmaml wrote: post #133
DCKing wrote: post #99

Earlier quoted context omitted.

The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong. Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, an…

> The key selling point of functional languages is not lambdas, but immutable state and referential transparency. Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.

I'm going to agree with parent. OO programming is mostly about objects...they have names and identity, with that identity they can have mutable state (would be difficult to have state without identity and aliasing). In pure functional programming land, all values are anonymous, there is no way to tell if you seen something for unless you setup a GUID in the value (which would also require state, but whatever). Those values have no identity, so mutable state is impossible, leading to a very different style of programming.

If you allow for value identities (via GUIDs or if your language is really impure) in your functional code, you wind up with a style of programming that is very similar to programming with objects (messaging those values to do things with their state). Heck, you wouldn't even need overt mutable state to arrive at a very OO style (see clojure).

Re: Java Developers

#148

Post by virmundi »

malka wrote: post #14
Hermel wrote: post #5

There is a lot of Cargo Cult programming going on among Java developers. Why using a simple constructor when you can use the factory design pattern? Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?

over the years, I developped a fiery hatred of XML configuration files.

Over the years I've developed a deep understanding for why XML configuration is great. Java's move to annotation, upon annotation. As a result there is no single, canonical place I can go to see what the general configuration is. I have to track through classes, that may or may not have a good structure to find a specific instance of a route. Spring 3.x configurations, with inheritance are wonderful. The only work is to follow the imports.

Re: Java Developers

#149

Post by adwn »

pjmlp wrote: post #134
agumonkey wrote: post #97

Earlier quoted context omitted.

I never found a way to sense the differences between OOP flavours (NPI). Are you thinking of ST/Ruby where it's object and method all the way down ?

There are many models: - OO like in Smalltalk - OO like in SELF - OO like in BETA - OO like in CLOS - OO like in COM - OO like in Haskell - OO like in C++ - OO like in Eiffel - OO like in Ada - OO like in Sather A few more models might exist.

> OO like in Haskell

Please explain. Are you referring to type classes?

Re: Java Developers

#150

Post by robmccoll »

So happy to read this, yes, yes, and yes.

Another big problem with Java to me is that the standard library and available frameworks are so massive, that there are thousands of ways to solve any given problem. This is bad, because only a handful of the solutions perform well, result in readable well-written code, and are efficient (from both a productivity perspective and resource utilization perspective). I'm not sure why, but it seems like many developers are almost trained to pick the bad ones. Perhaps the high level of abstraction enables the programmer to ignore the realities of the implementation?

Post reply on HN