Live data from Hacker News

Java Developers

nsainsbury.svbtle.com

261–270 of 321 posts

Re: Java Developers

#261

I think most of the problems are caused by enterprise, enterprise frameworks, and the sheer age of Java. There's a lot of technical debt built up and a lot of enterprisey frameworks that are way over engineered. I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc. I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competiti…

+1 for the DocumentBuilderFactory. I was trying to figure out why such an idea was implemented. I saw it sort of like having multiple implementations of DEFLATE on the same system. Seems like you really only need one...

There is also a lot of Java stuff dealing with dependency management. Not all of the principles are unsound, but they do have more long-term effects and make the code clutterly in the interim.

Re: Java Developers

#262

Earlier quoted context omitted.

How would you prefer to define UI layouts? Some other DSL? A binary format?

Another DSL. Structural DSL like this: form { input { name = "bob" label = "Bob" } button { action = #{bean.submit} } } I've actually wrote a C code generator DSL over the top of Win32 many years ago that did this so the financial app I was working on so we didn't have to write millions of dialogs in win32 loops.

You might already be familiar with it, but this looks a lot like QML.

Re: Java Developers

#263
post #253

Earlier quoted context omitted.

I disagree OOP is the correct way of thinking about the real world, and I think the software industry is starting to realize it was an overblown fad too (and moving on to the next fad, of course), BUT... ... I agree Java is not a particularly good example of OOP. It amazes me that so many people complain about Java "forcing OOP on everything". If I read framework source code, I see very little OOP in there. It's most…

If you disagree, would you mind explaining your reasoning? I suspect that we've started hitting the issue of "What, actually, is OOP?"

Well, part of the problem is that we've all accepted that OOP is the best way of modelling the real world, but there is no convincing proof. Maybe experience? I don't know. We do know modularity is valuable. We know OOP is a way of achieving modularity, but is it the best way? And is OOP-like-in-Java the best way of doing OOP?

OOP like many Java (and C++) programmers do it is certainly not what Alan Kay was thinking about (in his own words!). But that's merely an appeal to authority. Maybe Alan Kay was mistaken and the Java folks are right. So the other part of my problem is that OOP is not a well-defined concept at all. I cannot begin to agree OOP is the best way of thinking about the real world until we can determine what OOP is; a definition both a Smalltalk dev and a Java dev can agree on.

Re: Java Developers

#264

Earlier quoted context omitted.

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

> If you get good at programming... This is a very important point (hopefully more "when" than "if"). I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.

I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.

This is one of the biggest problems with Java — and other “pure OO”, “everything is an object” languages of the same style — particularly from a teaching perspective: when all you have is a class, every problem looks like an object.

If we present a language like Java as being the default, standard, safe option, how are new developers ever going to gain enough knowledge and experience to realise that their elaborate design with seven different classes in Java could have been replaced by a single 10-line function in Python, or a few short lines of Prolog, or a single query in SQL?

Re: Java Developers

#265
post #258
post #242

Earlier quoted context omitted.

It is central. Without polymorphism you don't have a way to abstract algorithms over types. So you just get ADTs as introduced by Mesa/Modula-2.

You can do OOP with only ad-hoc polymorphism, which is just method overloading, which is what Java and C++ do. Actual parametric polymorphism isn't necessary for OOP, and there are non-OOP languages that have it (e.g. SML has polymorphism but does not have objects). So, polymorphism and object-orientation are orthogonal concerns. OOP is about encapsulation, inheritance, and modules that couple mutable state (attribut…

For the curious, Ocaml mixes both, its object model is parametric (see: http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html)

Re: Java Developers

#266
post #243

Earlier quoted context omitted.

Doesn't change the point. It's called JAVA but with lazy streams and closures, everything Java culture built prior that will be moot and that's what the article is pointing at. Same thing happened in PHP land, people say PHP is great now, but what is PHP ? PHP5, which is a perlish javaesque thing ? or the regex craze html implicit template system that was PHP4 ? ... OOP is too verbose by it's essence compared to clos…

PHP is actually the perfect example to disprove my point (pig with new lipstick). I'll reflect on that.

PHP is a funny thing, started very very low (https://twitter.com/agumonkey/status/488432654577303554), and nowadays it's got a lot of very positive improvements (linguistic features, faster interpreter, principled community). Who knows how long it will survive ...

Re: Java Developers

#267

Earlier quoted context omitted.

You seem to be stuck in the topic of how useful structural typing is. Which I agree with.

Eh what? No. I couldn't care less about structural types. I care about simple, consistent rules. "X is a type, you can use it wherever you want" is one. "X is a type, but there is also Y, which you can't really express in position A and B unlike X, but can only use it if you carefully avoid doing things #1 to #4" isn't one.

I agree with partly with you.

I don't think it helps for consistency when you have to ask yourself why some functionality is defined in terms of a trait if it could be defined in terms of the structural type and just providing the methods would be sufficient.

Re: Java Developers

#268

Earlier quoted context omitted.

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?

Oh, I also disliked implicit conversions a lot. I considered them a wart at some point. Made everything hard to read and reason about.

Almost every other way of "extending" a type would have worked better in practice eg. Xtend’s Extension Methods.

Re: Java Developers

#269

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

+1 for the "toy immutable functions". Immutability everywhere is the current hype, but like mutability it has its advantages/disadvantages. The main consideration is the tradeof between performance(best for mutability) vs ease of use of development (best for immutability). However on HN, the war is dogmatic whereas reality is not that black and white. As a Java developer, I find immutable String and primitives very c…

> The main consideration is the tradeof between performance(best for mutability) vs ease of use of development (best for immutability)

No, no, no. Immutable data structures are not actually inefficient, they are just different. They were designed for different tasks and work better in that tasks. Imagine, for example, that you need to traverse list of customers in a large multithreaded application. While traversing, you don't want this list to be updated. So if the list is implemented with a mutable array, you have either to lock it all the time, or create a copy, both of which are pretty inefficient. With immutable list, on other hand, you can freely traverse it because you are guaranteed it will not change during processing.

Multithreading is one of the main sailing points for immutable data structures, but not the only one. IIRC, Java String are immutable to allow creating substrings as views on the same char array, which, on average, increases performance, not decreases it. Another cool thing is that with immutable data structures you can add new cool features like auto generation of `hashCode()` or memoization.

Surely, some algorithms require mutable data structures by design. Change one pixel in 1M image stored as immutable array is definitely bad idea. That's why most functional language tend to, but not limit you to using immutable data structures only.

Re: Java Developers

#270
post #258
post #242

Earlier quoted context omitted.

It is central. Without polymorphism you don't have a way to abstract algorithms over types. So you just get ADTs as introduced by Mesa/Modula-2.

You can do OOP with only ad-hoc polymorphism, which is just method overloading, which is what Java and C++ do. Actual parametric polymorphism isn't necessary for OOP, and there are non-OOP languages that have it (e.g. SML has polymorphism but does not have objects). So, polymorphism and object-orientation are orthogonal concerns. OOP is about encapsulation, inheritance, and modules that couple mutable state (attribut…

> You can do OOP with only ad-hoc polymorphism...

Which is still polymorphism. I purposely did not enumerate all CS forms of polymorphism, but can get more detailed if you will.

Post reply on HN