Pointers in C + Arduino Tutorial

[netwinder]

Hello EEVBlog fourm!

Reading through code online I got tired of seeing overly complicated code that could easily benefit from pointers. So I wrote a tutorial on it http://advtech.ca/index.php/arduino-c-pointers/ Tell me what you think

[nctnico]

Oh please stop!!! Pointers are the enemy of robust code. Too much can go wrong with pointers and that is why seasoned programmers avoid pointers as much as possible. Ever heard about buffer overflows and random crashes? That is the evil called pointers at work!

[helius]

I tend to agree, but in a language like C or Wiring there is not much you can do without them. With advanced C++ template metaprogramming it is possible to get away from pointers.

[Ian.M]

OTOH C arrays without extra bounds checking code for the index are just as dangerous, and as you cant pass arrays by value and sizeof() only works on the original array in the module its defined in, its a real PITA defining:

Code: [Select]

const unsigned int array_size=sizeof(array)/sizeof(array[0]);for each array in each source module, then adding extern declaration for all the array_size consts to the headers, and passing the array size with the array to every function that uses it so you can actually do the bounds checking to make it safe.

C++ is a little better as you can localise the code that accesses the array more easily without adding cruft to its interfaces, but when you get down and dirty, the implementation is just as fugly + the compilers are generally less trustworthy.

TLDR: Don't write code that needs repeated data structures and an absolute guarantee of no rogue memory accesses in C or C++.     

[Maxlor]

It's a nice tutorial. If you are looking for additional things to put in it, here are some suggestions:

- Be a bit more explicit about the difference of * in a declaration and when used as an operator.
- Discuss some common use cases of pointers; you show some examples, but none of them show the benefit of actually using pointers. I'm thinking that you could discuss:
  -- The most common example of pointer usage in all of C, strings!
  -- Output parameters on functions
  -- Being able to write more generic code, through, say, having 3 different configurations in 3 structs of the same type, then switching between them through a pointer at runtime.
  -- How using pointers instead of by-value parameters is more efficient; you should show this with structs though, not arrays.
- Actually I think that using pointer arithmetics instead of array indexing is less clear and should be avoided. There is one common use of pointer arithmetics though: STL-style iterators. Maybe explain how those work?
- char **argv. Or generally, why you sometimes see ** (array of C strings, or returning a pointer as an output parameter.)
- Discuss some of the more common types of program crashes caused by incorrect pointer usage, i.e. show which error leads to which crash, so people recognize the cause more easily.

That's all I can think of at the moment. Also, don't get discouraged by the people hating pointers. You can't avoid them if you're using C, and certainly not if you want to read and understand other people's code. Learning about them is a good thing.

[langwadt]

OTOH C arrays without extra bounds checking code for the index are just as dangerous,

that is probably because arrays and pointers go together as in; 

array == &array[0]

[Ian.M]

Yes that's the general issue, but the two are not strictly identical as in the original source module sizeof() can get the total array size from the array name, but not from &array[0].   That's just one of the nasty traps for the unwary in C and C++, compounded by the fact that it cant get the array size from an extern declaration that doesn't explicitly include the size, which leads to madness like:
-header-

Code: [Select]

#define ARRAY_SIZE=7
extern int array[ARRAY_SIZE];
-module-

Code: [Select]

int array[]={ 65, 66, 71, 34, 90, 23, 11};
assert(ARRAY_SIZE==sizeof(array)/sizeof(array[0]));
just to attempt to confirm the initialiser list matches the expected array size.

[hamster_nz]

Oh please stop!!! Pointers are the enemy of robust code. Too much can go wrong with pointers and that is why seasoned programmers avoid pointers as much as possible. Ever heard about buffer overflows and random crashes? That is the evil called pointers at work!

Any code is the enemy of robust code... I for one do not want to give up dynamic memory allocation.

Buffer overflows don't even need pointers...

Code: [Select]

   char buffer[10];
   for(i = 0; i < 11; i++)
     buffer[i] = 0;


[helius]

Buffer overflows don't even need pointers...

If you refer to the C standard, that code uses a pointer that is the result of the standard conversion of buffer. The only cases where array variables are not converted to pointers are when they are defined, or inside a sizeof expression.

[hamster_nz]

Buffer overflows don't even need pointers...

If you refer to the C standard, that code uses a pointer that is the result of the standard conversion of buffer. The only cases where array variables are not converted to pointers are when they are defined, or inside a sizeof expression.

I understand what you are saying, but as that example code was to illustrate the removing pointers from your source code does not eliminate buffer overruns - the ability to overflow any storage allocations is a side effect many aspects of the language.

I would conjecture that avoiding pointers might encourage buffer overflows in any moderately complex code, as without pointers you can't dynamically allocate storage for data that has an unknown size at compile time. Code then becomes littered with stuff like "char file_name[128]" and other statically allocated buffers that can be abused. better to:

Code: [Select]

  char *path_name;

  path_name = malloc(strlen(dir_name)+1+strlen(file_name)+1);
  if(path_name == NULL)
    return -1;

  sprintf(path_name,"%s/%s", dir_name, file_name);

  /* Use the path_name to do stuff */

  free(path_name);

You can't overflow path_name in that code...

[Mechatrommer]

Oh please stop!!! Pointers are the enemy of robust code.

barking at the wrong tree? instead of barking at one ownself? yeah keep blaming the tools. what i recently have is a program made out of a so called robust language, its a species of a snake. every time running it to make a usefull job, i almost always want to pull my hair out, the efficiency of the algorithm is close to 1%, too darn slow, for simply merging 2 polygons. to add insult to the pain, its the only free tool that can do the job out there.

[helius]

I understand what you are saying, but as that example code was to illustrate the removing pointers from your source code does not eliminate buffer overruns - the ability to overflow any storage allocations is a side effect many aspects of the language.

Agreed; my point is that it is really impossible to avoid pointers for all but the simplest programs in this language. So even if you think you have done it, that is not likely the case. (Does your program have a main(char, char**)?) Does your example actually demonstrate the removal of all pointers from a program? I would suggest not, since in C when arrays are used, it's almost always as pointers. To not use any arrays as pointers makes them largely useless.

I would conjecture that avoiding pointers might encourage buffer overflows in any moderately complex code, as without pointers you can't dynamically allocate storage for data that has an unknown size at compile time. Code then becomes littered with stuff like "char file_name[128]" and other statically allocated buffers that can be abused.

Since I've shown that "avoiding pointers" is a flat impossibility, we have no reason to speculate on its effects. The static allocation of buffers is a different topic and I don't think you have made a strong case: in practice, dynamically allocated buffers are equally subject to overflows in C because it is not trivial to calculate the required size. They add an additional bug source because each dynamic allocation must be explicitly tested for failure and the program must choose what to do.

[Mechatrommer]

havent they learnt about making type-safe, or auto boundary checking, or even memory management built in "data-class"? if anyone want to customized boundary-checked type-safe data type, that certainly can be made in C++, that other languages are very remotely incapable in this regard. how do they think that safe-data-types on the other languages are made?

[hamster_nz]

I understand what you are saying, but as that example code was to illustrate the removing pointers from your source code does not eliminate buffer overruns - the ability to overflow any storage allocations is a side effect many aspects of the language.

Agreed; my point is that it is really impossible to avoid pointers for all but the simplest programs in this language. So even if you think you have done it, that is not likely the case. (Does your program have a main(char, char**)?) Does your example actually demonstrate the removal of all pointers from a program? I would suggest not, since in C when arrays are used, it's almost always as pointers. To not use any arrays as pointers makes them largely useless.

I did say "source code", and I believe that "int main(void)" is accepted by most compilers if you don't want to use command line arguments.... and of course you would be a fool to avoid pointers most of the time (however for some situations that is the best thing to do...).

Which brings us back to Nctnico's the original post on not using pointers, and why I feel it is too harsh...

Pointers in C are a very sharp tool, and you need to be careful where and when you wave the around. However telling everybody to chop trees with a blunt axe because they might cut themselves is just silly.

[Keicar]

Misuse of pointers is the source of much pain & suffering, it's true - and they do make it pretty easy to stab yourself in the eye, but the solution to this does not lay in fostering ignorance. Sure, when you first learn a technique you're liable to overuse it (Maslow's Hammer springs to mind) - but eventually you learn the pitfalls, and adopt a disciplined approach - but you can only do that based on knowledge. And if you ever have to work on other people's code, you always face the possibility of coming up against someone's nightmarish sh*tstorm of indirection, so it's best to be prepared with a full working knowledge of your chosen language.

[obiwanjacobi]

The potentially dangerous but powerful tools a language offers should be kept in check.
If you have to think about all the details with every line of code you type, it wil be tiresome fast. That is why I like to encapsulate that stuff. Now that is not a free ride either, but when carefully constructed can make your life easier.

Here is my solution for an array for instance.
http://atl.codeplex.com/SourceControl/latest#Source/Code/ArduinoTemplateLibrary/Array.h

(You 'store' the size with the instance and you perform bounds checks)
I know it's not C but C++... I personally don't see any advantage in using C - unless that is the only compiler you have...

[netwinder]

Sorry about getting back so late - I would have enjoyed contributing to this discussion.

It's a nice tutorial. If you are looking for additional things to put in it, here are some suggestions:

- Be a bit more explicit about the difference of * in a declaration and when used as an operator.
- Discuss some common use cases of pointers; you show some examples, but none of them show the benefit of actually using pointers. I'm thinking that you could discuss:
  -- The most common example of pointer usage in all of C, strings!
  -- Output parameters on functions
  -- Being able to write more generic code, through, say, having 3 different configurations in 3 structs of the same type, then switching between them through a pointer at runtime.
  -- How using pointers instead of by-value parameters is more efficient; you should show this with structs though, not arrays.
- Actually I think that using pointer arithmetics instead of array indexing is less clear and should be avoided. There is one common use of pointer arithmetics though: STL-style iterators. Maybe explain how those work?
- char **argv. Or generally, why you sometimes see ** (array of C strings, or returning a pointer as an output parameter.)
- Discuss some of the more common types of program crashes caused by incorrect pointer usage, i.e. show which error leads to which crash, so people recognize the cause more easily.

That's all I can think of at the moment. Also, don't get discouraged by the people hating pointers. You can't avoid them if you're using C, and certainly not if you want to read and understand other people's code. Learning about them is a good thing.

Thanks for the feedback  , tonight I'll see to updating the post to include some of those topics. And I'll adress some of the pointer concerns down below.

Oh please stop!!! Pointers are the enemy of robust code. Too much can go wrong with pointers and that is why seasoned programmers avoid pointers as much as possible. Ever heard about buffer overflows and random crashes? That is the evil called pointers at work!

The enemy of robust code? I agree that adding pointers may make things more complicated, but pointers haven't been around for decades just to be an amusement to computer scientists around the world - they are incredibly useful and they can heavily simplify the development of alot of complex applications.
An analogy for you (its a tad exaggerated, my apologies in advance) but not using pointers just because "Too much can go wrong" is like using addition to solve a multiplication problem. Sure addition will yield the same results - but at what cost... (time, is the answer).
Just an example, but I hope you see the comparison

Plus if pointers are so unstable and broken, how do you think the Linux Kernel works? Sure we are talking about two different worlds here, micro controllers and kernels. However the Linux kernel is practically built using pointers *and many many other things*

I tend to agree, but in a language like C or Wiring there is not much you can do without them. With advanced C++ template metaprogramming it is possible to get away from pointers.

Agreed 

[nctnico]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

[John Coloccia]

 

If you're going to get involved in embedded engineering, you should probably learn how to use pointers without running into all the problems nctnico seems to run into. If nothing else, there's a great deal to be said for having so much C code available that you can draw from and use on practically any platform.

[ehughes]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

Can you name a few examples?        C# and Java cannot be lightweight.  Ever.    I have used plenty of buggy C# ad Java programs that leak memory and crash often.  The issue is the programmer and the process, not the language.

I have been hearing about the death of C for awhile now.      The data shows the opposite.

http://webpages.uncc.edu/~jmconrad/ECGR4101-2015-08/Notes/UBM%20Tech%202015%20Presentation%20of%20Embedded%20Markets%20Study%20World%20Day1.pdf

[nctnico]

If you're going to get involved in embedded engineering, you should probably learn how to use pointers

I don't get the elitist attitude from your post. Generally speaking pointers are the least well understood mechanism by students. Creating robust software is all about avoiding pitfalls and not telling people they should have watched out when it is too late.

[Mechatrommer]

Why do you think large application are written in language like Lua, Java and C#?

yes because the professional programmers dont want to deal with low level stuffs that they deemed think unecessary. they want to get it done quickly. done quickly = money quickly. there are some rational to this though.

Creating fast code isn't important anymore

with this type of mentality, the school of algorithm that we learnt all this while will be dead, not every datatype built into the managed language can be handle a particular purpose, not with ideal efficiency at least, imho. then we'll have a bunch of new breed of programmers that only rely on built in data type and produce snail speed applications. what concerned me is if this new breed will produce still buggy but darn less efficient program like what i've experienced recently (but granted its a free tool).

CPU power is cheap

not so with the recent broke down of Moore's Law.. though there are some (big) area like user interface (GUI) and the program's housekeeping job where this mentality is correct, but not in every area, such as cpu and process intensive operations.

[John Coloccia]

If you're going to get involved in embedded engineering, you should probably learn how to use pointers

I don't get the elitist attitude from your post. Generally speaking pointers are the least well understood mechanism by students. Creating robust software is all about avoiding pitfalls and not telling people they should have watched out when it is too late.

Indirection is the heart and soul of programming. It doesn't much matter if it's done with pointers or some other way. What is least understood by students  is neither here nor there. "Don't use transistors...they're too hard."

[netwinder]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

I'm sure getting a prototype up and running with Lua, Java, C#, etc does work - however I'm talking strictly in terms of rapid prototyping. You realize that Lua, Java, C# are built on C? I don't believe theirs a processor / micro controller out there that naively runs off of the Java virtual machine (I could be wrong though)

[obiwanjacobi]

I too can see using a different langauge that compiles down to native. So you can use C#, Java or Swift or whatever to have a strong typed, type-safe and controlled (managed) langauge, but still go down to native instructions (either at compile time or at runtime - almost too late compilation ;-) ) The overhead would be relatively minimal. And the parts that really require hand-optimized assembly need to be done by a pro anyway. Time to market coulld decrease and cost of testing could go down.
I tend to agree with Nico.

[zapta]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

What's your point, scraping this pointer article?

[madires]

There are so many car accidents. Stop driving cars! It's dangerous! Maybe some education and good practices help more. Where I live you can't do without a pointer - I mean - a car.

[netwinder]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

What's your point, scraping this pointer article?

Hey now its not that bad 

There are so many car accidents. Stop driving cars! It's dangerous! Maybe some education and good practices help more. Where I live you can't do without a pointer - I mean - a car.

Exactly! Where I live people can go without "cars" during the summer, but when winter comes around there is clearly a superior transportation method. I like analogies

[Mechatrommer]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car, i'm not sure what it is but i guess it will be a super automatic car where we dont have to do nothing, just speak turn left turn right speed up brake brake hard brake 90% etc etc. the best we have though is automatic car where the freedom of choosing which gear we are at is taken away. but well, eventually many automatic car did crashed.

[nctnico]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car,

At least a car with seat belts, anti-lock brakes and air-bags.

[netwinder]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car,

At least a car with seat belts, anti-lock brakes and air-bags.

It could be said that in a race car, you would want to remove a lot these "safety" features as they add weight. A lot the safety features that are essential in race cars are usually very minimal and skimpy. Were talking the difference between a gigantic bloated (slow) family mini van versus an F1 Racer (uber fast).

[helius]

Here is my solution for an array for instance.
http://atl.codeplex.com/SourceControl/latest#Source/Code/ArduinoTemplateLibrary/Array.h

(You 'store' the size with the instance and you perform bounds checks)
I know it's not C but C++... I personally don't see any advantage in using C - unless that is the only compiler you have...

For one thing you can use an initializer expression when you define a C array (and the size can be inferred from it). I didn't see any ability to do that in your code. For 1-D arrays the STL vector templates work pretty well already.

[tszaboo]

Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

While I dont totally agree with this, I agree with the hatred for pointers.
Pointers should be last resort. If you run out of computing time, and you need that little extra processing power just to make it.
Program everything, like you dont know pointers. Is the application OK? Good, no pointers. It is not OK? Use qsort, memset, memcpy, math libraries... Still not OK? Maybe then pointers, last resort.

[Jeroen3]

You are brave bringing pointers to Arduino. Good article.

You can't not use pointer.
Examples of pointer:
- Any peripheral register write/read.
- DMA use.
- Device drivers.
- Pooled memory.
- The first thing the mcu does is following a pointer.

Not using pointers is the same as storing your "pointer" as address+x, which is still a pointer! And is still subject to implicit boundary errors.

I'd like to see nctnico write a TCP stack without pointers. People scared of pointers often don't even know how to use multiple files. Code looks awful, and is bloated with bugs and inefficiencies.
The only upside to not using pointers is that code doesn't bus/hardfault (reset for arduino) that easily.

 

[dannyf]

"Tell me what you think "

Nice work.

I would suggest adding a section on function pointers as an intermediate course. After that, some combination of pointers and const attributes in the MCU setting. Ie. A pointer to s const type or a const pointer, ....

[Mechatrommer]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car,

At least a car with seat belts, anti-lock brakes and air-bags.

your analogy is not good enough. seat belt is something within our control, meaning we are still free to not use the seat belt, resulting no safety whatsoever, but we can take another measure to ensure safety such as drive slowly, we are still in freedom to use or to not use. otoh ALBS and air-bag are the "after effect" of a result of using a "feature", the main feature are brake pedal and steering/manuveribilty respectively, which in turn still in our full control. if we dont press brake pedal, no ALBS will take action, boom! steering wheel... if we direct the car to safe road, air bag wont blow. if we intentionally hit a brickwall, air bag will blow but the rest of the car, is not any good.

your after effect analogy in programming is more suited if we are still free to use the pointer or not to use, but in case we use it and disaster happened, say we tried to access out of bound area, then there will be "managed" after effect fail safe feature such as error throw etc. but i havent heard of a successfull fail-safe feature in case of pointer violation implemented at the same level of where the program is coded, except if one is to make a custom data-type class or on higher level (OS) the blue screen of death, one may think blue screen is a disaster, it is not, it is a failsafe feature, the nastiest one. but its actually to avoid further and more severe disaster. do you think air bag blowing is a bless? no, its a disaster, but only to avoid more severe disaster.

managed language otoh will encapsulate pointer beyond programmer reach, access only by indirect (type safe) manner where grant is given if the internal wisdom of the managed library says so. in case of your analogy, ALBS should encapsulate brake pedal too, so in order to brake, driver need to press something, a button maybe, and car computer will decide whether its wise to brake, or not, or brake with ALBS activated etc... through internal infinite wisdom, beyond user reach, control and desire.

[John Coloccia]

re: fast vs slow

Rule #1 is simply do the best job you can to not write bloated, crap code, and a good optimizing compiler will usually do a much better job than you making it run fast. There are exceptions, of course, and it also pays to know something about the kinds of things compilers will and won't optimize depending how you write your code. Generally, though, the point of pointers is not to make code run faster.

It also helps if you use C++ as opposed to C, even if you're just mainly writing C code. C++ typing is much better than C, and especially if you turn on the right compiler options it will go a long way to keeping you out of trouble. Much trouble is created when programmers get lazy and instead of actually creating proper types and structures they simply cast everything away so it can be handled with some random pointer. If you have a lot of (void*) and other casts in your code, it's usually an indication that someone is rushing or inexperienced. That's not to say there aren't times you need to do stuff like this, but it's an antiquated way of doing things. Disk space is cheap....teletypes are non-existent. There's no reason to use this sort of old fashioned style anymore because you're not helping yourself, and in fact you're probably making it so the poor compiler can't carry out the best optimizations.

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come, so may as well make your peace with it and learn how to use it properly.

[netwinder]

You are brave bringing pointers to Arduino. Good article.

You can't not use pointer.
Examples of pointer:
- Any peripheral register write/read.
- DMA use.
- Device drivers.
- Pooled memory.
- The first thing the mcu does is following a pointer.

Not using pointers is the same as storing your "pointer" as address+x, which is still a pointer! And is still subject to implicit boundary errors.

I'd like to see nctnico write a TCP stack without pointers. People scared of pointers often don't even know how to use multiple files. Code looks awful, and is bloated with bugs and inefficiencies.
The only upside to not using pointers is that code doesn't bus/hardfault (reset for arduino) that easily.

 

Thank you, and I can't say enough how frustrating it has been (not with Arduino) making a peripheral work properly without pointers, when I didn't know how pointers worked (I had this stigma that they were this scary horrible thing that would ruin my life) I just avoided them as much as possible. Then I tried them, and after about 2 hours of debugging, googling, and bowing down to a portrait of Kernighan and Ritchie, I eventually got the peripheral working, I was using less resources on the processor side of things, AND the code was much more readable 

[hamster_nz]

Wow! I am amazed at how many people seem keen on using Java on a micro-controller with 32k of program memory and 2kB or RAM.

It is all about using the correct tool for the job, and running bare-metal on a small 8 bit microcontroller C or a subset of C++ is pretty much the correct tool in most use-cases. Even on a small 32 bit microcontroller C and a less limited subset of C++ is usually correct tool.

A firm grasp of pointers and address spaces are even more important when you have to deal with the likes of PROGMEM.

Anybody here have any idea how Java or another higher language would handle having a second address space, that is even more immutable than an immutable object? As far as I know that doesn't fit inside the paradigm....

[nctnico]

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

[hamster_nz]

, and I can't say enough how frustrating it has been (not with Arduino) making a peripheral work properly without pointers, when I didn't know how pointers worked (I had this stigma that they were this scary horrible thing that would ruin my life) I just avoided them as much as possible. Then I tried them, and after about 2 hours of debugging, googling, and bowing down to a portrait of Kernighan and Ritchie, I eventually got the peripheral working, I was using less resources on the processor side of things, AND the code was much more readable 

One has to not use pointers to work out how to use pointers.

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

I don't think that the pool of technically adept people has grown at the same rate as the demand for technical people. So the average programmer is less capable that they used to be when programmers were a self-selected group of propeller-head nerds who felt the calling to flip bits.

It is no surprise that on average programmers are working at a higher level of abstraction, doing such things as coding business logic in SQL stored procedures or field validation in Javascript, but I also wouldn't be surprised if more lines of assembler are written this year then any previous year.

[netwinder]

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

But people still code in assembly, it may not be as much as before - however in interrupt based programming alot of interrupt sequences are programmed as an assembly subroutine for maximum efficiency. (For example)

[madires]

I'm still using assembler if it's necessary or provides a proper benefit, sometimes as inline code. But we should focus on the MCUs and the firmware. 20 years ago a 68HC11 had 256 bytes RAM. Today it's 1 or 2kB for a cheap ATmega. With the flood of cheap ARMs we have 32 bit MCUs with a little bit more resources. Still the goal is to use the cheapest MCU possible to solve a problem, unless you design something for a very low volume production.

[dannyf]

"Rule #1 is simply do the best job you can to not write bloated, crap code, and a good optimizing compiler will usually do a much better job than you making it run fast. "

I'm not so sure about that.

If you are in the business of writing code, I tend to think writing reliable and maintenable code that works is priority 1.

Size or execution speed isn't really that important, for the most part. Many institutions actually prohibit "fancy" obscure code. The reason is simple: bloat or slow code is much easier to deal with than buggy code.

[hamster_nz]

"Rule #1 is simply do the best job you can to not write bloated, crap code, and a good optimizing compiler will usually do a much better job than you making it run fast. "

I'm not so sure about that.

If you are in the business of writing code, I tend to think writing reliable and maintenable code that works is priority 1.

Size or execution speed isn't really that important, for the most part. Many institutions actually prohibit "fancy" obscure code. The reason is simple: bloat or slow code is much easier to deal with than buggy code.

Writing good code is such a multi-dimensional problem space that splitting it into "good and more-good" makes very little sense. Size might be important if it costs you on a high volume product, latency might be important if it is a VR tracking, speed might be important if it is a real time system.

Heck, I am sure that somebody could support the argument that code that doesn't work 100% correctly but is simple and maintainable is best (e.g. something along the "Close enough for Jazz" argument).

It is all about needs
- Needlessly slow is bad
- Needlessly complex is bad
- Needlessly bloated is bad
- Needlessly over-optimized is bad

The tough projects are the ones where everything is needed - "we need small, fast, highly maintainable code, to accurately solve a very complex problem"

[John Coloccia]

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

When was was that? 40 years ago before a good language like C was developed that allowed high level programming and low level access? The whole point of C was to have lightweight language that mapped easily to machine language and prevented you from having to drop to assembly for all but the most low level machine specific tasks. It was tailor made for this kind of work, which is why it's still close to the top in popular languages today, or maybe even is at the top again for all I know. You know what's loosing ground? Java, that's who, and everyone else are distant 3rds and 4ths. IMHO, Java was a terrible mistake that we're all paying for. I know a lot of people like it, but having used it my impression is not very favorable as a general programming language, though it's pretty good for tossing together little snippets of code that do small, well defined tasks.

Incidentally, there really IS a good reason to shun the C++ runtime library for embedded, because it's huge and ugly. There are ways to get around that, and sometimes the processor vendor even includes it's own libc++ that strips out all of the bloated craptastic stream, stdlib et. al. stuff and leaves you with a lean implementation.

C/C++ hasn't gone anywhere in 40 years, and has just gotten more popular and more entrenched, not less. The only reason it's not even more ubiquitous is because of C#, which is actually quite good IMHO, and the various environments that Apple and Android use for their apps. It's really unthinkable that C is on it's way out.

All that said, if you want a treat, and can get a compiler for your platform, you should check out the D programming language. It's really an improvement over C++ in many ways (though nothing is perfect).

[John Coloccia]

If you are in the business of writing code, I tend to think writing reliable and maintenable code that works is priority 1.

I'm not sure we have the same definition of bloated, crappy code. LOL.

[zapta]

All that said, if you want a treat, and can get a compiler for your platform, you should check out the D programming language. It's really an improvement over C++ in many ways (though nothing is perfect).

Using a non standard language has its own cost.

[John Coloccia]

All that said, if you want a treat, and can get a compiler for your platform, you should check out the D programming language. It's really an improvement over C++ in many ways (though nothing is perfect).

Using a non standard language has its own cost.

There are lots of hobbyists on the forum that don't care about that, but it's more popular and mature than you might think. Facebook has been using D for a good number of years, now. I personally think if anything has a chance to be the successor to C/C++/Java, D is it.

[Mechatrommer]

There are lots of hobbyists on the forum that don't care about that,

you are dealing with profesional here where they care you dont, where they dont you care. keep arguing like this is like pulling string indefinetely, pointless.

[John Coloccia]

There are lots of hobbyists on the forum that don't care about that,

you are dealing with profesional here where they care you dont, where they dont you care. keep arguing like this is like pulling string indefinetely, pointless.

Well, you're dealing with a professional here too, so I guess we're even. Let me tell you what the problem is, and why nonsense like this even comes up in the first place.

When you go to school and learn electronics, how do they teach it? Well, of course they start with high level concepts such as gates, and then they talk about building digital computers with the gates. Then, just before you graduate college, they introduce the concept of resistors, capacitors, transistors, etc....and they explain a little about voltage and current, and voila', you're an engineer.

Right?

No no no....completely wrong, it sounds crazy and it is crazy.  You start by learning about basic things, like resistors and caps, and you slowly build up into more complicated things. By the time you're ready to graduate, maybe you can't design a computer, for example, but you can at least see how you might get there from the basic building blocks.

But when we teach software, what do we do? We start with a so-called beginner language. Take you're pick....BASIC, Fortran, Pascal, Java, or even C and C++...whatever, they've all been used and more.  Bah. The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

[netwinder]

There are lots of hobbyists on the forum that don't care about that,

you are dealing with profesional here where they care you dont, where they dont you care. keep arguing like this is like pulling string indefinetely, pointless.

Well, you're dealing with a professional here too, so I guess we're even. Let me tell you what the problem is, and why nonsense like this even comes up in the first place.

When you go to school and learn electronics, how do they teach it? Well, of course they start with high level concepts such as gates, and then they talk about building digital computers with the gates. Then, just before you graduate college, they introduce the concept of resistors, capacitors, transistors, etc....and they explain a little about voltage and current, and voila', you're an engineer.

Right?

No no no....completely wrong, it sounds crazy and it is crazy.  You start by learning about basic things, like resistors and caps, and you slowly build up into more complicated things. By the time you're ready to graduate, maybe you can't design a computer, for example, but you can at least see how you might get there from the basic building blocks.

But when we teach software, what do we do? We start with a so-called beginner language. Take you're pick....BASIC, Fortran, Pascal, Java, or even C and C++...whatever, they've all been used and more.  Bah. The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

As a programmer I have quite some insight to add to this. I first learned to program in C (and in general) it was rather frustrating. This was likely because I didn't know much about semantics, program structure, and what that weird for loop does (don't worry, I know what it does now  ). Eventually I found these wonderful things called textbooks and I was happily on my way practicing this new language.

Some Universities around me teach software the way you say, through starting at the bottom of the system and working their way up.
This book (there is a third edition, but no free PDF floating around) studies computers starting with some basic technical knowledge, however it starts from C, it then discusses the various levels involving a C program (this is only the preface) and then after that it's bottom up, for a while they do program in assembly to demonstrate a few concepts (see the table of contents, pdf page . I've read part of this book, and while my C programming skills haven't improved I am much more effective at debugging and fixing code, thinking about code at lower levels, and optimizing code for speed.
https://doc.lagout.org/programmation/Computer%20Systems%20-%20A%20Programmers%20Perspective.pdf

However not all schools have this approach, in my school the mind set is "JAVA IS KING!!! Who cares how the VM works" and this leads to a lot of rather interesting code.

I digress, learning to program in assembly is like learning carpentry (sorry for another analogy, I can tell we have had too many of them) without power tools and by only using hand tools. Sure you eventually could get to the same results, but there will be an extremely steep learning curve, and lots of error along the way. There are a lot of carpenters out there that believe in this. However they are experienced - they already know how hand tools work.

My point is while hand tools are fun and great, we need power tools to get the bulk of the work done.

[John Coloccia]

As a programmer I have quite some insight to add to this. I first learned to program in C (and in general) it was rather frustrating. This was likely because I didn't know much about semantics, program structure, and what that weird for loop does (don't worry, I know what it does now  ). Eventually I found these wonderful things called textbooks and I was happily on my way practicing this new language.

Some Universities around me teach software the way you say, through starting at the bottom of the system and working their way up.
This book (there is a third edition, but no free PDF floating around) studies computers starting with some basic technical knowledge, however it starts from C, it then discusses the various levels involving a C program (this is only the preface) and then after that it's bottom up, for a while they do program in assembly to demonstrate a few concepts (see the table of contents, pdf page . I've read part of this book, and while my C programming skills haven't improved I am much more effective at debugging and fixing code, thinking about code at lower levels, and optimizing code for speed.
https://doc.lagout.org/programmation/Computer%20Systems%20-%20A%20Programmers%20Perspective.pdf

However not all schools have this approach, in my school the mind set is "JAVA IS KING!!! Who cares how the VM works" and this leads to a lot of rather interesting code.

I digress, learning to program in assembly is like learning carpentry (sorry for another analogy, I can tell we have had too many of them) without power tools and by only using hand tools. Sure you eventually could get to the same results, but there will be an extremely steep learning curve, and lots of error along the way. There are a lot of carpenters out there that believe in this. However they are experienced - they already know how hand tools work.

My point is while hand tools are fun and great, we need power tools to get the bulk of the work done.

For what it's worth, my official training is also in software, with a MS in Software Engineering. I personally never really had any of these problems. It all just came very, very easily, for whatever reason, and the choice of language is no more a stumbling block than choosing a flat head screwdriver over a Phillips. I think a lot of pros feel the same way...the language is just a tool and irrelevant so long as it's an appropriate tool.

My opinion comes from years and years of tutoring and helping people. When someone is having trouble, the initial reaction is always "Simplify...hide even more details!!". This is 100% wrong and is based on the concept that the guy is stupid and incapable of understanding, so you strip away everything that requires thought and try to give him some simple rules he can blindly follow. Disaster is always close behind because you can't do any real learning like that. I've found that when someone's having trouble with pointers, the thing to do is spend a day doing nothing but talking about the basics of how a computer works....memory, program counters, stacks etc. Real nuts and bolts kinds of things. It doesn't matter that they don't remember it all. It's just setting the foundation so they have SOME idea what I'm talking about. Without that, when you say words like "memory" and "address" it's nothing but words. You could say "cat" and "dog", and it would make just as much (or as little) sense to them.

I'll tell you why this is so screwed up.  Computer Science typically grew out of the Math department of Universities. It's probably changed now as older guys have retired and new guys are entering the system, but if you go back to the late 80s/early 90s when I went to College/Graduate School and you look at the degrees of the professors, they all have PhDs in some field of Mathematics since there was no such thing as Computer Science when they went to school. Most Computer Science departments are still part of the Math department, and it SHOULD be part of the Engineering school instead. Again, this is just because all of the professors were traditionally all math professors, so I guess Comp. Sci. goes in the Math department.

And we teach programming the same way we teach mathematics. You don't start with Peano Axioms and work your way up. You start with basic arithmetic, and then you add in some algebra and some calculus. And then you add in a little Linear Algebra and maybe some differential equations, and at each step you never look at the guts. You have some nicely polished practical rules that are the result of the basic axioms, but you NEVER start at the bottom and work your way up. You always start in the middle somewhere. That just doesn't work well for software because you never have a solid foundation to work from. It's magic, and the poor student is the sorcerer's apprentice.

[dannyf]

"The beginner language should be some sort of assembly languag"

Not sure.

Programming is to solve problems. That means algorithm, data structure and float control, and scopping.

Assembly does s poor job at that, and is non transferrable.

Of the main stream languages, pascal would have my vote. C can be too loose, and too powerful for beginners

[madires]

I've started with Basic at home and in school. Yes, my school was an early CS adopter, had PETs and offered CS as elective subject. Later on they moved to C128s with Comal80 and Modula modules. I think, Basic and Pascal are good programming languages to start with. From there you would select the next languages based on your career path. For an EE dealing with MCUs this would be assembly and C/C++.

[netwinder]

As a programmer I have quite some insight to add to this. I first learned to program in C (and in general) it was rather frustrating. This was likely because I didn't know much about semantics, program structure, and what that weird for loop does (don't worry, I know what it does now  ). Eventually I found these wonderful things called textbooks and I was happily on my way practicing this new language.

Some Universities around me teach software the way you say, through starting at the bottom of the system and working their way up.
This book (there is a third edition, but no free PDF floating around) studies computers starting with some basic technical knowledge, however it starts from C, it then discusses the various levels involving a C program (this is only the preface) and then after that it's bottom up, for a while they do program in assembly to demonstrate a few concepts (see the table of contents, pdf page . I've read part of this book, and while my C programming skills haven't improved I am much more effective at debugging and fixing code, thinking about code at lower levels, and optimizing code for speed.
https://doc.lagout.org/programmation/Computer%20Systems%20-%20A%20Programmers%20Perspective.pdf

However not all schools have this approach, in my school the mind set is "JAVA IS KING!!! Who cares how the VM works" and this leads to a lot of rather interesting code.

I digress, learning to program in assembly is like learning carpentry (sorry for another analogy, I can tell we have had too many of them) without power tools and by only using hand tools. Sure you eventually could get to the same results, but there will be an extremely steep learning curve, and lots of error along the way. There are a lot of carpenters out there that believe in this. However they are experienced - they already know how hand tools work.

My point is while hand tools are fun and great, we need power tools to get the bulk of the work done.

For what it's worth, my official training is also in software, with a MS in Software Engineering. I personally never really had any of these problems. It all just came very, very easily, for whatever reason, and the choice of language is no more a stumbling block than choosing a flat head screwdriver over a Phillips. I think a lot of pros feel the same way...the language is just a tool and irrelevant so long as it's an appropriate tool.

My opinion comes from years and years of tutoring and helping people. When someone is having trouble, the initial reaction is always "Simplify...hide even more details!!". This is 100% wrong and is based on the concept that the guy is stupid and incapable of understanding, so you strip away everything that requires thought and try to give him some simple rules he can blindly follow. Disaster is always close behind because you can't do any real learning like that. I've found that when someone's having trouble with pointers, the thing to do is spend a day doing nothing but talking about the basics of how a computer works....memory, program counters, stacks etc. Real nuts and bolts kinds of things. It doesn't matter that they don't remember it all. It's just setting the foundation so they have SOME idea what I'm talking about. Without that, when you say words like "memory" and "address" it's nothing but words. You could say "cat" and "dog", and it would make just as much (or as little) sense to them.

I'll tell you why this is so screwed up.  Computer Science typically grew out of the Math department of Universities. It's probably changed now as older guys have retired and new guys are entering the system, but if you go back to the late 80s/early 90s when I went to College/Graduate School and you look at the degrees of the professors, they all have PhDs in some field of Mathematics since there was no such thing as Computer Science when they went to school. Most Computer Science departments are still part of the Math department, and it SHOULD be part of the Engineering school instead. Again, this is just because all of the professors were traditionally all math professors, so I guess Comp. Sci. goes in the Math department.

And we teach programming the same way we teach mathematics. You don't start with Peano Axioms and work your way up. You start with basic arithmetic, and then you add in some algebra and some calculus. And then you add in a little Linear Algebra and maybe some differential equations, and at each step you never look at the guts. You have some nicely polished practical rules that are the result of the basic axioms, but you NEVER start at the bottom and work your way up. You always start in the middle somewhere. That just doesn't work well for software because you never have a solid foundation to work from. It's magic, and the poor student is the sorcerer's apprentice.

Can't agree with you more on this. One thing I love about (some of) the computer science texts I have is that they go so far in depth. My math textbooks on the otherhand are more along the lines of "Factor remainder theorem: p/q, go solve the zeroes of this polynomial function"  and not to put the blame on the textbook but its a real limiting factor in mathematics for me. I end up with questions like "why does synthetic division work" etc. Usually ends with a frustrated math teacher, as they would want to go to higher levels of problems when I need the lower levels explained first.

I digress, When I used to help friends out when I got more experience with CS, I tried the oversimplification method and it went just as you describe. They would get through the example I was coaching them with, and then with the next example they were cranking out broken code. Along the lines of "teach a man to fish" analogy.

[LazyJack]

"The beginner language should be some sort of assembly languag"

Not sure.

Programming is to solve problems. That means algorithm, data structure and float control, and scopping.

Assembly does s poor job at that, and is non transferrable.

Of the main stream languages, pascal would have my vote. C can be too loose, and too powerful for beginners

I cannot agree more. You are absolutely right. I used to teach programming at a university to EE and CS students, and C is a big pain in the backside for teaching programming. Instead of learning how to think and create the algorithms they get all lost in the details of the language or try to show off by implementing the whole program between the parentheses of for(,,). With little success of course.
As much as I love C for real world projects, I would definitely use Pascal for entry into programming. Unfortunately, this cannot be done, as students expect the university to teach "useful in practice" stuff, not realizing that once you know how to think as a good programmer, you can learn any language in half a day (excluding Lisp of course ).
But it does not work the other way around.

[dannyf]

"My math textbooks on the otherhand are more along the lines of "Factor remainder theorem: p/q, go solve the zeroes of this polynomial function" "

That sounds like a great textbook.

" I end up with questions like "why does synthetic division work" etc"

Sounds like an easier class would have worked better for you.

[IanB]

The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

Agreed. And this, incidentally, is one aspect I remember when elementary computer science was being taught to classes of 14/15 year olds back in the 1970's. There were at least two simulated machines with a basic hypothetical instruction set that students could write and run programs in to get some idea of how computers worked.

[netwinder]

"My math textbooks on the otherhand are more along the lines of "Factor remainder theorem: p/q, go solve the zeroes of this polynomial function" "

That sounds like a great textbook.

" I end up with questions like "why does synthetic division work" etc"

Sounds like an easier class would have worked better for you.

Absolutely is a great(horrible) textbook? And an easier class wouldn't work better, I just want to know how things work. When I understand how something works it makes using the something a lot easier. It relates to programming as if you oversimplified and didn't go into how things worked at a lower level, you would end up with questions like "why is my sorting algorithm causing a buffer overflow". A class where the teacher went more in depth would be nice.

The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

Agreed. And this, incidentally, is one aspect I remember when elementary computer science was being taught to classes of 14/15 year olds back in the 1970's. There were at least two simulated machines with a basic hypothetical instruction set that students could write and run programs in to get some idea of how computers worked.

This would be a good solution provided they transitioned into a higher level language in a easy-to-follow way.

[helius]

But when we teach software, what do we do? We start with a so-called beginner language. Take you're pick....BASIC, Fortran, Pascal, Java, or even C and C++...whatever, they've all been used and more.  Bah. The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

The key is to choose a set of abstractions that don't leak and are durable enough for whatever you need to do.

In your example of starting with "basic components like resistors and caps", who decided that these are the basic building blocks? A lot actually goes into making resistors and capacitors, they are not ideal, and they are not really even necessary to make circuits as shown by technologies like SLT hybrids. But in practice, for the kinds of things EEs usually do, it's generally adequate to regard them as fundamental even if they aren't. It's a compromise: by settling on a lumped element abstraction, we know that there are some things we can't do, but we don't usually need to do those things (except for transmission lines and so on). And the payoff is that modeling our circuits is easier.

In computer science, a similar tradeoff exists. While we could model programs as assembly code running on a concrete machine, in practice it's not necessary and doesn't give us any better insight into what is happening. Instead we choose a set of abstractions that hopefully do not leak—this is the major criteria that distinguishes good and bad language design. In a well-designed language, everything that happens in a valid program is explained by the language's semantics. We also want clear error messages that explain the reasons programs are not valid (it is possible to define a language where any possible input is valid [see Brainfuck and Befunge] but not especially useful). This is also a compromise where we know we can't do certain things (like debug hardware failures), but we gain tractable models at a single level of abstraction.

When learning computer design, a different level of abstraction is necessary that exposes the hardware, so assembly language is used. Should computer design be a prerequisite for learning programming? This sounds bizarre and it is. Without knowing programming, there is nothing to guide the requirements for computer hardware; it might as well be any other dumb widget.

[IanB]

In your example of starting with "basic components like resistors and caps", who decided that these are the basic building blocks? A lot actually goes into making resistors and capacitors, they are not ideal, and they are not really even necessary to make circuits as shown by technologies like SLT hybrids. But in practice, for the kinds of things EEs usually do, it's generally adequate to regard them as fundamental even if they aren't. It's a compromise: by settling on a lumped element abstraction, we know that there are some things we can't do, but we don't usually need to do those things (except for transmission lines and so on). And the payoff is that modeling our circuits is easier.

But resistance, capacitance and inductance are fundamental properties described by physics, which limit the realizable performance of any abstract component you try to construct. Therefore it is useful and important to understand such basic concepts so you can have an appreciation of the performance limits of the higher level building blocks you may be using. The "ideal" and "perfect" black box transistor, op amp or logic gate doesn't exist; it is an imperfect realization of an ideal with very definite limits to its performance. If you haven't learned some fundamental physics you will find it hard to recognize where these imperfections are and how they manifest.

In computer science, a similar tradeoff exists. While we could model programs as assembly code running on a concrete machine, in practice it's not necessary and doesn't give us any better insight into what is happening. Instead we choose a set of abstractions that hopefully do not leak—this is the major criteria that distinguishes good and bad language design. In a well-designed language, everything that happens in a valid program is explained by the language's semantics. We also want clear error messages that explain the reasons programs are not valid (it is possible to define a language where any possible input is valid [see Brainfuck and Befunge] but not especially useful). This is also a compromise where we know we can't do certain things (like debug hardware failures), but we gain tractable models at a single level of abstraction.

And the same thing occurs here. Not everything is explained by the language's semantics, and nor can it be. There are limitations imposed by the hardware, and some things are defined outside the language. For example, a language cannot usually define the exact behavior of floating point arithmetic at the limits, the rounding behavior, and the exception behavior. If you do not have an appreciation of how floating point hardware works at the binary level you will fall into some traps in your high level programming.

When learning computer design, a different level of abstraction is necessary that exposes the hardware, so assembly language is used. Should computer design be a prerequisite for learning programming? This sounds bizarre and it is. Without knowing programming, there is nothing to guide the requirements for computer hardware; it might as well be any other dumb widget.

Your argument seems to fall down at the first hurdle. Doesn't history tell us that the first stored program computers were designed before there was ever a fully developed theory of programming?

[John Coloccia]

Students are so ill prepared when they start learning about higher level concepts, like data structures for example, that all you ever get to is little toy structures....like little linked lists and things like that. And as they go along, they stumble and stumble and stumble because they don't actually understand the tools they're playing with. As I said before, it's a sorcerer's apprentice situation.

If they went in with a SOLID knowledge of how a computer actually works, the language is no longer important because it's easy to learn. And THEN you can have an in depth discussion of these higher level, and extremely important, concepts because you're not spending 90% of you're time trying to figure out a stupid program. The programming should be second nature and a non-issue by this point because it's no longer a mysterious black box, and the choice of language should be irrelevant. You just spend a day getting some basic concepts down, and then you sit down with your reference and use the tool. Doesn't work like this in school, does it? It should because it works like this when you're a pro in real life. At least it had better work like this or you're not going to have a very long career.

[helius]

But resistance, capacitance and inductance are fundamental properties described by physics, which limit the realizable performance of any abstract component you try to construct. Therefore it is useful and important to understand such basic concepts so you can have an appreciation of the performance limits of the higher level building blocks you may be using. The "ideal" and "perfect" black box transistor, op amp or logic gate doesn't exist; it is an imperfect realization of an ideal with very definite limits to its performance. If you haven't learned some fundamental physics you will find it hard to recognize where these imperfections are and how they manifest.

Resistance, capacitance, and inductance are not "fundamental" in the sense of fundamental particles and forces. They are collective effects that are observed under certain conditions. Don't mistake the lumped element abstraction for reality! It cannot predict behavior under some conditions, like when the circuit is moving in a magnetic field.

And the same thing occurs here. Not everything is explained by the language's semantics, and nor can it be. There are limitations imposed by the hardware, and some things are defined outside the language. For example, a language cannot usually define the exact behavior of floating point arithmetic at the limits, the rounding behavior, and the exception behavior. If you do not have an appreciation of how floating point hardware works at the binary level you will fall into some traps in your high level programming.

This is the leaky abstraction at work. Languages like C that punt basic semantics like arithmetic results to "implementation defined" behavior are badly designed for pedagogical purposes. It is completely unnecessary to rely on what the hardware does: whatever oddities in the floating point hardware are exactly like the Pentium F00F bug and just need to be rectified by the implementation.

Your argument seems to fall down at the first hurdle. Doesn't history tell us that the first stored program computers were designed before there was ever a fully developed theory of programming?

No, because Al-Khw?rizm?, Babbage, Lovelace, Boole, Frege, Church, and Turing had something of a headstart 
But even if they hadn't, it's a genetic fallacy to suggest "the first!" computer is in any way relevant.

[Mechatrommer]

Not everything is explained by the language's semantics

Languages like C that punt basic semantics like arithmetic..

i believe you people talking about "syntactic". a language doesnt define or explain semantics. language is a tool for building semantics and convey it to other medium for energy transfer or information sharing.

having said that, i dont tend the definition of a language as something inclusive to the "built in" or "standard" library or compiler/linker features that came with the language, which i believe why everybody debated here or in any other programming threads trolls that "this language" better than "that language", this language has better "managed language" that language is not. if C++ specification is extended to add this management libraries to the same magnitude as those other new fancy languages, C++ can be just as robust, without necessitating to block direct pointer access from programmer. then we can divide C++ programmer into 2 different classes, one is the hardcored pointer fans who care too much on code efficiency no matter how much time spent for the cause, and the other one is who are too afraid to use pointer and use C++ managed library extensively, production to delivery time is #1 priority.

i can understand if one argue this language is better than that language because of readability, but arguing about managed vs unmanaged and blaming on the "language"? duh this is just endlessly confusing ... btw C/C++ has been "managed" for this long with features such as throw and assert or even alloc/new etc, its just this "managed" buzz seemingly only taking place in those new and fancy languages for kids (no offense). actually semantics/error management (to some smaller extend than today) has took place long ago than what you have believed.

[John Coloccia]

i believe you people talking about "syntactic". a language doesnt define or explain semantics. language is a tool for building semantics and convey it to other medium for energy transfer or information sharing.

having said that, i dont tend the definition of a language as something inclusive to the "built in" or "standard" library or compiler/linker features that came with the language, which i believe why everybody debated here or in any other programming threads trolls that "this language" better than "that language", this language has better "managed language" that language is not. if C++ specification is extended to add this management libraries to the same magnitude as those other new fancy languages, C++ can be just as robust, without necessitating to block direct pointer access from programmer. then we can divide C++ programmer into 2 different classes, one is the hardcored pointer fans who care too much on code efficiency no matter how much time spent for the cause, and the other one is who are too afraid to use pointer and use C++ managed library extensively, production to delivery time is #1 priority.

i can understand if one argue this language is better than that language because of readability, but arguing about managed vs unmanaged and blaming on the "language"? duh this is just endlessly confusing ... btw C/C++ has been "managed" for this long with features such as throw and assert or even alloc/new etc, its just this "managed" buzz seemingly only taking place in those new and fancy languages for kids (no offense). actually semantics/error management (to some smaller extend than today) has took place long ago than what you have believed.

By "managed" in this context I believe they specifically mean running in the runtime virtual machine. You can get managed C++ with C++/CLI, which is an extension just as you suggested.

But I agree with you that I don't see a big deal with different languages concerning the quality of the end program. Pros, or at least competent pros, don't spend their days tracking down pointers flying off into space. While I'm sure it happens, it doesn't happen because of confusion or difficulty. It happens because of a logical error and it would have caused some other bug instead to be tracked down anyway.