O'Reilly -- The History of Programming Languages

[Tom Johnson]

>From time to time, some of us have expressed an interest in the evolution of
various computer languages.  Turns our others shared our interest and did
something about it.

http://www.oreilly.com/pub/a/oreilly/news/languageposter_0504.html --- The
History of Programming Languages

-- tj

==========================================
J. T. Johnson
Institute for Analytic Journalism -- Santa Fe, NM USA
www.analyticjournalism.com
505.577.6482(c)                                 505.473.9646(h)
http://www.jtjohnson.com                 tom at jtjohnson.us

"You never change things by fighting the existing reality.
To change something, build a new model that makes the
existing model obsolete."
                                                   -- Buckminster Fuller
==========================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070804/e2723edf/attachment.html 

[Prof David West]

In my book - Object Thinking - I referenced a lot of material from this
series of books re: Simula, Smalltalk, and C++ (Java was still absent
from the books) to make the point that a lot of so-called object
languages were never intended to be such and that the only reason they
made the claim was for marketing purposes.  And because programmers
failed to see why the history, purpose, and philosophy of a language was
relevant to using the language, 98% of the programmers still have no
clue how to to OO.

davew


On Sat, 4 Aug 2007 18:53:18 -0600, "Tom Johnson" <tom at jtjohnson.com>
said:

> >From time to time, some of us have expressed an interest in the evolution of
> various computer languages.  Turns our others shared our interest and did
> something about it.
>
> http://www.oreilly.com/pub/a/oreilly/news/languageposter_0504.html ---
> The
> History of Programming Languages
>
> -- tj
>
> ==========================================
> J. T. Johnson
> Institute for Analytic Journalism -- Santa Fe, NM USA
> www.analyticjournalism.com
> 505.577.6482(c)                                 505.473.9646(h)
> http://www.jtjohnson.com                 tom at jtjohnson.us
>
> "You never change things by fighting the existing reality.
> To change something, build a new model that makes the
> existing model obsolete."
>                                                    -- Buckminster Fuller
> ==========================================

[Russell Standish]

C++ is not just an OO language, obviously, but are you saying that it
isn't an OO language at all?

I use C++ extensively, and use it procedurally, functionally,
object-orientedly, generically, and often a mixture of all of the
above, as appropriate for the problem at hand.

I'm aware of C++ negative points (confusion between "." and "->", "[]"
and "()", ";" needed after class defintions, but not function or
namespace definitions), but all of these are superficial, and picked
up by the compiler immediately.

More significant C++ deficiencies...

Generic programming (ie templates) is a bit more of a problem - the
standard makes the inheritance model somewhat unintuitive. And
different compilers seem to interpret the standard differently,
meaning one needs to test all advanced template code carefully on
different compilers.

But having said that, using basic generic capability equivalent to
what Java or C# offers, is unproblematic, and useful even to novice
users.

Finally, there is the renowned memory management problems. This comes
from trying to program C++ using a Java or a C programming style. It
is simple to avoid all such problems by using the simple rule "no bare
pointers". Use a container, or a reference type (either the static
built in type, or one of the dynamic reference types available in
boost and/or TR1). The only reasons to use bare pointers is for access
to legacy APIs (in which case you should wrap it into a C++ type), and
for performance reasons, which you should only do after your code has
been fully debugged.

But I would still say that C++ gives me the ability to build more
complex code, more efficiently, in about a similar or even reduced
development time to other competitive languages. I couldn't give a fig
whether it follows a pure OO model or not.

Cheers

On Sun, Aug 05, 2007 at 07:31:12PM -0400, Prof David West wrote:

>
>
>
> In my book - Object Thinking - I referenced a lot of material from this
> series of books re: Simula, Smalltalk, and C++ (Java was still absent
> from the books) to make the point that a lot of so-called object
> languages were never intended to be such and that the only reason they
> made the claim was for marketing purposes.  And because programmers
> failed to see why the history, purpose, and philosophy of a language was
> relevant to using the language, 98% of the programmers still have no
> clue how to to OO.
>
> davew
>
>
> On Sat, 4 Aug 2007 18:53:18 -0600, "Tom Johnson" <tom at jtjohnson.com>
> said:
> > >From time to time, some of us have expressed an interest in the evolution of
> > various computer languages.  Turns our others shared our interest and did
> > something about it.
> >
> > http://www.oreilly.com/pub/a/oreilly/news/languageposter_0504.html ---
> > The
> > History of Programming Languages
> >
> > -- tj
> >
> > ==========================================
> > J. T. Johnson
> > Institute for Analytic Journalism -- Santa Fe, NM USA
> > www.analyticjournalism.com
> > 505.577.6482(c)                                 505.473.9646(h)
> > http://www.jtjohnson.com                 tom at jtjohnson.us
> >
> > "You never change things by fighting the existing reality.
> > To change something, build a new model that makes the
> > existing model obsolete."
> >                                                    -- Buckminster Fuller
> > ==========================================
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

--

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone [phone] (mobile)
Mathematics                        
UNSW SYDNEY 2052                 hpcoder at hpcoders.com.au
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------

[Douglas Roberts-2]

As one who lived inside a LISP machine for years, and worked extensively
building large OO-based applications using Loops, Flavors, CLOS, and KEE
prior to the birth of C++, I pride myself on being a member of that elite
2%.

I just wish I could get my fellow SW developers to agree with me.

;-}

--Doug

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell

On 8/5/07, Prof David West <profwest at fastmail.fm> wrote:

>
>
>
>
> In my book - Object Thinking - I referenced a lot of material from this
> series of books re: Simula, Smalltalk, and C++ (Java was still absent
> from the books) to make the point that a lot of so-called object
> languages were never intended to be such and that the only reason they
> made the claim was for marketing purposes.  And because programmers
> failed to see why the history, purpose, and philosophy of a language was
> relevant to using the language, 98% of the programmers still have no
> clue how to to OO.
>
> davew
>
>
> On Sat, 4 Aug 2007 18:53:18 -0600, "Tom Johnson" <tom at jtjohnson.com>
> said:
> > >From time to time, some of us have expressed an interest in the
> evolution of
> > various computer languages.  Turns our others shared our interest and
> did
> > something about it.
> >
> > http://www.oreilly.com/pub/a/oreilly/news/languageposter_0504.html ---
> > The
> > History of Programming Languages
> >
> > -- tj
> >
> > ==========================================
> > J. T. Johnson
> > Institute for Analytic Journalism -- Santa Fe, NM USA
> > www.analyticjournalism.com
> > 505.577.6482(c)                                 505.473.9646(h)
> > http://www.jtjohnson.com                 tom at jtjohnson.us
> >
> > "You never change things by fighting the existing reality.
> > To change something, build a new model that makes the
> > existing model obsolete."
> >                                                    -- Buckminster Fuller
> > ==========================================
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070805/1cafd975/attachment.html 

[Owen Densmore]

Sun made use of C++ API's (that customers see) illegal.  This was in  
the 1995-2000 time frame.

This was mainly because there was not a good binary standard for  
shared libraries at that time that used C++.  Also, it turned out  
that there were a few studies done about software engineering in C++  
being a failure -- it just took too much time for various projects to  
agree on their dialect.  Basically C++ at the time simply had too  
many ways to do the same thing.  Even constructors had oddly  
differing syntax and slightly different semantics.

The Scott Meyers book "Effective C++: 55 Specific Ways to Improve  
Your Programs and Designs" .. or as we called it "55 ways not to  
shoot yourself in the foot" was the final proof.  We simply could not  
agree on what the hell all the issues were.

So Sun decided it was fine to use C++ in isolation.  Groups like the  
multi media group I headed up for a few years decided on a C wrapper  
around a fairly complicated "delegation" system, separating the  
implementation from the interface.  At the time it was the only way  
to do so -- header files simply exposed too much of the  
implementation and fouled up our agile programming techniques.  It  
also had the advantage of making GC simpler: a trivial ref counted  
system allowed course grained GC to work very well at nearly no cost.

This idea of C wrappers became the corporate standard, and folks  
really loved it.  (Interesting enough, we *did* allow projects to  
interface to other project's C++ if they wanted to.  Zero decided to  
do so.  Just memory management could not be agreed upon.)

This was a sorta win-win situation: groups could use C++ in  
isolation, but customers did not have to adapt our protocols and  
dialects.  And it all worked fine with binary shared libraries.

I presume all this has been cleaned up.  But I remember a long  
conversation with Bjarne Stroustrup, who finally gave up saying: But  
its not SUPPOSED to be a great OO system, just a better C++.  Not  
sure its there yet.  Scott Meyers is still making a bundle trying to  
guide folks around the horrors.

HOWEVER: There is hope.  Look at the D language, for something that  
may actually solve all the C++ problems!  Here's the usual pointer:
   http://en.wikipedia.org/wiki/D_programming_language

     -- Owen


On Aug 5, 2007, at 4:07 AM, Russell Standish wrote:

> C++ is not just an OO language, obviously, but are you saying that it
> isn't an OO language at all?
>
> I use C++ extensively, and use it procedurally, functionally,
> object-orientedly, generically, and often a mixture of all of the
> above, as appropriate for the problem at hand.
>
> I'm aware of C++ negative points (confusion between "." and "->", "[]"
> and "()", ";" needed after class defintions, but not function or
> namespace definitions), but all of these are superficial, and picked
> up by the compiler immediately.
>
> More significant C++ deficiencies...
>
> Generic programming (ie templates) is a bit more of a problem - the
> standard makes the inheritance model somewhat unintuitive. And
> different compilers seem to interpret the standard differently,
> meaning one needs to test all advanced template code carefully on
> different compilers.
>
> But having said that, using basic generic capability equivalent to
> what Java or C# offers, is unproblematic, and useful even to novice
> users.
>
> Finally, there is the renowned memory management problems. This comes
> from trying to program C++ using a Java or a C programming style. It
> is simple to avoid all such problems by using the simple rule "no bare
> pointers". Use a container, or a reference type (either the static
> built in type, or one of the dynamic reference types available in
> boost and/or TR1). The only reasons to use bare pointers is for access
> to legacy APIs (in which case you should wrap it into a C++ type), and
> for performance reasons, which you should only do after your code has
> been fully debugged.
>
> But I would still say that C++ gives me the ability to build more
> complex code, more efficiently, in about a similar or even reduced
> development time to other competitive languages. I couldn't give a fig
> whether it follows a pure OO model or not.
>
> Cheers
>
> On Sun, Aug 05, 2007 at 07:31:12PM -0400, Prof David West wrote:
>>
>>
>>
>> In my book - Object Thinking - I referenced a lot of material from  
>> this
>> series of books re: Simula, Smalltalk, and C++ (Java was still absent
>> from the books) to make the point that a lot of so-called object
>> languages were never intended to be such and that the only reason  
>> they
>> made the claim was for marketing purposes.  And because programmers
>> failed to see why the history, purpose, and philosophy of a  
>> language was
>> relevant to using the language, 98% of the programmers still have no
>> clue how to to OO.
>>
>> davew
>>
>>
>> On Sat, 4 Aug 2007 18:53:18 -0600, "Tom Johnson" <tom at jtjohnson.com>
>> said:
>>>> From time to time, some of us have expressed an interest in the  
>>>> evolution of
>>> various computer languages.  Turns our others shared our interest  
>>> and did
>>> something about it.
>>>
>>> http://www.oreilly.com/pub/a/oreilly/news/ 
>>> languageposter_0504.html ---
>>> The
>>> History of Programming Languages
>>>
>>> -- tj
>>>
>>> ==========================================
>>> J. T. Johnson
>>> Institute for Analytic Journalism -- Santa Fe, NM USA
>>> www.analyticjournalism.com
>>> 505.577.6482(c)                                 505.473.9646(h)
>>> http://www.jtjohnson.com                 tom at jtjohnson.us
>>>
>>> "You never change things by fighting the existing reality.
>>> To change something, build a new model that makes the
>>> existing model obsolete."
>>>                                                    -- Buckminster  
>>> Fuller
>>> ==========================================
>>
>> ============================================================
>> FRIAM Applied Complexity Group listserv
>> Meets Fridays 9a-11:30 at cafe at St. John's College
>> lectures, archives, unsubscribe, maps at http://www.friam.org
>
> --
>
> ----------------------------------------------------------------------
> ------
> A/Prof Russell Standish                  Phone [phone] (mobile)
> Mathematics                        
> UNSW SYDNEY 2052                 hpcoder at hpcoders.com.au
> Australia                                http://www.hpcoders.com.au
> ----------------------------------------------------------------------
> ------
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

[Russell Standish]

On Sun, Aug 05, 2007 at 09:45:23PM -0600, Owen Densmore wrote:

> Sun made use of C++ API's (that customers see) illegal.  This was in  
> the 1995-2000 time frame.
>
> This was mainly because there was not a good binary standard for  
> shared libraries at that time that used C++.  Also, it turned out  
> that there were a few studies done about software engineering in C++  
> being a failure -- it just took too much time for various projects to  
> agree on their dialect.  Basically C++ at the time simply had too  
> many ways to do the same thing.  Even constructors had oddly  
> differing syntax and slightly different semantics.
>

The ABI issue is still with us. Its less of a problem in the open
source world (you just compile all your C++ libraries with the
compiler you want to use), than in the close source world, but if
you're in the habit of switching compilers regularly (I often switch
between gcc and icc), it is a nuisance to have to rebuild all your
libraries, or have special paths for different compilers. Its the same
problem with those OSes that have combined 32 and 64 bit modes (Irix,
the more recent Linuxes for instance).

> The Scott Meyers book "Effective C++: 55 Specific Ways to Improve  
> Your Programs and Designs" .. or as we called it "55 ways not to  
> shoot yourself in the foot" was the final proof.  We simply could not  
> agree on what the hell all the issues were.
>

Indeed, one of C++'s failings is the difficulty in learning how to
program it correct (not withstanding Meyers's fine efforts in this
regard). But _once_ you have learnt, you are every bit as productive
as in other (presumably easier to learn) environments.

>
> HOWEVER: There is hope.  Look at the D language, for something that  
> may actually solve all the C++ problems!  Here's the usual pointer:
>    http://en.wikipedia.org/wiki/D_programming_language
>
>      -- Owen

I'll look at D one of these days. I'm waiting for it to develop a level
of maturity and adoption... I have been a committed C++ programmer for
the last 14 years, but prior to that, I was a died-in-the-wool Pascal
programmer. I do switch for better languages, when significantly
better alternatives exist. At present neither Java nor C# cut the
mustard.

Cheers


--

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone [phone] (mobile)
Mathematics                        
UNSW SYDNEY 2052                 hpcoder at hpcoders.com.au
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------

[Douglas Roberts-2]

Interesting, Owen.  I'm curious what some of D's features will result in,
performance-wise.  Particularly garbage collection, and the single
inheritance hierarchy.

--Doug

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell

On 8/5/07, Owen Densmore <owen at backspaces.net> wrote:

>
> Sun made use of C++ API's (that customers see) illegal.  This was in
> the 1995-2000 time frame.
>
> This was mainly because there was not a good binary standard for
> shared libraries at that time that used C++.  Also, it turned out
> that there were a few studies done about software engineering in C++
> being a failure -- it just took too much time for various projects to
> agree on their dialect.  Basically C++ at the time simply had too
> many ways to do the same thing.  Even constructors had oddly
> differing syntax and slightly different semantics.
>
> The Scott Meyers book "Effective C++: 55 Specific Ways to Improve
> Your Programs and Designs" .. or as we called it "55 ways not to
> shoot yourself in the foot" was the final proof.  We simply could not
> agree on what the hell all the issues were.
>
> So Sun decided it was fine to use C++ in isolation.  Groups like the
> multi media group I headed up for a few years decided on a C wrapper
> around a fairly complicated "delegation" system, separating the
> implementation from the interface.  At the time it was the only way
> to do so -- header files simply exposed too much of the
> implementation and fouled up our agile programming techniques.  It
> also had the advantage of making GC simpler: a trivial ref counted
> system allowed course grained GC to work very well at nearly no cost.
>
> This idea of C wrappers became the corporate standard, and folks
> really loved it.  (Interesting enough, we *did* allow projects to
> interface to other project's C++ if they wanted to.  Zero decided to
> do so.  Just memory management could not be agreed upon.)
>
> This was a sorta win-win situation: groups could use C++ in
> isolation, but customers did not have to adapt our protocols and
> dialects.  And it all worked fine with binary shared libraries.
>
> I presume all this has been cleaned up.  But I remember a long
> conversation with Bjarne Stroustrup, who finally gave up saying: But
> its not SUPPOSED to be a great OO system, just a better C++.  Not
> sure its there yet.  Scott Meyers is still making a bundle trying to
> guide folks around the horrors.
>
> HOWEVER: There is hope.  Look at the D language, for something that
> may actually solve all the C++ problems!  Here's the usual pointer:
>    http://en.wikipedia.org/wiki/D_programming_language
>
>      -- Owen
>
>
> On Aug 5, 2007, at 4:07 AM, Russell Standish wrote:
>
> > C++ is not just an OO language, obviously, but are you saying that it
> > isn't an OO language at all?
> >
> > I use C++ extensively, and use it procedurally, functionally,
> > object-orientedly, generically, and often a mixture of all of the
> > above, as appropriate for the problem at hand.
> >
> > I'm aware of C++ negative points (confusion between "." and "->", "[]"
> > and "()", ";" needed after class defintions, but not function or
> > namespace definitions), but all of these are superficial, and picked
> > up by the compiler immediately.
> >
> > More significant C++ deficiencies...
> >
> > Generic programming (ie templates) is a bit more of a problem - the
> > standard makes the inheritance model somewhat unintuitive. And
> > different compilers seem to interpret the standard differently,
> > meaning one needs to test all advanced template code carefully on
> > different compilers.
> >
> > But having said that, using basic generic capability equivalent to
> > what Java or C# offers, is unproblematic, and useful even to novice
> > users.
> >
> > Finally, there is the renowned memory management problems. This comes
> > from trying to program C++ using a Java or a C programming style. It
> > is simple to avoid all such problems by using the simple rule "no bare
> > pointers". Use a container, or a reference type (either the static
> > built in type, or one of the dynamic reference types available in
> > boost and/or TR1). The only reasons to use bare pointers is for access
> > to legacy APIs (in which case you should wrap it into a C++ type), and
> > for performance reasons, which you should only do after your code has
> > been fully debugged.
> >
> > But I would still say that C++ gives me the ability to build more
> > complex code, more efficiently, in about a similar or even reduced
> > development time to other competitive languages. I couldn't give a fig
> > whether it follows a pure OO model or not.
> >
> > Cheers
> >
> > On Sun, Aug 05, 2007 at 07:31:12PM -0400, Prof David West wrote:
> >>
> >>
> >>
> >> In my book - Object Thinking - I referenced a lot of material from
> >> this
> >> series of books re: Simula, Smalltalk, and C++ (Java was still absent
> >> from the books) to make the point that a lot of so-called object
> >> languages were never intended to be such and that the only reason
> >> they
> >> made the claim was for marketing purposes.  And because programmers
> >> failed to see why the history, purpose, and philosophy of a
> >> language was
> >> relevant to using the language, 98% of the programmers still have no
> >> clue how to to OO.
> >>
> >> davew
> >>
> >>
> >> On Sat, 4 Aug 2007 18:53:18 -0600, "Tom Johnson" <tom at jtjohnson.com>
> >> said:
> >>>> From time to time, some of us have expressed an interest in the
> >>>> evolution of
> >>> various computer languages.  Turns our others shared our interest
> >>> and did
> >>> something about it.
> >>>
> >>> http://www.oreilly.com/pub/a/oreilly/news/
> >>> languageposter_0504.html ---
> >>> The
> >>> History of Programming Languages
> >>>
> >>> -- tj
> >>>
> >>> ==========================================
> >>> J. T. Johnson
> >>> Institute for Analytic Journalism -- Santa Fe, NM USA
> >>> www.analyticjournalism.com
> >>> 505.577.6482(c)                                 505.473.9646(h)
> >>> http://www.jtjohnson.com                 tom at jtjohnson.us
> >>>
> >>> "You never change things by fighting the existing reality.
> >>> To change something, build a new model that makes the
> >>> existing model obsolete."
> >>>                                                    -- Buckminster
> >>> Fuller
> >>> ==========================================
> >>
> >> ============================================================
> >> FRIAM Applied Complexity Group listserv
> >> Meets Fridays 9a-11:30 at cafe at St. John's College
> >> lectures, archives, unsubscribe, maps at http://www.friam.org
> >
> > --
> >
> > ----------------------------------------------------------------------
> > ------
> > A/Prof Russell Standish                  Phone [phone] (mobile)
> > Mathematics
> > UNSW SYDNEY 2052                       hpcoder at hpcoders.com.au
> > Australia                                http://www.hpcoders.com.au
> > ----------------------------------------------------------------------
> > ------
> >
> > ============================================================
> > FRIAM Applied Complexity Group listserv
> > Meets Fridays 9a-11:30 at cafe at St. John's College
> > lectures, archives, unsubscribe, maps at http://www.friam.org
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20070805/78bc6ac5/attachment.html 

[Prof David West]

If pressed into a corner, I would say that C++ is not an OO language at
all - because the philosophy behind its creation is antithetical in
important ways to the IDEA of objects.  Examples:

   Simula is considered the first Object language (not Simula-68 which
   was a programming language, not an object language like Simula) and
   its philosophical foundation was to create "natural" constructs
   reflective of a problem domain that could be easily combined and
   connected to solve problems - with zero concern about the machine
   resources or performance efficiency required behind the scenes.  In
   contrast - Stroustrup explicitly and adamantly refused to allow
   anything into C++ that would impair the speed of execution and
   efficiency of machine utilization that was available in C.

    Smalltalk - the exemplar object language (even though it is really
    class based and not object based like Self) had a similar
    philosophical foundation - to allow exploratory, "natural," and
    interactive dialog between domain experts (and children) and the
    machine in pursuit of a problem solution - also with minimal concern
    for machine performance, the machine was supposed to do the heavy
    lifting, not the human.  The closest that C++ came to this idea was
    Stroustrup's intent to provide "discipline" to out of control C
    programmers who prided themselves on how terse and obfuscatory they
    could make code that would still run and provide specified results.
    (they had annual contests dedicated to this endeavor and probably
    still do).

   The object idea is fundamentally dependent on the concept that
   EVERYTHING is an Object - and any language that enforces strong
   typing violates this principle.

Having said that - I would admit that C++ is indeed a Turing machine and
is therefore, at its core, cannot be differentiated from any other
programming language and that it does provide some constructs that allow
a developer to construct objects (classes) and do object-like coding -
but doing so is very unnatural, uncomfortable, and "feels wrong."

The idea of objects leads one to very different analytical (mostly
decomposition) and design solutions than procedural or data-based
thinking.  Given an object design it is very difficult to express that
design in C++ and trivial to express that design in Smalltalk.  (Ruby
makes it easy to express the idea but does make it a bit more difficult,
but only because you have to ignore some non-relevant aspects of the
language.)  Lisp - with CLOS,  Flavors and similar extensions -also
makes it easier to express object design.


> But I would still say that C++ gives me the ability to build more
> complex code, more efficiently, in about a similar or even reduced
> development time to other competitive languages. I couldn't give a fig
> whether it follows a pure OO model or not.
>

I would be willing to bet that an individual proficient in Smalltalk to
the same degree as you are in C++ could develop almost any piece of
software in 1/3 to 1/5 the time it took the C++ team, and with some
minor tricks make it run in as small or smaller a footprint with an
equal or lesser number of machine cycles.  I have consistently seen it
done.

davew

> ----------------------------------------------------------------------------
> A/Prof Russell Standish                  Phone [phone] (mobile)
> Mathematics                              
> UNSW SYDNEY 2052                         hpcoder at hpcoders.com.au
> Australia                                http://www.hpcoders.com.au
> ----------------------------------------------------------------------------
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

[Russell Standish]

On Mon, Aug 06, 2007 at 11:06:58AM -0400, Prof David West wrote:
>
> If pressed into a corner, I would say that C++ is not an OO language at
> all - because the philosophy behind its creation is antithetical in
> important ways to the IDEA of objects.  Examples:

  ....

>
>
>    The object idea is fundamentally dependent on the concept that
>    EVERYTHING is an Object - and any language that enforces strong
>    typing violates this principle.
>

Which appears to reinforce the statement I made that C++ is not _just_
and OO language. One can program C++ where every type used is derived
from a polymorphic base object in the way that you mention. But strong
typing is an important defence mechanism against bugs, so it would be
silly to actually program C++ in such a way.

> Having said that - I would admit that C++ is indeed a Turing machine and
> is therefore, at its core, cannot be differentiated from any other
> programming language and that it does provide some constructs that allow
> a developer to construct objects (classes) and do object-like coding -
> but doing so is very unnatural, uncomfortable, and "feels wrong."
>

This sounds like a C programmer talking!

> The idea of objects leads one to very different analytical (mostly
> decomposition) and design solutions than procedural or data-based
> thinking.  Given an object design it is very difficult to express that
> design in C++ and trivial to express that design in Smalltalk.  (Ruby
> makes it easy to express the idea but does make it a bit more difficult,
> but only because you have to ignore some non-relevant aspects of the
> language.)  Lisp - with CLOS,  Flavors and similar extensions -also
> makes it easier to express object design.
>

Where do these object designs come from? I get given problems (solve
x, y and z). Its up to me to provice the solution, and I usually do it
directly in C++, occasionally with a hand-drawn picture to see how
chunks fit together.

>
> > But I would still say that C++ gives me the ability to build more
> > complex code, more efficiently, in about a similar or even reduced
> > development time to other competitive languages. I couldn't give a fig
> > whether it follows a pure OO model or not.
> >
>
> I would be willing to bet that an individual proficient in Smalltalk to
> the same degree as you are in C++ could develop almost any piece of
> software in 1/3 to 1/5 the time it took the C++ team, and with some
> minor tricks make it run in as small or smaller a footprint with an
> equal or lesser number of machine cycles.  I have consistently seen it
> done.
>
> davew

That wasn't exactly the point I was making - I was referring to myself
choosing a language for a task given my already extensive experience
in C++. It does give a "lock-in" advantage to the language. I also had
in mind the supposed C++ replacements, ie Java and C#, rather than say
Smalltalk or Ruby.

I am not a 1 language shop. I do use Perl for some tasks, as it
sometimes is quicker to get stuff done in a rich, interpretive
environment. I use TCL for mostly GUI type work, and I'm thinking that
Java probably has significant advantages over TCL for GUI stuff.

Cheers

--

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone [phone] (mobile)
Mathematics                        
UNSW SYDNEY 2052                 hpcoder at hpcoders.com.au
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------

[Marcus G. Daniels]

Prof David West wrote:
> If pressed into a corner, I would say that C++ is not an OO language at
> all - because the philosophy behind its creation is antithetical in
> important ways to the IDEA of objects.
Computer architecture people (mostly the people that work on mainstream
compilers) tend to work from the hardware up, understanding the subtle
and important details of code generation on hardware utilization,
whereas computer scientists tend  to create languages that only
occasionally can be optimized effectively on existing architectures, but
have other appealing attributes besides performance.    

Ironically, C++ implementors are faced with language constructs that
hurt performance as much as they help.   Without pointers, it's easier
to identify objects that are untouched in a call hierarchy and prove
they are constant and thereby factor those calculations outside of
loops.   This is not to say that languages like Smalltalk don't
introduce their own problems.   Dynamic message dispatch, besides
involving a non-zero computation, can do a fine job of confusing branch
prediction, and stalling the CPU's pipeline of instructions.   In
contrast, C++ member functions can be inlined to their caller.

The main problem I have with languages that are more concerned with
ideas than performance, is that they never seem to manage provide the
programmer with an transparent model of how the language will map to
hardware.   Without that, it means either

1) the compiler can generate excellent code in a completely automatic way
2)  putting the burden on the programmer to have a full model of the
implementation and the architecture, in which case of course the
programmer can make fast code.   It also assumes that the programmer is
basically a language implementor, which is a pretty big demand
3) forcing the programmer to drop down to a lower level language for
performance (which taints the beauty of the main code and also assumes
the programmer knows how to use the lower level language)
4) tolerating up to an order of magnitude performance penalty

In the Lisp community, the approach was mostly #2.    Nowadays, say with
Java, #3 and #4 are the main approaches (#4 just because computers are
so fast now).  I don't think anyone has really succeeded in #1 yet,
except in specialized domains.

Marcus

[Owen Densmore]

BTW: we could likely try D fairly easily, its part of GCC:
   http://dgcc.sourceforge.net/

They call it GDC, but I doubt that signifies any interesting  
difference from the Digital Mars version:
   http://www.digitalmars.com/d/dcompiler.html
.. and the gnu version looks to have a wider distribution.

The FAQ on DM sez that the gnu version integrated the DM front end  
into GCC, so it looks like they are quite compatible.  It also points  
to DWT, a port of SWT from Java to D:
   http://www.dsource.org/projects/dwt/
I wonder if this suggests Java <> D ports are not that difficult?

 From the dgcc site:
   GDC works with GCC versions 3.3.x, 3.4.x, and 4.0.x.
     * Linux (tested on Fedora Core 5 x86 and PowerPC)
     * Mac OS X 10.3.x, 10.4.x
     * FreeBSD 5.2.1
     * Cygwin
     * MinGW
     * AIX (tested on 5.1)

I bring all this up because we could try it out, possibly on existing  
C++ programs modified for D.

     -- Owen

[Marcus G. Daniels]

Note that D doesn't really add Smalltalk features to C++.   Objective
C++ does, mostly.    (Objective C++ is in GCC.)

[Prof David West]

We probably agree on almost everything - especially at the level of
programming language comparisons (except the matter of typing which is
beyond the pale- the supposed benefits are totally illusory, IMHO, for a
variety of reasons).

For me, design is everything and a programming language is judged almost
exclusively on how easy it is to directly express the design.  (A
secondary consideration is the ease with which the language allows
iterative and exploratory development which excludes all compiled
languages.)

As for where the designs come from - mostly observation and adherence to
a few heuristics - almost all of which were espoused by (but not
necessarily followed by) the early proponents of OO.

Some example of how object designs differ:

If you are writing software for a vending machine - money arithmetic
belongs with the money object not an accumulator or a counter object, if
you are writing software to operate a brewery, design should proceed
from the point of view of the beer seeking to leave a vat and enter a
mouth instead of the perspective of the "control room" monitoring the
bottling line, if you are writing mathematica, your design should be
based on expressions that know how to modify and solve themselves (self
evaluating rules is the generic design) instead of any form of
"calculator" object.

You can sometimes tell if your design is OO by looking to see if you
have certain structures in your code:  case statements for example will
not exist (or be needed) if your design was OO, loops will never be
explicitly coded (instead you will send messages like "do" and "select"
to collection objects, and, if you are using an interpreted VM based
language, your code should be modifiable at run time - no need to "bring
it back to the shop" for modification, recompilation, relinking, and
re-distribution.

Russel -- if you would like to chat about design off-line where we do
not bore the others -- please email me.  You can give me a problem, I
will give you an OO design, and we can discuss its problems or merits.

davew




On Mon, 6 Aug 2007 15:29:28 +1000, "Russell Standish"
<r.standish at unsw.edu.au> said:

> On Mon, Aug 06, 2007 at 11:06:58AM -0400, Prof David West wrote:
> >
> > If pressed into a corner, I would say that C++ is not an OO language at
> > all - because the philosophy behind its creation is antithetical in
> > important ways to the IDEA of objects.  Examples:
>
>   ....
>
> >
> >
> >    The object idea is fundamentally dependent on the concept that
> >    EVERYTHING is an Object - and any language that enforces strong
> >    typing violates this principle.
> >
>
> Which appears to reinforce the statement I made that C++ is not _just_
> and OO language. One can program C++ where every type used is derived
> from a polymorphic base object in the way that you mention. But strong
> typing is an important defence mechanism against bugs, so it would be
> silly to actually program C++ in such a way.
>
> > Having said that - I would admit that C++ is indeed a Turing machine and
> > is therefore, at its core, cannot be differentiated from any other
> > programming language and that it does provide some constructs that allow
> > a developer to construct objects (classes) and do object-like coding -
> > but doing so is very unnatural, uncomfortable, and "feels wrong."
> >
>
> This sounds like a C programmer talking!
>
> > The idea of objects leads one to very different analytical (mostly
> > decomposition) and design solutions than procedural or data-based
> > thinking.  Given an object design it is very difficult to express that
> > design in C++ and trivial to express that design in Smalltalk.  (Ruby
> > makes it easy to express the idea but does make it a bit more difficult,
> > but only because you have to ignore some non-relevant aspects of the
> > language.)  Lisp - with CLOS,  Flavors and similar extensions -also
> > makes it easier to express object design.
> >
>
> Where do these object designs come from? I get given problems (solve
> x, y and z). Its up to me to provice the solution, and I usually do it
> directly in C++, occasionally with a hand-drawn picture to see how
> chunks fit together.
>
> >
> > > But I would still say that C++ gives me the ability to build more
> > > complex code, more efficiently, in about a similar or even reduced
> > > development time to other competitive languages. I couldn't give a fig
> > > whether it follows a pure OO model or not.
> > >
> >
> > I would be willing to bet that an individual proficient in Smalltalk to
> > the same degree as you are in C++ could develop almost any piece of
> > software in 1/3 to 1/5 the time it took the C++ team, and with some
> > minor tricks make it run in as small or smaller a footprint with an
> > equal or lesser number of machine cycles.  I have consistently seen it
> > done.
> >
> > davew
>
> That wasn't exactly the point I was making - I was referring to myself
> choosing a language for a task given my already extensive experience
> in C++. It does give a "lock-in" advantage to the language. I also had
> in mind the supposed C++ replacements, ie Java and C#, rather than say
> Smalltalk or Ruby.
>
> I am not a 1 language shop. I do use Perl for some tasks, as it
> sometimes is quicker to get stuff done in a rich, interpretive
> environment. I use TCL for mostly GUI type work, and I'm thinking that
> Java probably has significant advantages over TCL for GUI stuff.
>
> Cheers
>
> --
>
> ----------------------------------------------------------------------------
> A/Prof Russell Standish                  Phone [phone] (mobile)
> Mathematics                              
> UNSW SYDNEY 2052                         hpcoder at hpcoders.com.au
> Australia                                http://www.hpcoders.com.au
> ----------------------------------------------------------------------------
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

[Russell Standish]

On Mon, Aug 06, 2007 at 07:26:05PM -0400, Prof David West wrote:
>
> We probably agree on almost everything - especially at the level of
> programming language comparisons (except the matter of typing which is
> beyond the pale- the supposed benefits are totally illusory, IMHO, for a
> variety of reasons).
>

I'm sure this point has been done to death by wiser heads than I. I
can only comment that in practise, I have found strong typing helpful
in managing complexity. I would hate to write anything really complex
in Perl, for instance, but for simple stuff it is fantastic not to
have to worry about typing.

> For me, design is everything and a programming language is judged almost
> exclusively on how easy it is to directly express the design.  (A
> secondary consideration is the ease with which the language allows
> iterative and exploratory development which excludes all compiled
> languages.)

Interestingly, with EcoLab, I achieve this latter requirement by adding an
interpretive environment to the compiled core. It may not be elegant
in the sense Eiffel has an elegant compiled/interepreted hybrid
environment, but it does work, and is efficient (or at least can be
with care).

>
> As for where the designs come from - mostly observation and adherence to
> a few heuristics - almost all of which were espoused by (but not
> necessarily followed by) the early proponents of OO.
>
> Some example of how object designs differ:
>
> If you are writing software for a vending machine - money arithmetic
> belongs with the money object not an accumulator or a counter object, if
> you are writing software to operate a brewery, design should proceed
> from the point of view of the beer seeking to leave a vat and enter a
> mouth instead of the perspective of the "control room" monitoring the
> bottling line, if you are writing mathematica, your design should be
> based on expressions that know how to modify and solve themselves (self
> evaluating rules is the generic design) instead of any form of
> "calculator" object.
>

I had a lot of experience with SMP, a precursor to Mathematica. Nice
language, wonderfully expressive. But if you couln't express your
problem procedurally, you're so out of luck!

> You can sometimes tell if your design is OO by looking to see if you
> have certain structures in your code:  case statements for example will
> not exist (or be needed) if your design was OO, loops will never be
> explicitly coded (instead you will send messages like "do" and "select"
> to collection objects, and, if you are using an interpreted VM based
> language, your code should be modifiable at run time - no need to "bring
> it back to the shop" for modification, recompilation, relinking, and
> re-distribution.

You make this sound like a big deal!

>
> Russel -- if you would like to chat about design off-line where we do
> not bore the others -- please email me.  You can give me a problem, I
> will give you an OO design, and we can discuss its problems or merits.
>

People have threaded email readers. They can ignore this thread if not
interested. But there will be some who are.

I'll take you up on this. I have a problem. I want to express a
discrete space by a variety of tiling patterns, eg von Neumann, Moore,
and hexagonal (spherical close packing) in 2D and 3D.

The fundamental cell type has a method returning something with
collection semantics, ie has a begin(), end() and size(), which
represents the neighbours. Iterating over the neighbour list returns
references to the relevant cells.

Whilst this can be implemented as an ordinary graph, for memory
efficiency, it needs to be implemented as patches, with each patch
wired up into an appropriate graph topology.

I think I have a solution to this, but I haven't coded it yet. But it
definitely requires a switch statement, and for loops. I'd be
interested in your design though.

Cheers

--

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone [phone] (mobile)
Mathematics                        
UNSW SYDNEY 2052                 hpcoder at hpcoders.com.au
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------