While Arduino is a variant or subset of C it isn't quite C. Coming from Fortran, PL1, Unix variants, and A bit of basic and C, I would say I had no problem with learning it. But then I wasn't learning a language from a cold start like I did Fortran many years ago. But it's not just the language. The platform itself is not well documented as to its capabilities. Lots of beginner books out there but the most enlightening book I came across is a Sams book, "Teach Yourself Arduino Programming in 24 Hours". It gives a better in-depth appreciation for what it is capable of. Far beyond the simple Blink... Let me add this would NOT be my suggested first book on Arduino. But one for someone who already knows their way with Arduino.

 

I would think that when we use the term "embedded" I suspect we are using it in the context of professional development and career opportunities. Computers come and go. Operating systems and computer languages will come and go. Anyone still using CP/M? How much longer will C last? What will replace C? How much longer will Arduino exist? What will replace Arduino?

ASM will always be there even though in its hundreds of variants. Learning ASM is as fundamental as learning arithmetic and number systems. Learn C, yes. But learn the basics as well. Knowledge of both is transferable and will make you a better embedded engineer.

 

That's a little backwards IMO. Learning C as the language is the easiest task on the list if you have the slightest ability to program. C was designed to be simple and direct by people that programmed hardware, not a PC class machine. What's harder is using C as the platform for hardware control of devices. What I mean by that is the translation of hardware manipulation requirements into data structures and routines compatible with the abstract machine of C plus the extensions that every embedded system needs to make C work on that exact architecture. Designing embedded data structures should be a priority because with the proper data structures, interfaces and interfacing routines flow naturally with the least amount of needed computing.
https://www.coursera.org/lecture/embedded-software-hardware/1-introduction-to-data-structures-P5wI8

@nsaspook
I think you're missing my point. Someone learning should just learn C anywhere else to start. I'm not talking hardware control. Learn how to do something useful in C. It _is_ the easiest task on the list, and that's why it's a good starting point. If you can't master that, there is little point in pushing your luck with something harder.

@MrChips
I agree regarding Assembly- it's an absolute must for anyone who wants to program better in any other language. There is no substitute for understanding memory, pointers, indirection, etc. I miss the good ol' days before prefetch when you could modify your code on the fly to save space back when RAM paging and stack was at a premium.

 

Let me clarify that. Learning ASM will not make you a better programmer. But I agree with your next point. Learning ASM will give you a better understanding of how the hardware interacts with software, memory addresses, pointers, indirection, stacks, structures, unions, data types, etc.

BASIC is easier to learn than C.
BASIC was designed specifically to introduce programming at a basic level.

 

@nsaspook
I think you're missing my point. Someone learning should just learn C anywhere else to start. I'm not talking hardware control. Learn how to do something useful in C. It _is_ the easiest task on the list, and that's why it's a good starting point. If you can't master that, there is little point in pushing your luck with something harder.

I personally don't think C should be a very first language. C is an awful programming language for learning that happens to also be an extremely powerful low-level language. Easy to learn and easy to crash and burn in an instant with one stray operand. It's like giving the keys to a race-car to person with a learners driving permit. With experience you get used to walking the C programming tightrope.

All of the unsafe language freedoms that makes it a good low-level systems language makes it a wicked learning language from ground zero. An ALGOL W rooted language (Pascal lineage) IMO would be better.

 

@nsaspook
Good point.

I traveled a typical engineering route in programming languages in the '70s. FORTRAN came first followed by BASIC (with a sprinkling of CDC 6400 assembly in between). Then I was assigned a process control project in a nuclear reactor to be written in BASIC which turned to be a nightmare. Then I discovered ALGOL and got the project completed successfully.

ALGOL led to Pascal and there was no turning back with good usage of control structures and Structure Programming.
I was influenced by the work of Dahl, Dijkstra, Hoare introduced to us by our professor in a graduate level course in Computer Science (besides introducing us to APL, SNOBOL, LISP).

 

How much longer will C last? What will replace C?

A thousand languages have tried and failed to "replace" C. Compare the language spec for C++ with C and it's clear why C isn't going anywhere. It's the leanest and meanest systems language around.

The only plausible scenario in which C "dies" is if we experience a hardware revolution with a completely new hardware paradigm. But in that scenario every CPU architecture -- possibly even the load and store paradigm itself -- becomes obsolete. (I wouldn't be surprised, however, if one of the first things someone does on the new hardware is write a C compiler.)

ASM will always be there even though in its hundreds of variants. Learning ASM is as fundamental as learning arithmetic and number systems.

There is no such thing as the ASM language. Every processor has its own instruction set architecture and each assembly language implements a particular ISA. An expert in ARMv7 can write beautifully performant assembly for those CPUs, but will be completely at a loss for how to write the equivalent of hello, world in x86 assembly. Each CPU architecture has its own set of instructions (each with their own usage rules), registers and sizing conventions, memory addressing quirks, all of which must be learned in order to program them. And to write performant code, one must learn all the processor subtleties -- how many stages in the pipeline? is it superscalar? branch prediction? SIMD? FPU? multicore? cache coherency? -- all of which are handled differently by different architectures.

In short, to program in assembly one doesn't learn "assembly language", rather, one learns a particular CPU architecture. The claim that learning assembly will make you a better X is really the claim that learning how CPUs work will make you a better X. This may or may not be true, but it has nothing to do with assembly.

The irony (in light of the "How much longer will C last?" comment) is that C is essentially a universal assembly language, which makes it immune to the fast pace of CPU obsolescence, unlike actual assembly languages that necessarily live and die with their architectures.

 

What's your point?

I can think of many reasons why C programming paradigm will be replaced - OOP, associative memory, AI, neural networks, gigantic multiple processors, quantum computing...

Every C compiler that has to produce executable machine code has to convert your code to the specific MCU's machine code. In other words it has to use the native assembler. C cannot run without asm code unless you are using an interpreter, pcode or a virtual machine.

 

Has anyone else noticed that the OP seems to how the answer they were looking for,

and for last few pages, its just the normal crew that are chatting away to themselves,

 

What's your point?

What was I not clear on? You claim that "assembly language" will be around long after C. The only way that claim makes sense is if you believe that the set of assembly languages are essentially equivalent; once you know one assembly language, you pretty much know them all. I am disputing this claim.

Every C compiler that has to produce executable machine code has to convert your code to the specific MCU's machine code. In other words it has to use the native assembler. C cannot run without asm code unless you are using an interpreter, pcode or a virtual machine.

Now I have to ask what's your point? The fact that C compiles to assembly in any architecture is precisely why it will exist long after any particular assembler's language has gone obsolete. C is the closest thing we have to portable assembly, and a portable language will always outlast a non-portable language. Every assembly language is, by definition and design, not portable.

 

Has anyone else noticed that the OP seems to how the answer they were looking for,

and for last few pages, its just the normal crew that are chatting away to themselves,

Maybe the OP will learn something else in addition to the original question.

 

By the time I got my first job as a software engineer and data analyst, I had coded in many languages. Basic, Fortran, COBOL, LISP, ALGOL, Pascal and assembly. The broad selection of languages had more to do with my understanding of a processors internals than assembly.

I worked on a major project written almost entirely in Fortran. One part was implementing a hierarchical database system, before commercial products became available. The first iteration was dog slow. The project manager profiled the software calls, and several routines were rewritten in assembly. Performance issues disappeared.

So I propose another approach. Put yourself in a position to learn and use multiple languages in a variety of applications. Basic, C, Arduino, PHP, and maybe even Java. If you want to professionally develop code, broaden your horizons.

UPDATE: The second and third languages should be easier to learn. You’ll eventually get to the point that the language is irrelevant. You’ll be productive in any language in a day!

 

“C is portable assembler.”? Yes, to a thin machine that doesn't exist. C is not how the physical computer works, it's a thin layer that's easy to paste into real hardware but that pasting part is not a component of the C language. Most of the time you don't care and it's not important how that process happens but with small embedded systems it's usually very important to understand (like how the optimizer can change CPU derived timing and sequencing) that process. For this we need the actual datasheets of the device, not the C language manual. With an understanding of both we can learn more about how the machine works.
https://c0x.coding-guidelines.com/5.1.2.3.html
184 The semantic descriptions in this International Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant.

In the context of learning, my question is really this.

Are thin languages like the C a good one for for learning hopefully the principles of structured programming? I call the C language thin because it cuts the 'crap' of mandatory structure other than what's demanded by it's very wide definition of what's a valid program like a reasonable assembler should. This is great after you have the discipline to know when to not pull unstructured and Obfuscated C language tricks that would make a optimizing compiler ASM code generator blush.

int main(int b,char**i){long long n=B,a=I^n,r=(a/b&a)>>4,y=atoi(*++i),_=(((a^n/b)*(y>>T)|y>>S)&r)|(a^r);printf("%.8s\n",(char*)&_);}

https://github.com/ioccc-src/winner/tree/main/2020/burton

One of my kids has shown an interest in programming so I'm really trying to push her to looking at the more theoretical side of structured programming after looking a some of the first robotics code she started with last year before the Pandemic shutdown the program.

 

Maybe the OP will learn something else in addition to the original question.

That's possible @nsaspook

I look through the posts,

And what I see are one line answers

and a debate on the lines of this is my favourite, and when some one disagrees, the reply no your wrong

Im not certain what that would teach the OP,
may be that there are as many religious wars on forums as else where

 

Forget all the other languages and use FORTH
(That is what we used on 6502 core based controllers like the 6511AQ, and a Mitubishi on that I can't remember the type number of)
Oh, how could I forget the vision fruit sorter we made with the RTX2000 FORTH engine!

EDIT: This discussion as gotten way off the original question I feel. I hope the TS gets something from this all.

 

Forget all the other languages and use FORTH
(That is what we used on 6502 core based controllers like the 6511AQ, and a Mitubishi on that I can't remember the type number of)
Oh, how could I forget the vision fruit sorter we made with the RTX2000 FORTH engine!

What ever happened to FORTH,

 

Forget all the other languages and use FORTH
(That is what we used on 6502 core based controllers like the 6511AQ, and a Mitubishi on that I can't remember the type number of)
Oh, how could I forget the vision fruit sorter we made with the RTX2000 FORTH engine!

Been there, done that, No thanks.
https://forum.allaboutcircuits.com/...s-that-are-still-running.132038/#post-1092256

 

That's possible @nsaspook

I look through the posts,

And what I see are one line answers

and a debate on the lines of this is my favourite, and when some one disagrees, the reply no your wrong

Im not certain what that would teach the OP,
may be that there are as many religious wars on forums as else where

Even expert opinions are inconsistent, what's why there are so many experts.

 

Even expert opinions are inconsistent, what's why there are so many experts.

Good point

 

What was I not clear on? You claim that "assembly language" will be around long after C. The only way that claim makes sense is if you believe that the set of assembly languages are essentially equivalent; once you know one assembly language, you pretty much know them all. I am disputing this claim.

There is no universal asm language. You and I know that. Machine instructions are different from manufacturer to manufacturer, and even across members of the same family. Machine code is the native instruction of the machine. It is like the DNA in your system. It will never go away.

Now I have to ask what's your point? The fact that C compiles to assembly in any architecture is precisely why it will exist long after any particular assembler's language has gone obsolete. C is the closest thing we have to portable assembly, and a portable language will always outlast a non-portable language. Every assembly language is, by definition and design, not portable.

My point is languages come and go. One of these days C will be gone.
In 80 years of computing, see how many programming languages have evolved and disappeared.
https://en.wikipedia.org/wiki/Timeline_of_programming_languages

In terms of relevance of usage in 2021, with respect to the job market, Python tops the List.
https://www.northeastern.edu/graduate/blog/most-popular-programming-languages/