bilbo.dana@SEAS.UCLA.EDU (Dana Myers) (03/09/88)
Richard Harter <g-rh@cca.CCA.COM> writes on Date: 8 Mar 88 08:40:37 GMT: >In article <1354@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: >>In article <25284@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >>>Here is another feature for D whose absence in C has been irksome to >>>me -- I would like to be able to return several items from a function. >>>... But how do I get stuff back. >>>... Things which are returned need a mechanism equivalent to pass >>>by address. > >>Please don't design D until you understand C. > >Er, Dave, may I suggest it is inadvisable to make remarks such as >"Please don't design D until you understand C". I am not a C guru; >I read with respect the comments of people such as Chris Torek and >Henry Spencer. I don't need to be a complete expert in the language. >None-the-less I have been programming for 27 years, writing C for six >of those years, have written ~100,000 lines of C, and have dealt with >the vagaries of C implementations on a variety of operating systems. C'mon! Let me restate Dave's comment - "Please don't design a successor to C until you understand C". I think Dave's comment is perfectly advisable. To design a purported descendant of a given language, one must first have a complete understanding of what the ancestor language is. A working knowledge of a language is far different than a complete comprehension of a language. On the other hand, you may feel free to design any language you want, without a complete knowledge of C. In this case, don't feel as though your language is a successor to C, though it may appear a lot alike. I mean, afterall, would you consider designing a successor to Unix without fully understanding it in the first place? Or, does using the C libraries make one a Unix system expert? ;-) As Henry sez', 'Those who don't understand Unix are condemned to reinvent it, poorly'. The same could be true of anything, even C. Dana H. Myers Locus Computing Corp. Santa Monica, CA
g-rh@cca.CCA.COM (Richard Harter) (03/09/88)
In article <12187@brl-adm.ARPA> bilbo.dana@SEAS.UCLA.EDU (Dana Myers) writes: > >Richard Harter <g-rh@cca.CCA.COM> writes on Date: 8 Mar 88 08:40:37 GMT: >>>Please don't design D until you understand C. >>Er, Dave, may I suggest it is inadvisable to make remarks such as >>"Please don't design D until you understand C". Sundry tasteless self advertisement deleted. > > C'mon! Let me restate Dave's comment - "Please don't design a successor >to C until you understand C". I think Dave's comment is perfectly advisable. >To design a purported descendant of a given language, one must first have >a complete understanding of what the ancestor language is. A working knowledge >of a language is far different than a complete comprehension of a language. In a general way, I have to agree; in this specific case Dave simply didn't catch what the issue was, as should have been clear from the rest of the article. As a general principle, it is not wise to tell people that they don't know what they are talking about (a period should go here) unless you do know what you are talking about, what they are talking about, and whether they really don't what they are talking about. It tends to be embarassing. [I will take it kindly if people will make a point of not making snide comments about practicing what you preach :-).] I am not sure I know what you mean by "a working knowlege" and by "a complete comprehension", so I don't know whether I can agree with you. If you mean by a working knowledge, "I can write programs in language X just like I wrote them in language Y", then I agree. If you mean by "complete comprehension" know all the constructs and rules of the language, and be able to use them in practice, if necessary, I suppose I would also agree, with some reservations. Or does "complete comprehension" include knowing all variants, all machine dependencies, and all useful idioms? What are you talking about? In any case, the point in question was not the general question of language design -- it was the discussion of a particular feature of the language. The relevant comments are [a] the feature you want exists [b] the feature you want doesnt exist but isnt needed, [c] the feature doesn't exist and shouldn't, and [d] other. A knowledge of the general principles of the language (and of programming, and of other languages) are relevant for [c]. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.