Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!decwrl!limbo!taylor From: taylor@limbo.Intuitive.Com (Dave Taylor) Newsgroups: comp.misc Subject: Re: Request for War Stories Message-ID: <1063@limbo.Intuitive.Com> Date: 6 Aug 90 17:40:34 GMT References: <284@txsil.lonestar.org> <5428@stpstn.UUCP> Reply-To: taylor@limbo.Intuitive.Com (Dave Taylor) Organization: Intuitive Systems, Mountain View, CA: +1 (415) 966-1151 Lines: 92 Brad Cox respondes to an initial request by Marc Rettig with some comments on "today's process-centered paradigm for programming": > To paraphrase, a silver bullet does exist, but it is *not* a technology. > It is a paradigm shift; replacement of today's process-centered model > with a product-centered model; centering on a marketplace in > interchangeable software components instead of as today, on languages > and methodologies. I'll disagree. The key to my rebuttal is that the current evolutionary trend of programming languages is to become more specific, and more customized to a particular niche. Examples abound, including the Prolog language which embodies much information about expert systems, and the MacApp language which offers a high level of self-knowledge about the Macintosh interface. While it is true that the latter, at least, and similar "object oriented languages", accomplish this through the use of user extensible libraries, this too is nothing new. In C on Unix, for example, I've been able to bring in special sublanguages with specific additional features that I've needed for at least ten years, through the use of the "-l lib" flag at compile time. Indeed, my take on this is that the evolutionary step for prog languages is that they become more and more specific, resulting in languages that have a common ancestor and appearance (C, Pascal, FORTRAN, or LISP perhaps) yet can be carefully designed to fit into a specific programming niche. I believe that currently programming libraries offer this functionality. It's really a matter of thinking about things differently; if I want to have a language that looks a lot like C but offers more powerful mathematical functionality the solution is easy; I use "-lm" to add the math library at link time, and voila! Hundreds of new task oriented functions are available for my use. Ultimately what I see us doing is paralleling what happens in spoken languages too; C/Pascal/LISP offers the basic framework for the specialized languages, a framework that we can share and utilize as needed, and the libraries, existing or third-party supplied, offer specialized 'jargons' for the specific niche we're working within. This is completely analogous to the incomprehensible discussion between two professionals in a specific field (computers, medicine, psychology, etc) where individual words can be understood, but the overall point of the discussion can be missed. Obviously, I'm not a big fan of object oriented programming solving all the worlds problems. In fact, I believe that OO is rather an overrated approach to problem solving/programming; like other things, it can be the right solution, but it can also be the wrong solution. And so far, I have never seen a cleanly written, easily comprehended program written in C++, SmallTalk, or any of the other (typically syntactically ugly) so-called object oriented languages. Why do I draw this parallel, then, between programming language evolution and human language (evolution)? Because I believe that programming should be viewed as a type of creative writing; within the confines of a relatively small language, the author must convey (to an annoyingly strict reader/compiler) not only the problem, but the solution too. And ideally, this should be done in such a way that other people can come along later and *read* and *understand* what was written. To flip this around for a sec, a phrase that I've heard as a writer is that "you can always understand your own writing, it's the other people that are the problem". I think that instead of focusing on wierder, more esoteric, and less readable code (C++, for example), our industry should be putting more weight on trying to teach programmers how to communicate to not only their direct audience (the compiler) but the indirect audience too (other people who read/modify the code). Having had the misfortune of reading quite a bit of code from places like Bell Labs, AT&T, UC Berkeley, the University of Utah, Hewlett- Packard, Apple, and other places, all I can say is that it's the RARE programmer who can communicate effectively, with or without legislated coding styles. However, I digress. The point I hope I'm making here is that I don't agree at all with this so-called paradigm shift. I think that the approach to using programming languages as evolutionary problem solving environments is right on. But I don't think that "interchangable software libraries", per se, are going to solve any major problems over and above what we're already seeing today. [ps: interested parties might recall my "Programming Languages: Past, Present and Future" in Computer Language magazine a few years ago.... it talks more about this 'task oriented languages' idea] Just my two cents worth, as they say, -- Dave Taylor Intuitive Systems Macintosh Editor Mountain View, California Computer Language Magazine taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor