Path: utzoo!attcan!uunet!decwrl!ucbvax!AI.MIT.EDU!bson From: bson@AI.MIT.EDU (Jan Brittenson) Newsgroups: comp.society.futures Subject: Re: C's sins of commission (was: (pssst...fortran?)) Message-ID: <9009251539.AA22928@rice-chex> Date: 25 Sep 90 15:40:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 130 X-Unparsable-Date: Tue, 25 Sep T 11:39:17 EDT Jim Giles: >From article <9009220848.AA00539@wheat-chex>, by bson@AI.MIT.EDU (Jan Brittenson): > Surely what's wanted above is a reliable method to allocate buffers > that don't contain page boundaries or other unpleasant hardware > dependent things. This is clearly the job of the memory manager - to > give the programmer adequate support Who is the `programmer' - the application programmer or the system programmer? You don't seem to have a very clear concept of who does what. I for one wouldn't touch 4G programs with 5-ft pole; the same can be heard from the 4G people. Which isn't a big surprise, different programmers have different concerns. And at least in my experience there have easily 10-15 4G/COBOL/you-name-it application programmers to one or two system programmers. > Ah, but I'm still not convinced that the language of the future should > even _contain_ pointers. I'm not even convinced computers of the future will execute instructions sequentially, just because this happens to be the case today. > And, like GOTOs in flow control, pointers in data structuring tend to > result in spaghetti. If this is deliberate, it on the programmers > head. If someone just get some wires crossed though, I'm willing to > apportion at least _some_ of the blame on the language feature itself. Yeah, I tend to agree here. No one has said that system programming is easy to learn or get accustomed to, and regardless, constitutes a mere fraction of all programming effort, as well. You'll find a lot of system hackers on the networks writing free software of course - but I think they're a considerable minority at their respective workplaces, or else they're students. > What [the programmer] wants is to be able to say "DMA_port=command" > whenever he needs to. Why not have the compiler (or the loader) > contain a list of all the hardware-specific addresses with some > mnemonic names that the programmer can just declare and use? Why does > the programmer have to mess with addresses at all? Now this is a catch-22 as good as any! Who is to implement the semantics of "DMA_port=command"? I mean, I can type it at my terminal as many times as I like, even check the syntax, without anything happening to the DMA_port. > The database person would probably use whatever syntax he _presently_ > uses except without the need for dereferencing on the linked list > types of stuff. Give me a _specific_ example of what you think would > be hard. SELECT NAME=some_name AND SHOESIZE=10.5 FROM Register_1 You tell an applications programmer that he or she is to use something like: execute_sql(CMD_SELECT_ROM, 3, KEY("NAME"), find_var("some_name"), KEY_LOGICAL("AND"), KEY("SHOESIZE"), 10.5, "Register_1"); and the person is going to laugh you in the face! You *don't* want to build *everything* pereceivably useful into the compiler, or add syntax for it. There are excellent (well...) 4G compilers that generate C code, and they don't mind generating code that uses pointers one itsy bit. >> [...] or how to create a channel program in a mainframe environment. > Oh? You can do that in C? Certainly, with data structures and pointers. Although on IBM machines it's more commonly done in assembler, which compared to C is totally unintelligible and structureless. I much rather maintain a program written in C than ASSEMBLER XF. > Once you've learned a language it _is_ kind of like a trap. You begin > to see only how _that_ language works and not how to solve your > _actual_ problems at all. I am very wary of falling into that trap. But I'm not obsessed with syntax or a clear correspondence between syntax and semantics - semantics is most important to me. To a student or application programmer a clear correspondence between syntax and semantics is probably of more importantance than it is to me. If C doesn't allow me to do what I need to do, then I'd ditch C and go dig up an assembler. Which is a rare occurence indeed, but I doubt it would be less frequent without pointers or some address data type. > Our organization is currently switching _TO_ C/UNIX from something > else. All the trouble you predict is indeed upon us - the retraining, > the expense, the incidental blunders along the way. Perhaps C/UNIX was a bad choice then. Why C? What kind of software did you port? >> >> [...] >> >> 4. Implement malloc()/free(). >> >> [... I said standard C can't do it ...] >> >> No doubt you're correct. Implementation is fairly trivial in >> "nonstandard" C, and I fail to see how it could be made easier or more >> "defined" without any pointers (i.e. explicit object addresses) at all? > Actually, the implementation is quite trivial. period. I don't see why > we have to mung-up the language design to do something which should be > done in assembly for efficiency anyway. I don't think the efficiency issue is all that important. Portability and maintainability is of greater economical concern - it's penny-wise to code RTLs and kernels in assembler to gain 15% speed, while it'll take at least twice as long, be twice as hard to maintain, and not portable for shit. As a customer, you're stuck with a single vendor who can literally rip you off with upgrades and patches, i.e. make you even more dependent on half-working assembler code. --- Regarding the example I posted, against the importance of strings. I just like to add that it was not an argument for pointers, only against the often stated importance of strings as a data type. In fact, the program would probably have been much easier to write *without* explicit pointers, in Common Lisp for instance. Unfortunately, that was not an option.