What programming language should EE's learn first?

There should be no other choice.

Learning the lowest level language possible, Assembly.

Understanding how programming works at that level is key to being a good programmer.

C

But Assembly's hard!

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.

Sagar Jethani wrote:

 

But Assembly's hard!

 

 

 

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.

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

MK

Guy Grotke wrote:

 

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.

Guy Grotke wrote:

 

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.