Hacker News Reader

Comment by nine_k | Hacker News Reader

Java designers have really shot every language user in the foot by eschewing the notion of a function from the language. The only way to have a function is to create a class with a single static method.

Hence you can't have function composition, instead you get dependency injection, with an extra layer of XML files in most frameworks to allow injecting different stuff without recompiling the classes without access to the source, or just obviating the need to recompile.

DI is a nice concept, and is used to solve a real problem of declaratively configuring closed-source code. I bet that declarative DI implemented for CL or Scheme would look more compact and neat than the typical Java approach.

View on HN

> Hence you can't have function composition

No, the thing that stopped Java having function composition was the lack of (ergonomic) closures. But it got closures in 2014, and now you can do function composition. Despite the fact that it still doesn't have top-level functions.

I still don't really understand where all the XML came from, or the wave of equally unnecessary annotation-based dependency injection that came afterwards. There has been a dream of "write reusable components, then compose them to form applications" that has been very strong in Java right from the outset, and i tentatively think that people just didn't get that you could do the composition in code.

Java is an amazing language ... but somehow all the ills of J2EE are blamed on Java. Back in the 2010s itself there were a lot of frameworks which were supporting both declarative and code as config. But, it is fashionable to shit on Java.

Indeed! No functions, no closures, and no support for either on the JVM bytecode level.

Now you can have lambdas, and they go to a generated class as methods, so that the JVM could execute them.

Where XML came from: how do you configure WebSphere in 2000? XML was all the rage since mid-1990s. It had a ton of advantages, back when you did not have JSON, YAML, or TOML.

> people just didn't get that you could do the composition in code

Yeah, Java does that to people. It's such a limited language that it becomes impossible to conceive of better ways to solve problems.

Apparently it's come a long way since Java 6, it's even broken backwards compatibility, never expected that to happen. It's adopted many functional concepts in the usual insanely verbose Java style. Still a very limited language though, especially when compared to real functional and object-oriented languages. It's limited even when compared to C.

Apparently is too advanced for the Go crowd, so there is that.

Well, Go was explicitly designed not to be too advanced. Here's quotes from its designer:

https://news.ycombinator.com/item?id=16143918

> The key point here is our programmers are Googlers, they’re not researchers.

> They’re not capable of understanding a brilliant language

> So, the language that we give them has to be easy for them to understand

It's pretty insulting in my opinion. Imagine being a programmer at Google, likely one of the best jobs in tech, and reading this.

Yeah. Java's design mistakes directly lead to these design patterns being used constantly to work around the limitations of the language. It's such a drag.

Even if you have static methods, you still need to use this stuff because they are methods, not functions. Classes aren't objects so they can't implement interfaces or be passed around as parameters. Gotta make things like singletons and factories because of this just so you can essentially pass a function pointer around. There's names for stuff that in better languages just happens naturally without people even thinking about it.

What people like to blame Java for, was already common practice in enterprise C, C++, Smalltalk, VB and Delphi before the language came to be.

Why do you think the Gang of Four book uses Smalltalk and C++ without any traces from Java?

Probably in large part because their book came out before Java was even around. :-D

Exactly the point they were making. All these problems were already around at the time. In fact people didn't even see them as problems. Read gang of four, and they don't really mention working around the limitations of the language. It is as if they are not really aware how many of their problems are arising due to the language's design, and think their patterns are just a generically good to do it. People don't use a majority of them now because there is just no need for them anymore in modern languages.

So the Sapir-Whorf hypothesis is true for programming languages?

Curiously, Smalltalk also lacks the idea of a function. Everything is an object; instead of a function, you have a code block which is an object.

But, unlike Java, Smalltalk is (utterly) dynamic, and you don't have to declare a class for your code block. In Java, you had to dance that dance, until lambdas were introduced to let the compiler do that for you.

"III. Anonymous Function = Block?" slides 17 & 18

"Smalltalk blocks and closures origin and evolution" Juan Escalada

https://smalltalks2017.fast.org.ar/talks

Until lambdas came to be, the workaround was to use anonymous classes, very few people would do a separate class.

And no lambdas are not implemented that way, rather they take advantage of invokedynamic.

> > > Everything is an object…

"Every object in Smalltalk, even a lowly integer, has a set of messages, a protocol, that defines the explicit communication to which that object can respond. Internally, objects may have local storage and access to other shared information which comprise the implicit context of all communication."

p290 Byte Magazine 1981

http://worrydream.com/refs/Ingalls%20-%20Design%20Principles...

> > > … instead of a function…

Instead of a function, a message.

Let's take that literally —

  perform: aSymbol with: anObject
  
    Answer the result of sending a binary message
    to the receiver with selector aSymbol and argument
    anObject. Report an error if the number of arguments
    expected by the selector is not one.

(For more of those methods, see p425

https://rmod-files.lille.inria.fr/FreeBooks/SmalltalkVTutori... )

Last-time I remember using those #perform methods, it was for testing — walking the code sending arbitrary messages and and arguments.

"We chose Smalltalk and C++ for pragmatic reasons: Our day-to-day experience has been in these languages and they are increasingly popular."

"Design Patterns: Elements of Reusable Object-Oriented Software"

Indeed, because there were plenty of other ones to chose from, like VB, Clipper, CA-Visual Objects, a couple of 4GL that were quite trendy as well, Objective-C.

You forgot to check the publishing date,

https://en.wikipedia.org/wiki/Design_Patterns

Publication date => 1994

https://en.wikipedia.org/wiki/Java_(programming_language)

First public release => 1995

> You forgot to check the publishing date

No I did not.

Apparently you did, because that was the whole point, all this stuff predates Java.

Apparently you believe you have certain knowledge about what I did or did not do.

You don't. I do.

Regardless of who you are, you cannot reinvent historical facts, unless you want to share with us how to do it.

Once more, I did not "forgot to check the publishing date".

Then please explain to the audience what was the point of the comment written as if Java was around, just not chosen for the book.

That’s you mis-reading between the lines.

The authors’ statement is clear.

> What people like to blame Java for…

… perhaps came later, with embellishment

2004 https://martinfowler.com/articles/injection.html

CORBA, SOM, COM, DCOM/MTS+ came before Fowler's stuff, and DI was already a thing in such frameworks.

What do all these things have in common? They are all 'component oriented' architectures and DI is required for systemic treatment of [3rd party] components. (Btw add J2EE to your list.)

DI allows a generic runtime to instantiate and compose component graphs [via declarative initialization contexts]. The idea was we'd have reusable components. Somewhere along the line came Spring ("J2EE is too complex" lol) and before you knew it, any old application was using DI and now (per a scan of comments in this thread) everyone is quite confused what is the purpose of "passing variables to your functions" in this obscure manner.

J2EE started as a Objective-C framework and was ported to Java as Sun ramped down their OpenSTEP efforts.

> NEO was re-positioned as a Java system with the introduction of the "Joe" framework,[2] but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans

https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhe...

And we did just the same with objects factories and directories on the listed technologies.

Thanks, didn't know this bit of history.

Post hoc ergo propter hoc ?

Perhaps "What people like to blame Java for…" is how it was required to be done in Java.

Feeling superior quoting Latin?

Perhaps Java became a victim of enterprise culture, just like nowadays everyone is doing system level DI with Kubernetes orchestrations and WebAPI?

> quoting Latin?

When those are the appropriate search keywords.

Sim, eu sei que me poderia ter dado ao trabalho de usar o Google, mas para quê perder o meu tempo com alguém que se dá ao trabalho de escrever em Latim só para se mostrar superior.

> Java designers have really shot every language user in the foot by eschewing the notion of a function from the language. The only way to have a function is to create a class with a single static method.

Java does support lambda expressions.

Also, the fact that in Java everything is a class is something that cuts both ways. As you're already going to have classes, you can have your pure functions as static member functions from any class that suits your fancy. That pretty much works as a function within a namespace.

The lambdas aren't actually lambdas, they are anonymous classes with a single metthod according to the type-inferred interface, and they can't use variables that aren't effectively final.

That's just a way to make them work in the existing ecosystem (in C++ lambdas for example are just function objects with overloaded operator()).

The final is to avoid some mistakes, but they are still effectively closures.

Haven't touched Java 8+ in a bit, but I remember Function2, Function3, Function4<P,Q,R,S> etc when referring to a closure. Streams used a ton of specializations like ToDoubleBiFunction<P, Q> meaning (P p, Q q) -> double.

I wonder if such contracts are are solved now like in other languages with typed function references/pointers - C++/Go/etc (syntactic sugar is enough, doesn't have to be variadic generics). I remember 'var' was introduced so I suppose that worked if the closure type could be inferred.

I've always viewed the @FunctionalInterface interfaces in Java 8 as very similar to Rust's Option and Result. Sure they're just like any other interface, but you can do special things with them because of their properties (single method).

I would take that over Go's special syntax for map any day as I now have the power to create my own functional interfaces and plug them into Java's standard library.

Java supports lambda expressions since Java 8, 18 years since the first release of the language. Certain things got ingrained during these years, a lot of code bases created and maintained in a particular way. The initial decision to not have free-standing functions or lambdas definitely shaped the ecosystem.

The problem of the static method as a function is not the implementation, it's the ergonomics. It's not terrible, but certainly it is wordy. I agree that a conservative approach to adding any new syntax is wise for a project of such an industry footprint. But the wordiness is what the original article points at, not any logical design faults.

A static class method is exactly the same as a free-standing function, it's just in the class namespace. I don't see why you think that means you can't have function composition.

Not true. It's not first class. You can't pass a static class method to a method and then call it. You have to instantiate a Function instance or equivalent.

Ok but that's a separate weird limitation that only applies to Java.

You can pass static methods as parameters in at least C++, Python and Javascript.

That is orthogonal. Java could easily have free standing functions that are still not first class.

That's not actually true. You can use method handles to do that.

Only if you mark that class with `@FunctionalInterface`.

Unfortunately, methods are not first-class objects in Java (while classes, with .class, are).

Reply on news.ycombinator.com