🚀 go-pugleaf

In article <QG279:@xds13.ferranti.com> 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