I learned C by reading books and writing code but I had to take a couple of courses to get a handle on C++. If I hadn't learned C first I might have been able to learn C++ on my own because I've learned all the other languages rather quickly, and on my own. Java is very much like C but safer. If you really want to get down to the nuts and bolts of the hardware you will not be able to avoid C/C++. C is not too hard to learn but can get a newbie into a lot of trouble, but only once you get into pointers and a lot of work can be done without pointers at an introductory level.
When teaching new students you want them to have wins so they enjoy the learning experience. Writing my first "Hello World" in C was fun and easy, once I got the IDE set up correctly. Writing the code took a couple minutes. I labored for hours on the IDE. That was back in the DOS days and you had memory models to deal with because at one time someone thought computers would never need more than 64K of memory and Intel stuck to that limitation for a long time. To use more than 64K you had to segment memory and it got complex quickly. When I started using Microsoft VB it was a similar experience for different reasons. I better understood the concepts in the IDE but there were still a lot of decisions to make for my first application and event driven coding is much more complicated than sequential coding.
Now the CPUs are getting really advanced and I don't think it is practical for someone to have to learn assembly language as a first tool. Aseembler is more advanced and would be better learned after the student learns the hardware concepts in the computer so my happen in the second or third year of his or her education. I saw that Python was highly rated but I haven't learned it yet. I have heard great things about it though.
x86 isn't much better. Again, not a good first ASM. And I've heard that PIC is pretty nasty.
PIC asm isn't so bad, but any PIC I've used is Harvard architecture so if you've come from a Von Neumann style system it takes a while to adjust.
The problem with the question is that there's no real answer and I agree with Michael about that. Beyond that starting point though, it's pointless learning a language you'll never use.
For CS it's much more simple, C#,C++,C in no particular order. For webbies, JS, PHP etc. An EE on the other hand might need PIC today, AVR tomorrow, ARM, x86 and on down the list depending on the project. C might seem like a good choice, but without all of the libraries it's advantage is limited.
As an EE myself I've found none of the choices very useful, much more valuable is the general understanding of the principles that you can then apply to the problem at hand in any language.
I think EEs should learn an assembler language that runs on processors they are most likely to encounter when they get out into the work force, not for processors that are simple enough to be hand-assembled.
I once saw a juggler perform before an audience of mostly children. He told them: "If you want to learn to juggle, don't start with eggs. Start by juggling silk handkerchiefs, because then you're juggling in slow motion."
This applies to any difficult subject: start with simple fundamentals, and then work your way up one simple extension at a time. If you want to teach your child to read, don't start with Moby ***. Start with Green Eggs and Ham.
When learning ASM, there are architecture-independant fundamentals that you need to know. IMO you're much better off learning those on a simple architecture so that you're not distracted by the complexities of something like ARM or x86. Once you've mastered those fundamentals and a few extensions, you can apply that same knowledge to any other architecture that you come across later on. If you start with a complex architecture you end up "trying to drink from a fire-hose" and you'll say "But Assembly's hard!" like Sagar.
Another challenge with ASM is that if you run it on a real processor it can be really hard to debug. People sometimes refer to C as "programming without seatbelts". Well, ASM is "programming without seats, lights, brakes, tires, or a even a body". So you may be better off starting with a simulator, so that your program is running in a controlled environment with better fault handling and debugging capability.
I really can't understand the obsession with teaching Electronic/Electrical Engineers assembler and C as a first language - or is the general interpretation of EE "Embedded Engineer" ?
Perhaps we should all use ADA more to encourage precision !
Electronic/Electrical Engineers should be studying hardware first so they should have a first programming language that assists that - I vote for Python but Matlab is technically OK but has other issues (see rant above).
I think EEs should learn an assembler language that runs on processors they are most likely to encounter when they get out into the work force, not for processors that are simple enough to be hand-assembled. Nobody ever does that these days. And I doubt many EEs are ever going to need to write an assembler or compiler.
I have about 20 languages listed on my resume (as a CS guy), including assembler for several different processor families, but if I was a new EE grad right now, having C and ARM+Thumb assembler would open the most doors.
I'm slowly making my way through Bruce Smith's book on using Assembly on the Raspberry Pi. Good stuff, but hard to keep up with when you put it down for a few weeks to tend to other business. :-)
Actually, I'm doing a home course to brush-up on my assembly chops. I remember now why I didn't like it the first time around in college.
Some assembly languages are harder than others. The best one I've ever used is PDP-11 -- very clean, very orthogonal, simple instruction coding that allows you to read an octal dump and immediately recognize and decode common instructions. C was originally designed to produce excellent PDP-11 code, and you see the PDP-11's influence on C, in particular stacks growing towards low memory (most C compilers evaluate their arguments in right-to-left order) and the auto-increment and auto-decrement expressions. A C statement like "*s++ = *t++;" translates into one single-word PDP-11 instruction.
ARM started out as a RISC machine (Acorn RISC Machine) and after a few versions became Advanced RISC Machine and later just ARM. ARMv7 is quite hard to understand: each version added new instructions by sticking them into gaps in the previous versions' instruction codings. If you like complex railroad time schedules with myriad footnotes, take a look at the quick reference cards at arm.com. Then for even more fun, download the entire ARMv7-AR Architecture Reference Manual (the "ARM ARM") and try to figure out how many instruction formats there are. This doesn't impact performance, since the chip-level hardware doesn't care if instruction fields are scattered all over the place, but not a good first ASM IMO.
x86 isn't much better. Again, not a good first ASM. And I've heard that PIC is pretty nasty.
PowerPC is quite regular and I recommend it. I've looked a little at the MSP430 and so far it looks like a PDP-11 combined with some RISC philosophy, so I'd definitely consider it. AVR isn't bad.
Since most people program in C, the complexities of the underlying ASM don't matter to most programmers. But those of us who write compilers and (dis)assemblers do see it and cringe and/or gag, depending on the ASM. Go write an assembler and/or disassembler for ARMv7-A, with both ARM and Thumb-2 codings. It's loads of fun! It's nothing like an 8080 assembler, believe me.
Very important distinction here is that the question specified "EE", not "CS"!
EEs should learn C first, but not bother with C++ so much. C compilers are available for every processor made and by learning C you will be able to write code that runs on all of them. Learn to depend on C++ and you are not going to be happy when you need to program a PIC or some other tiny microprocessor. Your second language depends on your area of interest. Signal processing? Learn Matlab. Embedded systems? Learn ARM assembler. A few years ago, I would have said to learn assembler for 68xx, PIC, or AVR, but working with a Cortex M0 now I think maybe ARM is actually going to displace most of the little microprocessor families.
I would suggest a completely different order and choices for a CS major.
Top Comments