Too many programming languages?

[Berni]

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/

I had no idea about Basic being inside a ESP32. Its indeed likely meant just as an Easter egg but it does appear to be functional enough to actually do something useful.

But yeah these days if you want to program with an interactive shell Python is the way to go. Yes its not exactly fast or resource efficient, but when you want to just quickly throw together a little tool its hard to beat.

You are not going to want to build an entire product in Python. But the tons of community maintained libraries and simple easy to read language make it excellent for getting a working program in as short of a time as possible. The interactive feature of it also helps that because you can import your python program into the interactive console and then call functions and set variables manually to quickly see how a piece of code or library behaves rather than iteratively changing a line of code and re-running the whole lot.

For example if you need a tool that collects the pictures in a folder that have A in there name, checks if more than 50% of the picture has a red color and then save a thumbnail of that picture into another folder. Then you can do that with Python in about 10 or 20 lines after installing a few libraries trough the built in "pip install" feature.

Running python on a MCU tho...eww please no.

[beanflying]

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.

Smile when you say that I am actually a Fortran and Motorola 6800 Troll  What part of the bold type is not preaching from your Forth or die mantra. It is one tool like yourself that has a purpose but it is not a Universal one!

https://www.embedded.com/electronics-blogs/break-points/4023811/I-Hate-Forth

[techman-001]

Running python on a MCU tho...eww please no.

I reviewed it on a Cortex-M4 with 1MB Flash and MicroPython was pretty slick but quite different to my Forth system.

Where I click on 'make' and my Forth source is serially uploaded at 460800 baud to my mcu, MicroPython required the use of a pseudo /dev/usb-bulk storage facility on the target and a GUI on  the PC where one drags and drops the source file into the pseudo /dev/usb-bulk storage and it then flashes the mcu automatically.

It had a nice well designed feel about it. I think the MicroPython guys did a good job. For a Forth hater, MicroPython may be their interactive solution providing they have the on chip resources such as USB and memory, don't mind a garbage collector stealing cpu cycles or a 30x slowdown compared to Forth. Of course for interactive debugging the slowdown isn't usually a issue.

I note that STM now offer this same type of flashing facility in the STMXxx Nucleos with SWDv2.1

[techman-001]

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.

Smile when you say that I am actually a Fortran and Motorola 6800 Troll <snip>

Hard to believe because you actually recommended Arduino to the OP.

Not that I cared at the time, before you declared yourself to be a ranting Forth hater.

[beanflying]

If you want to selectively read a paragraph out of context yes I absolutely did but that is not my background which is fairly clear in the first bit. Some of the world has moved on from programming from 30+ years ago and the OP asked which he should learn. For good reason I didn't put up Fortran or Pascal in spite of them still being in use at reasonable levels.

The sensible and even pragmatic answer is still C or derivatives and or Python in the current times. Which micro you wrap them around is largely irrelevant but the Arduino IDE and platform is an easy one to get into but certainly not the most powerful.

Forth is niche and has a use but it is no way as you made claim to in your opening post!

[techman-001]

If you want to selectively read a paragraph out of context yes I absolutely did but that is not my background which is fairly clear in the first bit. Some of the world has moved on from programming from 30+ years ago and the OP asked which he should learn. For good reason I didn't put up Fortran or Pascal in spite of them still being in use at reasonable levels.

The sensible and even pragmatic answer is still C or derivatives and or Python in the current times. Which micro you wrap them around is largely irrelevant but the Arduino IDE and platform is an easy one to get into but certainly not the most powerful.

Forth is niche and has a use but it is no way as you made claim to in your opening post!

I only cut for brevity, everyone here can easily scroll down a few inches to see the full extent of your rantings if they so desire.

I'm still wondering why you say anything about Forth as you clearly don't know anything about it. You haven't argued ONE single technical reason why your choice (Arduino) is better than Forth or why Forth is unsuitable. All I've seen so far are emotive rants and mantras.

Fortran and Pascal are still in widespread use, but neither will run interactively on a STM32 so suggesting them would have been pretty stupid.

The Forth I use is a modern Forth, it runs on Cortex-M, namely STM32 the same MCU as the OP uses.

I wonder if you even realize that C and Forth are around the same age with both being designed in the early 1970's ?

I welcome any technical debate about Forth with you, but statements such as "Forth is niche" are well outside the OPs stated requirement. He asked for suggestions regarding a embedded programming language to learn and debug his STM32 boards I2C.

Perhaps you would like to try and criticize me again for suggesting a programming language that ran on his STM32 board *before* anyone here knew what hardware he actually had ?

You could start by demonstrating how your suggestion of Arduino will help him debug the I2C on his already designed and built STM32 board ?

[beanflying]

Yawn "Which micro you wrap them around is largely irrelevant but the Arduino IDE and platform is an easy one to get into" This is not a which micro is better than yours so stop muddying the topic. Arduino vs the rest is another can of worms for another thread at another time.

You are still preaching for a Language with perhaps less than a 0.2% AGAINST user base against C and derivatives at over 20%. Nothing wrong with Forth and the article I linked from Jack Ganslle while old still holds up and even in the comments there the disciples of Forth are present to defend the faith. https://www.embedded.com/electronics-blogs/break-points/4023811/I-Hate-Forth

Like suggesting an English speaker someone learn Latin first so they can then learn Italian...... Any guesses which Language I think Forth is?

[legacy]

BRING BACK BASIC!

(just kidding)

However, a derivative of my TinyBASIC port for the Arduino

I have a copy of "Dr. Dobb's Collection 1994", it comes with "lists" of assembly code. One of them is Basic68k, which has been recently reversed-coded from assembly/68k to C.

Yes, a full inverse processing through the tool Ida combined to a sort of "C language pattern matching", funny, ain't it?

It took several months, according to the author. Anyway, this way it's possible to recompile it for different CPU-targets rather than only for the old m68k, and one immediately consequence: ported to Arduino 

[legacy]

I still have a Intel 8049 with Dartmouth Basic in Rom

like this one? 

8051 with Intel Basic in ROM. GW-Basic ("basic with lines number") is still a used programing language. I mean, someone still uses it for the industry.

In Japan, there are still a couple of pocket computer calculators, that use Basic. The Sharp PC-e500 comes with gw-basic, an d CASIO-basic is what you find in every graphic scientific calculator, etc, but I have recently seen even a big industrial embroidery machine taking its frame input from a Basic console 

[techman-001]

I still have a Intel 8049 with Dartmouth Basic in Rom

like this one? 

8051 with Intel Basic in ROM. GW-Basic ("basic with lines number") is still a used programing language. I mean, someone still uses it for the industry.

In Japan, there are still a couple of pocket computer calculators, that use Basic. The Sharp PC-e500 comes with gw-basic, an d CASIO-basic is what you find in every graphic scientific calculator, etc, but I have recently seen even a big industrial embroidery machine taking its frame input from a Basic console 

No, just a spare chip. I was mistaken, it's not a 8049 as you can see from the pic I just took, it's a 8052 with onboard Basic. I think I ordered two back in 85, built up my own board and kept one as a spare.

[Sal Ammoniac]

C++ is an abortionate mess where knowledgable people spend a lot of time arguing over what ought to happen.

Hee, hee, hee! We share the same opinion of C++.

[mrflibble]

C++ is an abortionate mess where knowledgable people spend a lot of time arguing over what ought to happen.

Hee, hee, hee! We share the same opinion of C++.

I like it! That one is going in the QUOTES file.

And that is from someone who uses said abortionate mess on a voluntary basis. I'm sorry, but OpenMP is just too convenient.

Oh oh oh, and since I vaguely hear some spirited Forth debate on the background ... Question for those more in the know in the land of Forth: Is there a framework along the lines of OpenMP for Forth? Reason I ask is I'd like to do a comparison of several prime sieve implementations written in different languages. And among the permutations are, yes, a few multi-threaded ones. So for example for C/C++ I use OpenMP. I wonder if there's something like it for Forth.

I noticed on the wikipedia page on threaded code that Forth does support the notion of threads, the exact flavor apparently depending on compiler X vs compiler Y. So there is some hope, but I could not find a Forth equivalent of "The OpenMP API specification for parallel programming". Having to explicitly code all the synchronization & blockers and whatnot is somewhat ... inefficient in terms of developer hours spent.

[SiliconWizard]

Oh, many have said similar things about C++. A couple famous.

http://harmful.cat-v.org/software/c++/linus

"C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C."

http://tex.loria.fr/litte/knuth-interview

"The problem that I have with them today is that... C++ is too
complicated. At the moment, it's impossible for me to write portable
code that I believe would work on lots of different systems, unless I
avoid all exotic features. Whenever the C++ language designers had two
competing ideas as to how they should solve some problem, they said
"OK, we'll do them both". So the language is too baroque for my taste."

(It has become much worse compared to when he said that.)

Bjarne Stroustrup is actually a smart guy.
Maybe too smart for us mere mortals. 

[techman-001]

C++ is an abortionate mess where knowledgable people spend a lot of time arguing over what ought to happen.

Hee, hee, hee! We share the same opinion of C++.

I like it! That one is going in the QUOTES file.

And that is from someone who uses said abortionate mess on a voluntary basis. I'm sorry, but OpenMP is just too convenient.

Oh oh oh, and since I vaguely hear some spirited Forth debate on the background ... Question for those more in the know in the land of Forth: Is there a framework along the lines of OpenMP for Forth? Reason I ask is I'd like to do a comparison of several prime sieve implementations written in different languages. And among the permutations are, yes, a few multi-threaded ones. So for example for C/C++ I use OpenMP. I wonder if there's something like it for Forth.

I noticed on the wikipedia page on threaded code that Forth does support the notion of threads, the exact flavor apparently depending on compiler X vs compiler Y. So there is some hope, but I could not find a Forth equivalent of "The OpenMP API specification for parallel programming". Having to explicitly code all the synchronization & blockers and whatnot is somewhat ... inefficient in terms of developer hours spent.

"Is there a framework along the lines of OpenMP for Forth?"  I very much doubt it.

The only multiprocessor parallel processing Forth I know of is the Green Arrays 144 processor chip the GA144. Development of this system started in 2009. The GA144 not only has 144 Forth processors, it is fully clockless.

http://www.greenarraychips.com/index.html

There are some very slick videos on the GA144 by Daniel Kalny:
Forth Day 2016 presentation on Digital Image Processing Implemented in GA144:

[Kjelt]

The OO way of thinking / designing is great for many IT projects but less for small embedded projects IMO.
The good parts can also be done in C.
Each language has its benefits and drawbacks, domains to be applied succesfully and not.
Clean programming has nothing to do with the language it self but everything with the programmer and where and how he learned to program. I reviewed Mlocs of code in my jobs and had many discussions with many programmers and it always came down to where and how they learned to write code.

[bjdhjy888]

Why do they often put pictures of various animals on the cover of programming books? e.g.:

[SiliconWizard]

Why do they often put pictures of various animals on the cover of programming books? e.g.:

Note that the Java book has a much more "aggressive/wild" cover, while the C# one looks completely innocuous. Go figure...

[rstofer]

Why do they often put pictures of various animals on the cover of programming books? e.g.:

Note that the Java book has a much more "aggressive/wild" cover, while the C# one looks completely innocuous. Go figure...

O'Reilly started putting animals on the cover of their books a very long time ago.  It's just the way you can tell an O'Reilly book from everything else.

https://www.oreilly.com/ideas/a-short-history-of-the-oreilly-animals

[CatalinaWOW]

Why do they often put pictures of various animals on the cover of programming books? e.g.:

Note that the Java book has a much more "aggressive/wild" cover, while the C# one looks completely innocuous. Go figure...

O'Reilly started putting animals on the cover of their books a very long time ago.  It's just the way you can tell an O'Reilly book from everything else.

https://www.oreilly.com/ideas/a-short-history-of-the-oreilly-animals

Great story on how the animals came to be there.  I am sure that the fact that copyrights were expired or non-existent on these images was not a factor at all.   

[nigelwright7557]

Its horses for courses.
I wouldn't use a C compiler for code in a tiny 8 pin PIC micro.
And conversely I wouldnt use assembler for a 32 bit micro.

I first learned assembler, then C, then Delphi Pascal, then C# then most of the web programming languages.

These days things have moved on a lot with Mplab Harmony for the larger PIC micro's.

[GeorgeOfTheJungle]

The OO way of thinking / designing is great for many IT projects but less for small embedded projects IMO.

It depends on your definition of small and embedded. Right now in front of me there's a bunch of esp32s, and I've been writing a lot of C++ object::object()s for them lately. By the way, the esp32 rocks!

[Berni]

Its not that the OO stuff in C++ is bad.

Its more of an issue that people often don't use it right. They end up writing too many objects for every single little thing, stuffing them full of advanced C++ functionality because why wouldn't you if you have it and that's how you show off being a better programmer than everyone else. Then as the project goes on these objects start getting linked up to everything else more and more as they later on figure out they needed the two objects to do something with each other but there are like 4 other objects in the chain between them, so they say fuck it and call something directly in that object. The whole thing in the end becomes a huge tangled mess of objects that are no longer self contained units at all since trying to move one object into another project pulls half of the code from this program behind it in the form of code dependencies.

This happens especially easily for people that learn C++ as there first language and are taught to embrace this OO idea as much as possible.

I like to look at C++ as more of "Syntax sugar for C". You can do most of the stuff in C that C++ lets you do, but in C the code to do it can sometimes be long, messy and annoying. So instead of clinging to the object oriented ideology, instead just pretend you are writing C code, but when objects look like something that could simplify your code then use them.

You can write horrible code in any language, its just that C++ makes it easier to do so compared to C.

Performance wise C++ can be just as fast if you know what you are doing and not overuse its fancy features.

[GeorgeOfTheJungle]

But what's the meaning of small today? Because a small (it's really tiny!) esp32 is orders of magnitude more powerful than a desktop^W "workstation" PC of the 90's, but it's the size of a stamp. Therefore C++ makes sense, because this is by no means the 8051, PIC or 328p µC of bygone days.

https://en.wikipedia.org/wiki/Macintosh_Quadra_950

[Kjelt]

If you are indeed using something like sockets with many instances OO can become interesting, valid point.

What is small and what not is a topic on its own. I have done embedded programming on a machine that incorporated 3 sun workstations, 64GB of RAM and 2TB of storage each and I did not agree that this was an embedded software job at all  Still the manufacturer insisted of calling it embedded software since it was running inside a machine (the size of an office space). 

I also worked with an 8 bit uC with 128bytes of RAM and 2kB of ROM, now that I would not even call small but miniscule 

So yes the definition has become blurry over time. My old definition that anything with a display and GUI is not embedded was valid till 2005 or so when the small LCD displays became attached to dedicated uC's. So I kinda extended my personal definition of embedded as anything that has no GPU card , very disputable I know but I can't think of a better definition, perhaps someone else can.

[Berni]

Yeah the line of whats embedded software and whats just software can be quite fuzzy.

I suppose you can call embedded software stuff that runs on things that the general public doesn't consider as being a 'computer'. But then again what do smartphones belong into? You could definitely call the software running on an old Nokia 3310 as being embedded software, but the youtube app on a smartphone doesn't seam like it would count as that.

I guess one reason that people sometimes cringe at OO on microcontrolers is that in a lot of cases the resource usage tend to be hard to determine at compile time. But you can write such software in C too as soon as you start using malloc, but there its even easier to hog resources if you forget to release memory. In my opinion nothing wrong with C++ on things with 10s of KB of RAM, as long as its good C++ code and not a mess of shoehorned in advanced C++ features for the sake of using them.