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

101–110 of 321 posts

Re: Java Developers

#101

Post by dozzie »

matthewmacleod wrote: post #64
dozzie wrote: post #8

Earlier quoted context omitted.

Simplicity -- none, if talking about the resulting code. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Performance -- poor, regarding memory consumption. Indeed, the sweet spot. > If you need lots of cheap developers [...] Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. It's t…

Simplicity -- none, if talking about the resulting code. Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Bollocks. I challenge you to provide an example of a Java developer being sued for using the language. Performance -- poor, rega…

>> Simplicity -- none, if talking about the resulting code.

> Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot.

But Java is close. Compare its standard library with virtually anything else on the market. Nobody has dozen ways of reading a file, and in Java they can't be reduced to a one or two (buffered vs. unbuffered), because they're used in many places in the library.

>> Performance -- poor, regarding memory consumption.

> Bollocks. Uses more memory than C, but no manual management. Sweet spot.

Every other runtime has smaller memory requirements. No other runtime requires several hundreds megabytes of RAM to do anything non-trivial. Totally not the sweet spot.

>> Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent.

> In my experience, they're likely to be somewhat better skilled and educated. They're also far more likely to spend their time arse-ing around trying to implement an elegant, concise solution [...]

...which is generally a good thing, you just need to remind them they need to ship the product. They need different approach than mediocre programmers. With the latter ones you need to focus on preserving acceptable quality, with the former you need to focus on getting things done.

> [...] solution to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library.

Standard library in Java is hardly extensive. It only contains several typical containers, some networking (raw, HTTP, SOAP and Java's dedicated RPC), a little cryptography, XML parser, regexes and GUI toolkit. Oh, and routines for Zip files. It doesn't even have SMTP library built in. It doesn't have HTTP crawler library, like WWW::Mechanize. No XML-RPC or REST library. No built-in support for parsers. No indexed storage, like BerkeleyDB or TokioCabinet.

It's hardly "extensive".

Re: Java Developers

#102

Post by kasey_junk »

Wow there is a lot of bashing of the GoF patterns going on here. It seems like lots of people have a misconception about what patterns are. Patterns aren't a goal to meet with your software. They are common emergent solutions to standard design problems. The GoF didn't invent them, they just cataloged and provided a standard name for them.

So once we have a common name, shouldn't we use it? If I see a FooFactory, I have a pretty good idea what to expect in that class. So the problem with a FooFactoryFactoryAdaptor isn't that it is following GoF patterns or in it's silly name, it's that you have a solution that has at least 3 levels of abstraction. The patterns didn't cause that.

Re: Java Developers

#103

Post by vrotaru »

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…

   ArrayIndexOutOfBoundsException
   ...
   extends IndexOutOfBoundsException
   extends RuntimeException
   extends Exception
   extends Throwable
Not exactly an abomination, but I would not call it thing of beauty

Re: Java Developers

#104

Post by cousin_it »

seanmcdirmid wrote: post #63
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…

> "don't call me, I'll call you" pattern Just call it the Hollywood Principle [1], and ya, it sucks. Databinding frameworks like React go a long way in fixing this (and my own work [2] also). [1] http://en.wikipedia.org/wiki/Hollywood_principle [2] http://research.microsoft.com/pubs/211297/managedtime.pdf

I really like your work, but not sure that it lies on the right side of the framework/library divide. For example, to realize the full benefits of your approach, you define a new programming language with "no escape hatches". That's the most extreme kind of framework thinking!

My favorite post about libraries and frameworks is this one: http://web.archive.org/web/20130810134741/http://an9.org/dev...

> Frameworks hurt sharing. I'd really like to give you this fork Jimmy, but you're gonna need a knife and plate to use it. The framework checks out all your girlfriends for you, the framework won't let anyone dirty get through, the framework will wait up until you get in, the framework will always find out were you've been, the framework keeps you healthy and clean. Frameworks embrace, extend and hold on to greedily.

Re: Java Developers

#105

Post by wtetzner »

dmacvicar wrote: post #68
_pmf_ wrote: post #41

Earlier quoted context omitted.

> 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.

I did the two FP courses from Mr. Odersky using Scala as the main language and then continued playing with the language for small experiments. While the language is awesome in general, I would not recommend it at work.

Any particular reason you wouldn't recommend it at work?

Re: Java Developers

#106

Post by unclebucknasty »

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…

>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.

You nailed it. And, so did the author, with this:

>so often I find I’m reading code that looks more like a plan for something that solves a problem, rather than something that actually solves a problem.

Java--or perhaps the OO culture that came up with it, or perhaps the enterprise culture in general, or perhaps all three--does encourage a certain overengineering mindset. I am speaking as a recovered victim.

This permeates the entire culture. Remember when the Design Patterns books were first popular? Every Java dev was looking for a way to wedge in as many patterns as possible. There was a real sense that it was required to do development right. I think this (along with reading Java's APIs) is where Java devs began to fancy ourselves Architects Of Everything. You couldn't just solve a problem, no matter how simple. Instead, you had to develop something that could be infinitely extended or modified in the future. And, you'd better be sure that nary a public interface required updating if those future changes were necessary. Nevermind that you layered on extra classes, instantiated everything with a factory, and increased the initial complexity of using the code by orders of magnitude.

So, you were no longer solving a problem. Instead, you were architecting a flexible solution that could support solving the problem, along with every future variation of the problem you could conceive at the time. Then, you implemented your solution for the actual problem within this new, broader mini-framework you just created.

So, when reading this code, it's not uncommon to go through layer after layer trying to figure out where the actual work was being done.

But, the problem is that those future changes seldom came. So we were guaranteeing that our initial solution was overly complex and creating all of this baggage, while relatively infrequently redeeming that heavy cost in terms of avoidance of actual future pain that we imagined.

Re: Java Developers

#107

Post by dbaupp »

UK-AL wrote: post #33
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…

Assembly, and Low Level Coding is the exact opposite of solving 'real' problems. Your going low level to create problems that didn't exist, as opposed to working on the core issue(often business related) your software is trying to solve. Languages should allow you to focus on creating software that fixes a real world problem, as fast and cleanly as you can. That doesn't include bit flipping, or bit operators or anyth…

Writing low-level code is important for writing the underlying libraries for those high-level languages, e.g. the run-time systems or the big integer routines.

Re: Java Developers

#108

Post by nick_riviera »

mike_hearn wrote: post #89
nick_riviera wrote: post #9

I disagree with this, as a part time Java developer (I do C# most of the time). The points I disagree with: 1. OO is bad . Every paradigm is bad if you misuse it. If you build deep abstractions then you will hang yourself regardless. Some very elegant and simple designs can emerge from OO code, but only if you think about the problems first. The majority of pain consists of forgetting to do that step. There is no mag…

What's your beef with JavaFX? I've been using it recently and it's a surprisingly well designed and nice UI framework. Parts of it are kind of immature and there are occasional surprising holes in its functionality, but that's because the current generation (after dropping the scripting language) is only a couple of versions old.

Mainly FXML (I hate XAML as well) but it's better than Swing.

Re: Java Developers

#109

Post by nick_riviera »

mike_hearn wrote: post #91
nick_riviera wrote: post #18

Earlier quoted context omitted.

I don't think it's a matter of taste. TBH I write very little of the code that is checked in to the source control. The IDE does all the boilerplate. I literally design the method signatures, define the access policy for the methods and fill in a few gaps here and there. Play is not Java done right by any means. It's tightly coupled, has really poor documentation, breaking changes galore between major releases, deplo…

Ninja Framework is rather nice, I've found. I looked around for Java web frameworks lately and it seemed to be the one that balanced good documentation, features, simple configuration and so on to my liking.

Thanks - I will investigate this one.

Re: Java Developers

#110

Post by DCKing »

seanmcdirmid wrote: post #67
threeseed wrote: post #58

Earlier quoted context omitted.

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.

Scala isn't really functional, its more like a better Java that happens to include some FP abstractions (like C# does with Linq). Its actually a good OOP language, better than Java and even C#. Clojure is a Lisp, its niche. There will always be some people around who want to program in a Lisp, and many of them are just choosing Clojure today. Nothing new really.

It's unfair to call Scala 'not really functional'. Although I agree it allows for very rich OO programming, dismissing it as merely adopting "some FP abstractions" and comparing it to LINQ is bordering on FUD. To substantiate these claims, you have to at least give an example in which Scala falls short in being a functional programming language.

Interestingly, Scala's combination of OO and FP has given it (besides a lot of mockery and criticism) the title of a "postfunctional language".

Btw: I don't mean to pick on you, but you are talking a lot in absolutes on things I happen to disagree with in this thread.

Post reply on HN