Smalltalk is a tight design. So is Lisp. So is Forth. So is APL. C's design just feels like a pile of... stuff. Arrays are almost but not quite the same as pointers. You can pass functions but not return them. There's a random grab-bag of control flow keywords, too many operators with their own precedence rules, and too many keywords given over to a smorgasbord of different integer types with arbitrary rules for which expressions magically upconvert to other ones.
#include <stdio.h>
char *f(void) {
return "Yes, you can...";
}
char *(*g(void))(void) {
return f;
}
int main() {
puts(g()());
return 0;
}EDIT: At least last I heard. The example I gave is C89, and I know C99 and some GNU extensions. I don't know if a new standard introduced something else that could be referred to as a function that can be passed in but not returned.
A quick google for "c lambda" and "c closure" as well as looking for those keywords in the Wikipedia articles of C11 and C18 turned up nothing, so I guess not.
1: http://walfield.org/blog/2010/08/25/lambdas-in-c.html
2: https://en.wikipedia.org/wiki/Blocks_(C_language_extension)
There's a big misunderstanding here. Arrays and pointers are entirely different things. An array is a chunk of elements that lie next to each other in memory. A pointer is just a pointer.
The only thing that C does that causes confusion is pointer decay. If you use an array in an expression context, other than the sizeof operator, that expression evaluates to a pointer to the first element of the array.
And while it's confusing the heck of many people who never learned it properly, it's very useful. For example, string literals are arrays, too! Would you prefer to write printf(&"Hello, World\n"[0])?
That's it, in a nutshell.
Funny, I got the same feeling from Smalltalk and Lisp.
I own both "Common Lisp: The Language" and "Smalltalk-80: The Language and its Implementation", and while there are many ways those languages could be described as 'tight' (tightly-coupled, perhaps), at no point can you look at the C language and say "This could be smaller" without significantly removing functionality. Ok, perhaps there are some things around array/pointer syntax, etc. but the room for removing things from the language is very small.
LISP and Smalltalk are both 'kitchen-sink' languages. As I understand it (i.e. Unless I misread something or skipped a page) for an implementation to be a proper spec-conforming instance of Smalltalk-80, a screen and graphics server is required. Indeed, Smalltalk-80 requires a very specific model of graphics display that is no longer appropriate for the time. Steele's Lisp, has a number of functions that one could strip out and nobody would care or notice very much.
On the other hand, all of the C that is there serves a purpose.
Perhaps the only thing in your list that does feel like a tight design in addition to C, is FORTH. But FORTH puts the burden for the programmer to remember what is on the stack at any given time. It has some beauty, indeed, but all of the abstractions seem inherently leaky. I haven't programmed in FORTH, however, so I can't really talk more about how that plays out in practice.
If the "There is nothing else to remove" does not resonate with you, then I think the perspective of the OP, and myself, and others, when we call C a "small"/"tight" language, is that essentially, C was born out of necessity to implement a system. Conversely, the 'batteries included' aspect of Smalltalk and Lisp more or less presume the existence of an operating system to run. It feels like the designers often did not know where to stop adding things.
Most of the library functions in C, can be implemented very trivially in raw C. Indeed, much of K&R is just reinventing the library 'from scratch', there is no need to pull out assembly, or any more assumptions about the machine other than "The C language exists". Whereas, a lot of the libraries of Smalltalk and Lisp seem bound to the machine. Not to harp on too much about the graphics subsystem of smalltalk, but you couldn't really talk about implementing it without knowing the specifics of the machine. And while much of Lisp originally could be implemented in itself, Common Lisp kind of turned that into a bit of a joke. Half the time when using it, it is easier and faster to reimplement something than find whether it exists.
Apologies if this is repetitive or does not make much sense.
To me, ANSI C is “tight” in the sense that it is made up of a small set of features, which can be used together to get a lot done. But the design of the features, as they relate to each other, can feel somewhat inelegant. Those different features aren’t unified by a Simple Big Idea in the way that they are in Lisp or Smalltalk.
Lisp and Smalltalk, then, have “tight” designs (everything is an s-expression/everything is an object) which result in minimal, consistent semantics. But they also have kitchen sink standard libraries that can be challenging to learn.
(Although to be fair, Smalltalk (and maybe Common Lisp to a lesser extent) was envisioned as effectively your whole OS, and arguably it is a “tighter” OS + dev environment than Unix + C...)
FWIW, I am learning Scheme because it seems to be “tight” in both senses.
Standard libraries are a different matter, but I'm not too impressed by C there either; it's not truly minimal, but it doesn't cover enough to let you write cross-platform code either. Threading is not part of the pre-99 language spec, and so you're completely reliant on the platform to specify how threads work with... everything. Networking isn't specified. GUI is still completely platform-dependent. The C library only seems like a baseline because of the dominance of unix and C (e.g. most platforms will support BSD-style sockets these days).
I'm actually most impressed by the Java standard library; it's not pretty, but 20+ years on you can still write useful cross-platform applications using only the Java 1.0 standard library. But really the right approach is what Rust and Haskell are doing: keep the actual standard library very small, but also distribute a "platform" that bundles together a useful baseline set of userspace libraries (that is, libraries that are just ordinary code written in the language).
Common Lisp is kind of a language and a library. Parts of the library would be optional. Some standardization efforts (EuLisp, R6RS, ...) tried to defined a Lisp like-language in layers/modules/libs later on.
That said, given my comfort level and tendency to be more explicit rather than tricky, my C coding ends up surprising me a week or so later when I go back and realize "even at 2am" I did the right thing.
It's also a fun language to mess with junior programmers with.
the piles of stuff that C contains are the stuff of 20th century von Neumann architectures, the stuff that defines the undefined behaviors, and that's what has made C indispensible.
I'm not saying C's perfect, but you can't swap it out without replacing what it did and does.
The only speed advantage of Fortran, to my knowledge, comes from pointer aliasing information that C compilers have a harder time to infer. But that's more a consequence of the programming domain. Fortran is not a systems programming language. Fortran has specialized data structures for scientific computing built in (I think??). It's an apple and oranges comparison.
Plus the experience from all from us that had access to early C compilers on CP/M and home micros.
IBM already had a LLVM like toolchain for their RISC research with PL.8 and respective OS.
Only later did they switch to UNIX due to the market they were after.
Surviving mainframes are still writen on their system languages.
As for Fran Allen point of view:
"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."
-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming
Not checking for UB (aka invalid configurations) at runtime is what makes C (and any other language) fast - or more precisely, it's what allows compilers to emit efficient code.
Some languages / compilers rule out UB statically through the type system or other means, but that comes with tradeoffs that might, or might not, be worth making in your domain.
Not to mention the fact that other programming languages, on the mainframe and workstation space, were already starting to collect the benefits of whole program optimizers.
Except that clearly history showed that it wasn't enough, and we ended up with about 50 millions (and counting) different meaning for "static" for instance. I like C but its simplicity is almost by accident more than by design. It's pretty far from "perfect" in my book.
There are so many weird features about the language that can bite you ass for no good reason. Why don't switch() break by default since it's what you want it to do the overwhelming majority of time (answer: if you generate the corresponding assembly jump table by hand "fall through" is the easiest and simplest case, so they probably kept it that way).
Why do we have this weird incestuous relationship between pointers and arrays? It might seem elegant at first (an array is a pointer to the first element or something like that) but actually it breaks down all over the place and can create some nasty unexpected behavior.
Why do we need both . and -> ? The compiler is always able to know which one makes sense from the type of the variable anyway.
String handling is a nightmare due to the choice of using NUL-terminated strings and string.h being so barebones that you could reimplement most of it under an hour.
Some of the operator precedences make little sense.
Writing hygienic macros is an art more than a science which usually requires compiler extensions for anything non-trivial (lest you end up with a macro that evaluates its parameters more than once).
Aliasing was very poorly handled in earlier standards and they attempted to correct that in more modern revisions while still striving to let old code build correctly and run fast. So you have some weird rules like "char can alias with everything" for instance. Good luck explaining why that makes sense to a newbie without going through 30+ years of history.
The comma operator.
Undefined function parameter evaluation order.
I suspect that with modern PL theory concepts you could make a language roughly the size of C with much better ergonomics. I'm also sure that nobody would use it.
If this is true, then that makes perfect sense. C was attempting to look after its target market: assembly programmers.
I've often wondered this myself. The best I can come up with is that the underlying code generation includes an additional dereferencing step with ->, so having both . and -> makes the compiler a little more transparent.
Of course, in C++ you really need both because overloading -> is nice for e.g. objects that want to look like pointers.
> Why do we need both . and -> ? The compiler is always able to know which one makes sense from the type of the variable anyway.
You're contradicting yourself in a way.
Maybe K & R thought: "Why can't arrays decay to pointers? The compiler is always able to know which one makes sense from context anyway."
I agree with the your opinion about arrays/pointers, but disagree about ./->. A programmer reading the code might confuse a pointer for a non-pointer if you conflate . and ->
Or Zig (which is less superficially C-like on the surface, but is going for the same simplicity and low-level-ness).
The reason is that Dennis Ritchie wrote a submission to the committee¹ that described the ‘noalias’ proposal as “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs”, and, that “[i]t negates every brave promise X3J11 ever made about codifying existing practices, preserving the existing body of code, and keeping (dare I say it?) ‘the spirit of C.’”
Those comments describe what ‘undefined behaviour’ turned in to. The only reason dmr and others didn't make the same objections to it is that nobody realized at the time what the committee wording implied.
¹ available here: https://www.lysator.liu.se/c/dmr-on-noalias.html
So books of that day where written so you could learn a lot just from reading the book and thinking seriously about the examples, and working out the exercises in your head or on paper
It helped if every couple of days or so you could get some computer time and try out the things you learned, but it wasn't actually necessary. In the case of K&R, you could go through the whole book without touching a computer, and then one or two sessions afterwards trying things out could be enough to correct your misunderstandings.
I wish more books were like that today. Nowadays, they assume you are a computer all the while you are reading the book, and often depend on that when writing the text.
"const" as well (back ported from C++ ?). And being able to declare variables anywhere (instead of just at the beginning of a block)
Also, ironically, I feel like C presents an excellent case for an evolved language, not a designed language. Its very name is derived from BCPL, as are many of the semantics and notation.
It many ways Go feels like an updated C. It retains most of the basic abilities of C, while cleaning up some things (headers, etc), having more basic libraries included, and choosing some defaults around things like out-of-bounds array access that are probably more appropriate for the majority of most programs (outside of particular hot loops, etc) in an era where software is often connected to the network and security is a bigger concern.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475, http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
Undefined behavior is a great way to help the language help you; for instance, most loops look like infinite loops without it. All you need to do is test with ubsan to see if you're dynamically undefined anywhere.
Isn't this a simplification? Even for games, I'd expect most often to be GPU bound, then memory bandwidth bound, and only then CPU bound. Although I get that the hot loop thing/10% rule is not universally true for every CPU bound program (especially after code has already been heavily optimized).
But I'm not sure what you are disagreeing with. I didn't mean to totally deny the usefulness of UB in C++ (although I think the core rendering code of AAA games are more performance sensitive than "the majority of most programs"). I was just pointing out that C is certainly not as simple as it first appears, and many people new to it are not familiar with the rules around UB.
Go's able to design around some of the performance aspects without UB (using the native word size for ints by default can help some of the signed integer stuff, range loops can elide bounds checks, etc), but probably can't generate as optimal code as C can without dropping to assembly language.
https://www.digitalmars.com/articles/b44.html
A mistake that C++ missed an opportunity to fix.
But when the article implies that null terminated strings and the problems associated with them are caused by arrays decaying to pointers, I get more skeptical.
I mean it's not as if arrays in C are bounds checked anyway, so how would that have helped implement strings any better?
I guess you could have bounds checked them in the stdlib code, but you certainly wouldn't have gotten it for free just by knowing the array dimensions.
I've written an awful lot of C code, and I have much experience with the D way which uses arrays instead of null termination.
When I review a section of code consisting of strlen/strcat/strcpy/etc. I routinely find bugs in it, always centered around a mistake with the 0 termination.
When the array bounds are available, the compiler can optionally insert array bounds checks.
As for getting it for free, avoiding doing the strlen()'s is a big time saver.
Perhaps you were referring to C++, or some newer C dialect?
What I mean is, the K&R C had very few (if any) abstractions, other than those defined by preprocessor.
Like, you could look a the C code and pretty much "see" what the assembly code would look like after compiler did its work.
I've never used it for work or open source or anything "real".
Agreed. I read the whole thing in a weekend and had a pretty good idea about pointers and stuff afterwards. I feel a lot of people have trouble with pointers didn't read it.
* ZX Spectrum BASIC
* Assembly language (Z80)
* FORTH
* C
* ..
Learning C when I already knew assembly language made it obvious what pointers were. I suspect a programmer these days might start with javascript then jump to C and be a little mystified.
And in some ways the industry stopped programming in C as much.
What impresses me is reading Burroughs manuals, or the manuals, books and research papers from Xerox PARC and IBM in the 70's.
To me seemed like C was such a tight, perfect little design.
Only thirty keywords, and simple consistent semantics.¹
When I first learned it, it was still pre ANSI, and you declared a function like this
int f(a)
char *a
{
}
The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language.
I remember in the late '80s knowing my compiler so well that I could tell you what the stack frame would look like pretty much anywhere in my code. It was awesome to have that level of familiarity.
Soon after that things started to get more complicated, and I did a lot of Java, and I never again felt as dialed in to those languages as the late 80s C that I started out with.
The K&R book is worth a read if anyone missed it. It's beautifully written. A far cry from the 'opinionated' copy that you often find on the Go website.
Personally, I don't think you can make similar claims about Go's design or the 'because I told you so' tone that surrounds it.
1: Yes, I know, undefined behaviour, but this is my post and this is how I feel about C.