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

61–70 of 321 posts

Re: Java Developers

#61

Post by seanmcdirmid »

DCKing wrote: post #39
seanmcdirmid wrote: post #23

Earlier quoted context omitted.

In that domain, yes! How many UI frameworks are functional (beyond I think...Om?)?

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 services have less baggage of trends than UI heavy programs do.

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

The best HPC programmer I know (and probably one of the best in the world) uses C++ and CUDA, neither very functional.

Re: Java Developers

#62

Post by ivanlubenko »

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 like your comment. Do you have any examples of C# libraries that use the ideas you're talking about? Or even better - do you know of a tutorial or something where I can clearly see the two approaches compared and contrasted?

Re: Java Developers

#63

Post by seanmcdirmid »

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…

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

Re: Java Developers

#64

Post by matthewmacleod »

dozzie wrote: post #8
MrBuddyCasino wrote: post #3

Java hits a sweet spot of simplicity, platform stability, safety and performance. Also, its popularity in the enterprise is partly because interchangeable, cog-in-the-machine low quality developers can be productive in it and not cause too many meltdowns. Thats an economic advantage! If you need lots of cheap developers for your IT department, good luck finding 15 Clojure and Haskell gurus. I say that as a Java devel…

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, regarding memory consumption.

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

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

Bollocks. 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 to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library.

As an example, I once worked on a Mac GUI app for a company - bog-standard, nothing fancy. I took over from a developer who had been trying to build this using Racket; this involved building a Qt-Racket interface, which involved magical automated parsing of C++ header files, which meant… basically, not delivering a product. Meanwhile, the Objective C build was done.

The point is, there's far too much focus and snobbery about what tools developers use. There are loads of languages out there; pick one that has a reasonable amount of support and fits the problem domain, and build simple, maintainable code. You can do that in any language.

Re: Java Developers

#65

Post by dmacvicar »

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…

There are several examples of simple libraries in Java that makes you realize it is possible to provide solutions to problems without the "culture" that predominates the ecosystem.

For example Simple (http://simple.sourceforge.net) is a great XML serialization framework that does very well what it is supposed to do.

And there are others I haven't used, but you look at the API and think, this is what I want.

I was very impressed with jDBI (http://jdbi.org/) even if we could not use it because of Maven.

Re: Java Developers

#66

Post by dozzie »

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

Re: Java Developers

#67

Post by seanmcdirmid »

threeseed wrote: post #58
seanmcdirmid wrote: post #49

Earlier quoted context omitted.

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.

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.

Re: Java Developers

#68

Post by dmacvicar »

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

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.

Re: Java Developers

#69

Post by tinco »

seanmcdirmid wrote: post #48
Dewie wrote: post #45

Earlier quoted context omitted.

> 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. FP wasn't mentioned in the article. Criticism of OO doesn't necessarily mean embracing FP, as far as I know.

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 and Haskell do.

Re: Java Developers

#70

Post by arel »

As the author said its not the languages fault. And if you know what you are doing then Java is clean, mature, performant, dare I say it enjoyable platform to use.

I think there also a generational conflict here. Java is a development environment that was born in the big architecture and 'development as enginerring' era of the late 90s. Spring was a reaction to the over engineered J2EE and now even Spring, the early liberator is considered over engineered.

Its our dad's language.

There is still a certain mindset from that era that was conditioned by the GOF and Universities and amaeteurs churning out developers but it is increasingly rare.

In fact I find Java is amongst the most interally introspective and disciplined in terms of coding taste and style.

I can almost guarantee if I look at another Java developers codebase that I can follow their code structure and style without too much effort. I'm not sure that would be the case for the large amount of very individualistic FP code being generated currently.

Post reply on HN