Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!cmcl2!lanl!jxdl From: jxdl@lanl.gov (Jerry DeLapp) Newsgroups: comp.sys.transputer Subject: Re: What makes occam so good? Summary: Education of vendors. Message-ID: <11431@lanl.gov> Date: 3 Apr 89 17:20:02 GMT References: <8903291813.AA10019@uk.ac.ox.prg> Organization: Los Alamos National Laboratory Lines: 125 In article <8903291813.AA10019@uk.ac.ox.prg>, IAN@vax1.esprit.southampton.ac.uk writes: [much text deleted] > I can't really argue that occam has not been an obstacle to the general > acceptance of transputer systems, but I would argue that this is really a > problem of education of the consumers. Whenever I see someone use the phrase a "problem of education of consu- mers" I immediately wonder why it's a problem in the first place. As a person who has attempted "education of consumers" with respect to the advantages of occam, I feel that what really needs to happen in this case is "education of vendors." (And I believe this is true of just about every other case where "education of consumers" is the purported to be the "problem"). In my case, I suffered through learning the folding editor, ODS, TDS, OCCAM 1, OCCAM 2, five hour compiles, etc. because I was paid to do it by my company (In fact, I'm about to go do it again GAG :-). In the process, despite all the shortcomings of the software, I came to love the idea of the transputer. I then took on the duty of attempting to convince our customers that they should make the same effort on their own time, without much luck. Most of them decided that they'd wait for "real languages" (C and FOR- TRAN) before they'd try the transputer. The one scientist I worked with who attempted to use OCCAM worked for over six months on his application and never got it to work (and he knew what he was doing). We eventually got a C compiler for our system, and a similar application was up in two weeks. The root of the real "problem" as I see it is that any vendor of a new product (languages, chips, software) needs to keep in mind the follow- ing: 1) Most of the people who program and use computers are not computer scientists. They are not interested in learning new languages, new hardware, or in the intricacies of formal transforms of programs. They have a real world problem that they want to solve using the com- puter. In the scientific and engineering marketplace (the traditional users of new experimental systems) the lingua franca is FORTRAN, and, to a much lesser extent, C. 2) There is a "threshold of pain" that a person will not go beyond in his efforts to achieve a goal unless the benefit is clear. With respect to a new language, typically a scientist will not go to the effort to learn it unless his problem will be solved much much faster than his currently available familiar options. Most scientists I've talked with quote that their application must run 10 times faster be- fore they'll go to a major effort. Also, the scientist won't go to the effort unless your option is 10 times faster FOR THE SAME COST as his fastest available familiar option. The only exception to this rule that I've seen is when the problem simply can't be solved with available familiar options. 3) Before expending the effort of learning a new language/product/chip to solve a problem, it must be demonstrable that the item will have long term utility. e.g. will what I learn be valid 2 years from now, will my application be able to run on new wowie machine XYZ without a similar learning effort, etc. This is why UN*X, FORTRAN, and C are so successful, and why most people only program in assembler when they have to. [more deleted] > I tend to think it would > benefit them (INMOS) in to invest a little effort in making occam available on > machines other than transputers. If people got hooked, they would surely want > to buy transputer chips, since they make such good occam engines, and make > distributing occam programs so easy. [a very good description of the computer science advantages of occam deleted] I very much agree with the above statement, however I don't know of any instance of a VENDOR SPECIFIC and VENDOR DRIVEN language having long- term utility as a programming vehicle for general users. (People only program in assembler if they have to, and, official definitions aside, if it only runs on platform X, it's assembler, OCCAM included). Also, I'd contend that what would sell is transputer based systems, not chips, and it's highly unlikely that the systems would sell well unless the transputer world can agree on a paradigm for system software. Again, this is why UN*X is so popular. People love being able to run the exact same software on many different platforms. UN*X provides the system software paradigm that makes this possible. In my opinion, INMOS has fallen down on all three of the points I made above. In the case of point 1, the OCCAM "time to solution" is far too high. (Who cares if your problem is solved in 10 hours instead of 10 days, if it took you six months to port the application?) To use OCCAM, you not only have to learn a new language, but a new editor, execution environ- ment, linker, YOU HAVE TO BUY A TRANSPUTER BOARD just to develop code and, there's no system software to speak of available (e.g. no de- bugger). In my opinion, TDS is a lousy design for implementing an in- teresting new language (are you listening David May? :-). INMOS tried to roll far too many "neat ideas" into the package. Each idea taken on its own (e.g. the folding editor) has merit, but adding learning them to the task of learning a new language was a mistake (IMHO :-). In the case of point 2: The items above make the "level of pain" very high for a non computer scientist, and INMOS has not adequately demon- strated the necessary performance improvements to induce people to cross the threshold. (I'm sorry, but one of those toy PC boards just doesn't run 10X faster than a CRAY :-). I'd suggest that, in addition to promot- ing OCCAM on other platforms, INMOS ought to build and market product out of transputers a little larger than boards to go into PCs. Make it big enough that it's 10x faster than the fastest Cray out there now. The world would drool for it. In the case of point 3: It's not at all clear here in the US that the transputer has a future (please no flames, I am a true believer in parallel processing as represented by the transputer). INMOS has been scaling back it's US efforts. No one has built a big transputer machine that made a big splash. OCCAM only runs on transputers. INMOS appears to be uninterested in promoting OCCAM as a more general programming language. It's very difficult to demonstrate to a non-computer scien- tist how OCCAM is better than, say, C with some extensions for parallel- ism (and frankly, I'm not convinced that it is, I'd like to see threads (a la MACH from CMU) implemented in C for the transputer). -- _ /| The opinions here are my own, and even I don't agree with me :-) \'o.O' I am not an employee of LANL, I just use their computers. =(___)= I stole the .sig file, but I did not shoot no deputeeee. U Bill sez: AAAAK! PHHHT! jxdl@lanl.gov