Re: smalltalk vs. Ada

["Mark Lundquist" <up.yerz@nospam.com>]

"Rod Weston" <rod_weston@yahoo.com> wrote in message
news:f7ce0059.0106071420.2f38d37a@posting.google.com...

> Still investigating OOP languages.  I'm quite impressed with Ada, from
> what I've seen and read so far,

cool... :-)

> but now want to turn my attention to
> smalltalk.  Any ideas on how Ada and smalltalk compare?

OK, let's go!  I'll also throw in Java as an additional point of
comparison...

Smalltalk is a typeless language.  That doesn't mean there are no types or
that objects don't have types (that would be nonsense!); rather, it means
that the things in Smalltalk that correspond to what are called "names" in
Ada -- variables, method parameters, and method invocations -- are untyped.
That is, they denote objects whose types are unknown.  But since the only
thing you can do with an object is to "send it a message" -- that is, invoke
one of its methods -- the only error that can arise from an object having
the wrong type is when you try to invoke a method that does not exist for
the target object, and this is a run-time error.  Ada, by contrast, is a
quite strongly typed language.  Java also has strong static type checking.
But in both Smalltalk and Java, the only new types the programmer can create
are classes, where in Ada you can create new elementary types, array types,
etc.  And Ada's type system includes the powerful "subtype" mechanism which
is not found in any other mainstream language.

Smalltalk is also a "by-reference" language -- that is, a name denotes a
reference to an object, and the reference in turn designates or points to
the actual object.  There is no other way to access an object.  Ada is a
"by-value" language -- names denote objects themselves, and reference
semantics are explicit, i.e. a reference is an ordinary object, but of a
particular kind of type (an "access type" in Ada).  In languages with
by-reference semantics, the equality test really tests for *identity* of the
designated objects (since that's what equality of  two references means),
and assigment creates an alias, not a copy.  So things feel a lot different
in a by-reference language.  In Smalltalk, the reason for being a
by-reference language is deeply connected to typelessness.  If there is no
static typing, the implementation can't generate code to create an object as
a stack local, because if you don't know the type then you don't know the
size of the object.  So everything is allocated off the heap, and you just
pass around pointers to everything.  Java is also a by-reference language,
but for half-baked reasons.

Smalltalk (like Java) is a class-oriented language, i.e. everything is an
instance of a class.  Ada is not a class-oriented language.  Both Smalltalk
and Java are "pure class-oriented" -- they have a single-rooted class
hierarchy.  A practical implication is that although you might not like not
having generics, you can generally survive without them :-)

The classic Smalltalk (Smalltalk-80) doesn't have multiple inheritance,
although there are variants that do support MI.

Smalltalk, like Java, is meant to run on a virtual machine, and the compiler
compiles methods to bytecodes.  Ada is meant to be compilable to native
code, although of course it can also compile to bytecodes to run on a
virtual machine.

Smalltalk doesn't have a notion of "public vs. private members", because an
object's instance variables are visible only to the object's own methods,
i.e. all instance variables are "private".

Smalltalk, like Java, has a standard library that includes collection
classes.  Ada has no standard collection library.

Smalltalk has a programming environment including class browser, compiler,
debugger etc. that are all written in Smalltalk and run on the same virtual
machine as your program.  This is pretty important in a language where type
mismatches cause run-time errors :-).  When this happens, you are notified
by the fact that the debugger comes up in the context of the error, and
presto, you are debugging your code.  Also, you don't really compile a
"program" in Smalltalk as you compile individual methods as you write or
modify them.  Because of these factors, programming in Smalltalk has a real
incremental, dynamic, "rapid-prototyping" feel.

Ada has a hierarchial namespace.  In Smalltalk, the class namspace is flat.
There is a one-level "class category" attribute of classes, but this only
effects how the class is displayed in the class browser; it doesn't create a
namespace.  For instance, if I have a class Bone in category Body-Parts, I
cannot create a new class Bone in category Dog-Toys.

Ada is made for concurrent programming.  Smalltak has enought support to get
you by as long as you're not doing anything too complex.

Smalltalk was the system that brought together OOP, the mouse, and the WIMP
metaphor.  It brought class-oriented programming out into the daylight, and
class-oriented programming was the blunt instrument needed by the masses to
clobber into their brains an appreciation for the benefits of encapsulation,
inheritance, and dynamic polymorphism.  I guess it was probably worth the
brain damage.

I'm not a Smalltalk "believer", but I am a Smalltalk "fan", if that makes
any sense :-).  Although Ada is still my language of choice, I like
Smalltalk and I think it has a certain kind of coolness.  I learned
Smalltalk back in '87 -- before I learned Ada.

I'd suggest you try these languages out!  Download GNAT if you haven't
already, and start playing!  There are a lot of people on this NG who will
help you learn.  Same w/ Smalltalk; you can find an open source
implementation on www.squeak.org.

>  Are there any
> other OOP languages worth looking at?

Eiffel is probably worth looking at.  It's a pure class-oriented language
that supports multiple inheritance.  It embodies a philosophy called "design
by contract" that really seems like it belongs in Ada too, but nobody can
quite figure out where to make it fit.  Eiffel does not really have any
concept of interface and implementation being textually separated, so like
Java the methods are written in-line as part of the class definition.  I
much prefer the Ada approach where you have a specification and a body.
From what I've seen, Ada people seem to have a lot of respect for Eiffel as
a well-designed language, so I basically regard it positively even though
I've never actually used it :-).

Have fun!  Hope this helps...

Mark Lundquist