I also thought C should be the first language anyone learns. Cause you learn the most (about the machine) and other languages are easy peasy compared (well except for assembler, of course).
I find assembler is _much_ easier than C. At least the x86/amd64 and arm assemblers that I know. And assembler is much closer to the hardware, so would recommend learning x86 assembler as the first language, then C, then some scripting language like Python. It is a hard start but totally worth it.
I don't think that the first language you learn matters (except vocationally, of course!). What matters more is the understanding that every language has it's own 'take' on approaching the problem of instructing computers.
This 'take' (more formally called the language semantics), determines the kind of runtimes, libraries and tools that can be implemented for the language.
With this mindset, it doesn't matter which language you start with. When comparing languages, you go beyond simple syntax differences and compare what are the implications of the semantics. This will allow you to make more informed language selections for your project.
tl;dr: learn multiple languages as well as compare them effectively to profit !
I consider myself a fairly decent programmer. Better than a lot but by no means near the best. Through necessity I've had to learn a LOT of languages over my career and I have to agree with you that learning different types of languages will always be more beneficial to learning any one specific "special" language. That said, I HATE HATE HATE learning new languages. Most of the new languages I have to pick up these days are much like the old ones I've used in the past. The stumbling point for me is finding interesting starting projects to work on to learn them(I can't and I assume a lot of other developers can't) just read a book on a new language and get comfortable with it. Even the best language books have pretty painful starter projects for experienced developers. What we need(or what I need to find if anyone knows one) is a site that lists a bunch of interesting projects that target the specifics of different languages with a repository system for people to upload their results to for any potential feedback.
Hello World or my CD collection manager is no fun for anyone that regularly just glances at the obvious first chapter of any language book(variables) for basic syntax.
I don't hate new languages. I hate that fact that I need 27 different programming and scripting languages on a weekly basis to accomplish my tasks. And for contracts in the Microsoft realm, it's a moving target that changes every two years.
As for project ideas, I usually port smaller projects that I've done for home, work or charity into the new language, then try to refine them using the appropriate patterns/style of the language. I've rewritten some semi-complex utilities in C#, JScript, PowerShell, Python and Ruby.
Since I deal mainly with databases, one idea that I've been playing with recently is grabbing public domain data from the FCC or the Census Bureau and building desktop or mobile apps with the results. Example: take the Amateur Radio License information from FCC.gov and build a application.
"What we need(or what I need to find if anyone knows one) is a site that lists a bunch of interesting projects that target the specifics of different languages with a repository system for people to upload their results to for any potential feedback."
I would love this. The biggest hurdle for me learning any new language is what to write. I mean, I can only rearrange my iTunes library so many times. :)
I've long thought that people should start at the edges and move towards the middle. Start with an assembly language for exposure to the guts of the machine, and with something like Scheme for the theoretical stuff. Then work your way toward the middle with more common languages like C or Java or Ruby or whatever.
Except when it comes to cache, pipelining, registers, non-uniform memory access in general (not just cache), out-of-order execution and opcode pairing rules, SIMD architectures, and the existence of the processor status word. Other than that, yeah, C exposes you to a lot of worrying about memory allocation when algorithm design would be a better use of your time.
> other languages are easy peasy compared
The only way you could possibly say this is if the only languages you know are imperative Algol-derived ones with minimal type systems and no support for logic or declarative programming. Learning C doesn't make Prolog meaningfully easier. Learning C doesn't even make learning a mainstream language like SQL easier.
Understanding of the cache (specifically) and the memory hierarchy (in general), and of register allocation, are vital to writing efficient C code. Obviously, you don't have to understand that stuff to write marginal C code, but the idea that C hides it from programmers is a bit of a stretch.
I'm not sure what you mean by "the existence of a status word", since much of the expression syntax of C is a mapping of the status bits.
When I'm writing a bigint package in assembly, I can see whether the previous addition set the carry flag. In x86, I even have an adc opcode. There's nothing like that in C.
I would recommend almost anything with an interactive shell over a traditional C environment.
Python and irb are nice starting points because you can start out by claiming they are just a calculator, where you have to press return instead of =.
From there, you can go to variables (prevent you from having to type, e.g. the gravitational constant or a VAT percentage over and over), then to looping (print multiplication tables), to arrays (store them for later use, or as input for a loop to print year lengths for the planets, computed from their distance to the sun), and then to functions.
And all of that without having to teach people the difference between source, object code, and executable.
I agree that this is the case for casual programming. If you are teaching someone who has hardware experience (electrical engineer, etc), it is sometimes easier to build from the bottom up and C is as low as it goes without being assembly (a good and a bad thing).
For the low level stuff an assembly language is way better than C. C is still a LOT of magic that you won't be able to fully understand without understanding how the machine and the compiler works. In assembly a line corresponds to one instruction. What the assembler is doing is translating each line to an instruction number that the machine can interpret. That is a whole lot less magic than what happens in C. In addition, pointers are much easier to understand from a machine perspective than from a C perspective: they are just numbers indicating a location in memory. C makes that far too complicated with different data types, pointers to local variables (and higher up the call stack), confusing pointer declaration syntax, etc.
You can learn C syntax for assembly language idioms later. Starting out by learning the concepts plus the syntax at the same time leads to inefficient learning because when you're learning concepts like pointers it doesn't help to have to learn confusing stuff and syntax at the same time.
This does not apply to languages that cleanly abstract the machine like Scheme/Python/Haskell/what have you, but C lets the low level stuff shine through so much that you end up having to learn that anyway; you can't really learn it as an abstraction.
My first language was Javascript/Actionscript and then later Java. It wasn't until after that that I learned C and C++. But I agree that C should be one of the first languages learned.
> This still doesn't successfully counter the statement that C is the best language to start with.
I wasn't actually trying to refute that statement above; I was responding to the specific arguments used to support it.
Anyway, I agree with the other poster who replied to you: Pick a language with a REPL, as instant reinforcement of concepts is essential to ingraining them into the mind. Having a longer turnaround time means the lesson gets diluted by being interleaved with too much process (save the file, build the program, run it, look at the output, consider it, etc.).
> I don't understand how your comment is a refutation of the assertion that C will teach you more about the machine than other languages.
It completely hides some of the most important aspects of any modern hardware from you. The only thing it really exposes you to is manual memory management, and even then the view of memory C gives you is grossly simplified compared to how memory actually works on any modern hardware.
> Which language would you recommend using if you want to learn more about the machine?
Pick a machine and learn that machine's assembly language.
