You know you are old when...Y

[venusian]

[spoilers]They took every C++ weakness and made it a strength. Go, take a look.[/spoilers]

Well... that's certainly an opinion. I've used only up to C++14 but I wouldn't choose to use it on a new project today.

[Dvorak]

Got no further than C++17, myself.
C++23 is an epiphany, they say (maybe I got it wrong).

[KlaxonCow]

But we're talking C, not C++.

And, really, you're sort of proving my point as to exactly why a course might well choose C with deliberate educational purpose.

OOP, RAII, lambdas, template metaprogramming, coroutines, garbage collection, functional programming, etc., etc..

It's simply too much stuff. Particularly because, you know, though that list above glosses over it, a subject like "OOP" or concurrency are whole deep and complex subject areas in themselves.

Whereas, the full list of reserved keywords in C is: alignas (C23), alignof (C23), auto, bool (C23), break, case, char, const, constexpr (C23), continue, default, do, double, else, enum, extern, false (C23), float, for, goto, if, inline (C99), int, long, nullptr (C23), register, restrict (C99), return, short, signed, sizeof, static, static_assert (C23), struct, switch, thread_local (C23), true (C23), typedef, typeof (C23), typeof_unqual (C23), union, unsigned, void, volatile and while.

It's short enough that I can actually just list them all out. And, like, half that list is C23 additions (and a bunch of those - "bool", "nullptr", "true", "false" - are just backports of handy things from C++).

It's simplistic, sure. But that's the whole point. The whole thing is grok-able.

Folks often say that the thing about something like the C64 is that it was simple enough that a single person could grok the entire system.

So I can absolutely understand the perspective, from an educational viewpoint, that you teach C. Because it's small and simple enough to be fully understood.

And it doesn't require bringing in a load of new topics before you can begin. Like, if you're learning Java, then you've either got to teach OOP first / at the same time, or you've got to give students example code that has keywords like "class", "private", "public" and such in it, then tell the students "ignore that for now. Just consider it boilerplate that you have to copy into every program. It's a future module in the second year - OOP 101 - where we actually explain what the fuck is going on with all that stuff".

In an educational context, that matters. Loads of people hate maths exactly because a lot of shit is dumped on you - algebra, simultaneous equations, vectors, etc. - all at once, and its application to the real world is usually completely omitted, so you have no idea why you're learning any of it. While maths is a science, so there are wrong answers. In art, you can draw any old shit and, well, "that's an interesting interpretation". But, in maths, there is a singular "right answer" and you fail if you don't get it.

You're all thinking of real world application from the perspective of already knowing this shit. But pedagogy necessarily has a different perspective. For beginners, you've got to keep it simple, easily grok-able. Limitation is actually a good thing - here's a short list of all the keywords. That's it. That's all of them. And this is a learnable thing because it's nicely very finite.

And whilst I appreciate the "syntax is not actually important". It kind of is important. For the beginner, who's just starting out. For them, syntax is all-important.

Oh, indeed, for me personally, who's used goodness knows how many languages on goodness knows how many platforms, I give absolutely zero shits for syntax. Semantic is what matters - and I'm just looking up on Google what syntax this new language uses for doing this, this and this. Blender uses Python, so you have to write extensions in Python. I just looked up the syntax needed to do the things I'm already familiar with, looked up the API I could call and had it outputting the required output format I needed for my project in an evening.

I've been at this long enough that I kind of give zero shits for programming languages or platforms now. So many have come and gone, that I can't get worked up about yet another one. If you live long enough, then you start to see fashions come back into fashion again, and then you realise how it was all just meaningless arbitrary bollocks all along.

If you've ever read "the C programming language" by K&R, this is actually a deliberate design feature. The opening introductory chapter is a wonder to behold.

"C is a relatively 'low level' language; this characterisation is not pejorative".

What an opening line!

It then proceeds to tell you everything that C can't do. No, not what it can do, but everything it can't do.

"C provides no operations to deal directly with composite objects...", "The language does not define any storage allocation facility other than static definition and the stack discipline...", "there is no heap or garbage collection...", "C itself provides no input-output facilities", "C offers only straightforward single-thread control flow...", etc.

It provides examples of these things in other languages and then says "nope, C doesn't do any of that". Which is sending a message: these things are not absent because we didn't think of it, they're left out as a deliberate design decision.

"Although the absence of some of these features may seem like a grave deficiency, keeping the language to modest dimensions has brought real benefits. Since C is relatively small, it can be described in a small space and learned quickly.".

A brilliant opening chapter to that book. Best I've ever read in technical documentation.

It takes your assumptions - your expectation of being sold on how the language has a million amazing features - and then it happily shits all over that. Nah, C does almost nothing. By design. Everything is deferred to libraries, pretty much. There's about a dozen keywords total.

But, as it says, "this characterisation is not pejorative". This means it's very easily grok-able in an afternoon. It defers pretty much everything to libraries, because it has the attitude that these things should not actually be the responsibility of the language itself.

It's quite deliberately a "DIY" language that makes no assumptions. Not even memory allocation is built-in.

Indeed, one could say that it's not even really a language. It's more of a framework. It's "portable assembly language".

And I also have trouble with the basic idea of people who themselves learnt through languages like BASIC, C, Pascal, etc. then turning around and saying that no-one should learn coding through BASIC, C or Pascal. "Do as I say, not as I do", is it?

I do think that there's a lot of "hindsight" going on here. You're not talking as a beginner about what's good for a beginner, but rather as a veteran of what you'd prefer would have happened in some "what if?" past that never existed.

And I think I have a different opinion here, because I don't think you can avoid failure. Yes, we all used languages that suck and made horrible mistakes. But I don't think you can create a language that doesn't suck in some regard, and you can't learn without much failure. Failure is learning. Fail often, fail fast.

So I don't imagine, in my head, that there is some magical "golden path" to coding, where you never make a single mistake and all the languages you use are perfect.

That's not the real world. That's unrealistic.

Therefore, I actually agree with C's deliberate design decision. These things should NOT be part of the language itself. You should not "hard-wire" it all into the language. It should be separated off, because the correct place to be dealing with avoiding and remedying failure is through your processes and policies.

All non-trivial code has bugs. You should not be trying, in vain, to create some "bug-less programming language" where bugs are impossible to make, because this mythical programming language does not exist and can never be created. That's not where the problem should be being solved.

You're simply doing it in the wrong place, if you expect that your choice of programming language is going to magically make it impossible for you to fuck up.

Indeed, placing the responsibility in the wrong place is dangerous. If you now expect that bugs are impossible because you're using this "perfect programming language", then you'll stop looking for them. You won't design and test code with enough care, as you expect the programming language to do it for you.

C was epoch defining - everything that followed it, largely copied it - because it had this different attitude. Every other language was selling itself and raving about all the billion "features" it had built-in. And C defied that very deliberately as a design decision. "No, sorry, that's the wrong place for these things to be dealt with - none of that should be in the language itself at all". It defers the responsibility to where it should lie - in the code. And because it's external code, then it can be replaced, overridden, changed and fixed.

[Dio]

All non-trivial code has bugs. You should not be trying, in vain, to create some "bug-less programming language" where bugs are impossible to make, because this mythical programming language does not exist and can never be created. That's not where the problem should be being solved.

This statement is wrong in most respects. Obviously languages should try to save you from bugs. Bugs found at compile time have about 10% of the cost of bugs found in testing, which in turn have about 10% of the cost of bugs found in the field.

Eliminating certain types of bugs in the language is a very sensible idea. And indeed C does this - it's a much more bug resistant language than Python, for example, because it's strongly typed. (Weakly typed languages are very hard work when used on a larger scale, it's why Python starts to creak once you get over a few thousand lines of code. It's also one reason Python is heavily preferred for scripting and other toy jobs because people find strong typing an inconvenience).

Your last point is also dubious. One of the things academics hated about C was the bulk of features that came as part of it. Compare Pascal, for example, which has far fewer features than C. (Admittedly many of C's features are in its standard library, but unextended Pascal didn't have any way of doing most of it, in language or the library. It's basically completely unusable for anything that's not taking line-based input and output. It ended up taking a chunk of C's design in later versions to try to address this).

[PFVA]

I remember the times when people went on vacation without mobile phones, laptops, tablets, or TVs. At the most a small radio. And it was fun.

[F-ZeroOne]

And then people invented videogame arcades, and then it really was fun!

[Whiteball]

As kids you played cards, boardgames and then early computer games but all together as a family not each locked away in their own rooms hours at a time.

[Dvorak]

[spoilers]They took every C++ weakness and made it a strength. Go, take a look.[/spoilers]

Well... that's certainly an opinion. I've used only up to C++14 but I wouldn't choose to use it on a new project today.

Ach, fuck off, man, you now I'm right.

Code: Select all

string name{ "yakyak" };  

For instance.

So, remember pointers to member functions? Never got it right, me. The declaration maybe, but nothing beyond. - Just gimme lambdas. Grew up with Lisp, so gimme Closures.
The world before RAII? - Darkness.

Modern C++, I tells you.

[Dio]

RAII was well in use before C++14.

Lambdas are all very well for some of the simpler use cases, but the syntax is very clunky and they can be quite tricky to debug and profile.

[Dvorak]

RAII was well in use before C++14.

Lambdas are all very well for some of the simpler use cases, but the syntax is very clunky and they can be quite tricky to debug and profile.

And about closures I learned in a Lisp textbook from 1984 (Stoyan/Görz). In 1984.
Sure. They did not invent it. They used these concepts to fill holes in the language structure. And made it a strength.
Just an opinion, my opinion: they did quite well. Modern C++ is so much different from the C-style C++ I used to use back in my time.

Really? Am I the only one who's impressed by how far C++ came?

[Dvorak]

Lambdas are all very well for some of the simpler use cases, but the syntax is very clunky and they can be quite tricky to debug and profile.

In C++ they are just meant for the simpler use cases.

But, hey, lambda calculus is so 80s, and so deeply rooted into my brains.

[skab]

My younger son is just starting a computing degree at uni. They've rowed back from Java and are teaching C for the introduction to programming. Interesting choice. A whole new generation learning how to debug segmentations faults with printf and gdb.

Which is of course the only true way

I like that idea. C is as low level as modern-ish programming languages get. Most modern languages are so much isolated from the actual machinery under the hood that a huge percentage of programmers nowadays have no idea how shit actually works. Let them first learn how computers work, then let them enjoy the comfort of more modern languages.

I'd hate to have to deal with strings in C, that's always been horrible, but it helps with learning about computing in general, so that's a good teaching tool. Using Java as an introduction to programming is a bit like using a self-driving electric car for driving lessons. Just with a lot more classes...

[skab]

And that of course is when you know you are old. When Java is some modern shit to you.

[KlaxonCow]

I'd hate to have to deal with strings in C, that's always been horrible, but it helps with learning about computing in general, so that's a good teaching tool. Using Java as an introduction to programming is a bit like using a self-driving electric car for driving lessons.

Someone gets it.

What makes for a good programming language doesn't necessarily make for a good teaching tool.

Indeed, a good teaching tool must allow you to make mistakes. Because failure is an integral part of how we learn.

(If you want to teach a neural network to recognise cats, you can't only show it pictures of cats. Because if 100% of the training data is cats, then it'll just learn to always say "cat" every single time - and not learn to recognise anything - because that gives it a 100% success rate. You've got to have some pictures of dogs in there too, because that'll force it to actually look for the features that define these exceptions as being the failure state, or it can't pick out the exceptions to give you the right answer.)

I like your example. You can't learn to drive in a self-driving car (or at least a hypothetical fully autonomous car because, sorry, Elon, despite your hype, you ain't remotely delivered - but let's imagine a completely autonomous car actually was a thing). Because you're not doing anything and, significantly, you can't fail. So you can't differentiate between what you should be doing and what you shouldn't be doing, as it has no effect on the outcome.

And this is also why I still believe that the goal of a "bug-less programming language" is just fool's gold.

First of all, it's impossible. Orwell acknowledged that "NewSpeak" is, of course, completely impossible. You cannot have a language that's expressive AND restrictive at the same time. If you have negation - and what language can express anything without the concept of negation - then you can't have restriction. Because then you can always rebel. The language only permits you to say "Big Brother is awesome"? But if negation exists, then you can always say "Big Brother is NOT awesome".

It's a bottomless pit. You cannot have a "perfect" non-trivial general purpose language that simultaneously prohibits only the wrong stuff, but not an iota of the good stuff. It can be restrictive or it can be expressive / flexible, it can't be both simultaneously.

But, secondly, if you teach all new learner drivers in self-driving cars to ensure they cannot make any mistakes - as they're essentially prohibited from doing anything at all, because of that expressive vs. restrictive mutual exclusion - then not a single one of them actually knows how to drive.

It's counter productive. Because now you've got an army of people who don't know how to code and the only thing that's making their code work is the "bug-less programming language" preventing them from making any mistakes... but the perfect "bug-less programming language" is an impossibility, as you can't have expression and restriction simultaneously, so it will eventually fail.

For a baby to learn how to walk, it has to fall down. If you put in some contraption that holds it up all the time, the baby will never learn to walk - because it never has to depend on its own sense of balance, so it never learns how to maintain its own balance. Take the contraption away and the baby won't be able to walk, it'll just lose its balance and fall over.

You have to let the baby fall over. It's the only way it'll learn how to balance itself. Don't worry, nature has accounted for this - babies have extra padding and are more resilient to fall damage than you might credit. Also, they're much smaller and closer to the ground, and "f=ma" - less mass and a short distance to the ground, so not as much acceleration can build up before they hit the floor.

A learning tool must let you fail. It must let you put your hand in the fire and get burnt - and it is the pain you feel in your hand that makes you never ever do that thing again. Making mistakes is necessary. Pain serves a good purpose - you need an alarm system to inform you that you're going wrong or you'll just keep trying to walk on that broken leg until you permanently damage it beyond all repair.

This, by the way, is why data types are great. You need failure states to learn, but those failure states do not need to be catastrophic. So you can totally have a language where the compiler flags up all these warnings and errors - and if you treat the warnings and errors as failure states, and learn how to fix them all, then that's learning. But learning where your code can't do any actual real world damage (yet).

So, you know, I take advantage of data typing and never try to circumvent it. Languages that can "lint" the hell out of your code and pick up on your every mistake as a compiler error or warning are great. Where "strict mode" exists, I always turn it on.

I'm not advocating for "laissez faire" anarchy, to be clear. But fix bugs in the correct places. Fix the actual cause, don't patch some other bit of code to hide the problem - because that will eventually come to bite you on the arse, the instant the "protections" drop.

That is, in your world of everyone learning to drive in autonomous vehicles, everything might actually work just fine for the longest time - because you can just rely on the autonomous vehicle to always do the right thing on your behalf. Right up until the self-driving software has a bug or stops working. Then you're seriously fucked. Because no-one knows what to do or how to fix it.

"If you can meet with Triumph and Disaster
And treat those two impostors just the same;"
- extract of "If" by Rudyard Kipling.

[venusian]

Just an opinion, my opinion: they did quite well. Modern C++ is so much different from the C-style C++ I used to use back in my time.

Really? Am I the only one who's impressed by how far C++ came?

I am impressed by how far it's come and what they've managed to do. You're right, it's a completely different language now, a better one if one judges from the feature list.

But I'm also impressed by people who make life-sized models of Nobel prize winners from elephant dung. It's highly skillful, but I absolutely don't want to get my hands dirty.