Electronics > Beginners

what is the most relevant programming language for ee?

<< < (4/21) > >>

exe:

--- Quote from: rstofer on November 04, 2018, 12:08:18 am ---I don't want objects created and destroyed along with the requisite memory allocation and deallocation on a device with limited resources - so, C++ is out (in my view).

--- End quote ---

I use C++ and static memory allocation. So far I'm happy with it.

Fred27:

--- Quote from: vk6zgo on November 04, 2018, 02:05:46 am ---Solder? ;D

--- End quote ---
+1
Best answer so far.

tggzzz:
Don't focus on the language; they change regularly and will continue to change throughout your career.

Do focus on selecting the right tool for your next job:

* which languages employers will want you to use. There are surveys of that.
* what tools are available so you can develop your solution faster, especially libraries
* ways in which problems can be defined
* ways in which solutions can be expressed. These should be congruent with the problem, so you can see the implementation is a correct solution of the problem
* understand what each tool doesn't do
* seamless implementation of specifications in both hardware and software. Sometimes you need to move implementations from one to the otherand don't use a hammer to insert screws!

So, which tools should engineers have in their toolbox?

Provably correct implementation: Ada/SPARK.

Multicore processing: xC, OCCAM.

Hard real-time embedded, i.e. timings guaranteed by the compiler not by testing and hoping: xC.

Simple embedded programming: C.

Finite State Machines: either a specific tool or one of the standard design patterns in whatever language you are using.

Statistics: R and similar.

High performance computing and numerical codes: Fortran.

General purpose, without other overriding constraints: Java or Python.

Analogue electronics: Spice

RF: whichever very expensive tool your employer has purchased, or a limited freeware version.

Digital HDLs, especially for FPGAs: Verilog or VHDL.

Scalable soft-realtime, e.g. telecoms systems: Java.

Quick and dirty number manipulation: a spreadsheet.

Algebra, when exploring conceptual designs: Mathematica.

Be aware that C++ has become so complex that everybody and project has to choose a subset that is used and a subset that is avoided. One problem is that every project/designer/library chooses a different subset, often incompatible and often without realising the consequences.

brucehoult:

--- Quote from: tggzzz on November 04, 2018, 09:25:09 am ---Don't focus on the language; they change regularly and will continue to change throughout your career.

--- End quote ---

Not really. I first programmed in C in 1983 and C++ in 1988 and those are still what 95% of my work in operating systems, compilers and interpreters and JITs, runtime libraries, and embedded programming use, 30 to 35 years later.

Most of the other 5% is bash/grep/sort/etc/perl. Perl is 30 years old and Perl 5 24 years. The unix utilities are 35 to 40+ years old.

And I do all my editing in emacs. It's similar vintage.

I'd say you can't go wrong learning those tools. They're going to be here forever, even if there is something else that comes into popularity from time to time.

tggzzz:

--- Quote from: brucehoult on November 04, 2018, 11:09:41 am ---
--- Quote from: tggzzz on November 04, 2018, 09:25:09 am ---Don't focus on the language; they change regularly and will continue to change throughout your career.

--- End quote ---

Not really. I first programmed in C in 1983 and C++ in 1988 and those are still what 95% of my work in operating systems, compilers and interpreters and JITs, runtime libraries, and embedded programming use, 30 to 35 years later.

Most of the other 5% is bash/grep/sort/etc/perl. Perl is 30 years old and Perl 5 24 years. The unix utilities are 35 to 40+ years old.

And I do all my editing in emacs. It's similar vintage.

I'd say you can't go wrong learning those tools. They're going to be here forever, even if there is something else that comes into popularity from time to time.

--- End quote ---

First point: those languages have changed very significantly over the years. (I first programmed C in, IIRC, 1982 :) )

Second point: while they might be not inappropriate for the work you have done, there are alternatives with some advantages.

Third point: they are an inappropriate and/or a waste of time for many applications - see the list I gave. (Or maybe you really think it would be best to do statistical analysis or analyse analogue circuits in C!)

Fourth point: by concentrating on one tool/technology, you are limiting your future options. Technologies do become obsolete; I was once offered a job based around core memory! If you are the world expert in, say, CCDs, you will be very well paid until your employer is no longer interested in CCDs :)

Fifth point: if you know alternative tools and strategies, they can improve your designs and implementations even if you use a different language. FSMs in C are the canonical example, e.g. see this current topic: https://www.eevblog.com/forum/microcontrollers/state-machines-is-this-topic-taught-any-more/msg1931161/#msg1931161

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod