6 ms·
Its 2019, there are great people with 10+ year careers who've never touched C, in school or work.
by Jedi72 7y ago
Its 2019, there are great people with 10+ year careers who've never touched C, in school or work.
- gjulianm 7y agoBut in 10 years they will have touched JavaScript, C++, C# or Java, and they will surely understand how memory works, so they should be able to read C.
- blub 7y agoDoubtful. I think web development, mobile and enterprise are the biggest development domains by headcount, and neither has to normally touch C or C++. And that's fine, why does one have to understand an ancient language when they can interact perfectly fine with machines by using Python, Swift, Java etc?
- gjulianm 7y ago> web development, mobile and enterprise That's why I included Java, C# or Javascript. If you can read those languages you can read C. And it's not the language what they need to understand. C in itself is a fairly simple language, that's why I said that any person with experience in that family of languages would be able to read it straight away. What one should understand is how the computer is doing what you ask it to do. What does "create an object" mean, what is a "reference to an object", what are the heap and the stack, etc. These are concepts that are extremely useful and, as the parent comment said, almost required to know in order to be a full programmer and be able to understand what happens when you create your programs.
- blub 7y agoAny JavaScript or C# programmer will understand the ifs, elses and fors, but that doesn't mean they'll understand what the C code does or whether it's correct - two essential aspects of reading code. I've been doing C++ for more than a decade and had two tough experiences lately: * I had to review a C project of several thousand lines. It's impossible for a human to understand if memory management is done correctly without weeks of deep analysis, so I had to resort to tools. The logic of the code is also hard to make out because of the memory bookkeeping. * I was reading the open source code of a Linux program and had to dig deep into a couple of system topics and read the documentation for half a dozen syscalls to make sense of it. For me, C is one of the hardest languages to understand, you're always zoomed in at 10x, looking at all the insignificant details of memory management, working with strings and arrays, etc.
- gjulianm 7y ago> Any JavaScript or C# programmer will understand the ifs, elses and fors, I think that's what the parent comment meant with "reading (normal) C". The language itself is simple, because it only has the ifs, elses, and fors. Of course, given the simplicity of C the projects end up being complex because they have to manage a lot of things that other languages do for the programmer, but that is outside the scope of the language (i.e., you don't need to resort to the language manual to understand it). In other words, the discussion is not that everybody should be able to dive deep into C projects and instantly know what's happening, and know all syscalls and everything. The discussion is that a programmer should know what is memory management, what is a system call, etc, which is practically synonymous to being able to read normal C.
- oblio 7y agovoid strcat( char* dest, char* src ) { while (*dest) dest++; while (*dest++ = *src++); } This is pretty much C specific. And side-effect ridden, at that :-) I doubt the average Javascript programmer will figure that bit out, at a glance.
- kazinator 7y ago> If you can read those languages you can read C. If you can read those languages, you can probably tokenize C fairly well, and parse a decent proportion of it. But only understand maybe a small fraction.
- johnr2 7y ago>And that's fine, why does one have to understand an ancient language when they can interact perfectly fine with machines by using Python, Swift, Java etc? If the interpreter or VM used by any of those languages is written in C, someone still needs to understand it. Not to mention that it doesn't hurt to understand the internals of your chosen language if you want to make the most efficient use of it.
- blub 7y agoWhere someone should be a C pro, not the local JS guy that dabbles in C and can "read" it. Doesn't hurt to know the internals, but one's time's limited and better spent on other endeavors. If I wouldn't be doing embedded I wouldn't touch C with a 3m pole, nor would I need to :) In fact my life's mostly C free nowadays and I'm quite pleased with that.
- sureaboutthis 7y agoOne of the biggest fallacies I see spread on forums is the statement that the age of a language or a program is an indication of its failings and a need to be replaced. Typically spoken by amateurs and other hobbyists.
- blub 7y agoThe future's not looking great for C, in fact it's sliding slowly but unavoidably into irrelevance. It's stopped evolving and can't really shine in any of today's domains. It will still be around for decades, but mostly as legacy. I.e: not anything which is required to be learned.
- sureaboutthis 7y agoIn the meantime, it's one of the most used languages in the world and embedded in every device you use.
- blub 7y agoYou're likely correct, but most of that code's either been written long ago and is now in maintenance mode or if it's new code it's very specialized and irrelevant for 99% of the developer population. Do I care what some internal chip fw is written in? Not really, but it's probably C and it's probably full of security vulnerabilities. Such is life. There's also those that misguidedly use C when they shouldn't (e.g to speed up Python code). It's unfortunate, but such is C's siren song - mesmerizing one with promises of speed only to be dragged into the depths of undefined behavior.
- sureaboutthis 7y agoYou are incorrect in everything you said.
- blub 7y agoWhat interesting new C projects are being developed nowadays? I'm willing to change my mind in the face of facts. Here's what I know: * AI / ML can be done in many languages, but no one's seriously considering C, despite the performance requirements. C++ is sometimes used. * self-driving companies are hiring for C++. * Mobile is Swift / Kotlin with C++ for performance-intensive code where appropriate. * Web is anything except C and C++ (thankfully) * Game development is C++ * The enterprise has switched to web technologies or is still using Java/.net. * The desktop varies, but it's mostly .net / Swift + Obj-C / C++, with the exception of gnome perhaps, which I'd argue is an anomaly. C is still holding on in kernels and low level embedded, where it's expected that C++ and maybe Rust will continue to squeeze it. Personally I don't care that much about the above two. Banging the same bits for decades gets tiresome.
- kazinator 7y agoBecause (1) those are written in that ancient language, so you're not a complete engineer if you don't understand the workings of your tool, and those tools come with disclaimers which make every issue your fault. (2) integration with tons of C libraries or libraries with C API's is a reality.
- kccqzy 7y agoIf a programmer doesn't even have any curiosity to understand what's beneath their abstractions and how things really work behind the scenes in 10+ years, I wouldn't call them "great" at all. They may be productive, but still a mediocre hacker.
- ernst_klim 7y ago>understand what's beneath their abstractions C has nothing to do with this. C is a quirky old high-level language which has nothing to do with underlying abstractions, i.e. with how the machine works. If you want to learn what's beneath, you open a machine manual and read it.
- kazinator 7y agoThey have no debugging skills worth a damn. If a problem occurs in a tool or library they are using at a level below what they are used to, they need help. They are not complete engineers. You have to be a complete engineer because you take full responsibility for what you're doing. All your tools carry disclaimers in their licenses which absolve them of any responsibility if something goes wrong. for LANG in Python, Ruby, Rust, Java, ... : If $LANG has a bug, and because of that your $LANG program causes some harm to the customer's data, you can't blame $LANG. If I'm in a situation that I'm somehow required to do something with Python, and something goes wrong, I can debug it right into the Python internals. If the problem is with how GCC compiled $LANG, I can debug that too, and I can drop to the machine level if needed