How many people code in C these days, and if so, why?

[Cerebus]

Computing Science has failed to make a decent programming language.
Every language is intellectually orgasmic and the academics circle jerk off to them, but all fizzle out after many years, and then yet another language is born and the cycle repeats.

C is just a high-level assembly language, extremely dangerous because it really checks for nothing. Think of the all PC Trojans, viruses exe'd due to buffer overflows.
My CompSci Uni prof spent two weeks in class pissing around with pointers in C, seeing what would happen with "funky" de-referencing. It's worse than the Wild West.
Unfortunately C has made it to cars, airplances and other safety-critical applications for embedded systems. It's just too dangerous IMHO.

Just the other day I stumbled onto this:

Code: [Select]

boolean myFlag;

myFlag = 2;
myFlag = "A";
myFlag = 3.14159;

All of which of course compiles and runs in C. Absolute GARBAGE

Except of course it doesn't compile and, indeed, isn't C.

Code: [Select]

void FLoobiesAssertionIsThatThisWillCompileInC ()
{
    boolean myFlag;

    myFlag = 2;
    myFlag = "A";
    myFlag = 3.14159;
}

Which, if compiled, will yield this:

Code: [Select]

cerebus@shu:~/Desktop$ gcc-9 flooby.c
flooby.c: In function 'FLoobiesAssertionIsThatThisWillCompileInC':
flooby.c:3:5: error: unknown type name 'boolean'
    3 |     boolean myFlag;
      |     ^~~~~~~
flooby.c:6:12: warning: assignment to 'int' from 'char *' makes integer from pointer without a cast [-Wint-conversion]
    6 |     myFlag = "A";
      |            ^
cerebus@shu:~/Desktop$

C does not have a boolean type. A C compiler will definitely complain if you try to assign a string  (char *) to a non-string type. Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs.

If you're going to rant about a language a prerequisite is to know the language well enough to know whether you're ranting about the language or ranting about what you imagine the language is.

[Wolfgang]

Computing Science has failed to make a decent programming language.
Every language is intellectually orgasmic and the academics circle jerk off to them, but all fizzle out after many years, and then yet another language is born and the cycle repeats.

C is just a high-level assembly language, extremely dangerous because it really checks for nothing. Think of the all PC Trojans, viruses exe'd due to buffer overflows.
My CompSci Uni prof spent two weeks in class pissing around with pointers in C, seeing what would happen with "funky" de-referencing. It's worse than the Wild West.
Unfortunately C has made it to cars, airplances and other safety-critical applications for embedded systems. It's just too dangerous IMHO.

Just the other day I stumbled onto this:

Code: [Select]

boolean myFlag;

myFlag = 2;
myFlag = "A";
myFlag = 3.14159;

All of which of course compiles and runs in C. Absolute GARBAGE

Except of course it doesn't compile and, indeed, isn't C.

Code: [Select]

void FLoobiesAssertionIsThatThisWillCompileInC ()
{
    boolean myFlag;

    myFlag = 2;
    myFlag = "A";
    myFlag = 3.14159;
}

Which, if compiled, will yield this:

Code: [Select]

cerebus@shu:~/Desktop$ gcc-9 flooby.c
flooby.c: In function 'FLoobiesAssertionIsThatThisWillCompileInC':
flooby.c:3:5: error: unknown type name 'boolean'
    3 |     boolean myFlag;
      |     ^~~~~~~
flooby.c:6:12: warning: assignment to 'int' from 'char *' makes integer from pointer without a cast [-Wint-conversion]
    6 |     myFlag = "A";
      |            ^
cerebus@shu:~/Desktop$

C does not have a boolean type. A C compiler will definitely complain if you try to assign a string  (char *) to a non-string type. Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs.

If you're going to rant about a language a prerequisite is to know the language well enough to know whether you're ranting about the language or ranting about what you imagine the language is.

C is for users who know what they are doing and who can write code in a safe and defensive way.
There is very little "shoot yourself in the foot" protection, agreed. The dirty minds should therefore play with something else ...

[intmpe]

Huh? Are you new here?  This place is all about broad assumptions and generalizations and unsupported opinion

+1 thats because we are really talking about programming and as I was taught in school many years ago its as much an Art as it is a Science. It is not engineering, despite the fact that everyone who reads a book at barns and noble for that .net job gets called a software engineer. Its like your local HR getting renamed a Human Factors Engineer. For the majority of programmers it was just as hard in 1985 trying to extract every clock cycle out of a commodore 64 via assembler - probably harder because there was just a lot less access to information - and many of those who did it were kids. I wouldn't be surprised if the best python programmers out there today are kids via things like the PI.

[IanB]

C does not have a boolean type.

Why do you say this? Which C standard are you considering?

A C compiler will definitely complain if you try to assign a string  (char *) to a non-string type.

It will?

I just compiled this using my friendly local C compiler, and there were no warnings:

Code: [Select]

#include <stdio.h>

int main(void)
{
    _Bool flag;

    flag = 2;
    flag = "A";
    flag = 3.14159;

    printf("flag = %d", flag);

    return 0;
}

When I run it, it produces the output "flag = 1": the C language defines any non-zero value as true, and true is represented as 1. So the non-zero double is down-cast to a _Bool type and becomes 1.

[coppice]

C does not have a boolean type.

Why do you say this? Which C standard are you considering?

C has a boolean type, but the keyword for it is not "boolean" like the example code being referred to.

[IanB]

For interest.

Exhibit 1:

Code: [Select]

#include <stdio.h>

int main(void)
{
if ("not empty")
{
printf("The string is not empty\n");
}

if ("")
{
printf("The string is empty\n");
}

return 0;
}

Exhibit 2:

Code: [Select]

#include <stdio.h>

int main(void)
{
_Bool empty1 = "not empty";
_Bool empty2 = "";

if (empty1)
{
printf("The string is not empty\n");
}

if (empty2)
{
printf("The string is empty\n");
}

return 0;
}

Both produce the same output:

Code: [Select]

The string is not empty
The string is empty

This is canonical C, and is how the language is designed to be used, keeping it brief without unnecessary operations or verbosity.

[Cerebus]

C does not have a boolean type.

Why do you say this? Which C standard are you considering?

C has a boolean type, but the keyword for it is not "boolean" like the example code being referred to.

Presactly.

[IanB]

C has a boolean type, but the keyword for it is not "boolean" like the example code being referred to.

Presactly.

Frankly, this is at the level of a playground argument: "You didn't use proper grammar, so you're wrong! So there!"

I thought we were meant to be adults here?

[intmpe]

C does not have a boolean type. A C compiler will definitely complain if you try to assign a string  (char *) to a non-string type. Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs.

If you're going to rant about a language a prerequisite is to know the language well enough to know whether you're ranting about the language or ranting about what you imagine the language is.

Be careful with that though because back then these large US corporations with operations like Bell used to run like college campuses where a big part of your job was to publish or patent. I worked at Bell labs in NJ 10 years ago. It was half deserted and they were preparing the coffin for it out the front. When K&R wrote C in the late 70's was like the end of that whole era - so it was coming to an end then. You could say the same thing about a lot of US engineering companies. I earlier worked at GE research labs and it was a gloomy place just waiting for someone to drop and axe and write a requiem. They had gotten out of electronics 20 years earlier and had announced internally they would never ever under any circumstance re-enter the field. Profits were dead - they had gone to Japan/HK/TW by the late 70's. Now its China - its been china since the 90's. I was in Japan 20 years ago and could hardly find an appliance made in Japan. It was all coming out of China even then. And now its leaving China slowly even as they have been gearing up - although I suspect they are slowing that spending spree - they already have all the tech they need. At Motorola they used to call that part of the company Motorola University internally and it was a basic research arm. All of it died about 20 years ago - Motorola being one of the last. GE kept the campus open but the allowable work was shit and depressing. Short story is that time period is over, dead and buried. Even at Universities today you would be hard up to do what K&R did because you need to publish fast. Long term projects don't cut it anymore so you get a constant stream of published garbage. Both Universities and Industry are in trouble. Like I said - I did a US masters just for fun - it was complete shit - not even Masters level IMO. Good school. Mostly taught by adjuncts or even professors who could not give a shit about feedback. Even before this virus thing the only time they ever had was to throw your marks on a web page. Usually with no explanation. So its the worst degree I ever did. What was really hilarious was my colleague did a chip at one of the best public unis in the US using the same tool and the same fab company and process that I did 25 years ago as a 3rd year undergraduate. The difference? I actually had it fabed and went in to put it under the microscope when part of it had a problem. What did he get? Nada - they went through the process of the chip design and layout to the point of preparing the package for fab but the school did not actually spend the money to have it fabed. So that's my experience of US universities.

You want to work in a university like research environment in industry now? - I don't know of any US companies but Toyota Research Labs was pretty good and I was getting called by the basic sciences group at Huawei a few months back. It's always where the money, brains and leadership is, and no US company that I know has that. It's all run by private equity and wall street so their view is only a few years at most ahead.

K&R were lucky - they just made the end of the University like heyday at Bell. Assuming the building still stands if you walk into the lobby at Bell the walls are covered with patents from the 50's and 60's. The walls are 50's paneled walnut straight out of an episode of perry mason.

[Cerebus]

C has a boolean type, but the keyword for it is not "boolean" like the example code being referred to.

Presactly.

Frankly, this is at the level of a playground argument: "You didn't use proper grammar, so you're wrong! So there!"

I thought we were meant to be adults here?

There was rather more flawed in the argument put forth than just the spelling of a type name.

[Cerebus]

Be careful with that though because back then these large US corporations with operations like Bell used to run like college campuses ... etc

There is a huge difference between a commercial R&D facility, even ones as freewheeling as Bell Labs or PARC, and academia. The ongoing development of C & UNIX had to be justified at some point by a commercial aim, specifically the pretext used was to to produce a text processing system for the Bell Labs patent processing office. They might be ideas factories, but they are ideas factories that are expected to produce something that works at the end of the day driven by very different forces than academe.

[IanB]

There was rather more flawed in the argument put forth than just the spelling of a type name.

Yes, but so far you have not presented any of those flaws. So your objections are not supported by evidence.

[intmpe]

There is a huge difference between a commercial R&D facility, even ones as freewheeling as Bell Labs or PARC, and academia. The ongoing development of C & UNIX had to be justified at some point by a commercial aim, specifically the pretext used was to to produce a text processing system for the Bell Labs patent processing office. They might be ideas factories, but they are ideas factories that are expected to produce something that works at the end of the day driven by very different forces than academe.

There is actually not. Universities are businesses. They say at business school that engineers make the worst business people. This response proves it. Basic, Pascal, Minix, Linux, GNU, Netscape all came out of non-commercial activities. Even the Win3.1 TCP/IP stack that got everyone on the internet was non commercial.

If one were to be more correct then its the old addage necessity is the mother of invention. Managers and hence companies are by their nature non innovative and non-creative. If you want to find the most non-creative person in a company - go to the c-suite. When I was in GE research labs we had one of the luminaries come back in. He effectively lectured the managers that while they may want something NEVER pre-define the research outcome because if you do you will get nothing. And so it was. Good researchers will deliver output - I have never not delivered - but its not always what they want. What they want is not always possible. i.e. cost.

[Siwastaja]

Frankly, this is at the level of a playground argument: "You didn't use proper grammar, so you're wrong! So there!"

No, it just showed that the person who made that argument has actually used C very little, not even in the sense of reading other's code. For anyone working with C (hence being able to make an informed statement about its suitability) that piece of code would immediately strike as "not C".

It's an important distinction when someone "proves" C is shit by using a very short example of just a few lines, which obviously isn't C, claiming it "of course" goes through a compiler, which it obviously doesn't:

Code: [Select]

hrst@jorma ~ $ gcc test.c
test.c: In function ‘main’:
test.c:6:5: error: unknown type name ‘boolean’
     boolean myFlag;
     ^
test.c:9:12: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
     myFlag = "A";

If they had thought this over, the example would make the point. Now it's a piece of code which is neither C, nor showing any meaningful point even if corrected to be C. If anything, it demonstrates type safety on any compiler I tried (different clang and gcc versions; no extra flags necessary) by issuing warnings about the strange type conversions performed by the programmer (and hence, suggesting more explicit proof, in form of explicit cast, that the assignment is intentional.) Many modern languages would accept the equivalent series of statements, not only without any warnings, but performing "something probably useful", and worst, this would not be an example how not to do it, but an example how to do it.

All in all, even if adjusted to go through compiler, the example showing the implicit type conversions of the boolean type is funny in this context, because compared to most modern contenders (such as Python), C is more strongly typed, and from this viewpoint, more safe. If they wanted to show an example of C being unsafe, out-of-bounds indexing, or missing a zero termination on a string, would be classics, or using one of the many dangerous classic C standard library functions (such as sprintf) people still use out of convention.

The general direction seems to be: implement less and less type enforcement, and do more and more silent type conversion, for convenience, for beginners. Which, obviously, is dangerous even if it is convenient. Operations don't make sense when you don't know what the operands represent, and when the representation suddenly changes between adjacent operations.

But it's always trendy - have been for dedaces - to circle jerk around C's extreme level of dangerousness, and claim that modern alternatives are magically much more safer. This is naturally not the complete picture. C indeed lacks many "safety features", and has some dangerous design choices, but strict(er) typing (compared to most trending languages, that is), which is optionally bypassable with clear and explicit syntax, seems quite a good mix between safety and performance. It could be better, even in C you have implicit type conversions happening when you least expect it, allowing for a footgun of a sort, but it's still a lot better than having no type enforcement at all. (It always strikes me funny how people who show C isn't type-safe enough, offer the solution of removing type-safety completely.)

C has never been academically trendy because it isn't pure, all sides of it lack something. Yet it seems to be "good enough", and the contenders come and go, struggling, often trying to be too pedantic and losing the big picture.

Python's typing is handy, just type some letters from the keyboard without thinking, and it guesses the intent, and does fairly good job on it: when you test the code, it likely does what you wanted. For safety, relying on such luck element is an utter catastrophe (especially when the runtime can change its decision with a different version). The fact that a type is not only dependent on the code, but also the runtime data content (I remember struggling with this with PHP in 2002), is a safety disaster and it's very hard to get 100% test coverage.

That's why Python isn't used for mission-critical embedded work, but C is, despite its undeniable shortcomings, even regarding safety.

[Cerebus]

There was rather more flawed in the argument put forth than just the spelling of a type name.

Yes, but so far you have not presented any of those flaws. So your objections are not supported by evidence.

Look, if you're going to carp at someone at least read what they wrote before you carp on about it.

Computing Science has failed to make a decent programming language.
Every language is intellectually orgasmic and the academics circle jerk off to them, but all fizzle out after many years, and then yet another language is born and the cycle repeats.

C is just a high-level assembly language, extremely dangerous because it really checks for nothing. Think of the all PC Trojans, viruses exe'd due to buffer overflows.
My CompSci Uni prof spent two weeks in class pissing around with pointers in C, seeing what would happen with "funky" de-referencing. It's worse than the Wild West.
Unfortunately C has made it to cars, airplances and other safety-critical applications for embedded systems. It's just too dangerous IMHO.

Just the other day I stumbled onto this:

Code: [Select]

boolean myFlag;

myFlag = 2;
myFlag = "A";
myFlag = 3.14159;

All of which of course compiles and runs in C. Absolute GARBAGE

Except of course it doesn't compile and, indeed, isn't C.

< Fully formed example code and compiler output elided. >

C does not have a boolean type. A C compiler will definitely complain if you try to assign a string  (char *) to a non-string type. Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs.

If you're going to rant about a language a prerequisite is to know the language well enough to know whether you're ranting about the language or ranting about what you imagine the language is.

Just to make it easier for you, let me re-present the points you missed as a numbered list:

• Except of course it doesn't compile  - refers to "All of which of course compiles and runs ".
• C does not have a boolean type. - refers to "boolean myFlag;". Yes, I could have been clearer and used quote marks here - my bad.
• A C compiler will definitely complain if you try to assign a string  (char *) to a non-string type. Refers to "myFlag = "A";"
• Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. Refers to ""myFlag = 3.14159;
• And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs. If you can't work out what bit this refers to without hand-holding, god help you.

If you want to cast aspersions about "playground level" arguments, I think "I disagree with what you said, but I couldn't be bothered to actually read it." definitely qualifies for tarring with that brush.

[Cerebus]

That's why Python isn't used for mission-critical embedded work, but C is, despite its undeniable shortcomings, even regarding safety.

If you delete "embedded" from that sentence it is wrong. I spent most of last year fighting with a mission critical system written in Python that very definitely had the capability of bringing the internal and public facing network of a certain FTSE 100 company to its knees if it didn't work properly. Not a great choice of implementation language for the task it was performing, IMHO. Still, I got paid stupid money to fix it, so who am I to complain?

[Siwastaja]

Code: [Select]

if ("not empty")
printf("The string is not empty\n");

if ("")
printf("The string is empty\n");


(insignificant lines truncated by me)

Are you really, like seriously, claiming that this usage pattern would be a source of bugs or unsafe behavior?

All I see is a demonstration of a trap for very young players, total noobs coming "backwards" to C from Python or similar, when they are learning for the first day or so, assuming they have a high-level string datatype available.

No one is claiming that C is an easy, learn-in-a-day scripting language. It obviously requires learning and understanding, like most things in engineering, especially safety-critical.

But this is exactly the point of using C, being closer to the hardware. If such operations would be automatically converted to string comparison operations, string length calculations, ascii/unicode-to-boolean operations (are you expecting strings "true", "false", or what??) or whatever, you
1) would have absolutely no idea what's happening exactly, and what the exact result will be,
2) would have absolutely no idea about the consequences in runtime or memory usage, all of which is relevant not only on microcontrollers, but on higher-level system design as well.

Having all this specified formally would result in a massive standard no one could ever read let alone remember key parts of - even the C standard is quite daunting. This is a no-go for robust engineering. Hence, more "advanced" languages are based on hope, luck, and testing, which is great for productivity in "quick demonstrations", but do not produce robust and safe software, even if the languages would prevent overindexing.

It's quite revealing that you haven't even tried to specify what you would expect as a result from these code patterns, and why. Do you really think that "" should just silently equal to false, and "not empty" should silently equal to true, and why in the world is that? Is there a language with this kind of assumption, tell me because I really don't know? Or do you expect the compiler to pull in an AI module, trying to figure out the meaning of the human-language strings, like "Trump is an idiot" equaling true, and "Trump is great" equaling false?

[Cerebus]

There is a huge difference between a commercial R&D facility, even ones as freewheeling as Bell Labs or PARC, and academia. The ongoing development of C & UNIX had to be justified at some point by a commercial aim, specifically the pretext used was to to produce a text processing system for the Bell Labs patent processing office. They might be ideas factories, but they are ideas factories that are expected to produce something that works at the end of the day driven by very different forces than academe.

There is actually not. Universities are businesses. They say at business school that engineers make the worst business people. This response proves it.

Well, the first business that I was one of the 3 on the senior management team in the 90s went from zero to a profitable turnover of £6 million in its first year, so yeah, engineers clearly make terrible business people - I'm living proof!

Before you launch off making sweeping and somewhat ad homiem remarks on here, it's wise to consider that there's a lot of folks on here who've been around the block more than once or twice. What next, telling Win that he knows nothing about writing textbooks? Also, using "business school" as support for an argument is likely to draw hollow laughs out of anyone here who has encountered the output of "business schools" in real life. Hint: Most of them need assistance tying their own shoelaces.

Moreover, the idea that Universities are (or ought to be) businesses is more telling of a certain mindset than it is an accurate description of Universities. They are supposed to be institutes of learning and research.

Basic, Pascal, Minix, Linux, GNU, Netscape all came out of non-commercial activities. Even the Win3.1 TCP/IP stack that got everyone on the internet was non commercial.

If one were to be more correct then its the old addage necessity is the mother of invention. Managers and hence companies are by their nature non innovative and non-creative. If you want to find the most non-creative person in a company - go to the c-suite. When I was in GE research labs we had one of the luminaries come back in. He effectively lectured the managers that while they may want something NEVER pre-define the research outcome because if you do you will get nothing. And so it was. Good researchers will deliver output - I have never not delivered - but its not always what they want. What they want is not always possible. i.e. cost.

I'm not the one that contends that academe has not produced a good programming language.

[IanB]

Look, if you're going to carp at someone at least read what they wrote before you carp on about it.

I did read what you wrote. Maybe you could do me the honour of also reading what I wrote?

Just to make it easier for you, let me re-present the points you missed as a numbered list:

• Except of course it doesn't compile  - refers to "All of which of course compiles and runs ".
• C does not have a boolean type. - refers to "boolean myFlag;". Yes, I could have been clearer and used quote marks here - my bad.
• A C compiler will definitely complain if you try to assign a string  (char *) to a non-string type. Refers to "myFlag = "A";"
• Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. Refers to ""myFlag = 3.14159;
• And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs. If you can't work out what bit this refers to without hand-holding, god help you.

If you want to cast aspersions about "playground level" arguments, I think "I disagree with what you said, but I couldn't be bothered to actually read it." definitely qualifies for tarring with that brush.

I didn't miss your points. I just declined to get into an argument about them.

But since you press the issue, let me respond to your list:

You said it doesn't compile--it does.
You said it isn't C--it is.
You said C doesn't have a boolean type--it does.
You said C will definitely complain if you assign a string to a non-string type--it doesn't here.

I demonstrated all of these truths above in post #204.

I do not accept the conclusion that this means C is garbage, however. The language has good reasons for behaving the way it does.

But nevertheless the only mistake made by floobydust was failing to use the correct type specifier for a boolean. Like I said, a simple grammatical error.

[IanB]

Are you really, like seriously, claiming that this usage pattern would be a source of bugs or unsafe behavior?

No, I am simply demonstrating facts about the C language, after Cerebus stated a bunch of incorrect facts.

It's quite revealing that you haven't even tried to specify what you would expect as a result from these code patterns, and why.

Why would I need to specify such? It's part of how C works. A non-zero value evaluates to true in a conditional (boolean) sense, and a zero value evaluates to false.

This applies to all values, be they integers, doubles, pointers, chars, whatever. Therefore if you assign a value to a boolean variable, it will evaluate to true or false according to this rule. There is no reason for the compiler to barf or issue a warning about it.

As I said in the post you quoted:

This is canonical C, and is how the language is designed to be used, keeping it brief without unnecessary operations or verbosity.

[Picuino]

All of which of course compiles and runs in C. Absolute GARBAGE I hate dealing with this language, it needs to have some fixes that don't go all nutbar into C++ polymorphism, operator overloading etc. but people have given up and now it's Python as the latest fad language. Sigh.

That's the reason why I thought in the 90s that Pascal would become a more used language than C.
But in the end, C has remained a first-rate language, while Pascal or ADA hardly has a niche.

[Cerebus]

Are you really, like seriously, claiming that this usage pattern would be a source of bugs or unsafe behavior?

No, I am simply demonstrating facts about the C language, after Cerebus stated a bunch of incorrect facts.

To me it just looks like you're just out looking for an argument, not the first time recently that I've noticed that in your posts. Time to hit "ignore thread", at least for me.

[bd139]

Have to side with Cerebus here. The argument was void (excuse the pun).

[IanB]

To me it just looks like you're just out looking for an argument, not the first time recently that I've noticed that in your posts. Time to hit "ignore thread", at least for me.

I told you I was disinclined to argue and you accused me of not reading your posts. You ask me to address your points, and when I do you simply ignore what I present and accuse me of looking for an argument.

[IanB]

Have to side with Cerebus here. The argument was void (excuse the pun).

I showed in post #204 that the example program is perfectly valid C that compiles and runs without warning, entirely in contradiction to what Cerebus said.

It received no response whatsoever.

Apparently facts are unpalatable when they are contrary to people's emotional beliefs.