Too many programming languages?

[tggzzz]

You are all so wrong!
 

It is not the language you have to learn, it's the ecosystem (of a specific language/technology) you have to master.

Once you have some experience with any programming language syntax, learning other languages is really not a big deal (usually).
But learning the the environment is what requires time and experience.

There's some truth in that, but the ecosystem is a secondary consideration since (to a large extent) the ecosystem comes with the language. Many ecosystems are similar in concept, but the details require learning.

Learning a new language is relatively easy provided that the language is of a similar type. Examples: Delphi/Pascal, Java/C#.

But knowing C isn't much help when it comes to learning R, OpenSCAD, Java, Erlang, VHDL, Matlab etc. Why? Because the underlying concepts and semantics are so radically different.

Knowing when not to use a language is an important skill.

[brucehoult]

You are all so wrong!
 

It is not the language you have to learn, it's the ecosystem (of a specific language/technology) you have to master.

Once you have some experience with any programming language syntax, learning other languages is really not a big deal (usually).
But learning the the environment is what requires time and experience.

Even if you know the language, even if you know the ecosystem of standard libraries, by far the biggest task at a new company is learning all the tens of thousands of lines of local code they've written, often much more poorly designed and certainly less well documented than any language or standard library.

If you *don't* know the language and standard library used at your new job, learning those is usually a so much smaller job than learning the local environment that it's almost trivial. And you can google language and standard library questions.

[Kjelt]

Even if you know the language, even if you know the ecosystem of standard libraries, by far the biggest task at a new company is learning all the tens of thousands of lines of local code they've written, often much more poorly designed and certainly less well documented than any language or standard library.

100% agree and my last job it was more like 36Mlocs without documentation, and no in two years you don't master that.

[Berni]

I'm not.

In my first post I wrote (new emphasis) "You should learn the concepts, advantages and disadvantages of one example of each type of programming language. That will enable you to choose the right tool for the job, just as you should know whether to use screws, or nails, or bolts. Once you know the concepts, picking up the next language of that type is simple."

Yep exactly, the right tool for the right job.

And the right job for a tool called HDL languages is describing behavior of complex digital circuitry as i have pointed out in the very beginning. If you have sensible real world examples of HDL used for something else i would love to see it.

I was only involved enough at XMOS to get a slightly earlier heads up on new products and get some early access to dev tools. So i don't know the long term road map for there products, but what i seen so far was not living up to my multiprocessing expectations, hopefully they can change that in the future because it could be something truly innovative for computing. After all the useful applications of the language is determined by the hardware running it and so far XC only compiles for xmos chips.

Can you name a end application for XMOS processors where they really have an advantage over existing solutions like MCUs, DSPs, FPGAs?

The word "really" implies a subjective response, and there would be legitimate differences of opinion. That's true for all languages and technologies.

Most importantly for this thread, the application of concepts is most definitely not limited by the hardware. In particular, CSP concepts are embodied in many languages (and some hardware), of which xC is the most "pure" example.

The concepts will survive and be useful during an entire career, even though languages come and go and mutate to breaking point.

The OP would do well to understand the concepts.

Yes that is all fair and good, but the end goal of using a programing language is to create some useful output. So far XC can only be compiled into machine code for XMOS chips, so the only reason you would want to learn this language is if your end goal is running your program on one of these chips. If you want to run your code on something else like a PC you can do similar multitasking things in C++ or C# ..etc.

It makes no sense to learn new programing languages just for the sake of learning languages. Just go for what you are trying to do, have a look at what languages other people are using to do that and choose one of them and learn that as you go. Once you know one language its quick to pick up another one.

So since the main practical home user use for HDL is "FPGA stuff" it makes little sense to learn it until you actually get to using them and need it. Just don't get into the trap of "when you know how to use a hammer every problem looks like a nail" situation where you learn 1 single programing language and then use it for everything regardless of it being a good fit or not. Be open to learning new languages when there is good reason to do so. It usually taker longer to learn the environment and useful libraries than the language itself anyway.

[tggzzz]

I'm not.

In my first post I wrote (new emphasis) "You should learn the concepts, advantages and disadvantages of one example of each type of programming language. That will enable you to choose the right tool for the job, just as you should know whether to use screws, or nails, or bolts. Once you know the concepts, picking up the next language of that type is simple."

Yep exactly, the right tool for the right job.

And the right job for a tool called HDL languages is describing behavior of complex digital circuitry as i have pointed out in the very beginning. If you have sensible real world examples of HDL used for something else i would love to see it.

You have a strange view of the world: selecting a job for a tool. Most people select a tool for the job.

I don't have any examples that are in the public domain; sorry. However, you could start aquainting yourself with a subset of the concepts such as
https://www.vhdl-online.de/vhdl-ams/examples
http://www.denverpels.org/Downloads/Denver_PELS_20071113_Cooper_VHDL-AMS.pdf
https://www.doulos.com/content/training/vhdl-ams_training.php

I was only involved enough at XMOS to get a slightly earlier heads up on new products and get some early access to dev tools. So i don't know the long term road map for there products, but what i seen so far was not living up to my multiprocessing expectations, hopefully they can change that in the future because it could be something truly innovative for computing. After all the useful applications of the language is determined by the hardware running it and so far XC only compiles for xmos chips.

Can you name a end application for XMOS processors where they really have an advantage over existing solutions like MCUs, DSPs, FPGAs?

The word "really" implies a subjective response, and there would be legitimate differences of opinion. That's true for all languages and technologies.

Most importantly for this thread, the application of concepts is most definitely not limited by the hardware. In particular, CSP concepts are embodied in many languages (and some hardware), of which xC is the most "pure" example.

The concepts will survive and be useful during an entire career, even though languages come and go and mutate to breaking point.

The OP would do well to understand the concepts.

Yes that is all fair and good, but the end goal of using a programing language is to create some useful output. So far XC can only be compiled into machine code for XMOS chips, so the only reason you would want to learn this language is if your end goal is running your program on one of these chips. If you want to run your code on something else like a PC you can do similar multitasking things in C++ or C# ..etc.

It makes no sense to learn new programing languages just for the sake of learning languages.

Actually, it does make sense; careful choice of another different type of language can make you a better engineer.

Just go for what you are trying to do, have a look at what languages other people are using to do that and choose one of them and learn that as you go. Once you know one language its quick to pick up another one.

...of the same type of language.

It takes a long time to "pick up" OOP if you have only programmed a procedural language like C. I could tell you some success stories and some horror stories, but this isn't the place!

So since the main practical home user use for HDL is "FPGA stuff" it makes little sense to learn it until you actually get to using them and need it. Just don't get into the trap of "when you know how to use a hammer every problem looks like a nail" situation where you learn 1 single programing language and then use it for everything regardless of it being a good fit or not. Be open to learning new languages when there is good reason to do so. It usually taker longer to learn the environment and useful libraries than the language itself anyway.

But, if you have no concept of the benefits and applicability of HDL/statistics/OOP/functional/forward-chaining/backward-chaining/actor language differs from, say, C, then you will only ever use C. That leads to people that insert screws with hammers.

[SiliconWizard]

I'm not.

In my first post I wrote (new emphasis) "You should learn the concepts, advantages and disadvantages of one example of each type of programming language. That will enable you to choose the right tool for the job, just as you should know whether to use screws, or nails, or bolts. Once you know the concepts, picking up the next language of that type is simple."

Yep exactly, the right tool for the right job.

And the right job for a tool called HDL languages is describing behavior of complex digital circuitry as i have pointed out in the very beginning. If you have sensible real world examples of HDL used for something else i would love to see it.

You have a strange view of the world: selecting a job for a tool. Most people select a tool for the job.

Well, that sentence looked weird. I agree with you.

And yes, you can do a lot of things with an HDL apart from pure digital circuit design. VHDL in particular (and probably SV, although I don't know it much) is a full-fledged language with A LOT in common with ADA. There are even library functions for file I/O and other things. One obvious use is sophisticated simulation programs, but you can do pretty much whatever you want with it as long as you're not relying on a full-fledged runtime (as I said, you get limited functionalities such as file I/O, but you can still do a lot.)

[Berni]

Okay i will admit i did word that a bit backwards since you typicaly select your language according to what you are trying to do.

That is some impressive analog circuitry simulation in VHDL. Works in a pretty elegant way too. Tho most will tend to use SPICE for this.

I don't mean to ignore other languages until you find a problem that requires one. But you can get a pretty good idea of what a language is good at by googling around a bit and looking trough some tutorials for it, no need to actually learn it by writing your own code. Yes object oriented programing is a significant step up from your usual raw C but not so significant that a good C programmer couldn't wrap there head around the concept of it by reading a few quick tutorials. Id say the important thing is just to not judge a programing language by how it looks at first glance, some languages are ugly to look  at (the definition of ugly depends a lot on what you are used to a language looking like) but are still great at getting the job done.

Especially if you get into web development you enter a world of a gazilion different languages and libraries that are constantly changing, a lot of them doing the same thing but in a slightly different way,

Knowing 2 or 3 languages well is better than knowing 10 languages badly.

[emece67]

.

[tggzzz]

Okay i will admit i did word that a bit backwards since you typicaly select your language according to what you are trying to do.

That is some impressive analog circuitry simulation in VHDL. Works in a pretty elegant way too. Tho most will tend to use SPICE for this.

For an analogue problem with a little digital control, Spice is probably better.

The analogue capabilities of VHDL are merely one small example of system design, where digital logic is a small part of the system and where the boundaries between technologies are fluid and will change during the course of a project's lifetime.

One extreme example of the boundaries being ill defined is in the high frequency trading world. That mob puts the entire protocol stack in FPGAs. That includes the MAC layer, the transport protocols, and the business rules.

I don't mean to ignore other languages until you find a problem that requires one. But you can get a pretty good idea of what a language is good at by googling around a bit and looking trough some tutorials for it, no need to actually learn it by writing your own code.

Most language tutorials are poor. The last good white paper I read was in 1996, by James Gosling on the philosophy of Java.

Yes object oriented programing is a significant step up from your usual raw C but not so significant that a good C programmer couldn't wrap there head around the concept of it by reading a few quick tutorials.

Quick tutorials are likely to omit key fundamentals. One example is Python's GIL which prevents it having any scalability on multiprocessor machines.

Quick tutorials are unlikely to show how well solutions can be maintained and enhanced with different staff.

Id say the important thing is just to not judge a programing language by how it looks at first glance, some languages are ugly to look  at (the definition of ugly depends a lot on what you are used to a language looking like) but are still great at getting the job done.

Especially if you get into web development you enter a world of a gazilion different languages and libraries that are constantly changing, a lot of them doing the same thing but in a slightly different way,

That's a classic example of "languages" with miniscule differences. Know they exist and why, learn one if the need arises.

Knowing 2 or 3 languages well is better than knowing 10 languages badly.

You'll never know many languages well. But you need to know enough to avoid hammering in screws.

The worst example of that was someone that had to get a value from one Unix process to another. He knew databases, so he did it by one process adding a row to a table, and the other process doing database queries. Sockets? What are they?

[tggzzz]

I don't have any examples that are in the public domain; sorry. However, you could start aquainting yourself with a subset of the concepts such as
https://www.vhdl-online.de/vhdl-ams/examples
http://www.denverpels.org/Downloads/Denver_PELS_20071113_Cooper_VHDL-AMS.pdf
https://www.doulos.com/content/training/vhdl-ams_training.php

The first time I have notice about VHDL-AMS was in 2005. Since then I have not meet any people using it. Obviously this doesn't mean that it is not used, but I am curious about real projects using VHDL-AMS. Does it really have any significant role in industry?

I don't know, and that question should always be evaluated. Mind you, when I first used Java commercially (early 1996), there were no examples of commercial usage and even the best available IDE was written in C! Nonetheless Gosling's whitepaper was a model of exposing the key features, and it was clear that it was a significant advance and would become important. (Ditto C# five years later, but indicating there was no dignificant advance!)

The URLs are intended to dispell any notion that HDL==digital logic.
The URLs are not intended to illustrate how large complex systems can be modelled, implemented using stepwise refinement, and simulated.

[SparkyFX]

Are you a manager by any chance? They have no clue how much time it takes to snif on a language and learn something significant.

Having seen code samples does probably not justify to put it on your resume, but this never has been the question. The question is more or less if learning a single language and that alone might be a good decision, as mentioned by the OP.

Perhaps in the 60s you could know everything, nowadays that is really impossible and you better be pretty good at one thing (specialist) and moderately good at many other things, then be moderately to bad in everything. At least that is my experience.

In my experience you can be good at anything you currently work with as long as you keep learning. If you learn C once and don´t use it in 20 years better don´t call that competence. This would be as bad as working in that single language, but using outdated techniques all over the place and getting the complaints about it. So the question what to learn is second to actually keep learning.

Sometimes this can be as simple as feeling comfortable in an environment, looking up documentation and working within this ecosystem - in other words enable yourself to learn as fast as you can.

In our programming team

Thats a matter of where to find work... later, kind of a goal - maybe, because i would not have interpreted the question to include if electronics engineers should aim for the domain of CS and vice versa.

[beanflying]

Much as statistics lie and ZDnet has been known to not help by stretching the truth https://www.zdnet.com/article/programming-languages-python-predicted-to-overtake-c-and-java-in-next-4-years/ . This data 'claims' to be from 12 million IT heads.

Going to be different to the result of what a strict EE study would produce but C and Python (quickly rising use!) make sense and I am still looking but Forth is clearly hidden to protect it's power, wide use and appeal from view

[brucehoult]

Assembly language up six places!!

It's clearly the Next Big Thing. Groovy!

[techman-001]

Much as statistics lie and ZDnet has been known to not help by stretching the truth https://www.zdnet.com/article/programming-languages-python-predicted-to-overtake-c-and-java-in-next-4-years/ . This data 'claims' to be from 12 million IT heads.

Going to be different to the result of what a strict EE study would produce but C and Python (quickly rising use!) make sense and I am still looking but Forth is clearly hidden to protect it's power, wide use and appeal from view

The OP wanted to debug the I2C peripheral on his STM32 mcu.

C is not real time interactive and Python won't run on the OPs  STM32 mcu.

MicroPython will run on it interactively, providing the mcu has 256KB Flash and 16KB ram *just for Micropython*. It's also 30 times slower than Forth.

Guess which language from your list produced this real time STM32 I2C register data contents printout picture ?

And this real time resource stat ?

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 58368 FREE: 7168
RAM.... TOTAL PRESET: 8192 USED: 1180 FREE: 7012

[legacy]

And this real time resource stat ?

forget also ucLisp, this is pure crap, and implementing a minimal interpreter doesn't suite a small memory model very well because it consumes a lot of stack and cpu cycles 

[beanflying]

The OP wanted to debug the I2C peripheral on his STM32 mcu.

C is not real time interactive and Python won't run on the OPs  STM32 mcu.

MicroPython will run on it interactively, providing the mcu has 256KB Flash and 16KB ram *just for Micropython*. It's also 30 times slower than Forth.

Guess which language from your list produced this real time STM32 I2C register data contents printout picture ?

And this real time resource stat ?

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 58368 FREE: 7168
RAM.... TOTAL PRESET: 8192 USED: 1180 FREE: 7012

You reply like a true zealot - there is only one true programming language all other heretics must be burned at the stake. 

Tone it down we don't need a fanatical sermon from your keyboard! Forth as a 'specific' language is NOT appropriate as a solution for all and is NOT a solution for the project the OP is embarking on much as it could be used for PART of it.

There are more widely used solutions that are much better supported for the OP.

The original data I linked above https://www.tiobe.com/tiobe-index/ somewhere below 0.2% is where Forth and others are at.

[techman-001]

And this real time resource stat ?

forget also ucLisp, this is pure crap, and implementing a minimal interpreter doesn't suite a small memory model very well because it consumes a lot of stack and cpu cycles.

Perphas Forth is the only choice in this case 

I think Forth is probably a suitable choice in this case given the STM32 I2C debugging issue and the fact that the OP asked what language to learn. Naturally I didn't imply that Forth should be the ONLY language he should learn.

Another factor affecting all real time interactive languages other than Forth is the small but regular time they spend garbage collecting, which can be a issue where the mcu is needed to do other things at that time.

[legacy]

So probably a good solution, in this case, is something like a little GDB-stub, or a true-hw ICE.
What do you think?

[Nusa]

Overall language statistics only matter if you have no focus on what you intend to do. Once you start talking about a particular field or subject matter, the choices become more refined. If you're involved in the hard sciences, FORTRAN is still very relevant to most of those fields. If you're doing work for large business/finance, COBOL is something to know about. One can still make a living working with both of those 60+ year-old languages, despite them not even being on your popular list. People have been predicting their death for half my life. Similarly, I predict C and C++ are going to still be relevant and useful languages after most of us are dead.

[techman-001]

The OP wanted to debug the I2C peripheral on his STM32 mcu.
C is not real time interactive and Python won't run on the OPs  STM32 mcu.

You reply like a true zealot - there is only one true programming language all other heretics must be burned at the stake. 

Tone it down we don't need a fanatical sermon from your keyboard! Forth as a 'specific' language is NOT appropriate as a solution for all and is NOT a solution for the project the OP is embarking on much as it could be used for PART of it.

There are more widely used solutions that are much better supported for the OP.

The original data I linked above https://www.tiobe.com/tiobe-index/ somewhere below 0.2% is where Forth and others are at.

In other words you didn't understand a single thing I wrote as shown by your utter lack of technical argument.

Your use of the royal "we" in attempting to speak on behalf of the millions on this forum doesn't bode well for your mental state either.

I recommend you take a Valium or two, settle down and get a life.

[techman-001]

So probably a good solution, in this case, is something like a little GDB-stub, or a true-hw ICE.
What do you think?

In my opinion for STM32, C and GDB are outstanding, they are Free, available for many architectures and useful in small environments such as gdb-tui or massive environments such as the Java based Eclipse. I think it's the best of the non interactive solutions for small embedded available. It's not interactive, nor particularly trivial to learn and set up, but the C binaries GDB produces are about three times faster than Forth on the same hardware and smaller as no 19 KB on chip Forth Kernel is required.

I have gdb-tui set up here and it runs from a single shell script with all the usual set up stuff done by the time the pseudo gui appears. It is very impressive compared to what I had 20 years ago!

I can't comment on a true-hw ICE as I have never been able to afford one, and never used one anywhere I have worked. Perhaps someone else with firsthand experience with them may comment.


 

[hamster_nz]

The OP wanted to debug the I2C peripheral on his STM32 mcu.

C is not real time interactive and Python won't run on the OPs  STM32 mcu.

MicroPython will run on it interactively, providing the mcu has 256KB Flash and 16KB ram *just for Micropython*. It's also 30 times slower than Forth.

Guess which language from your list produced this real time STM32 I2C register data contents printout picture ?

And this real time resource stat ?

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 58368 FREE: 7168
RAM.... TOTAL PRESET: 8192 USED: 1180 FREE: 7012

BRING BACK BASIC!

(just kidding)

However, a derivative of my TinyBASIC port for the Arduino (http://hamsterworks.co.nz/mediawiki/index.php/Arduino_Basic) is in the masked ROM of every ESP32 chip.

Flash used - zero
RAM used - a tiny bit for the stack the rest is free for code.

I only found out about this from the Hackaday post - https://hackaday.com/2016/10/27/basic-interpreter-hidden-in-esp32-silicon/

[beanflying]

When it comes to learning programming languages, I'm often overwhelmed. The currently popular ones include but not limited to C, C++, C#, Java, Python, etc. You name it, you gotta learn them!

I think one should master one specific programming language, rather than being an expert of all.

The thing is, as an electronics engineer, which one should I learn most!?

p.s.: and one programming language's introduction textbook is often as thick as a brick used in the Empire State Building.

 

It depends on what you want to do. You said you're a electronics engineer so I'll assume you meant embedded control.

This is a contentious and flame prone question, and no doubt will soon devolve into rants, fud and being closed by the admins, especially if one offends the Gods of C, but before it gets that far I recommend :-

Low level you can't beat Forth
High level you can't beat Forth

So my advice is Forth. It's not 'popular' like C, but it's simple enough that you can learn all of Forth and even write your own Forth in a decade or so providing you put in some effort every day. After that you can hold the entire concept in your head.

You will need to be fluent in Assembler for your chip type(s) but you can learn Assembler as you learn Forth, they compliment each other.

It's quite unlikely you can learn all of C and write your own comprehensive C compiler in that same time frame.

Here is a  Forth sample: I recommend asking other programming language advocates to submit their code for this same task so you can compare them. Note I didn't need any libraries, there are no hidden include files, everything is present here for a STM32F0xx, Cortex-M0 MCU.

This Program calculates baudrates by reading the MCU configuration. Only works with USART1 16 bit oversampling which is the reboot default and will exit if 8 bit oversampling is in use.

It uses Mecrisp-Stellaris s31.32 fixed point support to calculate the Baudrate to two decimal places so you can choose the best BRR integer to use when setting up your terminal baudrate.

More information about Forth is available in my SIG below.

.

You entered this thread preaching a Language with a tiny following trying to convert the unwashed masses. Well before the OP added some more detail.

Get off the pulpit! 

[techman-001]

BRING BACK BASIC!

(just kidding)

However, a derivative of my TinyBASIC port for the Arduino (http://hamsterworks.co.nz/mediawiki/index.php/Arduino_Basic) is in the masked ROM of every ESP32 chip.

Flash used - zero
RAM used - a tiny bit for the stack the rest is free for code.

I only found out about this from the Hackaday post - https://hackaday.com/2016/10/27/basic-interpreter-hidden-in-esp32-silicon/

WHAT THE SH*T !!!!!

That's pretty darn cool!!!

When they pinch your code and it turns up in something as widespread as the esp32-silicon that's gotta be HUGE flattery

Nothing wrong with Basic for interactive embedded development either. I still have a Intel 8049 with Dartmouth Basic in Rom from a battery powered portable hardware testing unit I made around 1991. Using it in the field was the best thing since sliced bread back then.

[techman-001]

It depends on what you want to do. You said you're a electronics engineer so I'll assume you meant embedded control.

This is a contentious and flame prone question, and no doubt will soon devolve into rants, fud and being closed by the admins, especially if one offends the Gods of C, but before it gets that far I recommend :-

Low level you can't beat Forth
High level you can't beat Forth

So my advice is Forth. It's not 'popular' like C, but it's simple enough that you can learn all of Forth and even write your own Forth in a decade or so providing you put in some effort every day. After that you can hold the entire concept in your head.

You entered this thread preaching a Language with a tiny following trying to convert the unwashed masses. Well before the OP added some more detail.

Get off the pulpit! 

No little Arduino troll, I didn't write that. You added the BOLD typeface and didn't bother to mention it to the readers.

But thank you for proving my second line was accurate.