[article] Language Design Deal Breakers

[Paulo Pinto]

Am 26.05.2013 17:18, schrieb H. S. Teoh:
> On Sun, May 26, 2013 at 01:13:30PM +0200, Paulo Pinto wrote:
> [...]
>> Now it is too late for it, but at the time C could have stayed as
>> powerful as it is while offering:
>>
>> - proper modules, or at least namespaces
>>
>> - no automatic conversions between arrays and pointers. how hard it
>> is to write &a[0]?
>
> I think this was a historical accident. The original C, being an
> abstraction of assembly, simply inherited the convention of using a
> memory address to refer to some data, be it singular (pointer) or plural
> (array). Of course, in retrospect, this conflation was a bad idea, but
> it's not surprising why this choice was made.
>
>
>> - arguments by reference, no need to check for null for every parameter
>
> Again, this was a historical accident. In assembly, there is no
> distinction between a pointer and a reference, so it's not surprising
> why the inventors of C didn't make that distinction also. In retrospect,
> of course, this would've been a huge improvement, but as they say,
> hindsight is always 20-20.
>
>
>> - strong typed enumerations
>
> I've always been on the fence about this one. I wonder how things would
> have turned out if Kernighan and Ritchie had made a distinction between
> proper enumerations (nothing outside of the set is allowed) and what's
> essentially an int with named values (values outside the set of names
> are allowed). I find that a lot of C code actually want the latter, not
> the former, esp. with bitfields.
>
>
>> - memory allocation without requiring the developer to use sizeof
>> everywhere
>
> And typecasts everywhere. I mean, seriously, it's so incredibly annoying
> to keep writing:
>
> 	myLongNamedType *t = (myLongNamedType *)malloc(sizeof(myLongNamedType) * n);
> 	if (!t) { ... }
> 	...
>
> over and over and over. Talk about verbosity. (And this isn't even
> Java!)
>
> In retrospect, though, I can understand why it was done this way (malloc
> was just another library function), but again, hindsight is 20-20. Back
> then there was a lot of pressure to minimalize the language; nowadays we
> know better, and realize that certain things, like memory allocation,
> really are much better handled within the language itself.
>
>
>> - strings similar to what D has
>
> Yeah, ASCIIZ was both a blessing and a curse. A blessing in that you
> don't have to keep passing a length around; a curse in that sometimes
> passing a length around is the right thing to do.
>
>
>> - proper arrays, after all the compilers for other languages always
>> offered control over when bound checking code was generated
>
> Well, in those days, premature optimization was king, and I can see why
> C went the way it did. Saving every last byte was always a top concern,
> even if today we scoff at it (and rightly so!). Time proved, though,
> that ultimately we *had* to keep the length around for various reasons
> anyway, so in retrospect they should've been included in the first
> place.
>
>
>> In the end, same syntax, just some semantic improvements on the type
>> system.
>>
>> But now it is too late, we only have modern C++ with its warts, or
>> hopefully D, Rust, Go, C#, or something else as possible
>> replacement.
>>
>> However, given that C and UNIX are one and only, it will outlive us all.
> [...]
>
> I don't know, if we get our act together in polishing up D, we may yet
> live to see the rightful demise of C (or more likely, its fading into
> the obscure dusts of time). I'm hopeful, anyway. :)
>
>

I do understand why many of C decisions where made, specially 
interesting is to read Ritchie's history on how everything came out to be.

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

I started using computers at the age of 10 back in 1986, so there
are a few things that I missed about those early languages.

However given my special interest in language design and the endless set 
of information my university used to offer, I devoured all the 
publications I could put my hands on. According to many of those papers 
some of the languages available on those days for systems programming 
could have provided for a safer C, assuming their designers were aware 
of them.

Then UNIX's popularity made everyone have the same tools on their home 
systems and we got C instead of Modula-2 or similar languages.

I am not religious and will use it if it makes sense to do so, but since 
2001 I don't miss it.

--
Paulo