Much of an electronic engineer’s life is spent in front of a screen. And much of that time is creating and debugging designs using some textual format or other. Arguably, even humble Excel falls into that category of “tools”. At some point many electronic designers will end up performing schematic capture and maybe PCB layout – but much of the design is already done by then.
So, what languages are used?
Having no knowledge of C programming will hamper one’s ability to bring up new board with a microprocessor of any description included on them – and it’s a rare system which has no micro at all! [Forth][http://en.wikipedia.org/wiki/C_(programming_language)] has several vocal proponents, but it’s definitely a minority language.
If you do logic design then either VHDL or (System) Verilog is a must – very few schematic tools exist in this space. And the tools with which these designs are developed, tested and debugged tend to be controlled by the tool control languageTCL. TCL is a weird language – to me it feels dominated by the form of the source code, woe betide anyone who puts a brace on the wrong line, or omits a space after what (in most other languages) would be a separator charactre in its own right.
Personally, I’d rather use Python if writing scripts, and indeed I use Python frequently throughout my various roles, for quick hacks of data analysis through to a prototype stereo-vision algorithm. Perl is another good choice for quickly hacking together the tools that you need. I find it too easy to write unmaintainable code in Perl however, which is why I have moved to Python.
Matlab is another must for engineers who have to deal with numbers (like signal processing!). Or one of its free competitors Octave or Scilab. comp.dsp regular Vladimir Vassilevsky is fond of ironically saying “Matlab does all thinking for us” when a request is made for help implementing a system which has been designed in Matlab without thought for the real world. However, in the right hands, Matlab is a powerful tool for investigating engineering trade-offs very quickly. I’m fond of using Matlab to investigate algorithmic possibilities, always keeping in mind what the end implementation might look like (in software or hardware). Once I have a good algorithm prototyped, I can then create Matlab implementations which are degraded in various ways to emulate how my real implementation will look. For example, using limited bit widths rather than double-precision numbers. Or approximate square-root algorithms rather than numerically precise answers. If the degraded algorithm differs too much from the golden starting point, I need to undegrade it some! Once this is done, it is then useful for testing my real implementation. If it differs from the prototype degraded algorithm, I’ve done something wrong in the implementation somewhere.