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

[Alan Lovejoy <alovejoy@concentric.net>]

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?

I have programmed professionally in FORTRAN (2 years), Pascal (2 years), 
Modula-2 (1 year), C (I have done this a few hours at a time, several times
a month, for the last 9 years or so) and C++ (1 year).

I have also played with Ada83 (but not Ada95).  I have studied many other languages,
in the sense of having read books about them.

> 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...

My first programming language was PL/I.  Then Pascal.  Then Modula-2.  I really
liked each one when I first learned it.  Oh, and I learned BASIC many years ago,
way before anything resembling VisualBasic was even conceived of.

> > (Actually, statically-typed langauges have a useful niche, but that niche
> > does not encompass all of programming).
> 
> Which?

My opinion?  Static typing is indicated when you need the highest possible
performance, and/or when the abscence of absolutely all bugs is far more important 
than development time (but formal verification methods and technology should then
also be used).  I do not think that most programming projects meet either of these
criteria.  Examples of those that do: weather simulation, nuclear explosion simulation,
operating systems microkernels, (some) device drivers, x-ray machine control software
and strategic missile control software (although perhaps not all of it).

> I could state that Smalltalk has a useful niche (that doesn't encompass
> all of programming), but I don't want throw mud back.

But that's not mud.  I'd say the same myself.

> > Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was a
> > failure in the marketplace.
> 
> Why? Because static typing is bad, or because it was done badly, or just
> because the Smalltalk *environment* isn't designed with static typing in
> mind, or because the Smalltalk installations didn't want to convert
> because they would have had to retrain their developers? (The latter is
> one of the main reasons why Cobol and its ugly relatives haven't died out
> yet. Technical merit is just one factor among many that decide wether a
> language lives or dies.)

This is no mystery.  It was because the Smalltalk community does not perceive
dynamic typing as a significant problem nor static typing (of the common
variety) as an acceptable solution.

If you have a typing system that a) prevents "message not understood" exceptions,
but b) does not prevent Smalltalk code from being compiled that would work
at runtime were it not for the static type checking, then Smalltalkers would be 
interested.  I think progress is being made in this direction, but more needs to 
be done (unless there's something I don't know about, which is of course possible).

> > I conclude that static typing succeeds when
> > marketed to those who believe in static typing, and that dynamic typing
> > succeeds when marketed to those who belieive in dynamic typing.
> 
> No you can't. This is just rhetorics what you're doing.

I was answering rhetoric with rhetoric. So spank me. (Ouch!).

> > And dynamic
> > typing also succeeds when marketed to people who want the fastest
> > development times, and have no religious axe to grind over the issue.
> 
> 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.

Any language is just a tool.  Learn to use the tool that is most appropriate
to the task at hand--and be open to new tools that didn't exist a decade ago.

> > 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.

Sure.  But the point was that Smalltalk is gaining ground in spite of all
the prejudice against it, and in spite of the fact that using or adopting it is
swimming against the tide for C++/Java.

> 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.

I think there is significance to such things when an underdog technology
gains marketshare, in spite of being constantly deprecated and libeled by
the "in crowd."

> > 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.

The growth in Smalltalk started roughly four years ago.  It's a count of the
number of jobs where the primary job function is programming in a particular
language.

> > 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. 

Nor should you be.

> 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.

Smalltalk can call C just as easily as Java or Basic can.  Two way interoperability
(where C calls Smalltalk) has been a problem, but there are now at least two 
different Smalltalk implementations that compile to "native code" directly
(no bytecodes at all, this is better than JIT compilation).  With "classic"
native code compilation, two-way interoperability is not a problem.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|