Hacker News Reader

Comment by pjmlp | Hacker News Reader

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?

View on HN

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

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.

Reply on news.ycombinator.com