Xref: utzoo comp.lang.misc:6119 alt.lang.cfutures:290 Path: utzoo!utgpu!cs.utexas.edu!usc!apple!olivea!oliveb!amdahl!rtech!ingres!llama!thomasm From: thomasm@llama.Ingres.COM (Tom Markson) Newsgroups: comp.lang.misc,alt.lang.cfutures Subject: Re: Changes to C... Message-ID: <1990Nov20.220526.24202@ingres.Ingres.COM> Date: 20 Nov 90 22:05:25 GMT References: <9576:Nov1523:11:0990@kramden.acf.nyu.edu> <6096@lanl.gov> <14780:Nov1605:10:4490@kramden.acf.nyu.edu> <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> Reply-To: thomasm@llama.Ingres.COM (Tom Markson) Organization: Ingres Corporation, Alameda, CA Lines: 38 In article peter@ficc.ferranti.com (Peter da Silva) writes: >I've been skipping most of the articles in this thread, but the following >sentence brings up an interesting thought... > >In article <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> gl8f@astsun9.astro.virginia.edu (Greg Lindahl) writes: >> If you study this example, you'll see ways in which C can be changed >> to make it more useful for a wider class of problems. > >My initial reaction to most of the problems with C that people bring up >is "yep, probably right... but how do you fix the language without either >changing it into something almost, but not quite, entirely unlike C or by >making the coder's job immensely harder?". C is great. We all love C. But a time comes when you say "Modifying C is not the answer". If one modifies C, trivial changes may be made without breaking a lot of code (like adding a raise to the power operator). But if you want to do something more major (like adding exceptions or something equally major), your only two solutons are to: 1. add it in a way not to break everything else, 2. hack C so that the change will break existing code. In the latter case, you lose the advantage of modifying C (Why modify C if what you end up with is no longer C?) And in the former case, if you attempt to slide a major construct into C in a way as to not break existing code, you will end up with a hacked up, ugly, and probably ineffective implementation of your construct. Languages must move on. If C had attempted to be 100% compatible with BCPL, it would not be as clear and powerful a language as it is. The real solution is to start over and design something you feel solves the problems you encounter or corrects percieved deficits with C. If there are things in C you like, take them. The nature of programming languages is that they borrow from each other. Tom Markson Unix Systems email: thomasm@llama.rtech.com Ingres Corp phone: 415-748-250