johnson@cs.uiuc.EDU (Ralph Johnson) (04/04/91)
For the last few years I have been learning how to make software reusable. I have followed the object-oriented road using Smalltalk and C++. Software is not naturally reusable, and it is not easy to write reusable software. In fact, I have decided that the biggest problem with software reuse is that reusable software is so hard to make. Lots of people seem to be worried about problems like cataloging software components and how to retrieve a component from a library of million of components. I wish that were the problem! The real problem is that it is so hard to create reusable software. This leads to an interesting problem: how can we afford to pay the costs of developing reusable software? If a company is going to build several of something then it might be cheaper for it to first develop a system for producing systems of that kind. However, it will certainly not save money on the first system built. Some application domains, like graphical user interfaces, are popular enough that a company can build a set of reusable components and sell it and make lots of money. I don't think there are many of these application domains, and in any case most people seem to undervalue software and don't want to pay a fair price for it. Thus, it is only cost-effective to sell software if you can sell a lot of it, which rules out specialized application domains. The problem that I see is that there will be many areas where it would be valuable for us to develop standard libraries of software components, but there will be no economic incentives to do so. Does anybody have any ideas on how to solve this problem, whether it is a problem, or (better yet) references to papers that discuss it? Ralph Johnson -- University of Illinois at Urbana-Champaign johnson@cs.uiuc.edu
rsw@cs.brown.EDU (Bob Weiner) (04/05/91)
In article <1991Apr3.231849.13410@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: > For the last few years I have been learning how to make software > reusable. ... > The real problem is that it is so hard to create reusable > software. > > This leads to an interesting problem: how can we afford to pay the > costs of developing reusable software? The same way we afford anything else. We convince ourselves or become convinced that the benefit outweighs the cost. How do we do that? In the industrial world, we gather believable examples of where company A with an established reusability program is trouncing competitor company B who writes most of their software from scratch. The correlation becomes especially believable if company A points to this program as their main success strategy and if they used to trail company B. Electrical engineers have learned the value of standardization, though they do not always apply it. Computer scientists, software engineers, and programmers generally do not show this same understanding, at least as it applies to program generation. Their mindset will also shift as startling examples of technology advancement arrive. And if they don't, then maybe many people will find that they have been promoting the wrong crusade. > Some application domains, like graphical user interfaces, are popular enough > that a company can build a set of reusable components and sell it and make > lots of money. I don't think there are many of these application domains, > and in any case most people seem to undervalue software and don't want to pay > a fair price for it. Thus, it is only cost-effective to sell software if you > can sell a lot of it, which rules out specialized application domains. I think this is a forest-and-trees issue. The development of standardized sets of reusable software components should not be about the commercialization of the components but about their use as enablers in the construction of needed applications within real world constraints of time and resources. People don't make much money selling me a few screws, bricks, or 2-by-4s, but the person who builds a house with such things often gets a very good markup. Because people place much more value on the product he delivers than on the components from which it is made. Further, I submit that there will never be a shortage of software applications for people to work on, since we will forever raise our expectation thresholds for the functionality needed within programs. This in turn means that we will have to invent new components and even re-engineer the old ones as they become dated. All of this is just as true for any industry that society keeps vital through its demands. Since software spans virtually every industry, I see no need for you to worry that component standardization will finish the job once and for all. > The problem that I see is that there will be many areas where it would be > valuable for us to develop standard libraries of software components, but > there will be no economic incentives to do so. Even were this at all true, there are many organizations, even technical ones, which do things mainly for society's benefit. > Does anybody have any ideas on how to solve this problem, whether it is a > problem, or (better yet) references to papers that discuss it? Sony doesn't make a lot directly selling their media or miniaturized circuitry. They settle for market dominance in application areas: computer storage, consumer electronics, profession video, and so forth. The tree view is that they make this money from their competence in the underlying technology areas. The forest view is that they are good at drawing on these strengths to deliver well engineered, timely products in which they locate or develop solid demand. If you do sell non-standalone components, your only market is software developers. This market may be large enough to satisfy many entrepeneurs, but the applications market is insatiable. Remember, no one, in the figurative sense, wants an echo canceler but everyone wants a telephone, making it a popular target of both entrepeneurial and engineering talent. Easy to see why, isn't it? Bob -- Bob Weiner rsw@cs.brown.edu
locke@paradyne.com (Richard Locke) (04/05/91)
In article <1991Apr3.231849.13410@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes:
Ralph asks some good questions:
<...how can we afford to pay the costs of developing reusable software?
<Does anybody have... (better yet) references to papers that discuss it?
Though the book is at work & I'm at home, I recall the "Programmer
Productivity" by Capers Jones has a reasonably extensive discussion
on the economics of reusable software. Jones points out the the
world leaders in software productivity are good at reusing both
designs and code. He goes through a sample exercise of justifying
a large initial investment and showing the payback.
-dick
p.s. Note that Jones defines productivity (I'm paraphrasing here) in
terms of functionality delivered per unit of effort on the "version"
of the delivered software. You could define productivity differently
(like new lines of code/unit time) and this changes ;-)EGNILGES@pucc.Princeton.EDU (Ed Nilges) (04/06/91)
In article <1991Apr5.040312.29351@pdn.paradyne.com>, locke@paradyne.com (Richard Locke) writes: >In article <1991Apr3.231849.13410@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: > >Ralph asks some good questions: > ><...how can we afford to pay the costs of developing reusable software? A government or government-sponsored effort is one possibility. The U. S. Government printing office has long made a variety of information on various scientific topics cheaply available. It could start selling book/diskette combinations of reusable tools for various areas. This would prevent horrors such as runaway patenting of obvious algorithms (including blinking cursors.) It would also make it possible for small startups to concentrate development efforts on the end-user problem they were chartered to solve without having to buy collections of software typically priced past 200.00 per single-use package. Too many programmers in small businesses of all types are faced with a cruel choice: "wasting time" by developing documented reusable components or creating huge, unmaintainable agglomerations of single-purpose code. Private companies are loth to fund reusability since reusability entails clear documentation of procedures that are in many cases trade secrets. This costs these companies money in the form of too many programmers and it results in a poor product for the end user.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/07/91)
In article <1991Apr3.231849.13410@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: > This leads to an interesting problem: how can we afford to pay the > costs of developing reusable software? Easy: You *don't*. The problem in software today isn't code that's written once. As you observed, it is absolutely pointless to take a unique section of code and make it reusable---or even to start by writing it reusably. But as soon as the code is written twice, it should never have to be written again. As soon as you see that you're *reusing* software, you go back, make the original *reusable*, and then *reuse* it. Any competent programmer will assume that what he uses twice, he'll use again, and so he'll put in the extra effort so that it's easy to use. Never do this before you realize that the software will be reused, and you won't waste any money. (As many people have observed, there is a problem of communication here: if programmer X and programmer Y independently need something---once--- then neither of them will realize that it should be made reusable. The only way to improve this situation is to distribute code.) ---Dan
cox@stpstn.UUCP (Brad Cox) (04/08/91)
In article <RSW.91Apr4182149@tahiti.cs.brown.EDU> rsw@cs.brown.EDU (Bob Weiner) writes: >In article <1991Apr3.231849.13410@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: > >> For the last few years I have been learning how to make software >> reusable. >... >> The real problem is that it is so hard to create reusable >> software. >> >> This leads to an interesting problem: how can we afford to pay the >> costs of developing reusable software? Thanks, Bob, for reposting Ralph's question...I'd missed it somehow. (@#$$% usenet gremlins) The organizational motivation for reusability is specialization of labor; making a tree-structured industry of what was previously a monolithic collection of cottage industry skilled craftsmen; a heterogeneous tree of specialized craftsmen instead of a homogeneous collection of programmers all with the same skill set. But Ralph has his finger on the key obstacle to doing this...finding a way to keep the roots of this tree from starving. I believe the demand for a market in reusable components is high, but the supply is low, because of exactly what Ralph has identified; that the costs of building reusable components is extremely high, higher than those who have not tried to do this for a living is probably realize. For example, in my own experience (these are measured numbers based on nearly a decade of actually doing it), the costs of building something reusable are at least ten times higher than the costs of building it in the first place, and possibly much more. I'm referring to the costs of testing, documenting, porting (and retesting and sometimes redocumenting), advertising, marketing and selling. Note that the 10x costs are not easily amenable to technological assistance. If I'm right that the demand exceeds the supply, the situation will develop in a fashion economists are familiar with...prices will rise until reusable component producers decide that the gain exceeds the risk. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
egnilges@phoenix.Princeton.EDU (Ed Nilges) (04/08/91)
In article <6761@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > >I believe the demand for a market in reusable components is high, but >the supply is low, because of exactly what Ralph has identified; that >the costs of building reusable components is extremely high, higher >than those who have not tried to do this for a living is probably >realize. Darn right, Brad. As one who frequently gets into hot water for spending too much time making things reusable, I find that reusability is quite beneficial in ways that cannot always be quantified or cost-justified. Especially in contract programming, you are paid to do exactly what the customer wants, and it is the kiss of death to bill for reusable software. Nonetheless, a software system built out of reusable components seems always to work better and to be easier to maintain than one that is not so built, once you've tuned critical sections for efficiency. I am currently working on reusable environments in C and in REXX. REXX is a language for writing glue procedures in the IBM mainframe environment that is also useful for general programming and which also has implementations on the Amiga, the PC and unix. REXX at this writing is mostly interpreted. I find that it is much easier to make things reusable in REXX, because writing a reusable tool has only these steps: 1. Document 2. Code 3. Test using a standard harness (called TRY) which displays the before and after environment 4. Place on public disk Note that we document prior to coding. Normally, these components are so simple that this phase is the analysis phase in which we determine our requirements. Note, also, that these are NOT end-user tools: if they were, a "step 0" requirements phase would have to be added. To do a needs determination for these types of tools, we talk to ourselves. Developing C reusable components of equivalent simplicity is a con- siderably more daunting task in that we are using a compiler. This means that we have to set up libraries and worry about porting issues that do not arise in REXX. This does not mean that it is a waste of time to develop reusable C, just that it's more expensive in ways that the theoreticians do not see.
rh@smds.UUCP (Richard Harter) (04/09/91)
In article <1991Apr3.231849.13410@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: > This leads to an interesting problem: how can we afford to pay the > costs of developing reusable software? There have been some studies that show that one of advantages of the more productive programmers is that they reuse their own code. When one thinks about it, this is the optimal situation for reusability. I.e. the programmer is already familiar with the way the code works, its style, and its limitations. Furthermore she/he knows that the code exists and where to find it. Moreover "resusable code" in this context often consists of sections of code rather than complete modules. It might be profitable to think in terms of bridging the gap between programmers so that programmer X can reuse the code of programmer Y in much the same way that a programmer reuses her own code. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
jls@rutabaga.Rational.COM (Jim Showalter) (04/10/91)
>The problem that I see is that there will be many areas where >it would be valuable for us to develop standard libraries of >software components, but there will be no economic incentives >to do so. Does anybody have any ideas on how to solve this >problem, whether it is a problem, or (better yet) references to >papers that discuss it? It's largely the same infrastructural defect that afflicts companies in other areas: short-term focus. Clearly it costs money up front to write reusable software, and yet, amortized over several projects, such an effort pays for itself. But if a company only thinks 3 months ahead, there is no basis for such multi-year payback. Consider a concrete example: every air traffic control system and every air defense system in the world does "track management" (a track is a flying object's trajectory over time). Every such project I've ever been involved with has rewritten track management from scratch (at best scavenging bits and pieces from other iterations). Yet, it is clearly a reusable--and quite large--chunk of the overall problem. A company that noticed this and put such things on a multi-year accounting basis could solve the track management problem once and for all, and realize significant savings over the medium to long term. A few companies have realized that reusable software (particularly application-specific stuff) can provide a competitive advantage, and have started to budget appropriately. I hope the trend continues. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *
weide@elephant.cis.ohio-state.edu (Bruce Weide) (04/11/91)
In article <6761@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > >But Ralph has his finger on the key obstacle to doing this...finding a >way to keep the roots of this tree from starving. > Just to reiterate one of Ralph's important points that Brad goes on to observe later in the above article... The economic question is A key obstacle to practical software reuse, but there are also serious technical impediments to designing good reusable components. People who haven't tried it (seriously) often don't realize that. Even if we figure out how to solve the economic, psychological, sociological, managerial, ..., problems that impede reuse, we STILL have to solve the technical ones, too (e.g., how to design high-quality reusable components). So the economic question is not THEY key issue, IMHO. It is just one of many. In fact, if we solve all the other problems without having good reusable components, we may be worse off than we are now. People will then be able to reuse inappropriate, incorrect, inefficient software components more easily than they can now! -Bruce
johnson@cs.uiuc.EDU (Ralph Johnson) (04/13/91)
In article <3318:Apr705:51:2391@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> |> The problem in software today isn't code that's written once. As you |> observed, it is absolutely pointless to take a unique section of code |> and make it reusable---or even to start by writing it reusably. |> |> But as soon as the code is written twice, it should never have to be |> written again. As soon as you see that you're *reusing* software, you go |> back, make the original *reusable*, and then *reuse* it. Any competent |> programmer will assume that what he uses twice, he'll use again, and so |> he'll put in the extra effort so that it's easy to use. I agree that you should never try to write reusable software unless you have already written the software once. It takes a lot of experience with the application domain to understand what abstractions are important, There are a few areas, such as data structures, parsing, and now user interfaces, where there is a lot of community experience and you can learn about the application domain from books, but that is not common. The right way to develop reusable software is to generalize from a couple of non-reusable versions. However, I disagree that this solves the problem. Often it is not the components (i.e. subroutines or data structures) that you want to reuse, but higher level patterns and the overall architecture of the program. It is difficult to detect these patterns and to abstract them successfully. Putting it another way, you are never going to get InterViews by simple rewriting of X-based programs. In any case, my experience (and that of many others) is that you have to reuse software two or three times (in addition to the one or two times that it took to recognize its value in the first place) before all the "reusability bugs" are out. Many corporations have recognized the value of reusable software and are developing their own libraries. Sometimes this is the best strategy, especially for narrow application domains in which they have, and want to keep, a dominant position in the marketplace. However, a lot of what is being put in these libraries is the same as what everybody else is putting in. We would be a lot better off developing industry standard packages that students could learn, to minimize the cost of retraining new programmers, and to reduce the overall cost of software. There is a lot of reuse going on within single companies, but the marketplace for reusable software is not nearly as large as lots of people thought it would be. Is the marketplace for reusable software destined to be small? Ralph Johnson -- University of Illinois at Urbana-Champaign
marc@dumbcat.sf.ca.us (Marco S Hyman) (04/14/91)
In article <1991Apr12.182420.18587@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) bemoans: > Is the marketplace for reusable software destined to be small? Possibly, Ralph, but not for the reasons you give. I am constantly amazed at the number of re-implementations of standard library functions I see in C code. (Especially the number of broken re-implementations of bsearch.) If today's programmer (excuse me -- software engineer) can not learn what simple functions exist in today's standard C library how can we expect them to learn entire inheritance trees from multiple sources in the reusable software world of tomorrow. I can foresee a time when problems are being solved yet one more time simply because the programmer doesn't know that a tried solution is available. (Hindsight is usually 20/20.) IMHO the real question is one of training and indexing. Training to look for an existing solution first. Indexing to find the solution once you've decided to look for it. With current methods too many find it easier to just solve the problem again. -- // marc // home: marc@dumbcat.sf.ca.us pacbell!dumbcat!marc // work: marc@ascend.com uunet!aria!marc
EGNILGES@pucc.Princeton.EDU (Ed Nilges) (04/15/91)
In article <291@dumbcat.sf.ca.us>, marc@dumbcat.sf.ca.us (Marco S Hyman) writes: >In article <1991Apr12.182420.18587@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) bemoans: > > Is the marketplace for reusable software destined to be small? > >Possibly, Ralph, but not for the reasons you give. I am constantly amazed at >the number of re-implementations of standard library functions I see in C >code. (Especially the number of broken re-implementations of bsearch.) If >today's programmer (excuse me -- software engineer) can not learn what simple >functions exist in today's standard C library how can we expect them to learn >entire inheritance trees from multiple sources in the reusable software world >of tomorrow. Usually re-implementations of existing library functions are the result of ignorance of what's available, but not always. In the past, not all C compilers came with a complete library and you may be looking at code written in an environment lacking bsearch. The best course would be to replace the re-implementation with the Real Thing, but the re-imple- mentation may have features on which the rest of the code depends or worse it may have bugs on which the rest of the code depends. We badly need a "Programmer's Desk Reference." This would be a book and perhaps an accompanying compact disk which would list languages, compilers, tools and (on the model of the Physician's Desk Reference) their interactions and contraindications. However, in the existing world, such a tool is not likely to be made available. This is because although some company can publish such a book, PART of the authoritative nature of the Physician's Desk Reference was the willingness of physicians and the public to accept it as a neutral authority. I claim that any company publishing a Programmer's Desk Reference will be perceived as biased towards some way of developing software even if it does not have a bias. There is a refreshing consensus right now on the value of C as a programming language, but even C is not The Language of the Gods. The proponents of C++ claim that this language is better and I view REXX as the dark horse of the Nineties, and C is genuinely technically inferior to these languages...perhaps also to Modula and to Oberon. The train will be standing at Babel for the foreseeable future. It's popular nowadays to go to industrial history for software paradigms, but ripping paradigms out of historical context is dangerous. The medical profession as we know it today only arose in the 19th century (my own father was a neurosurgeon who studied under a man who studied under the first neurosurgeon, Cushing of Boston.) It arose in a Progressive matrix in which people were able to believe that a man who sold you Science and Truth was doing so out of an altruistic desire to Serve Mankind (the very sexism of my phraseology dates it, doesn't it?) Nowadays, when a person tries to sell us a programming language, we ask what's in it for you? Professor John Conway on our math department here at Princeton claims he's had to prove theorems many times because he FORGETS he proved them before. Perhaps the excellent programmer of the future will be a skilled reinventor of the wheel, able to create libraries from the ground up in the manner of a barn-raising on the frontier. Perhaps she will be assisted by programming languages powerful enough to do this, and the benefit will be that she won't have to worry about reusing someone else's bugs. I am not saying that this will be so and that it is not a good thing to use the library function whenever possible. But skilled programmers are skilled at BOTH reusing code AND creating reusable libraries: not just the former. In the world of REXX, IBM has just released the ability to support pipes in the manner of unix when this could have been done ten years ago, and the pipe tutorial lauds something called "pipethink". This Orwellian word means that programmers will ALWAYS reuse code, and I believe it is deskilling. "Pipethink" will create programmers good at fitting together confusing pipe expressions which may (or may not) do a particular job, but able to survive ONLY in environments where (1) all the tools are in place and (2) all of the tools work as advertised. Reusability AND the ability to make things reusable are both attributes of the skilled programmer!
sakkinen@jyu.fi (Markku Sakkinen) (04/16/91)
In article <12676@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: (Sorry, I am commenting on a small side issue of the long article.) >There is a refreshing consensus right now on the value of C as a >programming language, but even C is not The Language of the Gods. What consensus? If I have an approximately correct picture of American school grading, perhaps the name of the language is well chosen. And I think C is really more suited for Gods (and daemons) to program in than humans. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
frank@grep.co.uk (Frank Wales) (04/16/91)
In article <12676@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: >We badly need a "Programmer's Desk Reference." I'd love one. Thanks for offering to put it together. ;-) >However, in the existing world, such a tool is not likely to be made >available. This is because although some company can publish such a >book, PART of the authoritative nature of the Physician's Desk Reference >was the willingness of physicians and the public to accept it as a >neutral authority. I claim that any company publishing a Programmer's >Desk Reference will be perceived as biased towards some way of developing >software even if it does not have a bias. I think this fear is overstated; I'd lay you money that aromatherapy, homeopathy and other fringe stuff don't feature large as recommended treatments in the PDR. There's as much a mainstream in medicine as in software, although software's is maybe more Mississippi-like. An alternative example is the position of Encyclopaedia Britannica as the canonical general knowledge reference; it has its biases and problems, but it's still tremendously valuable nonetheless. >Perhaps the excellent programmer of the future will be a skilled >reinventor of the wheel, able to create libraries from the ground >up in the manner of a barn-raising on the frontier. I do hope not; I've written enough low-level bootstrap code for n lifetimes already. Don't ask about list and table stuff. :-( >Perhaps she will be assisted by programming languages >powerful enough to do this, and the benefit will be that she won't >have to worry about reusing someone else's bugs. Any re-invention must include re-inventing bugs; unless you're advocating the Holy Grail of programming languages, so "powerful" (do you mean expressive?) it prevents you from writing wrong programs. [I don't think you are -- I'm just checking :-).] >But skilled programmers are skilled at BOTH reusing code >AND creating reusable libraries: not just the former. Definitely. The twin legacy of good programming is both useful approaches to development and useful code for re-use. -- Frank Wales, Grep Limited, [frank@grep.co.uk<->uunet!grep!frank] Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303
jls@rutabaga.Rational.COM (Jim Showalter) (04/18/91)
%What consensus? If I have an approximately correct picture of %American school grading, perhaps the name of the language is well chosen. You do, and it is. %And I think C is really more suited for Gods (and daemons) to program in %than humans. Not gods--idiot savants. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *
jimad@microsoft.UUCP (Jim ADCOCK) (04/21/91)
In article <1991Apr16.123527.2854@jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: |In article <12676@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: | |(Sorry, I am commenting on a small side issue of the long article.) | |>There is a refreshing consensus right now on the value of C as a |>programming language, but even C is not The Language of the Gods. | |What consensus? If I have an approximately correct picture of |American school grading, perhaps the name of the language is well chosen. |And I think C is really more suited for Gods (and daemons) to program in |than humans. I don't know about a "consensus" or not, but I try to keep an honest picture in my mind about the relative size and importance of various products in the marketplace -- including the relative market impact of various languages. I do this by performing various kinds of primary source numeric studies. For example, below find some word-hit-counts and document-hit-counts based on searching the Computer Select database for various computer language names. [The Computer Select database is a monthly CD-ROM based database that contains full text from 40 of the most popular programming journals, as well as abstracts from 110 others. In addition is contains product information on thousands of software and hardware products. If you haven't checked it out yet -- I strongly recommend it] journal articles software products hit-counts: #words #articles #words #product-descriptions C 21482 6507 7956 6922 C++ 3111 578 178 117 Ada 2322 510 334 174 Pascal 2284 772 1809 1635 Cobol 1850 633 3814 3459 Fortran 1364 558 2193 1925 Smalltalk 741 212 15 11 Modula 665 112 87 62 Objective-C 186 40 14 7 Eiffel 158 34 1 1 Oberon 28 3 0 0 Modula 3 20 4 0 0 [Caveat: these are raw numbers from my hit searches. In the case of "C" only, the "C" word is such a small word that about half the total hits represent mis-hits -- articles for example, where the "C" word doesn't refer to the "C" programming language, but rather refers to Howard "C" Smith, or the like. [So you may want to mentally divide the "C" numbers by about 2]] Statistics can be interpreted many ways by many people. I leave it to the reader to get what they want out of these numbers. Below are *my own personal* conclusions: ---- C really is the dominant programming language for today -- but not so dominant that a "consensus" could be said to have formed behind it. C++ is the dominant "object oriented" programming language. *Some day* there really are going to be "Object Oriented" Cobol and "Object Oriented" Fortran compilers [because the market is big enough that *someone* is going to do it] To date there's still more talk about object-oriented programming than software products using it. [IE OOP is still not a mainstream programming approach] Some well-known OOPLs aren't going to garner enough market-share to make them a commercial success. Programmers would do well to choose an OOPL that stands a chance of making the cut. [Just because your favorite language above doesn't have large numbers doesn't necessarily mean that its failing -- if its a language that's only come out in the last year or two, it could simply mean that that language hasn't caught on yet] --- [If your favorite language isn't in the above list, its simply because I did not think of it while compiling the above numbers. All languages that I did search on are included in the above list]
jls@rutabaga.Rational.COM (Jim Showalter) (04/23/91)
Word counts are quasi-useless. A two paragraph article announcing yet-another dinky routine on a UNIX platform is hardly of the same importance as a paper on a successful delivery of a 2 million line of code Ada program on time and under budget. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *