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

[Tansel Ersavas <tansel@rase.com>]

Joachim Durchholz wrote:
> 
> Alan wrote:
> 
> > But replace "PL/I" with "any statically-typed language," and then you can
> > see the truth: "because any statically-typed language sucks, is why."
> 
> Come on, have you ever programmed in a statically-typed language?
> Seriously?
> What you say sounds just like a Basic programmer whom I tried to convince
> he should try (just TRY!) Pascal. He said he had seen it at the
> University, and Pascal sucked...

I used Pascal, C and C++ for more than 10 years, and developed and led
development of >500000 loc projects, and I am sorry to say that I still
think they suck. I now use Smalltalk and Self and sometimes Java if I
have to, and couldn't be happier.

About types, the following segment is an appendix to a recent posting I
made to these groups.

"The exaggerated importance of type checking in OO

There is a big debate about importance of type checking in object
oriented systems. We have one camp religiously defending type checking,
and another group defending unnecessity of it. There is a merit in both
sides� arguments. This has more to do with the implementation specific
problems than a general theoretical point of view. If we ask people who
are familiar with languages based on ADTs, type checking is so
necessary,
the absence of it is total catastrophe. If we ask a Smalltalker or a
Selfer, they will tell we that type checking is not all that important. 

The problem is two edged. The more type information we put into the
objects, the more we make them dependent of these types. Any changes on
these types will have to be detected, and these parts of the programs
need to be updated, even though in compiled systems a recompilation will
suffice in many cases. The reason of inflexibility of ADT based
languages such as C++ are partly due to their reliance on type checking.
On the other hand, in the languages that we get sinful flexibility, we
actually almost never know that we may have a problem that may lie in an
untested corner, and may lurk at an unexpected moment. 

Contrary to what people say, type checking is against the nature of
object oriented systems development. Remember, in OO, we only care about
the interface of the other object. In fact it should be an OO sin to ask
the type, because, in theory, we don�t want to get intimate with objects
we are interacting apart from their interface. We only want to know the
interface. But we do check types anyway, because we do not have another
way in many of the current popular languages to guarantee that this
object has the interface that we require. Type checking is necessary in
ATD based languages because of language structure. In languages such as
Smalltalk, on the other hand, even knowing the type of an object is not
a guarantee that this object will answer a method that we use, because
we can really delete any method for that object while the system is in
operation, so even type checking is not a perfect solution. 

Then what is the solution? Common Object Requester Broker Architecture
(CORBA) makes this possible by allowing us to define only the interface
of objects. However, this approach is not much of a use of objects
within the same language. Some other languages have the notion of a
subtype, which is dependent on the interface. In the
languages which do not offer such mechanisms, one obvious solution that
comes to mind is to offer an interface signature, that will indicate
that an object really offers all the services that it is required. This
will guarantee that type of the object can change any time as long as
the public interface signature of the object does not change. Then any
object binding to this object can ask its signature rather than type to
verify that
the interface is the same as this object was created. This has run time
costs associated with it, but solves many problems that are associated
with type checking. Furthermore it is not practical for many ADT based
languages.  

In most ADT based languages type checking is done at the compile time.
This approach gives us a lot of safety, but also has an expensive price
tag in terms of flexibility and compromise of object oriented approach.
There can not be much done to increase flexibility of such languages.
One of my solutions for flexible systems such as Smalltalk is, to use
high level tools to automatically embed type or interface checking code
in development and testing phase, and after all tests are done, to
remove these checks automatically, allowing systems to run without type
checking once they are in production. This gives me best of the both
worlds."

the entire posting can be found in http://www.rase.com/oodebate/
 
... 

> I have heard several indicators that Smalltalk is very good at getting
> stuff done, in the quickest possible time. I'm willing to believe this
> (sounds reasonable anyway), but nobody talks about the disadvantages in
> the approach. Those who know Smalltalk program in it, so they won't tell
> me - and I can't believe there are none.
> I don't want to be converted to Smalltalk. I want to know about advantages
> and disadvantages, so that I can decide which language is better for a
> given task.

As a person who is developing with Smalltalk extensively I see so many
advantages, it is like working in another dimension. Development and
debugging (which I don't need to do much of debugging) becomes a joy,
rather than a burden. 

Disadvantages? Many. First, it was not easy to come to this point. I had
to spend about a year, and if I wasn't assigned to a project I wouldn't
have done it, because I didn't see a need to switch from C++ I was
enjoying. 
For starters, most Smalltalks and their tools are ridiculously
expensive. To me, this means  the vendors  shooting themselves in the
foot, at the same time hitting us with the richocet. 
Second, it requires changes in the overall approach. For the first year,
my methods looked rather like C++ ones. Only after a while I was able to
slowly embrace the entire notion and apply it. I am still sometimes
amazed with certain things I can do which I call "sickeningly simple"
solutions.   
Third, the darn class library. It takes a lot of time to digest it.
Fourth, people say absence of MI is not a problem, but it is not true.
Just look at the Streams class hierarchy and implemetation, soreness of
absence of MI is clear. 
Fifth: as I mentioned in the type checking discussion, dynamic typing
has so many advantages, but also disadvantages. 
Sixth: Lack of standardized class libraries between implementations,
especially in the GUI part. Luckily now there are graphical frameworks
such as GF/ST which give good portability between Smalltalks
Seventh: The difficulty of felivering an application (stripping,
packaging, etc), which now we have good but absurdly expensive 
Eighth: Performance. Actually this is a non-issue. I never suffered from
performance apart from screen drawing, or number crunching. In some
complex applications I was able to beat C++ applications.

You can browse some issues with Smalltalk at
http://www.rase.com/oodebate/choices.htm. 

So how do I live with these? I don't. In Smalltalk you have the power to
correct things. The open system architecture allows you to do that. For
instance, adding a simple MI by delegation took me two hours to
implement. I use it sparingly, and more on the modeling side, but I have
it when I need it. I have developed a tool with it which we will release
shortly to fix most of Smalltalk's problems. This includes layering and
visualizing Smalltalk class hierarchy to make it digest easier. The best
thing in Smalltalk is you don't have to live with problems. You have the
power to fix them. Except speed which you can't do much about. For
number crunching I use C. Apart from that I find Smalltalk more than
adequate.
 
> > Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
> > system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
> > just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there
> > are so much fewer programmers than would be available for C++?  Why choose
> > Smalltalk, when there is such a wide-spread bias against dynamic typing?
> 
> Maybe because they are manager? Not all decisions, even in large
> companies, are based on rational arguments. There is trust in consultants
> involved, who aren't always impartial. There is also much internal
> backstabbing involved - sometimes managers influence other managers into
> bad decisions, to weaken their internal position.
>
> Not that I'm convinced this is the case with the companies that you listed
> as examples. It's just that such success stories don't prove a thing. It
> would be much more interesting to hear about the consequences of these
> decisions, not about the decisions themselves.

Why don't you come to Smalltalk Solutions 97? You may see many examples.
It is in NY at Marriot Marquis between March 10-13. 

> > Why has the use of Smalltalk been growing at 60% per year?  In spite of the
> > absence of any Java-style marketing campain?
> 
> Maybe because two companies happened to decide for Smalltalk, which makes
> a huge difference if the installed base is small.
> I'm sure any proponent for any other language can make up similarly
> impressing figures.
> That 60% figure is worthless - you don't say wether it's number of
> companies, number of developer seats, number of productive systems, or
> lines of code. You don't even say since when this growth started - it
> might be 1 1/2 year as well as twenty years.

This is not true. Smalltalk base is growing very strongly especially in
organizations such as banks. Most organizations come to a point where
maintaining the existing system becomes such a burden, they have to
change to a new system. What language will they choose for the new
system? Cobol? In some cases yes. Now there are quite different looking
languages, so called "Object oriented Cobol" in workstations. However
these are the minority. I read somewhere that 15% of banks chose
Smalltalk as their new language, which worries me, because there are not
that many Smalltalkers to develop and support these systems. I think the
problem with Smalltalk is not that there are too little of it, on the
contrary, with this speed, we don't have good people to support these
systems. So much so, I get requests to set up a "Smalltalk School of
NY", which I am considering.

> > Smalltalk offers many times faster development times--and much greater
> > robustness in the face of changing requirements.  That's a strategic
> > advantage, especially in businesses and industries (like securities trading)
> > where time is not just money, but big, big money.
> 
> I already knew this. I consider this an interesting property of Smalltalk,
> but I'm not convinced Smalltalk is best for everything. And as far as I
> know, Smalltalk can't be integrated into a multi-language environment (at
> least not with a considerable amount of work, or with serious efficiency
> problems), so I'm somewhat hesitant to recommend Smalltalk at all.

No, there are Smalltalks and class libraries with extensive multi
language support. I am internally using a tool that finds all strings in
an application, sorts, finds duplicates, and prompts for each of them to
modify, without changing or recompiling code, the simplicity of that can
literally make many people "sick". These things are so trivial in
Smalltalk. 

> Regards,
> -Joachim
> 
> --
> Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Kindest Regards
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-----------------------------