Post by Bill Coleman AA4LRPost by Ronald C.F. AntonyHowever ObjC doesn't sacrifice any of the dynamic aspects that
are important. Java does, and still isn't compatible with anything
but itself. So you pay a price, but you don't know what for.
I attended a talk at WWDC 97 entitled "Uncommon Object Model." At that
session, they impressed on people that the run-time model for Objective C
and Java were practically identical. So, it was rather easy to adapt the
Cocoa interfaces to Java. By comparison, it would have been difficult or
impossible with C++.
Practically identical is a relative term. When compared to C++, yes.
When compared amongst (wannabe) dynamic OOPLs, then not.
Post by Bill Coleman AA4LRThey only mentioned two features of Objective C that were not present in
Java: Posing and Swizzling. (Not being an Objective C programmer, I'm not
really sure what they are) They indicated these features were rarely used
in Cocoa. So a Java programmer can use Cocoa without facing too many
limitations in what he can do.
There is more missing, but these are two of the big things.
But the fact that they are rarely used doens't mean that when they
are used they are not absolutely essential ingredients to achieve
an elegant solution. Yes, 80-90% of run off the mill code can be
written in Java as well as in ObjC. The rest is what matters, because
given that what I can write in Java I can also write in ObjC rather
easily, but not always the other way round, and because I have a
mind that's not too keen on constantly switching between languages
with subtle semantic differences, I like to choose the language
that lets me solve all the problems, not just the 80-90% Java
lets me do.
Posing allows one class to assume the functions of another.
This would e.g. a feature that's very handy when implementing
component software.
Swizzling refers to an object altering it's class at runtime,
i.e. the fact that the runtime is fully polymorphic (and doesn't
give a damn about what class it's messaging and what it inherits
from, as long as it gets the message (pun intended)).
One place where this is very essential is the much cited EOFault
object, that replaces itself with the real object on demand and
then assumes the proper class identity.
There are of course only a few lines of code where this feature
is used, yet of course the entire EOF framework depends on it
and that in turn is used in most WO apps and a great many
intranet applications.
So even the Java programming WO developers reap the benefits from
ObjC by using EOF.
Maybe I'm more prone to dynamic programming due to my background in
AI/Lisp/etc. but like people who programmed in Java would refuse to
go back to C++ once they realize what the added functionality
of Java does for them, so people who learned ObjC to the fullest
feel similarly about going back to Java. (And the few who are
fortunate enough to be able to get by with SmallTalk probably
would not like to step down to ObjC...)
But there is more than just these two things. Categories and syntax
are amongst them as is the dynamic typing.
Post by Bill Coleman AA4LRPost by Ronald C.F. AntonyA simple byte-code based SmallTalk engine could do what
Java does, and a lot more and a lot better.
Interesting to note that Smalltalk and Java achieved their objectives
using very similar run-time techologies.
I know, and that what makes it so frustrating that the Java developer
stopped short when designing the language and left out important features.
Of course, to be fair, they wanted to program some set-top boxes and
didn't design Java as a general purpose language.
Java, like the web/http are essentially abused technologies, and are
pushed by hype and lemming-like masses who don't know any better.
The things the web is doing these days screams out loud for a new,
stateful protocol, and the things Java is used for these days screams
for languages like SmallTalk, CLOS, Python (so I hear) and ObjC.
Post by Bill Coleman AA4LRI suppose if Smalltalk had been
invented in this more modern era of high-performance machines, it might
have seen greater popularity.
Sun just could have saved themselves the effort of developing a new
language and have adopted SmallTalk right away. An innovative implementation
and a set of decent class libraries could have gone further, than wasting
the resources on the language development and then not having enough to
develop good libraries.
Post by Bill Coleman AA4LRPost by Ronald C.F. AntonyHeck, give people
an alternat syntax, if they are so afraid of brackets and so
attached to meaningless parameter lists like they are to be found
in C function calls....
(Here comes one of those "what if" questions:)
What if one had an Objective C compiler that produced Java bytecodes?
Naturally, it would be limited to the functions present in the Java
run-time model. Certainly such a hypothetical product would overcome any
syntactic objections.
It would make Java code more maintainable and more readable, and as
such would be a welcome addition. However, to remain precise,
there Java bytecodes are not restricted to Java, and really SUN is
just obfuscating the facts by calling them Java bytecodes.
The JVM is simply a virtual machine, that can run any number of types
of languages. e.g. there is a full Scheme (Lisp dialect) that compiles
into JVM, etc.
At that point we're down to method naming conventions. If we simply add
an ObjC-like syntax to Java but must use the Java libraries that
use methods of the form
someMethod(param1, param2, param3, param4), then we get an pseudo-ObjC
method call that looks like
[myObject someMethod:param1:param2:param3:param4]
and have the same unreadable code as if we had just written Java code.
ObjC syntax is not about brackets, it's about naming.
Here is a line of code I wrote some eight years ago:
return [self search:aNodeObject startingAtNode:aNode ofKind:[aNode class]];
I still understand it simply by looking at it, in plain English:
"Self, search a node object starting at node "aNode" of kind of "aNode"'s
class, and return it!" That would be a natural language equivalent.
See how similar that is? Try this in C or Java:
return self.searchStartingAtNodeOfKind(aNodeObject,aNode,aNode.class());
Ugh! :-(
Post by Bill Coleman AA4LRI don't buy the argument that Objective C is superior to Java merely
because of its syntax. Syntax usually comes down to personal preference.
Language features, on the other hand, limit what you can do or not do
with a given language.
The language is not superior to Java "merely" because of its syntax, but
also because of its syntax. The language determines how we think, and
the closer we think to natural language, the better we do think (at
least most people do). What you can do with an MS-DOS like interface
with cursor keys and app-specific graphics is also "the same" as what
you can do with an integrated GUI environment, and if you're used to
MS-DOS, then you may resist the move to Windows or the Mac.
(Maybe most on this list here are either total kids or have memories
that fade quickly, but I remember the drasic fights that some people
put up about how all this GUI stuff is just a toy, and how they can
do everything with the old-style interface, etc.)
Same thing, just because you're *used* to a particular syntax may present
you with a barrier of acceptance and entrance to a new syntax, but
that doesn't mean that there are not *objective* (pun once more intended)
criteria by means of which the quality of a syntax can be evaluated.
I mean, to take an extreme example, how many here would like to program
in APL (I guess again an example that dates me...)?
The very same people who designed the now universally accepted GUI paradigm
invented SmallTalk and its syntax, and they didn't do it for the fun of
creating yet another syntax, but to create a language that was easy
to understand even by kids, that was to a large degree self-documenting,
and that was maintainable in the context of multi-year, multi-person
projects.
So we're not talking here about Pascal vs. C, or Algol vs. PL/1
differences in syntax, we're talking about a very clear departure
designed around the way the human mind works.
Most other languages are designed to be easily machine parsable, hence
all the parameters come in one big lump, SmallTalk is designed to
let disciplined programmers write easily human readable code.
(Of course, if you really want, you can unreadble junk even in SmallTalk,
but you actually have to take an effort, while it comes naturally in
C et al.)
Anyway, enough of this here...
Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome