
Java Was Strongly Influenced by Objective-C - tambourine_man
http://cs.gmu.edu/~sean/stuff/java-objc.html
======
SeanLuke
Holy cow, that's my USENET posting. Will have to ask my sysadmin to record the
HN spike. I do find it funny reading postings here basically saying that,
regardless of what Patrick Naughton said, his language is actually based on
C++. Those language creators have some nerve! :-) Reminds me of the Kurt
Vonnegut scene in Back to School.

Even back in the '90s, when I wrote that as a wee PhD student, it was clear
that Java was derivative of Obj-C (among others) much more than C++.

EDIT: all the Newton references in that passage are because it was posted in
comp.sys.newton.misc (IIRC).

~~~
MCRed
And Objective-C is a derivative/recreation/highly inspired by SmallTalk.

But my question is, what modern language today is a copy of Dylan?

~~~
pavlov
None of them, unfortunately? (Unless I'm forgetting something.)

Of the languages created at Apple, Dylan was the most interesting one. Swift
is practical in many ways, but it's not inspired or visionary.

Swift is basically a better C++ with decent Cocoa interop built-in. It's
comparable to C# in originality... And that's not putting down either Apple or
Microsoft -- it's simply the realities of creating a language at a large
corporation with internal and external stakeholders.

~~~
Retra
I don't think 'originality' should be the goal of any language. Being novel
for the sake of novelty inhibits effective communication, it doesn't enhance
it.

~~~
AnimalMuppet
Originality is a virtue if the language really has a better way of solving
certain problems that people face. Even if it has merely a different way of
solving certain problems, that _may_ be very worthwhile, because the different
way may in fact turn out to be better.

But novelty just for the sake of novelty... yeah, not so much.

------
AdieuToLogic
I'm not sure how much Brad Cox[1] would like the characterization:

> Objective-C is an object-oriented mutant of C

But Java (the language) has little in common with C++ aside from the token-
level commonality both share with B.

As for Java's interfaces, those (as "zak_mc_kraken" mentions) have strong ties
to Objective-C's protocols, though I disagree with the subsequent statement of
them being "a simplification of C++'s multiple inheritance". IMHO, they are
far closer to C++'s class/function declarations.

I'd say Java had a similar influence as C++ did from Simula, introducing
superficial similarities with C++ due to its dominance at the time[2], but
incorporated more of the dynamics provided by Smalltalk-like languages (such
as Objective-C). Note the use of "super" for calling parent methods and the
lack of multiple inheritance in both.

1 -
[http://www.virtualschool.edu/objectivec/](http://www.virtualschool.edu/objectivec/)

2 - Fun bit of trivia: when Java hit the scene in the late 90's, you could
globally replace the word "reference" with "pointer" and the documentation
would read just the same. See section 2.2.9 of
[http://www.oracle.com/technetwork/java/simple-142616.html](http://www.oracle.com/technetwork/java/simple-142616.html)
for a prime example.

~~~
vbezhenar
I find a lot of similarities between Java and C++. Java is basically a subset
of C++ with some sugar around. When I was learning Java, I just made a link
between Java constructs and C++ constructs and that allowed me to learn Java
in one day and start getting things done. Of course I took few years more to
master Java, but that's another matter.

So Java "reference" is C++ pointer without asterisks and ->. All java methods
are virtual. Java interface is full-abstract class without fields (in Java 8
even not so full-abstract). Multiple inheritance only with interfaces. No
generics (I learned Java 1.4), one common ancestor Object, friendly GC
releasing you from the pain of memory management.

Basically the only new concept is package. Otherwise it's stripped C++ with
different runtime library.

~~~
wfunction
> Java is basically a subset of C++ with some sugar around.

Not sure where you got that from... the notion of a class being a "reference
type", which is the foundation of Java, doesn't even exist in C++. Every class
type is a value type in C++.

~~~
MereInterest
Sure, it does. In C++, you can declare everything on the heap, then pass
pointers by value. In Java, you declare everything on the heap (because you
can't declare it anywhere else), then pass pointers by value (because you
can't pass classes in any other way).

The only difference is that Java's subset also does not include pointer
arithmetic, so this is actually a safe coding practice, because it allows for
garbage collection to be performed.

~~~
wfunction
You're not countering the same claim I'm making.

Yes, C++ can emulate what Java is doing, but no, that's not what I'm saying.
I'm saying C++ classes are not _reference types_ , i.e., every class you
define is always a value type, which is the exact opposite of Java. Obviously
C++ also has pointers/references that could help you emulate Java, but that's
beside the point. The point is that classes work differently in C++ and Java,
and neither functionality is a subset of the other.

~~~
MereInterest
I suppose I'm not seeing the difference between Java's restriction of only
using reference semantics, and C++'s option of using reference semantics.
Since Java only provides reference semantics, while C++ allows both reference
semantics and value semantics, this would make Java be a subset of C++, in
this regard.

------
zak_mc_kracken
Not very convincing. Maybe Patrick Naughton was in love with Objective C but
there is little of that left in Java.

Depending on which angle you look at, you could see Java's interfaces as a
direct successor of Objective C's protocols or a simplification of C++'
multiple inheritance.

If you were to believe James Gosling, it's clearly the latter that influenced
Java's design. The fact that Naughton liked Objective C hasn't had much impact
on what Java ended up looking like in 1995.

~~~
w0utert
Having programmed many, many lines of C++, Java and Objective-C, I'd have to
agree. Maybe parts of Java were influenced by Objective-C, but surely there is
very, very little left of the philosophy behind how you write Objective-C
code. In fact, I'd say there's almost no similarity whatsoever.

In terms of how you program, Java is a lot more like C++, minus half the
language features that make C++ both powerful and dangerous. Obviously there
are fundamental differences, but I think it's pretty clear that someone
switching from C++ to Java would have a much easier time adjusting, then going
from C++ to Objective-C.

Also, I find the qualification of Objective-C as a 'mutant of C' a bit off the
mark. Yes, Objective-C is a superset of C, it's built on exactly the same
foundation, but the end result is and how you use it is completely different
in almost everything except the syntax of the pure C-constructs and
fundamental types.

~~~
tragomaskhalos
The fact that class methods are not polymorphic is a dead giveaway that Java's
heritage is more C++ than Smalltalk/Obj-C.

------
spiralpolitik
The saddest thing is that Java never implemented support for Objective-C
'Categories' so Java programmers are forever doomed to write classes called
StringUtil full of methods that really should be on the String class. After 20
years of Java programming this still annoys me.

That and making 'byte' signed.

~~~
javajosh
To me, the worst thing about Java is the tooling and OS integration. Compare
what it takes to invoke a node program with what it takes to invoke a Java
program. Or what it takes to do basic file IO in either of those. It's crazy,
and it will never get better. The best Java can do is wrap everything in a
build system ("just add an exec compiler plugin, configure for your main
class, and invoke mvn with special arguments!") or an IDE ("just create a run
config through the following 20 step process...").

It's true that if you spend a lot of time in Java these things fade into the
background, but these are exactly the things that shouldn't fade. You'll never
"whip up a quick script" in Java because of these problems.

~~~
spiralpolitik
Java was never designed to "whip up a quick script". Today as in 1995 there
are better alternatives to do that. Also Java was designed to abstract away
from the underlying OS to provide "write once, run anywhere" so its "as
designed" that OS integration is lacking.

Personally I think the tooling is the best part of Java. Having an IDE helps
you build more robust software by providing far more context than a text
editor ever could. The build systems have reached the point that its very easy
to do the right thing to build robust software. Compared with what came before
(make, imake, configure etc) the tools are much better.

------
michaelwww
Patrick Naughton... now there's a name I haven't heard in a long time. I went
to Wikipedia to find out what happened to him after his arrest. No jail time,
but he had to work for the FBI for free for a year.

~~~
tjr
The first book I read about Java was his. I remember enjoying his essay at the
end [this particular link being an unedited version]:

[http://blinkenlights.com/classiccmp/javaorigin.html](http://blinkenlights.com/classiccmp/javaorigin.html)

------
krisgenre
Maybe true. I recently ported an Obj-C project containing 9000+ lines of code
( no GUI ) to Java and was quite surprised about how easy the Obj-C code was
to read even though I knew nothing about it.

~~~
Reason077
The naming of parameters in method calls was something I found a bit weird and
overly verbose when I first used ObjC.

But I've come to appreciate that it can greatly improve readability when
trawling through unfamiliar code bases, and thankfully it's a feature Apple
have carried across to Swift.

Now days I often wish Java had external parameter names, too!

~~~
dilap
One of my fave obj-c features (which comes from smalltalk, I am told), and I'm
surprised more languages don't do it. Aids code readability immensely, and
basically eliminates an entire class of bug (of accidentally transposing two
params of the same type).

Most people tend to react to it really negatively at first encounter though.

------
mhomde
Wait... C# was strongly influenced by Java... by law of transitive properties
that means C# was strongly influenced by Objective-C.....
Nooooooooooooooooooooooooooooooooooooo.

That's like the opposite of finding out that Sweden named New York

~~~
MCRed
This is what makes C# so pleasant to use. Before C# Microsoft created a
language called J IIRC that was meant to compete with Java (Maybe it was J++?)

Wikipedia says J#, but I think this is a later incarnation:
[https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visu...](https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET#J.23)

~~~
prodigal_erik
[https://en.wikipedia.org/wiki/Visual_J%2B%2B](https://en.wikipedia.org/wiki/Visual_J%2B%2B)

------
ChuckMcM
That is pretty much the same way that I remember it as well. The interesting
dichotomy is that the NeXT 'cabal' as it were, primarily, the code/library
developers as was I, and James was primarily language design. But the group
was small enough that everyone had an opinion, and it often came up "well
Objective C does it this way..." or "C++ does it this way ...". James was
always a minimalist and Bill Joy (who was in Aspen working on the 'self'
language) was always pushing the edge of what you could express in a language.

------
reacweb
Objective-C was strongly influenced by smalltalk. I think Java is more
influenced by smalltalk than by Objective-C. The whole concept of compilation
toward bytecode that may be interpreted or compiled to native is very similar
to smalltalk. I think the influence of objective-C and C++ was mainly to avoid
reproducing mistakes, in particular the tricky syntax. The syntax of smalltalk
is very clean and simple which is not the case of C++ or objective-C.

~~~
cmrdporcupine
Java the language is more like Simula than Smalltalk. But yes, the JVM/runtime
is vaguely Smalltalkish, and this is no accident given that many of the key
contributors came from Self and Smalltalk lineages.

------
vmsisbetter
Not strongly enough unfortunately, otherwise it would have metaclasses and
class-side inheritance would work correctly.

------
rzzzt
An interesting tidbit on two unused keywords from the 1.0 specification [1]:

"The keywords const and goto are reserved by Java, even though they are not
currently used in Java. This may allow a Java compiler to produce better error
messages if these C++ keywords incorrectly appear in Java programs."

[1] [http://titanium.cs.berkeley.edu/doc/java-
langspec-1.0/3.doc....](http://titanium.cs.berkeley.edu/doc/java-
langspec-1.0/3.doc.html#229308)

------
protomyth
Brad Cox's two books are worth reading:

"Object-Oriented Programming: An Evolutionary Approach" ISBN-10: 0201548348
ISBN-13: 978-0201548341

"Superdistribution: Objects as Property on the Electronic Frontier" ISBN-10:
0201502089 ISBN-13: 978-0201502084

even after all these years, they still give some interesting insights

------
jasallen
Would kill for dates on each these messages!

------
comrade1
I remember when I moved from obj-c to java (as WebObjects made the same
transition) and being amazed at just how bad the java standard libraries where
compared to the obj-c foundation and other nextstep libraries. The obj-c
libraries were so nice and clean and focused.

Funny to see the 'oak' name reused - it's now an Apache project for a jcr
backend.

~~~
cturner
Do you remember any of the the names of method calls that were created by
converting the objective-c libs into java?

~~~
threeseed
If you mean WebObjects its libraries used almost the exact same method names
e.g.

    
    
      EOUtilities.objectsMatchingKeyAndValue(key, value);
    

You can still see a lot of the original code in Project Wonder e.g.

[https://github.com/wocommunity/wonder/blob/master/Frameworks...](https://github.com/wocommunity/wonder/blob/master/Frameworks/Core/ERExtensions/Sources/com/webobjects/foundation/NSArray.java)

~~~
cturner
Thanks - found one I was thinking of,
addObjectToBothSidesOfRelationshipWithKey

~~~
hugi
Or
EODatabaseContext.qualifierForLockingAttributesPrimaryKeyAttributesEntitySnapshot().

Work with WO made me prefer this style of long, self documenting
method/variable names.

------
eikenberry
They hid it well.

