General > General Technical Chat
How many people code in C these days, and if so, why?
Cerebus:
--- Quote from: Siwastaja on May 10, 2020, 07:17:23 am ---That's why Python isn't used for mission-critical embedded work, but C is, despite its undeniable shortcomings, even regarding safety.
--- End quote ---
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:
--- Quote from: IanB on May 10, 2020, 01:14:05 am ---
--- Code: --- if ("not empty")
printf("The string is not empty\n");
if ("")
printf("The string is empty\n");
--- End code ---
--- End quote ---
(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:
--- Quote from: intmpe on May 10, 2020, 03:48:15 am ---
--- Quote from: Cerebus on May 10, 2020, 01:46:46 am ---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.
--- End quote ---
There is actually not. Universities are businesses. They say at business school that engineers make the worst business people. This response proves it.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
I'm not the one that contends that academe has not produced a good programming language.
IanB:
--- Quote from: Cerebus on May 10, 2020, 08:13:14 am ---Look, if you're going to carp at someone at least read what they wrote before you carp on about it.
--- End quote ---
I did read what you wrote. Maybe you could do me the honour of also reading what I wrote?
--- Quote ---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.
--- End quote ---
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:
--- Quote from: Siwastaja on May 10, 2020, 08:33:29 am ---Are you really, like seriously, claiming that this usage pattern would be a source of bugs or unsafe behavior?
--- End quote ---
No, I am simply demonstrating facts about the C language, after Cerebus stated a bunch of incorrect facts.
--- Quote ---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.
--- End quote ---
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:
--- Quote from: IanB on May 10, 2020, 01:14:05 am ---This is canonical C, and is how the language is designed to be used, keeping it brief without unnecessary operations or verbosity.
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version