jlg@lambda.UUCP (Jim Giles) (03/24/90)
From article <5200059@m.cs.uiuc.edu>, by robison@m.cs.uiuc.edu: > [...] > I think a closer analogy is the following: > > Control flow Data flow > ------------ --------- > label r-value > goto assignment Actually, this analysis is correct. But, the original analogy was also correct. In the domain of data _structuring_ the element corres- ponding to GOTO is the pointer. In the domain of data _flow_ the analogous element is the assignment. > [...] This would lead one to > conclude that any imperative language is "dangerous", whether > it has pointers or not. It not only _would_ lead to such a conclusion - it has (past tense). What do you think all the functional language advocates are on about? Indeed, there is a sense in which assignment leads to some very complicated semantic issues which are completely avoided in functional languages. Fortunately for most of us, people tend to have an intuitive understanding of these semantic problems that makes concern about them somewhat less important. The same goes for GOTO (at least to some extent). In my opinion, the problem is worst for pointers than for either of the other two (people _don't_ seem to understand pointers - intuitively or otherwise). J. Giles
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/24/90)
In article <14290@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: >> This would lead one to >> conclude that any imperative language is "dangerous", whether >> it has pointers or not. > >It not only _would_ lead to such a conclusion - it has (past tense). >What do you think all the functional language advocates are on >about? Indeed, there is a sense in which assignment leads to >some very complicated semantic issues which are completely avoided >in functional languages. Fortunately for most of us, people tend >to have an intuitive understanding of these semantic problems that >makes concern about them somewhat less important. The same goes >for GOTO (at least to some extent). In my opinion, the problem >is worst for pointers than for either of the other two (people >_don't_ seem to understand pointers - intuitively or otherwise). So at each level of program language evolution we have something "considered harmful": FORTRAN et al - goto C - undisciplined pointers Pascal, Modula2, Ada - disciplined pointers Everything except ML? - assignment Where is this going to end? And what is going to be considered harmful about the functional languages? I would like to suggest: Functional languages - abstract beyond human comprehension :^) I seem to remember in the rationale for Ada something to the effect that it is advantageous from the standpoint of program understanding for things to be explicitly structured, where the structure is laid out in language constructs in the code, and is static. It seems to me that there is a benefit in assignment--it nails down a piece of data to a static structure so that the programmer has a chance to look at it and consider its role in the program. I have only looked at ML a couple times (one assignment for a languages course). Personally I find it difficult to grasp. It requires a strong mathematical background, as far as I can tell... I have done some stuff in Lisp, and that is what I had to fall back on to do anything in ML. The pattern-matching aspects of ML seemed to me especially hard to relate to. However, I am sure that if I applied myself as much to learn ML as I have to learn and master C, I would do fine with ML. When I try to view this subject objectively, I see that there are good elements in each paradigm, and a lot of the reasons given why certain constructs are considered harmful come from theories of psychology that relate to a programmer's presumed ability or lack of ability to grasp a problem and develop its solution. They can do all the studies they want, but that doesn't change a given programmer's ability to do well at applying a language to solve a problem. It all boils down to the effort required to excel at anything. The help that one gets from the tools is important, but I don't think that it can be said that the "safeness" of a language is the most important issue. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
drc@cs.brown.edu (David R. Chase) (03/25/90)
In article <260adcad.4abe@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >So at each level of program language evolution we have something "considered >harmful": > > FORTRAN et al - goto > C - undisciplined pointers > Pascal, Modula2, Ada - disciplined pointers > Everything except ML? - assignment > >Where is this going to end? And what is going to be considered >harmful about the functional languages? I would like to suggest: > > Functional languages - abstract beyond human comprehension :^) There's more choices than just those that you put up there. There's Lisp, which has its own problems (depending upon who you ask). The people at Xerox PARC decided that Mesa needed garbage collection , so they added it, but didn't make the rest of the language terribly much different from what preceded it. Similar, DEC-SRC and Acorn both extended Modula-2 with threads, exceptions, and garbage collection, but what remained was still essentially Modula-2. Modula-2+ was felt to have some warts, so a committee of people got together and defined (after some time) Modula-3, which is somewhat further from Modula-2, but still recognizably imperative, and quite capable of mucking around in its own run-time representation (in code marked "UNSAFE"). Anyhow, there's a wide variety of features, some useful, some useless, and no language has them all. Pointer arithmetic has always struck me as being a generally useless feature, especially given that compilers tend to do a better job of it wherever it pays off. David
mph@lion.inmos.co.uk (Mike Harrison) (03/26/90)
In article <260adcad.4abe@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > ... > > Functional languages - abstract beyond human comprehension :^) > Depends what you mean by human! I know that I find the functional paradigm natural. > ... It seems to me that there is a >benefit in assignment--it nails down a piece of data to a static structure >so that the programmer has a chance to look at it and consider its role >in the program. > If there is only a *single* assignment to any 'variable', it does that for you but is still safe, in effect you are just given a local name to the value of some expression. This does not require any change of state. It is *changing* the value that is dangerous. >I have only looked at ML a couple times (one assignment for a languages >course). I'm not familiar with ML, but I know Hope and Miranda. >mathematical background, as far as I can tell... I have done some stuff >in Lisp, and that is what I had to fall back on to do anything in ML. Someone in news.groups discussing a proposal for comp.lang.fuctional, called functional languages 'lambda calculus in drag', I think that sums it up nicely. > ... but I don't think that >it can be said that the "safeness" of a language is the most important >issue. Of course it depends what you mean by safe, but I take it to mean eliminating from the language all potential pitfalls which are not *absolutely* essential for the satisfaction of the rquirements specification for the program. Two points on this: - The domain of the application is relevant, I don't think I would be as concerned about the safety and correctness of an arcade game as I would about that of the 'fly-by-wire' software of a wide-bodied airliner. - I think that language pitfalls are related to: "The principle of minimum astonishment - the idea that (as far as can accomodated by other overiding requiremnets) a program statement will do what most experienced programmers would intuitively expect it to do" This implies that programming has cultural overtones - ie. if I wish to introduce some extremely novel feature in a programming language I must be very careful not to give it a syntax which makes it *appear* to be similar to some feature in a well known language, whose semantics it does not resemble at all. Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS;