Essential C (2003) [pdf]
cslibrary.stanford.edu
cslibrary.stanford.edu
Sure, there was a lot more to type. Debugging was harder. But there was a beauty to that. A simple mental model. A sense of control.
These days all jobs seem to be sort of online crap. Piles and piles of layers and complexity and heterogenous frameworks and tools. Being on call. Never being able to truly master anything because everything changes all the time.
/nostalgia
I still glance longingly at my dusty paper copy of The Linux Programming Interface (https://nostarch.com/tlpi)
/nostalgia
:-)
Of course there are those who claim it is actually frightfully complex, when it is those same people who are re-interpreting the standards to actually create that very complexity.
I'm not a fan of adding GC to C. I've hard my fair share of stress caused by GC issues. It's great 99% of the time but when you run into performance issues caused by the GC it becomes a very very leaky abstraction.
I haven't had any problem with performance with the Boehm GC personally, though for what I've used C for is not-real-time video processing stuff. I found I typically got better throughput using Boehm than I did when I was manually managing my memory, but for what I was using it for, a small pause wasn't really a problem as long as the throughput wasn't really affected.
If I were to guess, the C version would have a bit better performance in a single-threaded context due to the fact that I would occasionally use tricks to avoid reallocations/frees, and the Boehm GC is opt-in, so when I was reasonably certain I could handle the memory correctly, I would do it myself, minimizing how much was actually being done by the GC.
I do feel that a static functional language like Haskell might perform well (maybe even better-on-the-average-case?) in a multi-threading context, since I personally find dealing with locks in C (and C++) to be very difficult to do correctly, so utilization of some of the cool tricks in Haskell to avoid manual locking might benefit. I was too much of a coward to use threads and locks much at that job, so I haven't had much of a chance to test it.
C - static typing + closures and GC ≈ Scheme. If I wanted to write in that style, I'd just use Gambit and be done with it.
I got into C over 25 years ago. Didn't find it frightening back then, but I sure do now.
Still use it pretty often for firmware and kernel driver development, but I want to replace it with something safer. Then again, I also use assembler for same reasons... sometimes C just doesn't cut it for interrupt handlers when every cycle and/or code byte size counts.
That's what you have ASM for :D j/k
Why is that? Security related stuff?
Also when you have larger teams and more people touching the code, C can really shoot at your feet and elsewhere. From new and surprising angles.
I love C, but it really is a security nightmare full of footguns.
I don't code professionally though, since i can't for the life of me find a job in C which doesn't have already tons of guys like you guys with a century of experience in the language lining up to take it :D
C/asm is awesome, can't bare anything else
There's something to that, I think. And it's still an open question whether the newer languages that are in development at present will succeed in bringing some of that underlying "beauty" back. It's an important issue if we want lower-level programming to be more widely accessible.
(To clarify - the underlying machine model of C is beautifully simple, and newer low-level languages tend to be built on something very much like it anyway. The C language itself is frightfully complex - albeit less so than that other language in the C family that's often conflated with it.)
C might be the optimal point on the abstraction ladder as far as the trade off between (exposed) complexity and control.
... and there we stop. Nobody gets to create custom atoms.
Not so, there are a few specialized domains where having tracing GC easily available is genuinely useful. (Pretty much anything having to do with general graphs - the sort of stuff you'd traditionally use LISP for!) Go is a great fit for these use cases.
Rust is like something else entirely.
If you do this, it'll seem soon enough that the Javascript nightmare was just a dream. Takes balls though.
Can't stop smiling these days when I see people fighting over which language will rule them all. I spent tens of years searching for that language myself. Time I would rather have spent solving real problems using the best tools.
Lua is a great, easy to use, easy to apply, language -- with a healthy framework ecosystem, and it is very easy to put it to use in a legacy code-base, since its C-based, and we all know that C still makes the world go around. However, its not the fact of Lua, but the fact of 'put our own VM everywhere' that wins, imho.
A little too close to home.
EDIT: grammar.
Like this? https://andrewkelley.me/post/zig-stack-traces-kernel-panic-b...
I haven’t been able to think of a project to use it for, though, as all of my work these days is web related.
edit: What I meant by "cleaned-up" Pascal was addressing some of Kernighan's criticisms as seen in https://www.lysator.liu.se/c/bwk-on-pascal.html (also, the Pascal syntax is a bit bloated)
Pascal was a language I learnt in 1982 and love it for its elegance. The only thing i dislike and is still around its the begin... End and only because I'm a lazy typist and lazy reader.For me is hard to find Begin-end blocks... Harder than looking for stupid squiggles used in other languages. Go figure.
btw if you haven't check out Casey Muratori's Handmade Hero on youtube, it will fill you with joy.
Startups using frothier tech are often (not always) toy companies building toy products (hyper-scale toys are still toys).
Each time a new "hotness" language, framework, pattern, or dev/devops process comes out you have a rush of professional gurus working hard to build their business (e.g., speaking fees/books/blogging/training) by teaching that this is the new true way.
In the late 90's I began to notice how the new kids kept advocating for the newest so-called best practices to do things that the bad-old practices could handle just fine. Seeing the writing on the wall, I dipped out of the game a few years later.
Unfortunately, the unhelpful tech churn has worsened. Similarly, the quality of the product produced has worsened, or at best, not improved.
Note, hyper-scale advertisement services, global human tracking, and digital Skinner boxes are not an improvement to anything.
Meanwhile 50 year-old programmers with deep general development knowledge cannot find jobs. I guess it is easier for young founders to justify using frothy tech if there are fewer old-timers around to suggest otherwise.
edit-to-add:
/get-off-my-lawn
And of course, the Web became widespread around that time, as well. Whatever you might think about "hyper-scale advertisement services, global human tracking, and digital Skinner boxes", Amazon first became prominent in the dotcom era, and it's quite massive today.
While some newer languages are interesting, the dev stacks today are a mess.
Also, While we have safe pointers and GC everywhere, the lack of technical discipline/professionalism in the industry is worse than ever. I recognize that the C-suite and VCs share in the blame for this, but devs are the ones building things and evangelizing the newest-hotness that comes onto the scene.
But I do have to remind myself that compared to traditional engineering tracks, software engineering is still in its infancy.
/get-off-my-lawn
What concerns me quite a bit is the overt opposition we're now seeing to professionalism in the industry. The whole 'post-meritocracy' shtick, regardless of the best intention of the "useful innocents" who came up with that particular phrasing, is really a way of saying: "Professionalism? What professionalism? There's no such thing, we know better than that! Brogrammers r00lz FTW!" Again, this is clearly not what the proponents were seeking-- but in some sense, it's what the phrase actually means, out there in the real world.
/salty
I will shut up and go back to building this Android app I am working on -- what a horror-show of a platform.
I don’t need to chase the latest framework... but I’m also on my own for almost everything. Pros and Cons, but I wouldn’t leave it for anything web related.
I'd like to see Rust happen, because I don't see C++ as the embedded future. At least Rust had the good sense to leave garbage collection out.
However... I'll believe it when I see it. And by that, I mean when STM and Nordic and NXP and others are pushing out their own Rust device support files on their sites. When Keil or IAR or Rowley or Atollic pushes out a full featured IDE that uses a Rust compiler. When Rust is not only supporting the latest run of chips but there is a way to debug them with code-overlay. But until then...
AUTOSAR moved from C to C++14 as the certified language.
mbed is written in C++.
However, AutoSAR is a fair point. There are a lot of hands in the pot on that and them coming to an agreement to use C++ is rather surprising - counterpoint that Automotive ECU code is absolutely HORRIBLE right now and no one seems to know it. I work in Auto and all the mfgs have moved to a fix in the field model. It’s really bad, and I wouldn’t touch a first year new model for any reason.
So while AutoSAR C++ is interesting, this isn’t exactly the group that I want to model myself on.
Fair point though.
I'll take debugging C over modern C++ any day...
Same here. I worked quite a lot on C on Unix and some on Windows (including working on a successful database middleware product on Windows, which was used in some VB+Sybase/Oracle client-server projects) before I got into other languages like Java, Ruby (and Rails) and now Python for quite a while. Great fun working in C, although of course frustrating at times too, debugging weird issues. Also, somehow, I never found working with pointers (at least for simple to intermediate uses of them) confusing, like some do. (I once taught a C programming class at a large public sector company; while I was explaining the int main(int argc, char argv stuff, and the pointer to pointer stuff, the head of their IT dept. who was in the class, said "now it is 'overhead transmission' :)". Maybe I didn't have trouble with pointers because I had some hobbyist assembly language programming background from earlier, including learning about different addressing modes, such as direct, indirect, indexed indirect (or vice versa) (on the 6502 processor), etc., plus used to read a lot on my own about microprocessors, computer architecture, and suchlike related areas, even though they were not directly relevant to my higher-level application programming work (hint hint, to kids learning computers today). Working close to the machine is good. Also, a bit off topic, I kind of independently discovered the concept of refactoring. I was in a nice relaxed state one afternoon, at work, after a good lunch, but not heavy, so not drowsy, working on some Unix C program (likely a CLI one), and over a period of time, I noticed that I had been making small (behavior-preserving) incremental improvements to the code, one after another. In a very relaxed way, without any tension, taking my time for each small change, so I was fairly sure that each small refactoring change did not change the meaning or correctness of the program. Thought that was a good technique after I realized that I had been doing it. Unfortunately did not keep doing it with other code. It was only some years later that I read about the term "refactoring" and about Martin Fowler's book on the subject. I'm sure others must have discovered the concept similarly. Anyway, interesting incident.
Unlike the rushed, tense way in which some (many?) projects are conducted these days (and plenty earlier too), with people playing whack-a-mole with bugs introduced by said rush, "because we have to ship last week".
[1] (Frequent use of) exclamation marks is obligatory or you're not a (team) player, go home. /s
/s
I've gotten in several arguments with people about why I like C more than C++, and that's in no small part because I find C to be a lot simpler than C++. This is an example; I feel you can learn enough C to actually start doing stuff in a 45 page manual, where with C++ I did it for about a year and never really felt I had a real handle on all the idioms.
I know there are probably a lot of objective reasons to why C++ is safer or something, but I've always felt that if you embrace GCC's extensions, and glibc (and use of Boehm's GC for parts that need to be a bit safer), you end up with a language that's simple to learn, and has a lot of the features I actually use in other languages.
That said, this is coming from a very-much-not systems programmer, and I mostly do Lispey stuff nowadays.
Which isn't ISO C any longer, rather GCC C.
I'm personally not opposed to breaking from ANSI/ISO in regards to using GCC or clang; these platforms are incredibly well-tested and supported, produce fast executables, and work on basically every platform out there.
Contrary to the languages listed by you, there are plenty of compilers across the industry.
The computing world isn't composed only of FOSS UNIX clones.
Yes, the world isn't composed of FOSS UNIX clones entirely, but GCC works on a lot of platforms now that aren't Unix. MinGW has typically worked fine for me on Windows (not even counting Cygwin or WSL). I don't do systems programming, so I don't know how much (if at all) GCC is used on stuff like micro-controllers.
I suppose I didn't make my argument clear enough, but as I said, if you view GCC C as its own language, I don't view that as different than using rustc.
With all the Modern C++ changes happening, it seems like the standards committee is actively making it harder for people who want to understand the language completely. I much prefer C to C++ for the same reason, although I think some features from C++ are genuinely useful, like classes.
However, modern C++ enables safer and clearer semantics than what raw pointers offer, such as references or smart pointers.
C takes the middle road -- variables may be declared within the body of a function, but they must follow a '{'. More modern languages like Java and C++ allow you to declare variables on any line, which is handy.
I know this is not the case in C11 for example, but is there a compile-time speed-up when declaring variables in this way, or any other benefit?
Introducing additional variables later, means that if you emit code "as you go", you'll be less efficient - which makes no difference today, but was a big thing in the days C was designed; Most compilers back then were single pass, emit-as-you-go. There are relatively simple ways to deal with that even under the single-pass constraint, but in those days and the common compiler construction techniques prevalent at the time, it was considered harder.
There was always an issue of fixups with scope-exiting control transfer like break and goto - however, they are simpler, and don't harm emit-as-you-go compilation to the same extent.
EDIT: Looks like beagle3 beat me to it while I got coffee.
I call it "char" because that's how it's spelled, though.
Like the first word of char *. The accent is generally on the first syllable."
Is it designed to work like that or an oversight?
https://news.ycombinator.com/newsfaq.html
However, links to the original discussion of an old article might be useful if people are interested in the topic but no discussion occurs on the current posting. Or, the previous discussion may have some interesting comments that are worth revisiting.
Edit: the first example is clearly stepping through values in an array, and the other is flipping some bits and setting others... what's hard to understand about that?
a ^ c | d
(a ^ c) | d
a ^ (c | d)
I dislike some overuse of parentheses, but in this case I'd definitely use them.
a = b[i++]
a = b[i]
i++ // or even better,
// i = i + 1
// and unequivocally
// rejecting any
// compiler for which
// it might matter.
a = b[i++]
If you're going to be reading C code, you have to be familiar with certain idioms that might be unfamiliar to someone who doesn't know C.
I would certainly reject any compiler for which these:
a = b[i++];
a = b[i]; i++;
a = b[i]; i = i + 1;
As a writer, whether of code or natural language, you are responsible for the thought patterns your writing actually induces in the mind of the reader, the practical side effect of someone reading your code, and emphatically not whatever you intended them to think.
In this sense your defense of b[i++] just fails. It has nothing whatsoever to do with uniquity of the known value of i++, because that is already assuming something (familiarity with C syntax) that is dangerously foolish to assume of a code reader.
Especially when an effortless alternative exists (i = i + 1) that meets a much, much wider natural expectation about assignment and order of operations.
I’m not advocating for using it, per se, but I’d be shocked to find any C programmer who knows the latter but not the former.
I read through mountains of legacy Scala code while working on my first several projects, and have assisted dozens of other new developers (most of whom also have never once read or thought about Scala previously).
The assumptions people made in that codebase still give me nightmares, mostly over how foolish and lazy they are in little ways, little unexplained “self documented” things that create multi-hour stumbling blocks but which could have been written in a more “elementary” style in the first place (without sacrificing any necessary language features).
When I see things like, “any C programmer should know ...” I just slap my head in stupor. It just misses the point entirely. It’s of zero importance whatsoever to write code in language X in a style that benefits mostly only “people who know language X.”
Pretend you’re writing the code for a freshman intern who will look at it in 5 or 10 years with no prior knowledge of the language it’s written in, and now you’re in the correct ballpark for how to write professional software.
Is it too much to ask for someone to look them up if they find one they are not familiar with?
For me personally or likely for other experienced engineers, code compactness is a nice thing.
But this is unimportant, because nobody should be writing the code for me or with me in mind. Code compactness for the sake of other experienced engineers is an extremely stupid thing to prioritize above the simplicity of reading straightforward, separated operations that rely on as few concepts as possible.
Code compactness is nowhere near as important as concept compactness, because the latter appeals to all engineers, not merely to other experienced ones.
Anything that requires or introduces a new concept or mixes multiple concepts together is more costly in terms of hurting readability and maintainability than corresponding “longer” code that relies on fewer concepts.
It would perhaps be instructive if you could enumerate or point to what you consider to be a good set of concepts to work from. Clearly there are some absurd answers ("it's all NAND gates in the end"), but I don't imagine that's what you're thinking. Would you include functors? applicative functors? Different forms of memory management? APL/R/Numpy-style arrays? setjmp/longjmp?
It’s kind of like martial arts. You are encouraged to learn a huge variety of skills, mostly fundamentals but also esoteric advanced things.
But when it comes to actually using them in real life, you should try to avoid needing to use them at all costs, and even when you are absolutely forced to use the knowledge, use the simplest, most straightforward way to address only the problem at hand, never in excess or for personal interest.
It’s about self-discipline, to orient your code for the mind of an inexperienced novice despite the fact that your simple code might be solving state of the art problems.
It happens to all programming languages when engineers don’t prioritize future-proof readability as a first class part of maintainability along with testing and judicious choices about when to invest in extensibility designs vs when to ignore extensibility.
What does it say about the competence of "future" engineers if they can't understand code written by past ones?
One of my favourite sayings is "the code is unreadable to you, because you are not qualified to understand it yet". Perhaps we should not encourage the degradation of our craft.
It doesn’t say much about those future engineers at all.
It’s easy to write inscrutable code that even veteran engineers can’t understand, yet still “gets the job done.”
Also, you act like this would imply that all future engineers are the same, but that is not true and not related to my points.
You’re writing code for the inexperienced future engineer, some poor soul tossed into a legacy codebase without much help. It’s not their fault they were put in that position. It’s sink or swim. Good code helps _that_ person swim.
As for the quote you mention,
> “One of my favourite sayings is "the code is unreadable to you, because you are not qualified to understand it yet".
That is a horrible way of thinking, with built in condescending attitudes and everything. If code is unreadable to someone, beyond basic syntax definitions, that is the author’s fault and not at all the reader’s fault for being inexperienced.
The reason 5th graders can’t read Infinite Jest is because David Foster Wallace tried to make it complicated, not because, in some skewed perspective, the writing is perfectly simple but 5th graders just aren’t experienced enough yet. It’s a complexity property of the writing not of the reader’s brain.
With literature you can get away with this because there are extenuating arguments about artistic merit.
For business software, not so. In that case, if you write something more like DFW and less like Hemingway, it’s a sign of laziness and lack of self-discipline.. and not at all a sign of skill advancement.
Most code that creates value to people is messy, written in a hurry with vague specifications & unclear understanding of what the end user wants or would pay for, and it gets iterated by disjoint teams of people with competing timelines, politics, credit mongering and resource constraints, and most of it is for reporting something to someone.
If you don’t step back and realize that bare metal performance and esoteric data structures and algorithms generally don’t matter and can be picked up quickly by just about any engineer, and that real value comes from putting careful scaffolding and comments around hacked up business logic that needs to be future proofed against highly volatile business circumstances, you’re just going to be miserable and probably should quit and try to find a financially viable open source job on a compiler team or something where the exceedingly rare assumption you want to enforce (that most people reading your code are above average at the idioms of the language or tool you’re using) has some prayer of being relevant or applicable.
Let's not conflate the essential complexity of a problem domain with what's purely a result of grossly sub-standard development practices. And let's not pretend that the clowns are any better at coping with "real world limitations, deadlines, customer demands" - they're not.
To call it “substandard development practices” is like saying that wealthy people shirking their civic taxation responsibilities through offshore accounts is “substandard economic practices.” It just is.
with no prior knowledge of the language it’s written in
W...T...F...? Someone who can't understand the code they've been assigned to work on is simply unqualified for the job.
Nobody said anything like this! I don’t understand how you make this conflation mistake.
Before I ever read one single character of Scala code, I had written hundreds of thousands of lines of code in C, Python and Haskell, among others.
It was easy to understand Scala code despite having never read it except for places where people tried to rely on needless shorthand or obtuse ways of doing things.
I can’t understand your response. It’s so easy to write C code that a veteran C expert has to spend hours to understand, or to rewrite the same code in a way where a freshman who only ever used Java could equally easily understand it.
Familiarity with how to unlock meaning from badly written code is not the same thing as experience with a language.
If you want to read something in a language you don't know, you learn the language. Every profession has its own terms of art, its own abbreviations and lingo, and to suggest that those don't have any value is just ridiculous.
I seriously don't understand this attitude. You don't see other professions saying how they should be understandable by everyone who hasn't studied them. Why should programming be any different? I blame the "everyone can code" charlatans...
> “If you want to read something in a language you don't know, you learn the language”
but this means you’re missing the point. If you are writing something like a tech manual in Japanese, and you know ahead of time that it will be required that sometimes people totally unfamiliar with nuanced Japanese (but with high skill at picking up badic ideas in any language) have to rely on your manual, then how should you write it?
The foolish answer is to say you’ll write it with advanced Japanese language constructs and then turn around and say, “oh well, novices who want to rely on the manual should have gone and learned advanced Japanese.”
The smart answer is to say you’ll use self-discipline and restrain yourself from nuanced Japanese, and instead write in a way that novices have a good chance of decoding with minimal extra effort, and of course advanced Japanese readers will also still be able to get what they need too.
This is such a self-centered idea, approaching it like, “I can write whatever code I want using whatever idioms and it’s someone else’s fault if they didn’t learn the language sufficiently ahead of time before they found themselves needing to quickly read my code.”
a = b[i++] + c[i++]
a = b[i] + c[i]
i += 1Chances are you haven't been using C much for hardware/low-level stuff, because the ^ operator is seldom seen outside of that context.
On the other hand, the precedence of & and | (and likewise, && and ||) should be general knowledge: the former has the higher precedence, in analogy with multiplication vs addition.
You can't be serious. How is this ambiguous in the slightest? Assuming that you actually know some rudimentary C.
The amount of dumbing-down that I've seen happen to programming is already beyond ridiculous. You should definitely look at APL, Lisp, or some of the other more expressive languages out there if you think anything beyond the equivalent of glorified Asm (one statement per line, one operation per statement, one use per variable...) is "dense and unecessary[sic] shortcut".
I think this a relevant article to start understanding the opposite point of view: https://news.ycombinator.com/item?id=13565743
The problem for me here is not that it's "too complex", but that it's ambiguous even for experts with a casual glance. It makes perfect sense right now after you've written it, but months or years later, the person reading this while doing some maintenance or debugging might glance over and not see the subtlety of pre- vs post-increment while they are busy with other tasks and deadlines. It does make sense to avoid such pitfalls, where possible.
IMO all these features of C makes programming and therefore system design anti-fragile. Anecdotal experience based on interactions with a few C programmers who work on embedded systems.