Re: language design after Algol 60, was Add nested-function support

On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:


>George Neuner <gneuner2@comcast.net> writes:
>>The necessity to write "Design Patterns" was, IMO, acknowledgement
>>that the average programmer could not figure out how to express their
>>ideas under Java's limited object model.
>
>Design Patterns was published in 1994 (based on work that started in
>1990), before Java was published in 1995.


Java began in 1991 ... as a language called "Oak". Many people used
and/or experimented with Oak for mobile programming prior to it
becoming Java. It was very well known.




>Moreover, [Design Patterns] says at the
>beginning that the design patterns are somewhat language-specific, and
>that the language they have in target is C++.


That is *partly* true, but read on.




On page 14, it says:
<quote>
  :
We chose Smalltalk and C++ for pragmatic reasons: Our day-to-day
experience has been in these languages, and they are increasingly
popular.


The choice of programming language is important because it influences
one's point of view. Our patterns assume Smalltalk/C++-level language
features, and that choice determines what can and cannot be
implemented easily.
  :
</quote>




Smalltalk had/has single inheritence only, and it's dynamic dispatch
mechanism is very different from that of C++. Examples that were
meant to work in both languages had to be targeted to the lowest
common denominator ... which in most cases meant Smalltalk even if the
syntax of the example was in C++.


The largely Smalltalk centric text transferred very naturally to
Oak/Java because their object models shared many of the same
limitations. Oak already was more popular than Smalltalk by the time
the book was finished, and the more expansive desktop Java was
starting to take off as well.


[Yes, I have ... in honesty, read parts of, skimmed others ... the
book. And yes, I worked with Smalltalk (ParcPlace on the Macintosh)
plenty enough to be familiar with its object model. Smalltalk was my
6th or 7th programming language - I was learning Objective-C at more
or less the same time, so I'm not quite certain of the chronology
there. C++ (at least what it added wrt C) came next as my 8th
language.]




There is some good stuff in the book, but many of the patterns either
are trivial to implement or simply unnecessary in C++ where all code
does NOT have to be ensconced in some object. Many others add little
value in C++ beyond some algorithmic decoupling.


Now decoupling is a three edged sword: it can make code more
maintainable, but it can also make code more complicated. In either
case, it can (and usually does) make code slower.


C++ programmers accept that using objects exacts a small runtime cost,
but as a breed they tend to eschew things that make their programs
*unnecessarily* slower.


So C++ programmers largely ignored "Design Patterns" because many felt
it really wasn't all that useful to them.




OTOH, Java programmers embraced it and held it up as the gospel of
program design. For quite a long while, if you weren't intimately
familiar with the gory details of <insert pattern here>, you couldn't
get a Java programming job to save your life.


Not so for C++. Few C++ managers gave a damn whether you could
describe <insert pattern here> ... most were more interested in how
you would go about solving the problem.




>It seems to me to be
>more a guideline of how to make use of the vast possibilities of a
>programming language to achieve certain things effectively (and with
>maintainable results), rather than a guideline on how to work around
>limitations.


That's undoubtedly what it was intended to be. Unfortunately I think
it ended up being more of a crutch for Java.




>- anton
YMMV, and certainly it will.
George

Return to the comp.compilers page.
Search the comp.compilers archives again.