Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: George Neuner Newsgroups: comp.compilers Subject: Re: language design after Algol 60, was Add nested-function support Date: Tue, 10 Apr 2018 14:32:20 -0400 Organization: A noiseless patient Spider Lines: 99 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <18-04-034@comp.compilers> References: <49854345-f940-e82a-5c35-35078c4189d5@gkc.org.uk> <18-03-103@comp.compilers> <18-03-042@comp.compilers> <18-03-047@comp.compilers> <18-03-075@comp.compilers> <18-03-079@comp.compilers> <18-03-101@comp.compilers> <18-04-002@comp.compilers> <18-04-003@comp.compilers> <18-04-004@comp.compilers> <18-04-024@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="61041"; mail-complaints-to="abuse@iecc.com" Keywords: design, history, Java Posted-Date: 11 Apr 2018 13:22:30 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2053 On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >George Neuner 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: : 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. : 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 , 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 ... 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