Tried to reply to @Fast-Nop who had replied to someone wondering if C would be a good first language.

IMHO C should have been put to sleep ages ago. A few years ago I downloaded the latest, greatest C Standard. For a language billed as small and simple (by many) it was over 800 pages long. Still there's a lot that's unspecified like order of evaluation of function arguments. Int etc is implementation dependent. And error handling, let's not go there. The macro assembler throws away all the semantics leaving behind a cryptic value. It's a complex language due to the innumerable interactions possible.

It's been called assembly language for the PDP-11 minicomputer. Recently learned that even the VAX-1 was built from SSI chips like the 4-bit 74181 ALU. The VAX.

Anyway I had several excellent books on programming style written by Henry Ledgard. He despaired of making C look readable. I commend his books which are so old that the code is UPPERCASE A lot of he wrote had to do with program design, naming things, writing good comments and that the visual shape of a program assists mental clarity.

I guess that people recommend it for the amount of things one needs to know properly before doing anything useful. I like it, but understand the dangers of it and cannot appreciate outside of the embedded, compiler, kernel space for which it is used so much.

What would be your thoughts on a very first language that can teach people about memory management etc?

Not going against what you said btw, you bring good points, sadly I cannot provide much imput since the only thing i have ever built with C was a small interpreter that was above and beyond shitty.

Is this related to weekly rant?

I'm not convinced C is a good first language, because you end up caring a bit too much about the mechanics of the computer and a bit too less about the programming/algorithm/whatever which imo are far more important for a first course. It's not really illuminating for beginners. And as it is the "low level" (it really isn't) view that C exposes is an abstraction that leaks like a colander.

It is however an absolutely vital language to know because of said mechanics (can substitute with Rust etc. as per taste).

@RememberMe that's why. Because you have to care about mechanics. That's the damn point!

@iiii you can either learn the logic side first and then learn how the hardware does stuff, or the other way round, it doesn't actually matter for competence. But to somebody just starting out, I think it's a waste to start off by going from the low level/comp arch side. It's the difference between *computing* and *computers*.

Of course it's important and everybody should have had some training on how stuff actually works. My point is for the vast majority of people it probably shouldn't be the *first* thing they learn.

@RememberMe I think it does matter. If you learn just high level algorithms first you might also learn a lot of wrong ways to do everything because you was not focused on mechanics. Mechanics are the basics, algorithms aren't the basics. If you break order it most probably will cause problems

@iiii I disagree, because
1. My point is for a *first* course. Go in as deep as you want in later courses. Assuming a 3 or 4 year degree, I'm talking about the kind of Intro to Programming course you'd have in literally the first semester when you don't even know how to add numbers or repeat something via a loop. If we're talking about self learning, this is the kind of thing you might follow online tutorials for on your own when you're starting off. Sure you could have started off from doing low level stuff and hurrah for people who have. I'll contend that it's not all that different from starting off with say JS or Python. If you've got the basics down, it doesn't matter how.

2. People's brains don't shut down after their first introduction to programming. Learning the craft is a multi-year process and by far the most important thing to learn is the basics, which is rooted in logic. You can pick up anything after that depending on the direction you're going into. Said "bad habits" (which really are just abstraction domains manifested) are quite easily unlearned. I've seen web devs zip through a course on making file systems in C, EE undergrads doing cloud app dev in Java, ex app devs working in OS dev, and type theorists writing hardcore Verilog for high performance FPGA work. All possible.

@iiii @RememberMe in regards to the idea that learning about the mechanics might derive away from algorithmic thinking. I think that gap is breached nicely by C. Think of the K&C book, it introduces various concepts early on, and a lot of courses utilize C or C++ in this regard (building simple trees and linked lists etc) because one can comfortably focus on the algorithm and the design.

I did not learn C as my first language, but it was within one of my uni level classes. Some of the people in that class had taken the introductory course in Python, C hit them like a train, they were used to thinking in terms of algorithms with all the facilities that Python contains, but oh boy was seeing them struggle with a basic linked list painful as all hell.

@AleCx04 that's what I meant. Just plain algorithms won't do without also the mechanics of the said algorithms. They shall be together.

@AleCx04 sure - they struggle and they learn it, and now they have both algorithmic thinking and mechanics down. I never said it was easy or that by learning algorithmic thinking you magically learn how computers work. You need both. That was never in question. The question was, which one first?

When I came here for masters so many people in my batch had 0 experience with C. Oh boy did they struggle in that first introductory systems course. But they learnt and got through it and now they're zipping along with systems stuff. It's not terribly complicated especially once you're used to applying logic to solve stuff.

The really difficult things in our field would be difficult no matter which language you use or how you started.

@RememberMe people's brains don't shut down, but the thing you learn first have much better roots than the one which should be replacing it. Delearning bad habits is harder than just not learning them in the first place.

@iiii I don't really agree, but even so, I'd much rather people have experience with algorithmic thinking than some weird half assed view of how computers work but can't actually do much with them. Logic is eternal, it applies everywhere regardless of the system or the environment. Being rooted in algorithmic thinking makes you enormously flexible and capable at actually doing things or just enjoying the craft.

Again, you need both. But first, computing. Then computers.

Ideally even I'd say you learn both at the same time but since we're talking about establishing an order here, my vote goes to thinking rather than implementation.

@RememberMe whatever. You don't seem to be open for conversation anyway. There's no point in continuing.

@iiii sorry about that, I actually just spent all day arguing this out for some course design work. In case it felt like I was pulling that opinion out of my ass, it's from assisting with introductory programming, systems, and comp arch classes. The algorithmic-first approach just seems to work better (and it works very well indeed), even though these folks go on to do hardcore systems courses in C and stuff. Besides, they make cool, tangible stuff when learning programming for the first time, which is always really nice to see.

@RememberMe I see how that can be easier for newbie to give them a thing that "just works" but I fail to see benefits in the long run. Sure, some can retrofit their knowledge and adapt to fundamentals, but I would assume that's more of a rare case rather than a common one. People tend to stick with what they already know than with what they don't.

@30hrs Actually, it was the other way around. That poster had already opted for C as first language and wanted some general hints.

Also, C does have its unpleasant quirks, e.g. too much undefined behaviour that should better have been implementation defined.

But stuff like varying int has been solved decades ago with the C99 portable data types. The error handling is OK, and if you want exception style (which I don't recommend), you have always setjmp/longjmp. The preprocessor is actually nice if used properly.

I am not experienced with C at all, but things are finally starting to "click". After 6 years of learning Linux and starting out with bash, I do know the constructs that make up a programming language now. That being said, libcurl still fucks me up every time and the heap is something I'm outright scared of. I do not yet understand though why it is supposedly so hard to write free() right after you malloc or calloc something. As far as habits go, it looks like closing HTML tags to me. You "can" forget to do it, but it is not good style. Then an acquaintance of mine told me about all the other functions it might still be used in, and got confused again. C is hard, and the steep learning curve is (IMO) too much to ask for. Start out easy mode and gradually work your way down the rabbit hole. I wouldn't want noobs to be making their programs leak memory like a colander quite frankly. If they can only play with toys, just make them play with toys. They can join the big boys later.

Manual resource management is the point of choosing C - and I agree with @iiii that this is something good to learn from the start. I see a lot of needlessly slow stuff even in JS where it's clear that people have no idea what the code is doing under the hood. Basically because they have no idea about how computers even work.

Actually, Pascal would be a better language for starting, but the drawback is that it's dead for actual usage so that you would have to learn first Pascal and then C on top of it.

@Condor The problem isn't freeing memory in a function where you allocated it. It's when you hand around the pointers because you need that memory also elsewhere.

But for beginning, you don't even need any of that. Just use some static arrays, and you're good to go. Actually, that's also where you leave it in particular for embedded systems where you often don't want any dynamic memory handling at all.

In my opinion an easy language is a good way to start. So i would never advise C. If you like simpler stuff like python or PHP, you can grow to the other ones if you want. Or.. Write the way as suppose to in the easy languages.

Put C to dead is one of the last things i would ever say tho :P But still, my upvote for your great rant.

I think most people are on the wrong track....

A lot of programming deals with our own preference and let's say "individual compatibility" (experience / talent / thinking / individual behaviour).

C requires a certain effort. You'll dabble a lot in smaller, mundane programs usually before you go into e.g. writing larger modules / libraries, and start to gain experience in real projects. Starting with a real project is a possibility but you need to be very diligent, strong minded and hard working as you need to learn and process a vast field of knowledge - mostly in parallel.

Script languages lower the barrier - they give the "dangerous illusion" of being easier / more accessible. A bit like a venus fly trap.

While indeed most reach a deeper understanding of basic concepts first, they'll sooner or later realize that things got way too messy... I'd say it's only logical. You have a lot of possibilities to create a mess, as in most scripting languages you'll find a plethora of libraries / modules / extensions and just hot glue stuff together.

Some do it in a more planned way, others... Well. :) ;)

The outcome is clear. Most realize now that software architecture is important and start the hard road of self improvement, the rest just says fuck it and becomes a burden for everyone else.

(True independent of language, fucktards exist everywhere)

TLDR: Scripting is easier at the beginning, but you'll hit at a certain point the wall of "I didn't know what I was doing" - very hard usually. Like crash dummy hard.

In C or other higher languages you'll have it the other way around. It's challenging right from the beginning which doesn't make it easier, but due to being more challenging you usually tend to think about things in a more "careful" manner.

I think both experiences have their own merit. Programming and IT is after a certain point (except you want to do everyday the same) the process of accepting that one has to continually learn new things and adapt.

@inawhile you're not the one who does not understand how C is hard at all.

Thank you for sharing!