6 ms·

In my opinion, it's because new programmers find C scary due to the prevalence of Python. There's no need to learn anything anymore with all of our RAM and stor

by alar44 4y ago

In my opinion, it's because new programmers find C scary due to the prevalence of Python. There's no need to learn anything anymore with all of our RAM and storage. Programming has essentially turned into scripting. Today you load the boiler library and type start().

ChuckNorris89 4y ago
>Today you load the boiler library and type start(). Not when you have safety critical real time applications that need to be certified. Gas boiler control isn't move fast and break things web development. Unless you want to blow yourself up. That's why old AVR solutions are still used. They've been certified once, they work just fine for this purpose even on newer products. So you go with it. It's a slow moving industry for this reason. Also, embedded dev is way more than writing C or python code and how many "bits" your CPU core has. You need to take into account clocking sources and stability, analog and digital I/O, on package voltage regulators, tolerance to glitching and brownouts, etc. and for certain applications, AVR chips are way more robust than newer ARM or RISC-V shiny.
- rtpg 4y ago
  I don’t want to go too much into C vs Rust but loads of C code out there, when it comes time to manipulate strings or do something a bit complicated, ends up a hacky mess. For all the implications you are making about “move fast and break things” in web dev, at least newer tech stacks makes it easier to not completely break your data structures cuz the abstraction ceiling made doing things the right way hard. Of course experienced C programmers “get it”, design their code in a way to avoid these pitfalls, and can right performant, correct code. I just think that it’s easier with a lot of other tools for stuff that’s just a bit complicated
  - ChuckNorris89 4y ago
    I feel you're mixing things up. Not every embedded application requires parsing strings or JSONs like you do with web frameworks. AVRs and 8 bit chips in general are mostly used in various fixed point numerical control applications like CNC, industrial automation, elevator control, and white goods for the home like washing machines, HVAC, and microwave ovens, so for that they're perfect and so is C. All they do is read some buttons and sensors, crunch some basic math, run a state machine, and turn some motors, LEDs and relays ON and OFF. That's it. Complex string manipulations is something you'll never see on an AVR chip in such production applications.
    - jjoonathan 4y ago
      Fixed point is a perfect example of an abstraction ceiling that makes it unnecessarily hard to do the right thing. At first it's fine, but then you'll want to do some filtering, and then some coefficient buckets will start to overflow, and then you'll start tracking exponents, and before you know it you've sunk engineer months or years into an ugly, buggy, underpowered reinvention of floating point numbers.
      - ChuckNorris89 4y ago
        I've shipped safety critical motor control embedded software that runs flawlessly on thousands of cars using only fixed point math without it being ugly, buggy or underpowered, precisely because everything was computed only in fixed point fractional math. You're just making up FUD.
        jjoonathan 4y ago
        "It was good enough for me, so it should be good enough for everybody." Lol.
      - otter-rock 4y ago
        Seems like you didn't need fixed point in the first place. It's for when you need guarantees.
  - scoutt 4y ago
    I've worked on dozens of embedded projects that don't need string manipulation. Or just outputting some log string through a serial port, which is removed in release. Why do you think you'll need to process input strings? > just a bit complicated Like what? Most embedded projects don't use concurrency, or even dynamic allocations. Not every projects is a hackable bluetooth/wifi stack, that you need Rust otherwise [insert favourite exploit FUD here]. It can be as simple as a toothbrush with two buttons and a motor.
    - deleted 4y ago
      [deleted]
    - rtpg 4y ago
      I’m just talking about business logic and data structures. It seems fine to want to not have bugs in principle! Though to your point when we’re talking about 8-bit microprocessors the amount of complications that could even be placed. I just feel like it’s totally normal to feel lacking when writing/reading certain kinds of code in C.
      - scoutt 4y ago
        > business logic and data structures. It seems fine to want to not have bugs in principle! I think there is no (embedded) language so far which prevents you from having bugs in business logic.
  - pjmlp 4y ago
    Those Python programmers scared of learning C, can also use certified Pascal and BASIC compilers then. https://www.mikroe.com/mikropascal https://www.mikroe.com/mikropascal https://www.mikroe.com/mikrobasic https://www.mikroe.com/mikrobasic
- alar44 4y ago
  Agreed, I was illustrating what Python programming looks like to me. Having experience in embedded C, I see Python as a templating language at best, and it's obviously not something you'd use for critical systems. Every time I use Python I end up rewriting libraries in C.
jacquesm 4y ago
I much prefer simplicity in the runtimes of things that have the potential to affect lives in a catastrophic way. With the summit being 'no runtime', which makes validating a design that much easier.
atoav 4y ago
I program C, Python, Rust and Javascript, Java, C#, C++, ... And I can assure you the reason I started using Rust is not that I find C too scary. It is an interesting language that has some seriously interesting concepts in it. To rule out certain (very security relevant) classes of mistakes entirely is good as well. That being said, learning Rust also made me a much better C programmer, because it forced me to deal with many problems and concepts that might bite even experienced C programmers once in a while all while using a language that just won't let you do the stupid stuff. Of course that makes you angry and you curse at the compiler. And then you think about why this doesn't work and this is the moment where you pause and go: "Oh.." For me the enlightenment came when a tech blogger asked for the fastest string tokenization program in any language and I sent him my 10 minute naive Rust thing and it won second place. The first place was hand crafted assembler. My thing could handle UTF-8, the other could not. This is a real and tangible thing, not just some "shiny" thing.
- 2143 4y ago
  > it won second place Out of how many? While I'm pretty sure you're a very competent programmer, there's a possibility others used non-optimal algorithms. A good algorithm in a slow language can, on the limit, be faster than a bad algorithm in a faster language. Case in point: Norvig's sudoku solver in Python blows everything else away in performance because he put a lot of thought into the algorithm [1]. I wrote a C program to solve sudoku (using a backtracking approach), and it was nowhere as fast as Norvig's python program. Can anybody conclude python is therefore faster than C? No! The only thing you can conclude from that is that I'm a lousy programmer :) Sure you can reimplement Norvig's program in Rust or C or assembly or Brainfuck or whatever, but that's besides the point. [1] https://norvig.com/sudoku.html https://norvig.com/sudoku.html
  - atoav 4y ago
    > Out of how many? 20 or so. It has been a while ago so I cannot recall the exact way I did it, but I certainly didn't implement any specific algorithm, I just did the straightforward thing using Rusts builtin functions as a realistic emulation of a lazy programmer. The point of my comment was not to claim that Rust is the faster language. The point was that you can write mediocre Rust and still end up with extremely performant code that covers a lot of ground.
scoutt 4y ago
> all of our RAM and storage This has a cost. Even saving a marginal 10 cents can make a difference. Even if we live long enough to see a 10 cents microcontroller with 1GB of RAM/FLASH, there will be a $0.000001 part using the same technology but with 2K RAM and 16K storage. If I'll be making millions of boilers, guess which one I will use. > Programming has essentially turned into scripting. Hard real time applications disagree with this. And remember that someone still has to lay the foundations to run scripts in an MCU. > There's no need to learn anything anymore I heard the same thing and several variants, 20 years ago when .NET came out.
- sudosysgen 4y ago
  10 cents for 1 million boilers is only 100k. That's about the price of an additional engineer, so it may very well be worth it to move up in abstraction instead.
  - scoutt 4y ago
    What should I do with an extra engineer? Should I hire one just for the sake of moving up in abstraction? 100k saved is 100k earned. Half a Ferrari.
    - sudosysgen 4y ago
      It's exactly the reverse. You need fewer engineers because it's going to be much easier to write the same code at a higher level of abstraction. So you can have that engineer work on something that's going to make you revenue, or hire one less dev.
socialdemocrat 4y ago
More about C just being really outdated. There has been some innovation in programming language design since the 1970s. Python is not exactly cutting edge and is an entirely different language. But Rust, Go, Swift, Zig, D, Terra, Nim and many others can potentially fill much of the same niche as is occupied by C today.
patrec 4y ago
> In my opinion, it's because new programmers find C scary due to the prevalence of Python. A professional programmer who does not find C scary is about as confidence inspiring as a nuclear engineer who does not find plutonium scary.

by alar44 4y ago

ChuckNorris89 4y ago

>Today you load the boiler library and type start(). Not when you have safety critical real time applications that need to be certified. Gas boiler control isn't move fast and break things web development. Unless you want to blow yourself up. That's why old AVR solutions are still used. They've been certified once, they work just fine for this purpose even on newer products. So you go with it. It's a slow moving industry for this reason. Also, embedded dev is way more than writing C or python code and how many "bits" your CPU core has. You need to take into account clocking sources and stability, analog and digital I/O, on package voltage regulators, tolerance to glitching and brownouts, etc. and for certain applications, AVR chips are way more robust than newer ARM or RISC-V shiny.

rtpg 4y ago
I don’t want to go too much into C vs Rust but loads of C code out there, when it comes time to manipulate strings or do something a bit complicated, ends up a hacky mess. For all the implications you are making about “move fast and break things” in web dev, at least newer tech stacks makes it easier to not completely break your data structures cuz the abstraction ceiling made doing things the right way hard. Of course experienced C programmers “get it”, design their code in a way to avoid these pitfalls, and can right performant, correct code. I just think that it’s easier with a lot of other tools for stuff that’s just a bit complicated
- ChuckNorris89 4y ago
  I feel you're mixing things up. Not every embedded application requires parsing strings or JSONs like you do with web frameworks. AVRs and 8 bit chips in general are mostly used in various fixed point numerical control applications like CNC, industrial automation, elevator control, and white goods for the home like washing machines, HVAC, and microwave ovens, so for that they're perfect and so is C. All they do is read some buttons and sensors, crunch some basic math, run a state machine, and turn some motors, LEDs and relays ON and OFF. That's it. Complex string manipulations is something you'll never see on an AVR chip in such production applications.
  - jjoonathan 4y ago
    Fixed point is a perfect example of an abstraction ceiling that makes it unnecessarily hard to do the right thing. At first it's fine, but then you'll want to do some filtering, and then some coefficient buckets will start to overflow, and then you'll start tracking exponents, and before you know it you've sunk engineer months or years into an ugly, buggy, underpowered reinvention of floating point numbers.
    - ChuckNorris89 4y ago
      I've shipped safety critical motor control embedded software that runs flawlessly on thousands of cars using only fixed point math without it being ugly, buggy or underpowered, precisely because everything was computed only in fixed point fractional math. You're just making up FUD.
      - jjoonathan 4y ago
        "It was good enough for me, so it should be good enough for everybody." Lol.
    - otter-rock 4y ago
      Seems like you didn't need fixed point in the first place. It's for when you need guarantees.
- scoutt 4y ago
  I've worked on dozens of embedded projects that don't need string manipulation. Or just outputting some log string through a serial port, which is removed in release. Why do you think you'll need to process input strings? > just a bit complicated Like what? Most embedded projects don't use concurrency, or even dynamic allocations. Not every projects is a hackable bluetooth/wifi stack, that you need Rust otherwise [insert favourite exploit FUD here]. It can be as simple as a toothbrush with two buttons and a motor.
  - deleted 4y ago
    [deleted]
  - rtpg 4y ago
    I’m just talking about business logic and data structures. It seems fine to want to not have bugs in principle! Though to your point when we’re talking about 8-bit microprocessors the amount of complications that could even be placed. I just feel like it’s totally normal to feel lacking when writing/reading certain kinds of code in C.
    - scoutt 4y ago
      > business logic and data structures. It seems fine to want to not have bugs in principle! I think there is no (embedded) language so far which prevents you from having bugs in business logic.
- pjmlp 4y ago
  Those Python programmers scared of learning C, can also use certified Pascal and BASIC compilers then. https://www.mikroe.com/mikropascal https://www.mikroe.com/mikropascal https://www.mikroe.com/mikrobasic https://www.mikroe.com/mikrobasic
alar44 4y ago
Agreed, I was illustrating what Python programming looks like to me. Having experience in embedded C, I see Python as a templating language at best, and it's obviously not something you'd use for critical systems. Every time I use Python I end up rewriting libraries in C.

jacquesm 4y ago

I much prefer simplicity in the runtimes of things that have the potential to affect lives in a catastrophic way. With the summit being 'no runtime', which makes validating a design that much easier.

atoav 4y ago

I program C, Python, Rust and Javascript, Java, C#, C++, ... And I can assure you the reason I started using Rust is not that I find C too scary. It is an interesting language that has some seriously interesting concepts in it. To rule out certain (very security relevant) classes of mistakes entirely is good as well. That being said, learning Rust also made me a much better C programmer, because it forced me to deal with many problems and concepts that might bite even experienced C programmers once in a while all while using a language that just won't let you do the stupid stuff. Of course that makes you angry and you curse at the compiler. And then you think about why this doesn't work and this is the moment where you pause and go: "Oh.." For me the enlightenment came when a tech blogger asked for the fastest string tokenization program in any language and I sent him my 10 minute naive Rust thing and it won second place. The first place was hand crafted assembler. My thing could handle UTF-8, the other could not. This is a real and tangible thing, not just some "shiny" thing.

2143 4y ago
> it won second place Out of how many? While I'm pretty sure you're a very competent programmer, there's a possibility others used non-optimal algorithms. A good algorithm in a slow language can, on the limit, be faster than a bad algorithm in a faster language. Case in point: Norvig's sudoku solver in Python blows everything else away in performance because he put a lot of thought into the algorithm [1]. I wrote a C program to solve sudoku (using a backtracking approach), and it was nowhere as fast as Norvig's python program. Can anybody conclude python is therefore faster than C? No! The only thing you can conclude from that is that I'm a lousy programmer :) Sure you can reimplement Norvig's program in Rust or C or assembly or Brainfuck or whatever, but that's besides the point. [1] https://norvig.com/sudoku.html https://norvig.com/sudoku.html
- atoav 4y ago
  > Out of how many? 20 or so. It has been a while ago so I cannot recall the exact way I did it, but I certainly didn't implement any specific algorithm, I just did the straightforward thing using Rusts builtin functions as a realistic emulation of a lazy programmer. The point of my comment was not to claim that Rust is the faster language. The point was that you can write mediocre Rust and still end up with extremely performant code that covers a lot of ground.

scoutt 4y ago

> all of our RAM and storage This has a cost. Even saving a marginal 10 cents can make a difference. Even if we live long enough to see a 10 cents microcontroller with 1GB of RAM/FLASH, there will be a $0.000001 part using the same technology but with 2K RAM and 16K storage. If I'll be making millions of boilers, guess which one I will use. > Programming has essentially turned into scripting. Hard real time applications disagree with this. And remember that someone still has to lay the foundations to run scripts in an MCU. > There's no need to learn anything anymore I heard the same thing and several variants, 20 years ago when .NET came out.

sudosysgen 4y ago
10 cents for 1 million boilers is only 100k. That's about the price of an additional engineer, so it may very well be worth it to move up in abstraction instead.
- scoutt 4y ago
  What should I do with an extra engineer? Should I hire one just for the sake of moving up in abstraction? 100k saved is 100k earned. Half a Ferrari.
  - sudosysgen 4y ago
    It's exactly the reverse. You need fewer engineers because it's going to be much easier to write the same code at a higher level of abstraction. So you can have that engineer work on something that's going to make you revenue, or hire one less dev.

socialdemocrat 4y ago

More about C just being really outdated. There has been some innovation in programming language design since the 1970s. Python is not exactly cutting edge and is an entirely different language. But Rust, Go, Swift, Zig, D, Terra, Nim and many others can potentially fill much of the same niche as is occupied by C today.

patrec 4y ago

> In my opinion, it's because new programmers find C scary due to the prevalence of Python. A professional programmer who does not find C scary is about as confidence inspiring as a nuclear engineer who does not find plutonium scary.