[article] Language Design Deal Breakers

H. S. Teoh hsteoh at quickfur.ath.cx
Sun May 26 08:18:11 PDT 2013


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. :)


On Sun, May 26, 2013 at 05:22:18AM -0400, Nick Sabalausky wrote:
> On Sun, 26 May 2013 13:27:55 +1000
> Peter Williams <pwil3058 at bigpond.net.au> wrote:
> > 
> > I should mention that this was back in the mid
> > 90s and C++ may have improved since then :-).
> > 
> 
> I dunno. The more I learned about C++'s more advances features the
> more disillusioned I became with it. I was always happiest (or at
> least, least unhappy) with the "C with classes" form of C++.

Have to agree with that. Though when templates first came out, they were
a huge thing for me. It was only later that it became clear that the way
C++ handled them was ... well, it left a lot to be desired. :) When I
got acquianted with D's templates, I was totally blown away. It was like
a veil was lifted and I saw for the first time what a *real* template
system ought to look like.


> But then again, maybe that has nothing to do with "older C++ vs newer
> C++"?

"C with classes" *was* the older C++, whatever that meant. Since then
C++ has been trying to become purely OO (and failing horribly, IMO --
Java takes the cake in that area, no matter how much I may dislike that
fact), and tried to clean up the horrible mess it inherited from C (but
not very successfully). C++11 (finally!) introduced lambdas and type
inference, and a bunch of other stuff, but ... meh. A lot of it feels
like "too little, too late".


T

-- 
Indifference will certainly be the downfall of mankind, but who cares?
-- Miquel van Smoorenburg


More information about the Digitalmars-d mailing list