General > General Technical Chat

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

<< < (43/99) > >>

Cerebus:

--- Quote from: intmpe on May 10, 2020, 01:25:51 am ---
Be careful with that though because back then these large US corporations with operations like Bell used to run like college campuses ... etc

--- End quote ---

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:

--- Quote from: Cerebus on May 10, 2020, 01:32:58 am ---There was rather more flawed in the argument put forth than just the spelling of a type name.

--- End quote ---

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

intmpe:

--- 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. 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:

--- Quote from: IanB on May 10, 2020, 01:20:48 am ---Frankly, this is at the level of a playground argument: "You didn't use proper grammar, so you're wrong! So there!"

--- End quote ---

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: ---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";

--- End code ---

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:

--- Quote from: IanB on May 10, 2020, 02:12:01 am ---
--- Quote from: Cerebus on May 10, 2020, 01:32:58 am ---There was rather more flawed in the argument put forth than just the spelling of a type name.

--- End quote ---

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

--- End quote ---

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


--- Quote from: Cerebus on May 10, 2020, 12:38:34 am ---
--- Quote from: floobydust on May 09, 2020, 11:23:33 pm ---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: ---boolean myFlag;

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

--- End code ---

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

--- End quote ---

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.

--- End 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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod