3 ms·

You can't learn C in an afternoon.

AlotOfReading 8y ago
You can absolutely learn the syntax of C in an afternoon, or a few days at worst, if you're not having to learn to all the other concepts interesting C programs require. Much of the immense learning curve comes from th things that are "outside C", like how to synthesize high level concepts from the lower level primitives in the core language and system specific gotchas the language doesn't shield you from.
- zbentley 8y ago
  > You can absolutely learn the syntax of C in an afternoon, or a few days at worst That depends on what you mean by "learn". Learn it well enough to make something that works for you, on your architecture, with your toolchain? Sure. Learn it well enough to know which combinations of the syntax you (thought you fully) learned trigger undefined and wildly variable behavior in the wild or when run with other libraries/build environments? Hell no. And bugs caused by that stuff are distressingly common. That's not a "system specific gotcha". It's a huge area of skill-requiring behavior that arises directly within the core syntax of the language. Saying "you can learn C in a weekend" is like saying "you can learn to drive a car in a weekend" in reference to learning how to maneuver a car alone in a big empty parking lot. Technically true, but it'll leave you woefully unprepared for operating that car the way almost everyone wants to: around other cars, in more complicated contexts, subject to many more unpredictable factors (other people).
  - chungy 8y ago
    "Learn C in a weekend" (or afternoon) is akin to getting accustomed to a new model of car, _with prior driving experience_. Each car has its own quirks, each programming language has its quirks. Learning C from the background of already knowing how to program is like driving a new Ford Focus off the lot and getting used to it. Learning C++, on the other hand... is expecting you to pilot a jumbo jet after your only experience was the Ford Focus.
    - kqr 8y ago
      > "Learn C in a weekend" (or afternoon) is akin to getting accustomed to a new model of car, _with prior driving experience_. ...in an empty parking lot, sure. C brings a whole host of old issues to the table that you simply do not get to experience in other languages. C is deceptively easy to think you know, but I have yet to see evidence of someone actually using it responsibly.
- waynecochran 8y ago
  You don't really know a language until you've program with it awhile. You are not going to write many significant programs in 24 hours.
- gaius 8y ago
  You can absolutely learn the syntax of C in an afternoon, or a few days at worst, if you're not having to learn to all the other concepts interesting C programs require. It is the same with any reasonably serious language. I mean you can learn Python syntax in an afternoon but it will be 6 months before you can use NumPy (and friends) without spending more time poring through the documentation than actual coding. Same with Java, C++, .NET, to be productive you must internalize a vast ecosystem and if you aren't doing it every (working) day then skill fade is very real.
- Too 8y ago
  A big problem of learning any programming language "in an afternoon" is dodging all the cargo-cult bad advise on the internet. If you know what's bad advice it's easy but when you start from 0, any tutorial looks equally legit and you might end up a week in a rabbit hole that is more destructive than productive. An experienced programmer knows when to stop googling, when to use classes from the standard library and when to roll your own algorithm. A beginner does not and can easily start writing their own timezone-handling class or spend a day finding and configuring a package on npm that could be written in 3 lines yourself. So in hindsight it feels like you should have been able to learn all this in an afternoon, but the road there is actually tougher than you remember.
developer2 8y ago
To use an old meme: "One does not simply learn C". Instead, one learns: 1. Everyday C syntax. It's not strictly required to learn every esoteric and historical thing about the language; if you go down that rabbit hole, you'll be down there for years. 2. How to properly structure and organize code and header files. It takes a little while to understand exactly what goes into a header file (and why), how to anticipate and avoid problems like cyclical include dependencies, etc. 3. Data structures and algorithms. While not a feature of the language itself, most projects are going to need non-trivial data structures (one example: hash map/table or alternative). Surprisingly, there are very few freely available implementations one can just import and use. By and large, every developer custom builds their own implementations. It should not be underestimated how much of a time sink this truly is. This aspect is trivialized by veterans, who have spent a decade or longer accumulating and tuning their own personal collection of reusable/tweakable snippets. 4. Compilers, linkers, and build tools. Thankfully the standard compiler options are good enough for nearly everyone, because the options are so numerous and complex that I'd bet even the developers of the compilers themselves get lost in that forest. 5. Finally, you're not doing much with C itself; rather, you're interfacing with everything your operating system provides. Most of your time is spent learning every aspect of POSIX (or equivalent) for your target architecture. This is quite straightforward (just time consuming) if you're targeting one architecture - say, Linux. The moment you want to support anything even remotely cross-platform (Linux, *BSD, macOS, Windows), you're essentially opening Pandora's box. Note that none of the above is really a criticism of C. There is simply more to using C than its syntax - and those other moving parts are where nearly all of one's time will be spent.

You can absolutely learn the syntax of C in an afternoon, or a few days at worst, if you're not having to learn to all the other concepts interesting C programs require. Much of the immense learning curve comes from th things that are "outside C", like how to synthesize high level concepts from the lower level primitives in the core language and system specific gotchas the language doesn't shield you from.

zbentley 8y ago
> You can absolutely learn the syntax of C in an afternoon, or a few days at worst That depends on what you mean by "learn". Learn it well enough to make something that works for you, on your architecture, with your toolchain? Sure. Learn it well enough to know which combinations of the syntax you (thought you fully) learned trigger undefined and wildly variable behavior in the wild or when run with other libraries/build environments? Hell no. And bugs caused by that stuff are distressingly common. That's not a "system specific gotcha". It's a huge area of skill-requiring behavior that arises directly within the core syntax of the language. Saying "you can learn C in a weekend" is like saying "you can learn to drive a car in a weekend" in reference to learning how to maneuver a car alone in a big empty parking lot. Technically true, but it'll leave you woefully unprepared for operating that car the way almost everyone wants to: around other cars, in more complicated contexts, subject to many more unpredictable factors (other people).
- chungy 8y ago
  "Learn C in a weekend" (or afternoon) is akin to getting accustomed to a new model of car, _with prior driving experience_. Each car has its own quirks, each programming language has its quirks. Learning C from the background of already knowing how to program is like driving a new Ford Focus off the lot and getting used to it. Learning C++, on the other hand... is expecting you to pilot a jumbo jet after your only experience was the Ford Focus.
  - kqr 8y ago
    > "Learn C in a weekend" (or afternoon) is akin to getting accustomed to a new model of car, _with prior driving experience_. ...in an empty parking lot, sure. C brings a whole host of old issues to the table that you simply do not get to experience in other languages. C is deceptively easy to think you know, but I have yet to see evidence of someone actually using it responsibly.
waynecochran 8y ago
You don't really know a language until you've program with it awhile. You are not going to write many significant programs in 24 hours.
gaius 8y ago
You can absolutely learn the syntax of C in an afternoon, or a few days at worst, if you're not having to learn to all the other concepts interesting C programs require. It is the same with any reasonably serious language. I mean you can learn Python syntax in an afternoon but it will be 6 months before you can use NumPy (and friends) without spending more time poring through the documentation than actual coding. Same with Java, C++, .NET, to be productive you must internalize a vast ecosystem and if you aren't doing it every (working) day then skill fade is very real.
Too 8y ago
A big problem of learning any programming language "in an afternoon" is dodging all the cargo-cult bad advise on the internet. If you know what's bad advice it's easy but when you start from 0, any tutorial looks equally legit and you might end up a week in a rabbit hole that is more destructive than productive. An experienced programmer knows when to stop googling, when to use classes from the standard library and when to roll your own algorithm. A beginner does not and can easily start writing their own timezone-handling class or spend a day finding and configuring a package on npm that could be written in 3 lines yourself. So in hindsight it feels like you should have been able to learn all this in an afternoon, but the road there is actually tougher than you remember.

developer2 8y ago

To use an old meme: "One does not simply learn C". Instead, one learns: 1. Everyday C syntax. It's not strictly required to learn every esoteric and historical thing about the language; if you go down that rabbit hole, you'll be down there for years. 2. How to properly structure and organize code and header files. It takes a little while to understand exactly what goes into a header file (and why), how to anticipate and avoid problems like cyclical include dependencies, etc. 3. Data structures and algorithms. While not a feature of the language itself, most projects are going to need non-trivial data structures (one example: hash map/table or alternative). Surprisingly, there are very few freely available implementations one can just import and use. By and large, every developer custom builds their own implementations. It should not be underestimated how much of a time sink this truly is. This aspect is trivialized by veterans, who have spent a decade or longer accumulating and tuning their own personal collection of reusable/tweakable snippets. 4. Compilers, linkers, and build tools. Thankfully the standard compiler options are good enough for nearly everyone, because the options are so numerous and complex that I'd bet even the developers of the compilers themselves get lost in that forest. 5. Finally, you're not doing much with C itself; rather, you're interfacing with everything your operating system provides. Most of your time is spent learning every aspect of POSIX (or equivalent) for your target architecture. This is quite straightforward (just time consuming) if you're targeting one architecture - say, Linux. The moment you want to support anything even remotely cross-platform (Linux, *BSD, macOS, Windows), you're essentially opening Pandora's box. Note that none of the above is really a criticism of C. There is simply more to using C than its syntax - and those other moving parts are where nearly all of one's time will be spent.