peter@ficc.uu.net (Peter da Silva) (01/09/89)
In article <5795@medusa.cs.purdue.edu>, rjh@cs.purdue.EDU (Bob Hathaway) writes: > Lets please stop using the term B&D languages, this is a bad > analogy and a heavily biased opinion. Maybe I can't adequately > express classes or model abstractions in expression-based > language X and feel similarly constrained. I don't think anyone's using "B&D" to refer to object-oriented languages. B&D refers to strictly type-checked languages that really don't have any other features to distinguish them from the run-of-the-mill weakly typed language. Pascal is the common example. Are you using the phrase "dynamically typed" to refer to object-oriented languages? I haven't run into this phrase before, and it's quite evocative. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
rjh@cs.purdue.EDU (Bob Hathaway) (01/12/89)
David Gudeman writes: >It's not an analogy, it's a pun. And it refers to the philosophy of >language design in which the language designers feel it is their >responsibility to constrain (hence ``Bondage'') the programmer to >adhere to certain Disciplines in programming. Now, ``Police state >language'' is an analogy. And it doesn't refer to a paradigm (a way >in which a given languages encourages the programmer to view >computation) since there can be functional and logical B&D languages >as well as imperative ones. >You don't lable a language ``B&D'' just because you can't do something >in that language, you call it that because (1) there is something you >can't do, (2) the designers of the language predicted people would >>want to do it, and (3) the designers deliberately made it impossible >because they thought it was a bad thing to do. This sounds like you don't know programming as well as compiler writers, language designers, programming language hobbyists, ... I, and several others I have talked to can do anything we can do in C in Pascal, Modula, Ada, etc. At *worst* we'll resort to medium level programming or operating system calls, or even external language interfacing although the first two possibilities are sufficient. Ada and Modula-2 offer low-level facilities and Ada doesn't even require explicit context clauses to access the system package. > >I don't suppose there is much point in arguing language design >philosophy, since different languages are designed with different >goals and priorities. > This is true but at the risk of sounding elitist, just because you can't figure out a way to program something in Language X doesn't mean proficient programmers can't. Peter da Silva writes: >Are you using the phrase "dynamically typed" to refer to object-oriented >languages? I haven't run into this phrase before, and it's quite evocative. No, although object-oriented languages such as smalltalk are frequently dynamically typed. I usually consider two basic types of polymorphism, statically checked and dynamically checked, although this is not the canonical view. Generics and Milner's type inference system are examples of statically checked (typed) polymorphism. This form can be accomplished at compile time and offers strong type checking. Dynamic typechecking, which I often refer to as arbitrary polymorphism, is a more powerful form and usually cannot be accomplished at compile time. Traditionally, Strachy defined two forms of polymorphism. The first is ad hoc polymorphism, or operator overloading, where the same function name can refer to several distinct subprograms and the parameter type structure is used to select the correct piece of code. The second is parametric polymorphism, (sometimes universal polymorphism contains this category), which refers to subroutines which can acept several distinct parameter type structures. Several texts describe polymorphism, such Principles of Programming Languages, by Tennet. Bob Hathaway rjh@purdue.edu
gudeman@arizona.edu (David Gudeman) (01/12/89)
In article <5818@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: ]David Gudeman writes: ]... ]>You don't lable a language ``B&D'' just because you can't do something ]>in that language, you call it that because (1) there is something you ]>can't do, (2) the designers of the language predicted people would ]>>want to do it, and (3) the designers deliberately made it impossible ]>because they thought it was a bad thing to do. ] ]This sounds like you don't know programming as well as compiler writers, ]language designers, programming language hobbyists, I _am_ a compiler writer, language designer and programming language hobbyist. Language design and implementation are the main subjects of my PhD research. ] ... I, and several ]others I have talked to can do anything we can do in C in Pascal, Modula, ]Ada, etc... As far as doing anything you want, obviously you can. Theoretically all programming languages are computationaly equivalent. The question is _how_ you do it. Can you treat a variable as an integer at one point then turn around and make it a pointer? If your first reaction is that no one should ever do that, then you may as well use police state languages. It's hard for me to think of other examples, because it has been so long since I've been interested in this class of languages. They are really all so similar and _boring_. (I mean the class of medium-level algorithmic languages including Algol, FORTRAN, COBOL, Pacal, C, Ada, etc., both police state and anarchy types.)
phipps@garth.UUCP (Clay Phipps) (01/13/89)
In article <2670@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <5795@medusa.cs.purdue.edu>, rjh@cs.purdue.EDU (Bob Hathaway) writes: >> Lets please stop using the term B&D languages, >> this is a bad analogy and a heavily biased opinion. >Pascal is the common example. Let's not take ourselves too seriously, here. Just fight back. Create a label for the languages favored by those who created the term "B&D", and see if you can get it to catch on. "B&D" obviously has. For philosophical background on the "B&D" languages, see especially: Niklaus Wirth: "On The Design Of Programming Languages" (invited paper), Proc. of IFIP 1974, p. 386..393 (maybe reprinted in the ~1985 IEEE anthology of language design papers). Wirth emphasized the importance of simplicity, especially in designing a new language, and preferred "transparence and clarity of its features, and by a regular structure" over "conciseness and unwanted generality". Intelligent people can disagree over notions of what constitutes "simplicity". It is ironic that Wirth was a grad student at Berkeley, undoubtedly one of the spiritual centers of C partisanship. Folks on the other side of S.F. Bay might wish to see C.A.R. Hoare: "Hints On Programming Language Design", Stanford A.I. Lab memo AIM 224/C.S. Dept. Report CS-403, October 1973. Hoare's paper also emphasizes the importance of simplicity. What has Ritchie written on his philosophy of language design ? -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800
phipps@garth.UUCP (Clay Phipps) (01/13/89)
In article <2670@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Are you using the phrase "dynamically typed" >to refer to object-oriented languages? >I haven't run into this phrase before, and it's quite evocative. I would certainly call APL "dynamically typed", but I don't think of it as "object-oriented". As I recall, in (Classic) APL, if you don't like the value in a variable, you can replace it with a value of any type, including an array of rather arbitrary dimensions. Now *that's* dynamic. The SNOBOLs probably also qualify as "dynamically typed", but not "object-oriented". -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800
chris@mimsy.UUCP (Chris Torek) (01/13/89)
>David Gudeman writes: >>You don't lable a language ``B&D'' just because you can't do something >>in that language, you call it that because (1) there is something you >>can't do, (2) the designers of the language predicted people would >>want to do it, and (3) the designers deliberately made it impossible >>because they thought it was a bad thing to do. In article <5818@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >This sounds like you don't know programming as well as compiler writers, >language designers, programming language hobbyists, ... I, and several >others I have talked to can do anything we can do in C in Pascal, Modula, >Ada, etc. The point is not whether the ultimate goal can be accomplished (the answer is almost always `it can'), but rather whether the means by which you wish to accomplish it has been ruled out in advance. My favourite example (as of the last time I gave an example, anyway :-) ) of this is the classical list-building loop: var head, tail, l : list; head <- nil; tail <- nil for ever do l <- get_input exit when l = nil (if head = nil then head else tail.next) <- l tail <- l rof return head This algorithm works fine in Pascal, C, etc. But the way I prefer to write it in C is this: struct list **p, *l, *head = NULL; p = &head; while ((l = get_input()) != NULL) { (*p)->next = l; p = &l->next; } return head; You *cannot* write this algorithm in (standard) Pascal, because it will not let you compute the address of `head' or that of `l->next'. There are reasons for that, but they amount to what David said: >>and (3) the designers deliberately made it impossible >>because they thought it was a bad thing to do. (and maybe it *is* a bad thing, but that is irrelevant to the label `B&D'). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
kers@otter.hpl.hp.com (Christopher Dollin) (01/18/89)
Erland Sommarskog said: | But to throw some new wood on the fire, consider the following: Assume | you have routine you want to call but whose name you don't know until | run-time, thus you have the name in a string. Now in which langauges | can you easily do this? Interpreting langauges like Lisp and Basic, | support this I guess. But compiled langauges? It's not a matter of compiled vs interpreted; you can map strings to the contents of the so-named variables in compiled Lisp. The question is: how much information about the names of things is left lying around at run-time? In Lisp, the symbols (and their values) are part of the language, and so can be interrogated by the running code. Of course it's likely to be *easier* in an interpreted language, since the interpreter has to keep all that stuff around anyway. Example compiled language that lets you call a routine known by a string: Pop11. Code to do so: (the_string.consword.valof)( args ) or, if you prefer prefix notation rather than dotted suffixing: valof( consword( the_string ) )( args ) Caveats on request. Regards, Kers. "If anything anyone lacks, they'll find it all ready in stacks."
marc@hpfcdc.HP.COM ('Thelonious' Sabatella) (01/19/89)
/ hpfcdc:comp.lang.misc / sommar@enea.se (Erland Sommarskog) / 2:18 pm Jan 16, 1989 / > >But to throw some new wood on the fire, consider the following: Assume >you have routine you want to call but whose name you don't know until >run-time, thus you have the name in a string. Now in which langauges >can you easily do this? Interpreting langauges like Lisp and Basic, >support this I guess. But compiled langauges? -- BASIC wouldn't necessarily support it (remember, many BASIC's don't have named routines; many of those that do may require static expressions for CALL targets). Lisp certainly does, and quite naturally. For compiled langauges, you have essentially described the "case" statement. I know, it's not the same thing, but considering that in a statically compiled language like C, Pascal, or Ada, the range of callable functions is completely determined at compile time (and hence at coding time, if you plan things well), you can get the same effect. C and Ada will also let you have a mapping (say, a hash table) from strings to functions (addresses in C) and let you call a function indirectly in that manner, which is more in keeping with the spirit of the request, but still requires advance planning by the programmer. Actually polymorphic languages (such as most OO languages) behave this way in principle, even if they don't extend the ability to the programmer. Forth, which is a threaded-interpretive language, meaning it is "kind of" compiled (like "kind of pregnant :-), can be tricked into giving the same behavior as Lisp (i.e., completely arbitrary routines that the programmer never in a million years would have imagined would be chosen dynamically can be executed given a string and a definition), but it is more of a "hack" than a natural technique as in Lisp. But it would be possible to encapsulate the hack into a single word which would give the same functionality as the Lisp 'eval'. So, in the context of B&D, what does this say? For one, thing, the 'discipline' enforced by C, Pascal, Ada, et al is that the programmer must anticipate what the possible values are for the string, and handle each case individually. This doesn't prevent you from doing what you want to do, as in the degenerate case the range is every routine in the program plus all library routines made visible as a result of the link, but it does prevent you from doing it in a manner which would not require you to explicitly specify this range, and an explicit mapping from the domain of strings into this range. Standard Pascal is more limited than C or Ada in this regard. Since none of these language let you create new routines dynamically (another 'discipline'), this is sufficient. In Forth, it is difficult, but by no means impossible, to extend the language dynamically, and it is correspondingly difficult to execute a routine given only its dictionary name. In Lisp, both are trivial. So, IN THIS CONTEXT, I would rate these language as follows: [ most B&D ] Pascal, C, Ada, Forth, Lisp [ most B&D ] Any polymorphic/OO language which extended its built in collision resolution mechanism to the programmer would probably fit in either to the left or right of Forth, depending on how natural the construct was. Also, for this purpose, Fortran and Pascal are essentially equivalent. -------------- Marc Sabatella HP Colorado Language Lab marc%hpfcrt@hplabs.hp.com
rjh@cs.purdue.EDU (Bob Hathaway) (01/19/89)
>all programming languages are computationaly equivalent. The question >is _how_ you do it. Can you treat a variable as an integer at one >point then turn around and make it a pointer? If your first reaction Yes, use variant records in Pascal and Modula-2 and unchecked_conversion in Ada. rjh@purdue.edu
gudeman@arizona.edu (David Gudeman) (01/20/89)
In article <5856@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >>all programming languages are computationaly equivalent. The question >>is _how_ you do it. Can you treat a variable as an integer at one >>point then turn around and make it a pointer? If your first reaction > >Yes, use variant records in Pascal and Modula-2 and unchecked_conversion >in Ada. The question is _how_ you do it. You have to use variant records in Pascal and Modula-2 and unchecked_conversion in Ada. This is because the designers of Pascal, Modula-2, and Ada thought that sort of thing was dangerous, and wanted to make it inconvenient to do. The inconvenience was supposed to discourage such practices, and the extra syntax was supposed to make sure it didn't happen by accident. I'm getting really tired this. There seem to be some people out there who are deliberately pretending not to understand what is meant by B&D just for rhetorical effect. They support their favorite languages by pretending that the criticisms are vacous. They fail to notice that the criticisms are just negative responses to _deliberate_ goals in the language design. These exact same goals are the reason others feel the languages are _good_ things. Get it? We critics take things that supporters say are good, and we say they are bad. So if the languages don't have these bad features, then they don't have the good ones either. They are the same damn features. If you don't think there is any substantive difference between C and Modula-2, why do you use Modula-2? Why not use a language which has much broader distribution and is much better known? Tell me why you think Modula-2 is good, and you will be describing what I don't like about it.
kroyer@ogccse.ogc.edu ( Steen Kroyer ) (01/20/89)
In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: >I'm getting really tired this. There seem to be some people out there >who are deliberately pretending not to understand what is meant by B&D >just for rhetorical effect. They support their favorite languages by >pretending that the criticisms are vacous. .............. I agree. I've been following this discussion with some interest, but it seems to have come to a point where not much new input is generated. One person posts a message saying that language X is/is not a B&D language, and another quickly responds "'tis not true! I clearly remember one occasion in the spring of '84 where I failed/succeeded in doing [whatever] in X (:-)". So to pour some gasoline on the burning wood supplied by a recent poster, I'll venture to say that almost ANY language can be thought of as being/not being B&D. It looks to me as if the fact that almost any language has an underlying "philosophy", is being overlooked by many. By this I mean that the designers of a language normally have a clearly stated goal, such as supporting a particular programming paradigm or solving a certain class of problems. These goals will then pervade the language in the form of a more or less implicit stated set of rules telling you how, and for what, you should use this language. Of you stick to the rules (which you can't do unless you understand them), you'll probably think "Oh, this is a nice language". But if you break the rules, consciously or not, you're not adhering to the built-in discipline of the language, and will probably feel restrained. Two extreme examples : * Assembler: Intended for use at the lowest level of abstraction, at the border between hardware and software. So, if I want to do some bit-fiddling in the register of some I/O controller, or write a small piece of time-critical code, I'd feel right at home in assembler. But if I want to construct a fancy data-type, B-trees say, I'll wast a lot of time doing things a higher-level level language could have done for me. Like ensuring type-consistency, through the use of a typechecker. So I'd feel constrained (having to do a lot of "unnecessary" work) because assembler doesn't support this type of programming task. * A purely functional language (like SML, Miranda etc.): Designed to allow the programmer to write, and think about, programs in a very formalized and abstract way. It's a dream to construct abstract datatypes in a decent functional language, but I sure wouldn't want to write a time-critical interrupthandler in SML. (I know, I know, SML allows side-effects and might therefore not be considered entirely pure, but that's beside the point fella's {;-). So, to sum up: I don't think it makes much sense to claim that language X is/ain't a B&D language under any and all circumstances. Some languages come close to being usable general-purpose tools, but language design is like politics : you can't have it all, so you've got to compromise. The only other alternative is to build in everything but a kitchen-sink, and that certainly won't make a pretty design and would problably not be everything to everybody anyhow. ----------------------------------------------------------------- | Since nobody else will, I'm forced to speak for my self, etc. | | Steen Kroyer - Oregon Graduate Center - kroyer@ogccse.edu | -----------------------------------------------------------------
marc@hpfcdc.HP.COM ('Thelonious' Sabatella) (01/20/89)
/ hpfcdc:comp.lang.misc / rjh@cs.purdue.EDU (Bob Hathaway) / 6:34 pm Jan 18, 1989 / >>all programming languages are computationaly equivalent. The question >>is _how_ you do it. Can you treat a variable as an integer at one >>point then turn around and make it a pointer? If your first reaction > >Yes, use variant records in Pascal and Modula-2 and unchecked_conversion >in Ada. > >rjh@purdue.edu ---------- Fine. Now tell me the address of a global variable in Pascal. There may be some bizarre construct that will get you this, but it is something that Wirth clearly intended you not to do, and gave you no easy way to do it. B&D is relative, folks. C and C++ don't let you write self-modifying code; ASM does. ASM doesn't give you polymorphism, C++ does. Pascal gives you neither, but gives you true block structure. There will always be some things you can do in a language X you can't do in Y or Z, but things you can do in Y and/or Z you can't do in X. -------------- Marc Sabatella HP Colorado Language Lab marc%hpfcrt@hplabs.hp.com
firth@sei.cmu.edu (Robert Firth) (01/20/89)
In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: >The question is _how_ you do it. You have to use variant records in >Pascal and Modula-2 and unchecked_conversion in Ada. This is because >the designers of Pascal, Modula-2, and Ada thought that sort of thing >was dangerous, and wanted to make it inconvenient to do. The >inconvenience was supposed to discourage such practices, and the extra >syntax was supposed to make sure it didn't happen by accident. The designer of Pascal and Modula-2 can speak for himself. As the person who designed the unchecked programming features of Ada, however, please let me state that the above speculation does not accurately represent my thinking or my intention. 1. There must be a means to convert a value of one type into a value of another type without change of representation. This is necessary, for example, if one wishes to write a storage allocator, to compute the checksum of a datagram, or to manipulate the components of a floating-point number. These examples are used in my lecture in the 'IBF on Ada' course, which stresses the point that any systems programming language must include features sometimes called "low level" or "machine dependent". 2. As will be evident from the above, this feature is 'dangerous' only if misused, as is the case for almost any other programming language feature. However, it does give the designer some problems. The main problem is one of program management and maintenance: . the code might not be portable. non-portable code should be easy to find . the code will need more careful validation, since one cannot rely on the type checking of the compiler. such code should alert the program tester or maintainer to its presence . many programming methodologies prescribe some form of automatic (or at least cheap) mechanism for detecting and controlling the use of non portable or otherwise special code. The best solution to this problem is therefore to require any package that does these things to import something explicitly: this is a simple cue to the maintainer and is susceptible to automatic management (as is done by Alsys 'Adaprobe', for example) Again, these concerns are stated explicitly in my lecture, in most books on Ada (such as Barnes' 'Programming in Ada'), and in the Ada Rationale. 3. Given a language with user-defined types, it is necessary to make the conversion mechanism as general as possible, so that it can be applied to new types as well as old ones. The solution in Ada is to use generics, and the generic actually defined is the simplest that will work. There was no intention to make it costly to use unchecked conversion; indeed, the cost is no more than that of doing I/O: one line of code to import the facility and one line of code to do the required generic instantiation. This is the essential cost of any type-parameterised library unit. Robert Firth
jack@cs.glasgow.ac.uk (Jack Campin) (01/21/89)
Erland Sommarskog said: | But to throw some new wood on the fire, consider the following: Assume | you have routine you want to call but whose name you don't know until | run-time, thus you have the name in a string. Now in which languages | can you easily do this? Interpreting languages like Lisp and Basic | support this I guess. But compiled languages? This is the usual way you load procedures in PS-algol - with orthogonal persistence you can use dynamic naming for any denotable value (dynamic naming of bitmap images for user interface objects is dead handy). It's compiled to an abstract machine code. Any other languages let you *name* a procedure at run-time for use in future runs, and save its environment of definition to make the semantics work right? This lets you store partially applied closures; we use it all the time. (Scheme *ought* to be capable of this if made persistent; maybe ML too if persistent refs were added. But I don't know another language that actually *can* do it.) -- Jack Campin * Computing Science Department, Glasgow University, 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND. 041 339 8855 x6045 wk 041 556 1878 ho INTERNET: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk USENET: jack@glasgow.uucp JANET: jack@uk.ac.glasgow.cs PLINGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack
kevin@cit-vax.Caltech.Edu (Kevin S. Van Horn) (01/21/89)
In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: [with reference to treating a variable as an integer at one point and as a pointer at another point] >The question is _how_ you do it. You have to use variant records in >Pascal and Modula-2 and unchecked_conversion in Ada. This is because >the designers of Pascal, Modula-2, and Ada thought that sort of thing >was dangerous, and wanted to make it inconvenient to do. The >inconvenience was supposed to discourage such practices, and the extra >syntax was supposed to make sure it didn't happen by accident. Give me a break! What's so horribly difficult and inconvenient about writing x.f1 when you want to use x as a variable of type t1, and x.f2 when you want to use it as a variable of type t2? And I think you're way off base when you say that the designers of Pascal et al. introduced variant records to make such type conversions difficult; they merely wanted to make them *explicit*. As to your statement that, "the extra syntax was supposed to make sure it didn't happen by accident," well I should hope so! By definition, if you used a pointer as an integer "by accident" then what you wrote was not what you really intended, and any rational person would want to know this. Kevin S. Van Horn
gudeman@arizona.edu (David Gudeman) (01/21/89)
In article <8282@aw.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: ]In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: ] ]>...the designers of Pascal, Modula-2, and Ada thought that sort of ]>thing was dangerous, and wanted to make it inconvenient to do. The ]>inconvenience was supposed to discourage such practices, and the extra ]>syntax was supposed to make sure it didn't happen by accident. ] ]The designer of Pascal and Modula-2 can speak for himself. ] ]As the person who designed the unchecked programming features of ]Ada, however, please let me state that the above speculation does ]not accurately represent my thinking or my intention. Wow, I didn't know we had a celebrity in the discussion! :-) You don't suppose Wirth is reading too do you? In defense of my remarks, I want to point out that I never intended them as a rigorous explanation of the intentions of the designers. My remarks were obviously too general and simplistic for that (though in re-reading, I see that it is not obvious that I knew that). ]1. There must be a means to convert a value of one type into a value ] of another type without change of representation... As you indicate later, this is only necessary if you are doing low-level programming. It is not obvious that all languages should support this sort of thing... ] ...However, it does give the designer some problems... ] . the code might not be portable. non-portable code should be easy ] to find ] . the code will need more careful validation, since one cannot rely ] on the type checking of the compiler. such code should alert the ] program tester or maintainer to its presence ] . many programming methodologies prescribe some form of automatic ] (or at least cheap) mechanism for detecting and controlling the ] use of non portable or otherwise special code. I don't understand what you mean here. ] The best solution to this problem is therefore to require any package ] that does these things to import something explicitly:... This is the first statement where I disagree, and I believe this may be a crucial point seperating totalitarian from anarchical language designers. I don't believe the solution is to _require_ anything. How do you know when you design the language whether these points will matter in any given situation? Why does this have to be built into the language? Why not trust the programmer to modularize and document the code correctly? ]...There was no intention to make it costly to use unchecked conversion; ]indeed, the cost is no more than that of doing I/O: ... I said ``inconvenient'', not ``costly''.
sommar@enea.se (Erland Sommarskog) (01/22/89)
David Gudeman (gudeman@arizona.edu) writes: >Why not trust the programmer to modularize and document >the code correctly? If we could trust programmers there would be no need for language of any higher level than C. -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se
gudeman@arizona.edu (David Gudeman) (01/22/89)
In article <9175@cit-vax.Caltech.Edu> kevin@cit-vax.Caltech.Edu (Kevin S. Van Horn) writes: >In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) >writes: > [with reference to treating a variable as an integer at one point and as > a pointer at another point] >>The question is _how_ you do it. You have to use variant records in >>Pascal and Modula-2 and unchecked_conversion in Ada. This is because >>the designers of Pascal, Modula-2, and Ada thought that sort of thing >>was dangerous, and wanted to make it inconvenient to do. The >>inconvenience was supposed to discourage such practices, and the extra >>syntax was supposed to make sure it didn't happen by accident. > >Give me a break! What's so horribly difficult and inconvenient about writing >x.f1 when you want to use x as a variable of type t1, and x.f2 when you want >to use it as a variable of type t2? Well you forgot delcaring the type. And if you change implementation slightly, you may have to find and change the declaration. And anyone reading the code has to find the declaration. And I don't recall using the word ``horrible'', or even ``difficult''. I distinctly used the word ``inconvenient'', because I meant ``inconvenient''. If I had meant ``horribly difficult'' I would have said ``horribly difficult''. > And I think you're way off base when you >say that the designers of Pascal et al. introduced variant records to make >such type conversions difficult; --------- There's that word again, you know, the one I didn't use? >they merely wanted to make them *explicit*. And that is often inconvient. (Note the exact term ``inconvient'' and please don't get confused again.) >As to your statement that, "the extra syntax was supposed to make sure it >didn't happen by accident," well I should hope so! By definition, if you used >a pointer as an integer "by accident" then what you wrote was not what you >really intended, and any rational person would want to know this. Maybe _you_ want language designers protecting you from yourself, but I can get along fine without their help. I never said (am I repeating myself?) that it was a good thing to do the conversion by accident, and I agree that any rational person would want to know when such an accident happens. Some of us rational people prefer the inconvenience of having to find out for ourselves to the inconvenience of burdening the language with extra syntax. Anyway, the issue wasn't the convenience (or horrible difficulty) of using variant records, it was the propriety of language designers trying to coerce programmers into using a particular style. Variant records are essentially a method of forcing the programmer to document certain things. Tell me though, what makes the language designer think he knows better how to document a program at language design time than I know at coding time? I can think of at least two cases in which such documentation isn't necessary. First, a short throw-away program. Second during a detailed optimizing phase of a larger program, when you are changing the implementation of something twenty times a day to measure performance. In neither case is it worthwhile to document much of anything. To those who disagree with the above paragraph, enjoy all the documenting you want. But _I_ still don't want such practices forced on me by my programming language.
diamond@csl.sony.JUNET (Norman Diamond) (01/24/89)
David Gudeman (gudeman@arizona.edu) writes: > >Why not trust the programmer to modularize and document > >the code correctly? In article <4265@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > If we could trust programmers there would be no need for language > of any higher level than C. You mean machine language and front-panel switches. The reason trustworthy programmers have occasional (:-) use for languages at higher level than these is that it does save work to have overloaded operators, polymorphic procedures, etc. And it saves work to give rules to the compiler once instead of using the editor to copy code. Even trustworthy fingertips sometimes hit the wrong button. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
sommar@enea.se (Erland Sommarskog) (01/25/89)
David Gudeman (gudeman@arizona.edu) writes: >Kevin S. Van Horn (kevin@cit-vax.Caltech.Edu) writes: >>Give me a break! What's so horribly difficult and inconvenient about writing >>x.f1 when you want to use x as a variable of type t1, and x.f2 when you want >>to use it as a variable of type t2? Gudeman goes on with with various objections that this is "inconvenient". Before I comment that, let me first say I find this of less interest in this case; variant records as a mean of conversion in Pascal and Modula. Inconvenient or not - it's certainly not a good method. When you are using x.f1 and x.f2 you are far away from the declaration and you don't see that you are referring to the same field. And to make it even more fun: it's compiler dependent too. Look at: CASE boolean OF true : (ch1, ch2, ch3, ch4 : char); false : (int : integer); END; In which order the chars are allocated is up to the compiler to decide. >Maybe _you_ want language designers protecting you from yourself, but >I can get along fine without their help. ... >But _I_ still don't want such practices forced >on me by my programming language. (And lot of similar deleted.) You may not want to be protected, and you if write code for your very own private use, there's no problem. But if I were your boss, I'm sorry, I'd prefer you waste some extra time and money with those small "inconveniences" (I'm not talking variant records here, rather Ada style or type-cast operator a la VAX-Pascal) than have to pay a lot more money due to the mistakes you made because there was no type checking. -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se
randy@m2xenix.UUCP (Randy Bush) (01/26/89)
In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: >In article <5856@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >>Yes, use variant records in Pascal and Modula-2 and unchecked_conversion >>in Ada. >You have to use variant records in Pascal and Modula-2 ... Nope. The professor heard the pleas. Modula-2 has unchecked casts. Eg. pointer := PointerTypeName ( ArbitraryValueOfSameNumberOfBits ) Or the new form being suggested in recent ISO work pointer := SYSTEM.CAST ( PointerTypeName, ArbitraryValueOfSameNumberOfBits ) -- { mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bush
bdb@becker.UUCP (Bruce Becker) (01/26/89)
In article <4265@enea.se> sommar@enea.se (Erland Sommarskog) writes: +-------------- |David Gudeman (gudeman@arizona.edu) writes: |>Why not trust the programmer to modularize and document |>the code correctly? | |If we could trust programmers there would be no need for language |of any higher level than C. +-------------- The point of high-level languages is that they relieve the burden from programmers so that they are no longer required to implement specifications in such tiny, incredibly detailed steps. That way programmers don't need to be mistrusted to make as many low-level mistakes. They have the ability to work at a larger conceptual scale thereby, allowing mistakes to take on a more global character. This affects others more directly and is therefore more likely to demand solution earlier on... +-------------- |Erland Sommarskog |ENEA Data, Stockholm This signature is not to be quoted. |sommar@enea.se +-------------- Cheers, -- _ _/\ Bruce Becker Toronto, Ont. \`o O| Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu \(")/ BitNet: BECKER@HUMBER.BITNET ---mm-U-mm--- "Moderation in pursuit of justice is no virtue" - Oliver North
rjh@cs.purdue.EDU (Bob Hathaway) (01/26/89)
Erland Sommarstog writes: >>If we could trust programmers there would be no need for language >>of any higher level than C. David Gudeman writes: >If you don't think there is any substantive difference between C and >Modula-2, why do you use Modula-2? Why not use a language which has >much broader distribution and is much better known? Tell me why you >think Modula-2 is good, and you will be describing what I don't like >about it. A last point from me on this discussion concerns a few software engineering issues: code can be used for purposes other than intended, programmers can leave, prototypes can evolve, programs can grow very large, etc. Well designed programs will survive gracefully, poorly designed ones won't. Since the design of good programs can be reflected in code, I prefer languages which provide the best facilities to model these abstractions such as Ada, Modula, etc. Since these languages provide adequate escape mechanisms for use when necessary, I find them suitable for general purpose programming. Bob Hathaway rjh@purdue.edu