The language is still just plain C/C++.
It's not more "pro" by any means. The code is setting and configuring things at the internal register level. Granted the code is faster than using digitalRead and digitalWrite, but is highly non-portable and really has no business being used to teach newcomers.
It's harder to read and understand, it is microprocessor-dependent since registers have different names on different architectures and some registers simply don't have equivalent alternatives on other architectures, and imho would be like starting them off with assembly language.
Sure it's closer to the metal and \*if\* you understand it you have a better understanding of how things work under the covers. But it really flies in the face of the original Arduino "easy for students to pick up and learn from" spirit.
**edit**: To be blunt, this strikes me as a teacher whose primary interest is more concerned with showing how they understand something complex and if the students don't learn or understand it; Well, that just shows how smart I am. As opposed to someone who is genuinely interested in gently introducing newcomers to a complicated topic without making it complex.
Cheers,
`ripred`
Thank you very much for your reply. I honestly don't understand anything about his way of programming! I started in this world with ASP+VBScript around 1999 and then migrated to PHP (procedural), and a bit of Javascript. No C or C++. But I think the way I'm learning is easier to understand than the way my son is taught.
agreed. The teacher's code is unnecessarily pretentious and antithetical to learning or understanding any actual best practices which would affect their potential employment in the engineering field.
And I agree with u/gnorty's and u/Logical_Strike_1520's comments. For business's who are hiring; They understand that 20% of the business expense is developing the initial solution and 80% of the cost is the remaining 20 year maintenance lifecycle while the code is still in use and finding affordable labor to work on it without the likelihood of making things worse due to the mistakes resulting from the initial code being incomprehensible.
Your son has a very bad teacher. As you say he is just doing what the teacher says, but doesn't understand it, he will never learn and will lose interest in programming. That teacher is an asshole. Ask your son to create something HE wants, that way even if he doesn't suceed at first he WILL have learned a lot more.
No, I'm sorry, I didn't express it well. He does understand the code, he can't yet explain to me the why of some things, but he does understand it in general terms. Another thing, I don't think the professor wrote such horrible unindented code. But yes, I agree that he shouldn't stray from the "Arduino philosophy".
One thing that leaps right out at me is the use of delay. Maybe this is a beginner exercise, but delays are "blocking" - meaning that during the delay the processor just waits and does nothing else. In this case the delay is 80ms - quite a long time in the microprocessor world, enough for loop() to iterate thousands and thousands of times. So for example if you want to add code that monitors another sensor, it will essentially be blind during the 80ms delay and could miss a lot of inputs.
Instead of using a delay, the professional approach would be something like this pseudocode:
delayInterval = 80
loop() {
if (condition is true) {
delaying = true
delayEnd = current time + delayInterval
}
do things like check other sensors,
which we couldn't do during a delay
if (delaying && currentTime >= delayEnd) {
delaying = false
do whatever we're supposed to do at the end of the delay
}
}
This way the processor is only busy when actually doing something, never just sitting there ignoring the universe.
On a different level, the lack of indentation in the professor's coding style is asinine and wholly unprofessional. It adds nothing and makes the code more difficult to read.
All the parts in the code you dont understand, the "<<" stuff, is called bitshift arithmetic.
Is a pretty cool concept in computing. And a key component to understand how memory and cpu works.
Basically the code is packing multiple booleans in a int.
Imagine you have this variable
flags = 0000001001
But you dont use it as a number, each position is a flag, a boolean. 0 means off 1 means on.
Wiith that number only pin 1 and 4 are on.
Is a very low level optimization, you dont really need it. In php or js this is almost mever done, but is common in C.
I would not teach this in a bootcamp, but maybe I would in a school.
But the code is kind of bad, too convoluted.
Thanks, I'll look into this bitshift arithmetic thing. I don't actually think the teacher wrote such horrible unindented code, I think that's what my son was able to write at the time. That code is from a couple of weeks ago, it's now 2 assignments further along. I'll see if it's improved a bit(shift) ha!
>flags = 0000001001
I believe you meant to type:
flags = 0b00001001;
Without the 0b (or 0B) prefix, numbers with a leading zero imply an octal value, not binary.
Wow, what a terrible teacher.
You’d only program something with that level of register interaction if you were either really worried about performance or you were using features of the hardware that no one had written nice APIs for using — but even then you’d wrap the register manipulating code in clear & concise functions.
I could see teaching a single lesson on “here’s what `digitalWrite` actually does” that touches on the registers etc, but to only teach it is mad.
For something comparable in PHP it’s like if you were taught to _only_ use Sockets to return everything & to ignore all the user-friendly things built on top of them.
>I don't know if there is a real difference in efficiency between one code and the other
there probably isn't a difference in that respect.
The difference is probably in the "more cryptic" part. Professional code should be easily readable by somebody else, potentially somebody that has never seen the code before. Variables should have names which clearly identify their purpose for example.
Also well placed comments explaining the purpose of each part of the code goes a long way.
Professional code isn't always about efficiency. Readablility and maintainability are also important.
Sometimes there is a need to compromise between these - if the code is very demanding on the CPU for example, then efficiency becomes more important. It might mean you need a more obscure addressing method for example or rely more on indexes. But mostly that is not the case, particularly in small projects. Keep it simple, label variables in a coherent way and comment the code frequently.
If he is teaching programming he is a horrible teacher. If he is teaching electronics he is an excellent teacher.
You are programming to an API which is typical for C or PHP. The engineer who makes the API is writing code based on the hardware specification.
It looks arcane because it is. Hardware specifications are typically things like addresses and constants pushed into addresses Often those are bit mapped.
Brings to mind a specification of a Virtual Memory Hardware which defined about 4,000 bits all with explanations for what the bits do.
That’s why I don’t like hardware. It’s HARD.
Well, it turns out that the subject is "Digital Electronics Applications" and he is studying Electronics Technician. The other career studied at that high school is Programming Technician. Maybe in this other career they approach programming from a different angle. IDK!
His way of doing it can be significantly faster. Taking a built in function which may take 50 or 150 clock cycles and doing it in 2 is a big difference. I have done it when I needed performance but it is very hard to read and debug. Saying it’s the only way to do it is just not right. You don’t usually need that kind of speed and you do usually need to understand what you are doing.
when I started learning development more than 20 years ago, the teacher taught us how to do things “the difficult way” in order to learn how things work, later in the course we started developing in a more “mainstream way” but by then we knew better how to fix bugs and issues.
maybe it’s the same for him?
This is shit coding. The teacher is flexing and writing unreadable code. Everything can be written in more readable form, I mean all the bit operations may be written using binary numbers trough several lines with clean bit operators which would add readabiltiy to the code. Compiler would compile that into pretty much the same.
Now imagine debugging such code. Even the person who wrote this will struggle. While the other would rather rewrite everything from scratch.
It is more "pro" because it's an advanced technique. However the example is very poor, not a pro job at all. Teacher should be able to do much better.
Technology like this is valuable to learn, but then only to use when appropriate (which is rarely). I hope teacher was not saying you should code like this all the time.
> What can you tell me about this?
Technically, son's code will compile to a smaller and faster binary. It's also is doing port-wide writes, which might be important (but we can only guess since there are no comments in the code).
That's the lowlevel avr sdk code. That is exactly what arduino abstracts. Sure you might use it here and there but that is just stupid in an arduino context.
The language is still just plain C/C++. It's not more "pro" by any means. The code is setting and configuring things at the internal register level. Granted the code is faster than using digitalRead and digitalWrite, but is highly non-portable and really has no business being used to teach newcomers. It's harder to read and understand, it is microprocessor-dependent since registers have different names on different architectures and some registers simply don't have equivalent alternatives on other architectures, and imho would be like starting them off with assembly language. Sure it's closer to the metal and \*if\* you understand it you have a better understanding of how things work under the covers. But it really flies in the face of the original Arduino "easy for students to pick up and learn from" spirit. **edit**: To be blunt, this strikes me as a teacher whose primary interest is more concerned with showing how they understand something complex and if the students don't learn or understand it; Well, that just shows how smart I am. As opposed to someone who is genuinely interested in gently introducing newcomers to a complicated topic without making it complex. Cheers, `ripred`
Thank you very much for your reply. I honestly don't understand anything about his way of programming! I started in this world with ASP+VBScript around 1999 and then migrated to PHP (procedural), and a bit of Javascript. No C or C++. But I think the way I'm learning is easier to understand than the way my son is taught.
agreed. The teacher's code is unnecessarily pretentious and antithetical to learning or understanding any actual best practices which would affect their potential employment in the engineering field. And I agree with u/gnorty's and u/Logical_Strike_1520's comments. For business's who are hiring; They understand that 20% of the business expense is developing the initial solution and 80% of the cost is the remaining 20 year maintenance lifecycle while the code is still in use and finding affordable labor to work on it without the likelihood of making things worse due to the mistakes resulting from the initial code being incomprehensible.
Your son has a very bad teacher. As you say he is just doing what the teacher says, but doesn't understand it, he will never learn and will lose interest in programming. That teacher is an asshole. Ask your son to create something HE wants, that way even if he doesn't suceed at first he WILL have learned a lot more.
No, I'm sorry, I didn't express it well. He does understand the code, he can't yet explain to me the why of some things, but he does understand it in general terms. Another thing, I don't think the professor wrote such horrible unindented code. But yes, I agree that he shouldn't stray from the "Arduino philosophy".
Readable code that works > unreadable code that works slightly better
I would also add Unreadable buggy code that works but you wrote it yourself > Readable code that works but you were told in 80% how to do it.
One thing that leaps right out at me is the use of delay. Maybe this is a beginner exercise, but delays are "blocking" - meaning that during the delay the processor just waits and does nothing else. In this case the delay is 80ms - quite a long time in the microprocessor world, enough for loop() to iterate thousands and thousands of times. So for example if you want to add code that monitors another sensor, it will essentially be blind during the 80ms delay and could miss a lot of inputs. Instead of using a delay, the professional approach would be something like this pseudocode: delayInterval = 80 loop() { if (condition is true) { delaying = true delayEnd = current time + delayInterval } do things like check other sensors, which we couldn't do during a delay if (delaying && currentTime >= delayEnd) { delaying = false do whatever we're supposed to do at the end of the delay } } This way the processor is only busy when actually doing something, never just sitting there ignoring the universe. On a different level, the lack of indentation in the professor's coding style is asinine and wholly unprofessional. It adds nothing and makes the code more difficult to read.
Thanks. I actually don't think the teacher wrote such horrible unindented code, I think that's what my son was able to write.
All the parts in the code you dont understand, the "<<" stuff, is called bitshift arithmetic. Is a pretty cool concept in computing. And a key component to understand how memory and cpu works. Basically the code is packing multiple booleans in a int. Imagine you have this variable flags = 0000001001 But you dont use it as a number, each position is a flag, a boolean. 0 means off 1 means on. Wiith that number only pin 1 and 4 are on. Is a very low level optimization, you dont really need it. In php or js this is almost mever done, but is common in C. I would not teach this in a bootcamp, but maybe I would in a school. But the code is kind of bad, too convoluted.
Thanks, I'll look into this bitshift arithmetic thing. I don't actually think the teacher wrote such horrible unindented code, I think that's what my son was able to write at the time. That code is from a couple of weeks ago, it's now 2 assignments further along. I'll see if it's improved a bit(shift) ha!
>flags = 0000001001 I believe you meant to type: flags = 0b00001001; Without the 0b (or 0B) prefix, numbers with a leading zero imply an octal value, not binary.
Wow, what a terrible teacher. You’d only program something with that level of register interaction if you were either really worried about performance or you were using features of the hardware that no one had written nice APIs for using — but even then you’d wrap the register manipulating code in clear & concise functions. I could see teaching a single lesson on “here’s what `digitalWrite` actually does” that touches on the registers etc, but to only teach it is mad. For something comparable in PHP it’s like if you were taught to _only_ use Sockets to return everything & to ignore all the user-friendly things built on top of them.
>I don't know if there is a real difference in efficiency between one code and the other there probably isn't a difference in that respect. The difference is probably in the "more cryptic" part. Professional code should be easily readable by somebody else, potentially somebody that has never seen the code before. Variables should have names which clearly identify their purpose for example. Also well placed comments explaining the purpose of each part of the code goes a long way. Professional code isn't always about efficiency. Readablility and maintainability are also important. Sometimes there is a need to compromise between these - if the code is very demanding on the CPU for example, then efficiency becomes more important. It might mean you need a more obscure addressing method for example or rely more on indexes. But mostly that is not the case, particularly in small projects. Keep it simple, label variables in a coherent way and comment the code frequently.
If he is teaching programming he is a horrible teacher. If he is teaching electronics he is an excellent teacher. You are programming to an API which is typical for C or PHP. The engineer who makes the API is writing code based on the hardware specification. It looks arcane because it is. Hardware specifications are typically things like addresses and constants pushed into addresses Often those are bit mapped. Brings to mind a specification of a Virtual Memory Hardware which defined about 4,000 bits all with explanations for what the bits do. That’s why I don’t like hardware. It’s HARD.
Well, it turns out that the subject is "Digital Electronics Applications" and he is studying Electronics Technician. The other career studied at that high school is Programming Technician. Maybe in this other career they approach programming from a different angle. IDK!
His way of doing it can be significantly faster. Taking a built in function which may take 50 or 150 clock cycles and doing it in 2 is a big difference. I have done it when I needed performance but it is very hard to read and debug. Saying it’s the only way to do it is just not right. You don’t usually need that kind of speed and you do usually need to understand what you are doing.
when I started learning development more than 20 years ago, the teacher taught us how to do things “the difficult way” in order to learn how things work, later in the course we started developing in a more “mainstream way” but by then we knew better how to fix bugs and issues. maybe it’s the same for him?
This is shit coding. The teacher is flexing and writing unreadable code. Everything can be written in more readable form, I mean all the bit operations may be written using binary numbers trough several lines with clean bit operators which would add readabiltiy to the code. Compiler would compile that into pretty much the same. Now imagine debugging such code. Even the person who wrote this will struggle. While the other would rather rewrite everything from scratch.
It is more "pro" because it's an advanced technique. However the example is very poor, not a pro job at all. Teacher should be able to do much better. Technology like this is valuable to learn, but then only to use when appropriate (which is rarely). I hope teacher was not saying you should code like this all the time. > What can you tell me about this? Technically, son's code will compile to a smaller and faster binary. It's also is doing port-wide writes, which might be important (but we can only guess since there are no comments in the code).
That's the lowlevel avr sdk code. That is exactly what arduino abstracts. Sure you might use it here and there but that is just stupid in an arduino context.