Re: OO, C++, and something much better!

[TanselErsavas <tansel@rase.com>]

James O'Connor wrote:
> 
> Robert Dewar wrote:
> >
> > Tansel said
> >
> > ">What is highly debatable? I have used C++ for a long time and now I am
> > >using Smalltalk, and there is NO comparison in development times. They
> > >are simply different categories. Turtle vs. Rabbit."
> >
> > Yes, an apt reference to the fable, and I trust you remember who wins the
> > race between the Tortoise and the Hare (which is the translation of the
> > Greek I am used to, but I doubt we know precisely what animals Aesop was
> > describing to this level of detail).
> 
 
> Yes, that was perhaps a bad anology on his part to try to prove that
> point :)


I actually deliberately used this example. First of all, it has an
element of truth that although you can develop applications very fast
with Smalltalk, fine tuning and packaging them is slow, even with
Today's nice tools, so I don't think that we should create an illusion
that it is all a bed of roses. However, still there is no comparison. It
is my observation that since it is so easy to develop in Smalltalk, the
first target of people is to make the system run. That allows so many
performance problems to creep into the system, which need to be
optimized later. On the contrary, in primitive languages efficiency is
always a factor. These types of problems are very solvable through good
training and tools.

Second, for "the Tortoise and the Hare", isn't it the time that we
stopped believing such things? Just because we have a fable from the
mythological times, does it mean that it is true, or it will always be
like that? We are living in an age that we can have our own experiments
rather than relying on old dogma. 

> > In this case, the reason for the tortoise winning may well be found in
> > the long term maintenance and life cycle costs. Yes, languages like
> > Smalltalk are certainly handy for quick prototyping, but who knows what
> > the long term life cycle cost effects will be -- answer: no one, because
> > commercial use of Smalltalk is too new to have more than scattered data.

Not really. I have used most commercial languages including Smalltalk
long enough, to see development and maintenance with Smalltalk is always
so fast, it is just another dimension. You need people who know what
they are doing though. The biggest problem with Smalltalk is people, and
organizations who insist in developing applications with an army of
people who don't know much, rather than a few good people. 
 
> I once commented to an (Ada advocate) friend that the more dynamic your
> language got, the more you needed dynamic tools to deal with it.  When I
> did Ada83 years ago, I could use source code print-outs to debug my code
> because every object was statically typed and every subprogram call was
> statically bound.  Now that I use Smalltalk (Ada people think I've
> fallen from grace, Smalltalkers think I've reached enlightenment),
                                                     ^^^^^^^^^^^^^
Congratulations! I had already noticed that light coming from your
direction.

> source code print-outs are not as valuable because it us much harder to
> derive runtime state and flow of control.  I wouldn't necessarily say
> that over-reliance on dynamic debuggers is good, even in Smalltalk.  The
> debuggers are very powerful in Smalltalk, but even better is to use the
> various powerful cross-referencing tools to ensure those errors don't
> happen in the first place.
> 
> >
> > Someone actually posted earlier to this thread the idea that it was pretty
> > useless to have the compiler verify type invariants, because debugging
> > would find the errors easily. It is positively scary that there are
> > programmers around who could say this with a straight face. But then
> > any exposure to the general community of programmers is a very
> > frightening experience :-)

The idea of keeping the compiler as simple as possible is a very
important step in obtaining language flexibility and portability . C has
relied on this, and I find Smalltalk's simplicity and language syntax
brilliant. It takes time to digest it though. However, "you can not do
it with the compiler" does not mean that you have to do it with
debugging. This is not an either-or case. Lint type of tools are used
for C and C++, and Smalltalk environments are very clever to identify
many potential bugs. I use a technique that automatically embeds type
and other safety checking into code and automatically remove when I
don't need them any more. I will commercialize this in future releases
of my Snowball Rapid Systems Engineering tool. 

...

> James O'Connor

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------