“C is portable assembler.”? Yes, to a thin machine that doesn't exist. C is not how the physical computer works

That's the point -- there is no single "how the physical computer works". Every computer is isomorphic to any other as an abstract machine -- i.e., they all have the same computational power/expressivity -- but every implementation (the architecture) is unique. The C language provides just enough abstraction to be implementable on any machine, but not so much that it prevents the programmer from "touching" the hardware.

Are thin languages like the C a good one for for learning hopefully the principles of structured programming?

I wouldn't recommend C as a first language to a casual learner, someone who just wants to get their feet wet in programming. Better, I think, is to learn the basics of logic and flow control with a highly-abstracted untyped language. C is just too pointy with sharp edges for comfortably learning the basics. The lack of a first-class string data type is a source of frustration and wasted time for newbies, who at that level should be spending their time writing/breaking/fixing more complex programs, not wrestling with C's idiosyncracies.

C is great for experienced programmers who need to be close to the hardware because it's small, simple, and mostly stays out of their way. But new programmers aren't actually creating programs to solve problems, they're creating programs to learn how to think about logic in a structured way. C's lack of abstraction is a hindrance in this regard.

 

In terms of relevance of usage in 2021, with respect to the job market, Python tops the List.

With that in mind, maybe start with a Raspberry Pi Pico. A very cheap board with quite a decent amount of documentation to help.
The RasPi ecosystem is pretty extensive and easy to get help with.

 

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.

I'm still not sure what your point is. If you learn an assembly language, you've learned the "DNA" for one particular processor. That processor will surely go away long before C goes away.

My point is languages come and go. One of these days C will be gone.

C will be around far longer than any assembly language you care to name. How is this not obvious to you?

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/

Python, like Perl before it, will surely be replaced by the next script language du jour. C (a top 5 language in your list) is more than 50 years old, and it's remained relevant because it fills a unique need as a systems language. C isn't going anywhere.

 

What ever happened to FORTH,

It drank a FIFTH, developed a LISP and PASCALed out on the BUS.

 

With that in mind, maybe start with a Raspberry Pi Pico. A very cheap board with quite a decent amount of documentation to help.
The RasPi ecosystem is pretty extensive and easy to get help with.

It's a good controller but the amount of documentation (as is to be expected from a multi-processor 32-bit controller) is daunting for a beginner looking under the hood. If you stay in the Python 'Flower Garden' or a eventual Arduino support compatibility layer things are better.

In the hands of a device hardware and software 'expert' (Raspberry foundation engineers) the results are impressive.
https://github.com/Wren6991/picodvi

 

It drank a FIFTH, developed a LISP and PASCALed out on the BUS.

very clever..

like it

 

C will be around far longer than any assembly language you care to name. How is this not obvious to you?

Can you name an assembly language?
Assembly language which is converted to machine code is what makes the machine run.

Can you name me gasoline that makes your car engine run?

 

Well, you could name it Bob...

 

Can you name an assembly language?

I can't tell if you're being facetious, but I'll take you at face value. Since there is no such thing as the assembly language, each assembler (the software that actually produces the machine code) defines its own language. Some of these have names, but everyone simply calls them by the name of the assembler. So, for example, Microsoft's arm assembly language is called armasm; Microchip's AVR assembler is called avrasm2; GNU's assembler is called gas. Etc.

And though each language has its own syntax, features, and labeling conventions, the only truly important difference between them is their target architecture. So, for example, people typically refer to any 32-bit Intel assembly language as 'x86', even though the various x86 assemblers don't have compatible syntax. This usage reflects the fact that for assembly languages the ISA is what is important. Language details, like the order of the operands or how immediate values are represented, aren't significant -- the resulting opcodes are the same regardless. In this sense, we can name any assembly language by its target ISA: x86, x64, ARMv7, etc.

Assembly language which is converted to machine code is what makes the machine run.

What's the actual point of this over-simplified statement? You said it in response to my argument that C is architecture independent and therefore will outlast any given assembly language, which is necessarily dependent on a specific architecture. You keep using "assembly language" as if it means the set of all possible assembly languages, as if they form an equivalence class. But this is clearly a false equivalence: a person who learns MIPS64 does not suddenly know how to program x86.

 

You guys realize TS threw in the towel 60 posts ago and is probably at home playing with Legos, having given up on dreams to enter the world of electronics?

(Exactly the sort of thing Arduino was meant to address) <js>

 

You guys realize TS threw in the towel 60 posts ago and is probably at home playing with Legos, having given up on dreams to enter the world of electronics?

(Exactly the sort of thing Arduino was meant to address) <js>

If the TS did then the actual interest level was pretty low. When I was a kid, Hell, High Water or a bunch ofl blowhard experts would have never stopped me from exploring or learning.

 

Let's see if we can bring this round of discussion to a close.

TS, if you are still reading here is my suggestion.
If you are now starting out and you are goal oriented, start with Arduino and learn and be proficient with C programming language. If you want to advance further into a possible career in embedded systems, learn the assembly language of any MCU.
Since the Arduino is based on Atmel ATmega328, learn to program this chip using assembly language and C, together.
If you want to go further, learn in addition to C and assembly language, Python, Java, PHP, MATLAB.

 

If the TS did then the actual interest level was pretty low. When I was a kid Hell, High Water or a bunch ofl blowhard experts would have never stopped me from exploring or learning.

I remember my introduction to physics and online panels of blowhard experts quite well. I must have been around 10-12. I was homeschooled, so no science teachers to bounce bad ideas off of. My parents thought my idea was good, worth pursuing, so I was allowed onto the newsgroups to seek further help. My idea was to make a motor which ran solely on magnets held in opposition. A perpetual motion machine, I learned from less than gentle explanation. They were ruthless. I was a pretty well spoken kid, so they probably never suspected I was anything other than an adult and an unforgivable idiot. I learned a lot from that though. First time I'd ever heard the word "thermodynamics." It spawned new interests.

 

My answer is neither and both. What you should do is pick one - flip a coin. If it does what you expect then go explore the other. If it doesn't do what you want then go explore the other.

I agree, the important part is jumping in not being in indecision about whether it’s better to learn to swim in a river or a pool

 

Okay so lets say I don't know anything about PIC microcontrollers (because I don't) and wanted to learn. Where would I start? well.

There is the Nigel Goodwin pic tutorials, if you prefer C over assy, then there are converted programs for them out there.
Also Picmicro has many APP-notes for most applications.
Max.

 

I agree, the important part is jumping in not being in indecision about whether it’s better to learn to swim in a river or a pool

I like your learning to swim analogy, but personally I learned to swim in a pool at the shallow end, If you try jumping in a river you can soon be in over your head. So I would recommend the Arduino. For learning the basics there is nothing better, that is exactly what it was designed for. They are so low cost if you find it too basic just move on to PICs.

 

Since the Mars rover is currently in the news, it should be pointed out that the rover systems were programmed in C, not assembly. Assembly just isn't pertinent today.

 

Since the Mars rover is currently in the news, it should be pointed out that the rover systems were programmed in C, not assembly. Assembly just isn't pertinent today.

Likely someone wrote some RDA750 computer RTOS bootstraps and custom hardware drivers in Assembly within the codebase. It might have been with inline asm using C under VxWorks.
https://www.artisantg.com/TestMeasurement/94829-1/BAE-Systems-RAD750-3U-cPCI-Single-Board-Computer
Compiled C code is machine code, assembly language is machine code. Somewhere there is a machine code list of the program and people who know how to read it.

https://ai.jpl.nasa.gov/public/documents/papers/rabideau_iwpss2017_prototyping.pdf
https://www.cio.com/article/3569577...e-mars-rover-perseverance-an-inside-look.html

 

Compiled C code is machine code, assembly language is machine code. Somewhere there is a machine code list of the program and people who know how to read it.

Compiled *any* code is machine code. People aren't learning/using assembly because it gives them a better use/understanding of the hardware.

 

Compiled *any* code is machine code. People aren't learning/using assembly because it gives them a better use/understanding of the hardware.

I disagree about learning and having a good understanding of a specific machine assembly if you're required to code detailed low-level functions on the hardware. The C abstract machine doesn't describe the underlying machine hardware, compilers are not perfect, compiler coded optimizations are not exactly what we need for X hardware interface and there are times you need to completely escape the C abstract machine and OS. To really understand the hardware you MUST know something about the instruction set, memory architecture, register architecture, etc .... Do you believe that Linus (and the people that port Linux to various hardware platforms) don't deeply understand the assembly code the compiler produces to be linked to machine code.