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

51–60 of 321 posts

Re: Java Developers

#51

Post by needusername »

icebraining wrote: post #20
skrebbel wrote: post #11

A lot of these bloated patterns that got popular in the Java world have shorter, simpler alternatives when programming in a functional style. You often don't need multiple child classes to implement a template method if you can just pass a function to the constructor. You don't need a BananaFactory if you can just inject a createBanana function. Remarkably many Gang of Four design patterns are unneeded once you can p…

I don't think Android supports Java 8, though.

I don't think Android supports even Java 7. Sure, maybe source level but AFAIK invokedynamic and method handles are still missing.

Re: Java Developers

#52

Post by godzilla82 »

watwut wrote: post #21
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?

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.

Re: Java Developers

#53

Post by DCKing »

seanmcdirmid wrote: post #15

> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do. > Even today you’ll still find a strong b…

> Because we all know, Google is known for hiring flakes who can't code or design real systems.

The primary reason Java is the language used for Android is the very same reason that Android is used so much in enterprises: it is easy to learn, and easy to get developers for. But the language's primary redeeming quality has become an economic one, and not that the language itself is so rewarding.

Re: Java Developers

#54

Post by seanmcdirmid »

thaumaturgy wrote: post #31
seanmcdirmid wrote: post #15

> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do. > Even today you’ll still find a strong b…

> OO actually works well for scaling complexity, much better than toy immutable functions do. Sure, but the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled. A low-hanging example of this is the singleton pattern, and the Wikipedia section titled "Example of use with the Abstract Factory pattern" saves me from having to bother making…

If you get good at programming, you actually know when to apply these patterns (and many others not in the GoF bible).

And of course, I mix OOP and FP styles all the time, I'm not a purist by any means (a guy who does F# once commented on how FP my C# code looked).

Re: Java Developers

#55

Post by seanmcdirmid »

DCKing wrote: post #53
seanmcdirmid wrote: post #15

> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do. > Even today you’ll still find a strong b…

> Because we all know, Google is known for hiring flakes who can't code or design real systems. The primary reason Java is the language used for Android is the very same reason that Android is used so much in enterprises: it is easy to learn, and easy to get developers for. But the language's primary redeeming quality has become an economic one, and not that the language itself is so rewarding.

Most of the Googlers I know writing Java code would rather not be writing Java code. They would prefer Python or even Javascript (and a lot of FP enthusiasts also), but Java is what Android needs so Java it is. I would be very surprised if Google was hiring many people who only knew Java or were even very enthusiastic about it.

Perhaps the only language more reviled than Java in Google is C++.

Re: Java Developers

#56

Post by threeseed »

_pmf_ wrote: post #41
threeseed wrote: post #29

Earlier quoted context omitted.

Actually there are "real systems" being written in FP e.g. Clojure @ SoundCloud. They just aren't architected the same way. Instead of a monolithic WAR you end up with a series of micro services. FP is actually more suited than OO for micro services since it naturally forces developers down the "do one thing well" approach. So I would stop with the "OO is what real people use" nonsense if I were you. Because language…

> Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space Let's see how much of the momentum these languages keep after Java 8. Default methods, the new stream API and lamdas provide much what most developers need without introducing baroque features and orthogonal infrastructure.

If you think those features change anything then you must have a poor understanding of FP or why people are moving to Scala/Clojure. It is a fundamentally different way of developing code that is starting to look really appealing to the enterprise.

The iterative development with a REPL approach deployed with micro services lends itself well to Agile development where big bang architecture simply doesn't work.

Re: Java Developers

#57

Post by cousin_it »

gb wrote: post #40
cousin_it wrote: post #34

Earlier quoted context omitted.

Interesting! The most important difference between frameworks and libraries seems to be the "don't call me, I'll call you" pattern. Frameworks call your code, while libraries get called by your code. It's easy to see why "don't call me, I'll call you" leads to unreadable code. A piece of code is readable if you can understand how it works, not just what it does, and a big part of "how it works" is figuring out the co…

The main advantage is when doing something like this is Haskell the code you pass around can't have arbitrary side effects, so you don't actually need to worry so much about where it is called.

Yeah, I agree that having no side effects helps quite a bit. But you still need to understand control flow to reason about time and space complexity, which are a sort of "unavoidable effects".

Re: Java Developers

#58

Post by threeseed »

seanmcdirmid wrote: post #49
threeseed wrote: post #29

Earlier quoted context omitted.

Actually there are "real systems" being written in FP e.g. Clojure @ SoundCloud. They just aren't architected the same way. Instead of a monolithic WAR you end up with a series of micro services. FP is actually more suited than OO for micro services since it naturally forces developers down the "do one thing well" approach. So I would stop with the "OO is what real people use" nonsense if I were you. Because language…

I worked on Scala for two years seven or so years ago (2005-2007), and I'm not really worried about it (Scala is a great OOP language, and a soso FP language). Compared to Scala, Clojure has a minuscule user base (as one would expect for a Lisp).

Well there is an overwhelming trend towards Scala/Clojure both in the enterprise and for large internet sites. When companies like Twitter, LinkedIn, Foursquare, Netflix, eBay etc start embracing FP languages you can be sure the rest of the world takes notice.

My point was that serious companies are doing serious work with FP languages.

Re: Java Developers

#59

Post by falcor84 »

cousin_it wrote: post #34
mobiuscog wrote: post #19

I agree with much of the article (also as being a java developer for the last 17 years). However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem: Frameworks. Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is a…

Interesting! The most important difference between frameworks and libraries seems to be the "don't call me, I'll call you" pattern. Frameworks call your code, while libraries get called by your code. It's easy to see why "don't call me, I'll call you" leads to unreadable code. A piece of code is readable if you can understand how it works, not just what it does, and a big part of "how it works" is figuring out the co…

+1 for the last sentence. I get this nice "do this, then do that" understandability feeling when I work with python scripting of cloud services (e.g. AWS with boto). You get all the powerful apis and OOP mechanics boiling down to readable procedural code with helper functions.

Re: Java Developers

#60

Post by dmacvicar »

While I have seen what you describe, I am not sure if it is only specific to Java, and I have to admit that I enjoy working with the Java platform. There are things in the ecosystem that annoy me more.

We use Java in a non-standard environment: products built on a enterprise Linux distribution, and therefore built using the same infrastructure and conventions: everything is built from source as a dependency chain, so that you can patch it and provide support, and ship those patched components back as packages. Everything is built in a repeatable environment, jailed in a VM, no network, that only contains the dependencies you declared.

So there were those nice times where building a Java library meant packaging 2 or 3 dependencies, then packaging the library was as simple as unpacking, apply any patches, set the classpath to the dependencies and run ant. Then install the resulting jar. It played well with the environment.

Java build tools are insane.

To build most libraries I now need Maven. Maven needs like a hundred dependencies to build, plus some plugins that need those dependencies, and those plugins build with Maven, the dependencies too. At the end, to build Maven, you need to have all components which are the reason you are building Maven in the first place.

So this makes me thing Java developers don't think in terms of layers, and they pull dependencies without balancing the costs (writing one function vs depending on 20 more jars).

A build tool should have almost no dependencies outside of the base system (in this case the JDK) and the compiler.

But no, they added even a Dependency Injection container. And now they realized that the one from Google is better, so they switch to it, but without removing the old. So now they may be depend on 150 packages instead of 100. Great. Lets add more stuff.

Imagine if to build make you need to have Gtk, and a library that builds with cmake and another library that builds with scons.

And all the noise with this advanced nuclear engines and frameworks to power something as simple as a build tools is at the end useless. At some point the project still declares technical bankruptcy and dies. Java has a lot of "choice" in terms of libraries, but a good percentage of them are dead projects.

Post reply on HN