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

71–80 of 321 posts

Re: Java Developers

#71

Post by coldtea »

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

They have some nice scallable backend systems, but a lot of their output is ho-hum, especially when it comes to their Java inspired teams (GTW etc).

Re: Java Developers

#72

Post by dmacvicar »

dozzie wrote: post #66
dmacvicar wrote: post #60

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…

Programmers rarely see how their software is built and shipped. Those who have this opportunity rarely have their taste developed to see that external dependencies have cost associated. And it's not something specific to Java: I see the same in Ruby and Python. It could give the perspective to programmers requiring from them that they always build their software on a freshly installed machine with no network connecti…

That is why I don't understand the "enterprise" sticker they try to put on some Java stuff.

Building without network connection was a feature most of these enterprise "build tools" did not get right from the beginning.

Patching a dependency, rebuilding the affected chain and ship it back to the customer is something I still ignore how the Java ecosystem does with their native tools.

Probably they just do "mvn" in their workstations and .zip the output folder.

Re: Java Developers

#73

Post by rakoo »

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…

> I challenge you to provide an example of a Java developer being sued for using the language.

Google ? https://en.wikipedia.org/wiki/Oracle_v._Google

Re: Java Developers

#74

Post by DCKing »

seanmcdirmid wrote: post #61
DCKing wrote: post #39

Earlier quoted context omitted.

It's unfair to focus on "UI frameworks" when UI frameworks are specifically aimed at supporting client OSes where they have to deal with "preferred frameworks", all of which were developed when OO was all the craze. Functional programming has only been discovered as a practical paradigm quite recently! Besides, implying that "big serious programs" necessarily implies that they are UI programs is completely wrong. Uns…

OOP is well suited to UI programming because it is built around metaphor. FP doesn't quite work because UI programmers like to think in terms of buttons and windows rather than f and g. > Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those…

> FP doesn't quite work because UI programmers like to think in terms of buttons and windows rather than f and g.

This is because people have been educated in thinking in objects for thirty years now. This is again a result of history, not because of the qualities of OO over FP.

Besides, there's no reason why you couldn't do that using functional programming. FP is not (necessarily) object oriented, but that doesn't mean you cannot reason about 'objects' in a different sense.

> As someone who works in a distributed systems team, ha! Where are these functional programmers writing high performance parallel code? Microsoft? Google? Facebook? Maybe map reduce and some pipeline descriptions can count as functional but that's about it (even the UDFs are imperative).

I'm not talking "distributed" systems that do HPC work; functional programming in general cannot achieve that level of low-level performance (as long as you don't count Rust's ambitions). I'm talking 'scalable' systems that do a lot of messaging processing (like web services and queueing systems). Twitter, Walmart, LinkedIn (Scala), Facebook, Whatsapp, dozens of companies in the telecom industry (Erlang) and Jane Street (Haskell, OCaml, F#) are examples.

Re: Java Developers

#75

Post by pjmlp »

Java is not the problem, enterprise architects are.

If anything, Java allowed the so called architects a much easier path to such crazy skyscrapper designs than any enterprise language before it.

So of course they went crazy with Java, and later on C#, because it was so easy to do so, without being caught in core dumps and similar issues.

Anyone complaining about enterprise Java, just needs to go back a few decades to see what was being done in C, C++ with CORBA/DCOM, VB/Delphi, CLIPPER and tons of wannabe 4GL languages.

Any language that wins the hearts of enterprise architects will suffer the same pains that Java is known for.

I can already imagine a "Enterprise Functional Design Patterns" and similar books.

Re: Java Developers

#76

Post by seanmcdirmid »

tinco wrote: post #69
seanmcdirmid wrote: post #48

Earlier quoted context omitted.

What other choice is there? Old fashioned procedural? Logic rule driven? Some "other flavor of OO but lets not call it OO" (e.g. component entities)? From a paradigm perspective, there are really only two in active contention.

CES is definitely not a flavor of OO. It can be mixed with OO and it can easily be implemented in OO languages, but it's far from being OO. You can't say 'entities are objects so CES is object oriented' because entities are not objects in the OO sense. So yes, the other options are static procedural and component oriented like CES. Interfaces without inheritance are also gaining popularity, I think this is what Go an…

I guess it really depends on your definition of "objects." If it quacks like a duck, its probably a duck. Inheritance is not necessary at all for objects (since at least the Treaty of Orlando).

Re: Java Developers

#77

Post by pjmlp »

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…

What I find quite amusing is that all these posters bashing OOP, end up using languages that actually do offer some form of OOP, as they seem to lack the understanding that Java OOP is not the only way of doing OOP.

As all modern languages, even functional ones, have OOP support.

Re: Java Developers

#78

Post by zmmmmm »

It will be interesting to see if Java8 inspires a fresh look at the design approaches used in the Java world. So many of those over-architected Java designs are trying to solve lack of flexibility and expressiveness in the language. There's an opportunity now to keep the good and move on from the bad ... it's terribly unfortunate though that it's not clear if Android will ever properly update from Java6 syntax. If it doesn't a large amount of the Java ecosystem is never going to move on from there.

Re: Java Developers

#79

Post by pjmlp »

agumonkey wrote: post #50
_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.

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…

> OOP is too verbose by it's essence compared to closures.

Then CLOS is too verbose?

Re: Java Developers

#80

Post by auggierose »

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

What? React is a framework as well. componentWillUpdate much?
Post reply on HN