> A knowledgeable software developer, among other things, stays clear of these issues.

This is the "no true scotsman" fallacy.

Languages can be designed so that less than perfectly knowledgeable programmers fall into the pit of success, or they can be designed so that they fall into the pit of failure.

For people making your argument, I like to provide this challenge: Go take a flight on a 737 MAX that hasn't had its MCAS fixed/disabled. That should be fine, right? After all, no "true" pilot ought to disregard one sentence on page 437 of the flight manual that they weren't even given during a 1 hour training video. A true professional pilot memorises the engineering blueprints, the source code of the avionics, and the wiring schematics, surely. So you have nothing to fear! The plane is "safe", and pilots can be trusted to be knowledgeable.

Go buy that ticket.

> This is the "no true scotsman" fallacy.

Sorry. Not even close. Source: I actually studied Phisolophy/Logic at Uni. Good try though.

Also, your aircraft example is absolutely ridiculous.

This isn't an appeal to purity at all. This is about domain knowledge and experience.

A more appropriate example might be the contrast between someone who has only done 3D printing now deciding to design and make parts meant for CNC machining. The lack of expertise and understanding will result in some pretty serious problem.

Another example, this time about software development. I have over ten years of professional software development using Forth. Someone coming to Forth from, say, Python, is likely to make an mess until they understand how to approach problems in Forth. I also have about ten years professional coding experience using APL. Same thing. Someone coming to APL from other languages is going to run into problems until they gain enough knowledge to write APL.

> I actually studied Phisolophy/Logic at Uni. Good try though.

Appeal to authority.

PS: I studied philosophy too.

Nope. Wrong again. You should probably take that class again.

I am telling you that I evaluated your claim, I didn’t google it or ask ChatGPT.

Very funny. And also very wrong. Again.

God, this attitude reeeallllyy grinds my gears.

This is precisely why C has outstayed its welcome in so many areas of software development.

Every time some kid looking for a self-confidence boost buys into the idea that using a language with a minefield of archaically-named string manipulation functions somehow makes them a ‘real’, ‘smart’, developer, we are all left a little worse off.

No, it’s not the fault of the language’s design. It’s not even the fault of history - the fact that C was conceived at a time when security wasn’t what it is. It’s these damn kids that only know Python and JavaScript! Why can’t they be as smart as us C developers!

This is all completely ignoring the fact that in 2023 we have no shortage of string manipulation-related vulnerabilities in widely popular and supposedly battle-tested C code. All some version of the typical list completely justifiable human errors that anyone is bound to make writing C.

A language that is so popular but that so few people seem to be able to write secure code with, is not a very good language.

I’m immediately skeptical of anyone that’s not of the view that the single best thing we as an industry can do for security is to drastically reduce the amount of C code in circulation. It always comes down to “I’m set in my ways and I think I’m superhuman”.

My hope is that these modern, sensible systems programming languages successfully eat the world faster than the pool of C developers thins out, as people slowly retire, and more greenhorns clue into the fact that C is being used in more places than it ought to be.

Signed, someone that did learn C in school, and has written it professionally.

> God, this attitude reeeallllyy grinds my gears.

> ‘real’, ‘smart’, developer

It should not. And you are taking my comment completely out of context. 100% out of context. Violently out of context.

I have not even implied that this is about "real" or "smart" developers. C'mon!

This is about TWO things: Knowledge and experience. And that is IT. That's what I said.

So, pretty please, don't put words in my mouth and get all self-righteous about something you invented.

> Why can’t they be as smart as us C developers!

They can! All they have to do is learn and develop the experience base to use the tool correctly. Nobody is saying it can't be done. Again, don't put words where I did not use them.

Do you drive a car every day?

Yes?

Do you think you would do well if you got in the seat of a Formula 1 car?

Of course you would not. Because you lack knowledge and experience in the domain. You can learn. Of course you can learn. And that requires work and dedication.

Blaming the Formula 1 car for the lack of knowledge and experience of the driver is nothing less than ridiculous.

I did start with C at university, C and Scheme. We didn't go very in depth in the "defensive programming" part, especially with C. We talked a bit about safety when we were doing web and database stuff, but I think that's it. I am pretty lucky, one of my friend is in cybersecurity, another is very good with C, and there are lots of people online freely sharing their knowledge, so at least I kind of know what I don't know.

On the other hand, not everyone had that luck. I've seen a good number of people that are very good at what they do but lack more general culture. But it's hard to keep up with everything. Software is a huge world, I think already way too big for everyone to know everything. And it's not just software too, it's important to learn about business too, and maybe a bit of maths here and there isn't a bad idea, and there's also the hardware part, networking, and every day there is more and more and more.

What I mean by this is that I don't know how things were before, but today, for a lot of people that write code, it's not possible to know everything, have everything fit inside your head. In those cases, people usually start asking for more guardrails in their tools, because they're no longer manipulated only by experts. And sometimes the experts themselves ask for guardrails too. So some want tools to change, others don't want them to change, and both have a point.

On one hand, I understand that blaming the tool isn't a good attitude to have. On the other hand, my job consists in building tools for other professionals, and I feel like I have way higher standards for the tools that I produce compared to the tools that I use.

> On one hand, I understand that blaming the tool isn't a good attitude to have. On the other hand, my job consists in building tools for other professionals, and I feel like I have way higher standards for the tools that I produce compared to the tools that I use.

I think your view is of this is reasonably balanced. There is that element of someone without extensive experience not knowing what they don't know.

Well, can we blame them for that?

Thirty years ago, probably not. Today, I think the answer could be yes. A few days of time well spent web searching, reading and watching videos can bring someone from complete ignorance of a subject to having a very good starting point from which to grow. Today there's information on almost anything anyone might want to learn, free and widely available. What, generally speaking isn't widely present is the willingness and dedication to learn.

I have friends my age who stopped learning twenty years ago, maybe even sooner. They just don't care enough. Or maybe they thought they were safe and did not need to. In at least one case I know, that was a huge mistake. He started life as a field service engineer with great prospects. He never bothered to learn anything new. Today he sits in a trailer at an oil field 24/7 manually logging various pressures and temperatures multiple times a day.

I also blame the educational system for some of this. Maybe I was fortunate to have gone to school when I did. We started with assembler. Actually, machine language, raw 1's and 0's. By the time I learned C I had designed a few industrial control computers and fully coded them in assembler. The transition to C was very easy. And nobody had to tell me where the dangers were...because, coming from assembler, it was obvious.

That is a good point, we've never had so much information accessible. On the other hand, it's sometimes hard to know what actually matters. Maybe we (or I) don't know how to fully tap into its potential, but I still feel that I progress way faster when I can talk to someone that has experience. I can access their knowledge, but I can also start to see how they think, how they approach problems, how they solve them, what they value.

I've also heard that for them, it can be valuable to have someone with a fresh outlook on things. You notice things that people got used to, and most of the time things make perfect sense considering the situation, but sometimes there's an opportunity to improve things for the better.

You're right about learning, it's a lifelong process. I do think that doing this along other people helps. Sometimes working on something by yourself can be quite lonely, especially if the people around you are not that much into all of that. That kind of loops back into the discussion about tool. Blaming your environment is counterproductive, but it's still important to pick it carefully.

One could take a glance at these and easily believe that they do the right thing. I don’t think that no one would accidentally miss such a small error from time to time.

Of course, and the more experience you have the less of this will happen.

I've been writing software in over a dozen languages for over 30 years. Generally speaking, when I write code, even complex code, in any language, it just works. Not because I am something special. I have done a lot of of work across a wide range of application domains and have made my share of mistakes over the years.

Of course I make mistakes. Everyone does. Yet these mistakes. They have nothing to do with lack of domain knowledge. People who approach C without having a clue as to how memory, registers and the internals of a processor and memory system work are going to create bad code.

Blaming the language, the tools, is irrational. You can write perfectly good, safe and performant code in assembler. And boy, can assembler be a minefield in the hands of someone without experience!

Are we going to blame the processor microcode then? No, of course not.

So, there are no bad tools, no bad languages, ever? A chainsaw without hand guard is a fine tool, and the blame is on whoever got their own arm chopped?

I find that dubious, to say the least. Languages are not all equal, obviously. You can take an existing language and make it worse by removing some useful features of degrading existing ones; so why couldn't you make it better? In the case of C, its string handling has been proven time and time again to be a (collection of) footgun.

> A chainsaw without hand guard is a fine tool, and the blame is on whoever got their own arm chopped?

I think you are stretching it. Still, let's go with it.

I have done a ton of construction work in my life. From large projects at home ($200K-ish) to managing the build of a $12MM data center I designed. Because of this I have been around construction guys of all kinds and skill levels. And, of course, I have a lot of personal experience doing the work as well, from carpentry to just-about anything in a typical home or commercial project.

Anyhow, I always cringe when I see experienced construction guys work with modified tools that have had safeties removed to make the work go faster. One example of this was when I watched these guys cutting concrete blocks with a handheld grinder. They had removed the guard that typically covers half the blade. The entire blade was fully open and spinning at 10K+ RPM. When asked they said they'd been doing it this way for twenty years, it's faster, they can see the cut and control it far better. Still had all fingers.

Same is true of guys cutting framing lumber with circular saws or skillsaw's while propping-up the pieces with their bodies.

To me, someone with not even 10% of the experience they have, that was unthinkable. I would have lost fingers and limbs. I would have ended-up in the hospital almost instantly and possibly take others with me.

It's a relative term. Are the tools bad? Well, when experienced professionals can use them safely day in and out (this is their job, they've been doing it this way every day for twenty years), can we really blame the tool of I grab it and proceed to remove a finger or three?

No. Of course not. I know the American system of liability doesn't work that way, but that would be and should be 100% my fault for not having the experience necessary to approach such a thing safely.

It's the same thing, it doesn't matter if we are talking about coding, CNC machining or downhill skiing. Newbies love to blame the skis for what they did wrong, or the $150K CNC machine for crashing the $10K spindle into the table. It's never their fault. Sure.

>Do not confuse bad programming or lack of knowledge with something attributable to a language, any language.

In C everyone starts out as a "bad programmer". In other languages people are merely inexperienced.

>however, someone with deep-rooted experience in these languages who jumps into C is very likely to do some truly horrific things. The language isn't the problem, at all.

You are contradicting yourself.

> In C everyone starts out as a "bad programmer"

In everything in life one starts out as a "bad <X>". I would be a bad free diver (I'd probably kill myself).

People inexperienced in <X> lack knowledge in <X>. That is not an insult. That's just reality. One can do some pretty serious mistakes as an inexperienced Python programmer (example: async/await) or downhill skier.

It's not the language, it's lack of knowledge and experience.

It's not the ski's, it's lack of knowledge and experience.

Are we now in a culture where saying that someone is doing <X> badly because they don't have experience is an insult? OK, great. Let's blame everything else, except for lack of experience. C is the problem. Please don't use it.

It will be very interesting to watch as the "not my fault/blame everyone but me" crowd faces having justify their lack of skills with what tools like ChatGPT will evolve into. Very interesting. I guess we'll blame LLM's for not knowing <X> well enough to be hired.

Funnily, GPT-4 seems like it generates pretty bad C code but pretty good Python code.

The C code will have silly things, like bad style or `double d = malloc(sizeof(double))` (instead of `double*`), which makes it evident that its training data was full of pretty bad C code. Which makes sense since most C code out there, like on StackOverflow, is bad. Same with Bash code.

The worse quality of code available in these langs suggest to me that these langs are inherently more difficult, which means people are more likely to be bad at them.

Whether they deserve blame for that, or whether it disqualifies them as legitimate technologies, is subjective. Objectively, though, you're accepting a higher rate of failure by using them over less difficult alternatives. If "good <X>" colloquially means "<X> with high likelihood of generating desired outcomes" and "bad <X>" means "<X> with high likelihood of generating undesired outcomes", I think it's fair to call both "bad langs". ;p

> Funnily, GPT-4 seems like it generates pretty bad C code but pretty good Python code.

It's only a matter of time. And likely not a lot of time.

I asked ChatGPT to write a fast CRC-16 calculation algorithm in ARM assembler given a set of preferred registers and other constraints. I compared it to my own code, written a while back. Not too bad.

It wasn't clever about using assembler tricks experienced assembler coders understand, yet the code passed my test suite. My code was much faster because it was written with the benefit of experience that had me reaching for optimizations ChatGPT did not.

The interesting part was when I asked that it modify the code to work with a different buffer structure and be able to compute CRC-8, CRC-16 and CRC-32 with various modifiers.

It did it in just a few seconds. The code passed 100% of my tests. Not super fast or efficient, but it worked. I remember when I had to do that myself with my own code, it took over a day.

This is today, mid 2023. Give it a year or two (maybe less?) and it will be a tool to contend with. People who like to blame everything else rather than their lack of knowledge and experience will not do very well in that world.

Why would I pay someone to do <X> when they bring nothing special to the table?

Here's the huge paradigm shift (at least for me):

I could not care less what someone knows or does not know. I care about the range and breath of their experience and how they approach learning that which you do not know.

Someone like that can use any available tool, including AI tools, to deliver value in almost any domain. Someone who blames others (tools, people, the system, whatever), cannot.

We might just be entering an era in which experience will be shown to have serious value.

> Funnily, GPT-4 seems like it generates pretty bad C code but pretty good Python code.

Back when OpenAI had code-specific models based on GPT-n they were generally specifically advertised as best at Python; I suspect their coding-related training data and human feedback on coding tasks all favors Python by a significant amount (and I supect that that actually gets reinforced by positive feedback, since this makes it most likely that they get used with Python over time, too.)

:o Huh. I guess it's not a fair sampling of code out in the wild then.