Brian Kernighan on C [video]
youtube.com
youtube.com
C is beautiful.
For a register machine, C can be pretty beautiful.
It's funny you talk about parsing command line options. Plan 9 solved that problem well with the arg(2) macros. [1]
In fact, Plan 9 in general is a premier example of really clean and elegant ANSI C-compatible code. [2]
[1] http://man.cat-v.org/plan_9/2/arg
[2] e.g. https://github.com/0intro/plan9/blob/master/sys/src/libndb/n...
Even in crusty pre-ANSI C, it's very elegant stuff.
(Then I look at the Bourne shell sources and weep. It's like the author of that was in denial of everything that made C a decent language and wanted desperately to be doing something else)
It's another sense of beauty, the one of talking almost directy to the machine, with few abstractions, and few wastage.
If a programmer uses a language poorly it can be the programmer but in a lot of cases it can also be the language, that has poorly thought out, conflicting, etc constructs.
There is a field called PL research (part of Computer Science) and researchers can all agree on several problems that C (and what would have been a better design).
Some of the problems are so obvious that the creators of C admitted them too. Some have been corrected in later revisions (C99 etc).
The tool can be the source of your issue if its not made correctly.
"Pure wire-mesh electric blanket -- no insulation whatsoever! Only $20 dollars. Will raise the heat with sparks of electricity, plug directly into your 110v outlets!".
Sure, works as advertised. But it's ill concived and will fry anybody trying to use it, either because he wants to or because he is forced to (by his boss or needing to deal with legacy code in the case of a programmer).
The example is contrived to showcase the point, but the gist is: "works as advertised" doesn't mean much with regards to quality or well thought-out architecture.
Of course if you're simply comparing size, keep in mind that Stroustrup's book is aimed at beginners. And provides a thorough discussion of many things in the language. The C book is terse and not really aimed at beginners or students.
If an EE and/or comp. sci. major can't grasp logic, they should not be in the class/major, and these classes are commonly referred to as "weed-out classes." "Programming" is derived from math (I'll provide source if you want), which is logical at its core. The keywords while, if, else, they're not hard to understand.
I don't know what teaching "programming" means.
I don't know about that. Knowing only a bit of Pascal (and Fortran and Basic, but they're less similar), I picked up K&R over a four-day weekend, and really understood it, without even a compiler to experiment with. (All except for argc and argv - had to try it out to see what was going on there.)
At Caltech ~1990 it was the textbook for the C programming course that was the usual first course in computer programming. And it seemed quite good in that role.
That difference isn't as large as I would have expected. Part of that may be style or formatting; C++ seems to have about a third more lines per page and smaller text, so I guesstimate it has about 50% more text per page. Looking at the descriptions of the preprocessor that seems about right; C needs 19 pages to do that, while C++ manages it in 13.
That would make the C++ language description about 3 times as long as that of C.
If we handwavily suppose that difficulty goes like size squared (perhaps every pair of features generates a possible interaction you have to understand) then a description 3x longer makes for a language more like 10x harder. [EDITED to add:] Which feels about right to me for the relationship between C and C++.
[1] Of course there are exceptions; some "Turing tarpit" languages like Brainfuck can be completely specified with very little text, but are difficult to do anything useful with because they are stripped so very bare.
I am not sure why it would be surprising that something as ambitious as C++ would take this long to evolve into a better form. C++ has always been very useful, but it continues to get better, IMO.
I seem to have presumed carry over of a quantifier or range that wasn't clear :)
C++ is valuable in its richness. Its richness comes at a price and indeed, fitting it all in one's head is very difficult.
In the case of C++, it's neither required, nor even possible to learn ALL of C++ (not without a couple decades of experience). C++ is a monster, a colossus, a many tentacled monstrosity of hundreds if not thousands of sometimes very complicated features. You cannot possibly master it all.
Yet the barrier to entry is as high as C, if nothing at least because C is a subset of C++. You don't have to be a template metaprogramming wizard and make full benefit of the latest standards' new features in order to know C++. As an example, in my work in physics I use C++ consisting of C, templates, the STL and POD structs. I don't use C++'s immense OOP tools simply because I don't like/don't need them. Someone else might use the full OOP features of the language. Still someone else might reduce it to C with templating because they like C but hate not having generic programming.
In short: C++ is what you make of it. Your C++ is a subset of the C++. It's your job to decide what features you want to learn and make use of. Don't feel like you don't understand C++ because you don't know Stroustroup cover-to-cover by heart.
Two departments or companies aren't going to use the same subset of C++.
Coding standards also evolve over time as languages evolve and better ideas about software engineering happen. 2015 C++ is much different than 2000 C++. Unless you always work on greenfield development with coworkers that strictly follow the same standards and C++ subset and you never do any kind of maintenance work, you will need to learn more parts of C++ than you may personally wish to use or learn.
I guess I just don't understand why people consider "too many features" to be a shortcoming.
Complexity and subtleties in a large language can make it difficult to write correct software.
I can point to one policy that guarantees safety becomes much easier: prefer modern C++14 idioms whenever possible.
That's a mighty large assumption.
Typical physicist--at least you can approximate many C++ developers as spheres!
If you aren't expected to do this, or even to be able to, perhaps the language is poorly designed.
But it was painful at times, and required a tech lead who could really enforce their opinion about what code should look like. In the end, at crunch, code was often written that used features outside the subset, and everybody did find themselves having to figure it out, to learn more about the language.
"Just use a subset" was always a solution better in theory than in practice for medium sized teams.
How big is the team of developers you have in C++, and what proportion have written code in other C++ shops, and how time-constrained is your development? C++ for R&D type projects is very different from C++ for getting a shed load of features out the door on time, in my experience.
I agree C++ is pretty messy, but if we got a 3rd edition K&R it would be much larger than the original.
Also no sure most people could understand C, but "most programmers" should be able to understand C if they tried. I concede I can barely understand C++, but I use a bare minimum of its features and write C when I can.
And having run into my fair share of memory-related problems in C, there are languages I much prefer for everyday programming (Go, Python). Ironically, the kind of issues a garbage collector addresses have never been much of a problem for me. But there have been times where I would have killed for a compiler switch to enable array bounds checks; this might reflect poorly on my programming skills, but this is by far the nastiest type of problem I have run into using C.
But C makes it still much, much easier to form a reasonably accurate model of how your code will be executed on the computer at runtime than C++. Compared to the alternatives (C++, Ada, Rust come to mind), C is still a gem of simplicity, and it continues to be popular for a good reason.
I hope there's more of this interview computerphile will release in due course. It is a fascinating time to hear about from the guys who -- essentially -- engineered our profession.
Absolutely impressive human being all around!
On a related note I absolutely love the Computerphile videos with Professor Brailsford. I could listen to that guy talk all day.