6 ms·

Exactly! Fortunately, the article didn't point out one of C's great advantages is that it's so lightweight it can fit into and run on all kinds of interesting

by diydsp 13y ago

Exactly! Fortunately, the article didn't point out one of C's great advantages is that it's so lightweight it can fit into and run on all kinds of interesting systems where other languages are infeasible economically. Cortices rule!

pjmlp 13y ago
Except there are other safer languages to choose from, like Pascal and Basic compilers. http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikrobasic/ http://www.mikroe.com/mikrobasic/
- brokenparser 13y ago
  And they're all way too slow for what I'm doing.
  - pjmlp 13y ago
    Why are they slow? If you are going to invoke the usual C FUD about bounds checking and such, you can disable them on parts where performance REALLY matters. Plus all compilers share the same backend.
- exDM69 13y ago
  > Except there are other safer languages to choose from, like Pascal and Basic compilers. I'm curious, why do you say "safer"? These are languages for microcontroller programming. The things you do there are bound to be "unsafe", like peeking and poking memory for memory mapped i/o and disabling/enabling interrupts. Unless, of course, all the possible things (i/o, timers, interrupts, etc) are wrapped in some kind of "safe" api so you essentially don't have access to low level facilities any more. The Arduino programming environment is kinda like this but you can still cause bad things to happen and if all else fails, hang the device with an infinite loop. Is there any backing for such claims of "safety"?
  - weland 13y ago
    > I'm curious, why do you say "safer"? These are languages for microcontroller programming. The things you do there are bound to be "unsafe", like peeking and poking memory for memory mapped i/o and disabling/enabling interrupts. There are things which are inherently safe by design in languages like Pascal -- e.g. in a naively-written program you can't write past the boundary of the UART RX buffer and thrash some other array in your program -- but your observation is fair.
    - exDM69 13y ago
      > There are things which are inherently safe by design in languages like Pascal -- e.g. in a naively-written program you can't write past the boundary of the UART RX buffer and thrash some other array in your program -- but your observation is fair. Which, of course, you can accomplish in C by wrapping your UART buffer handling code in functions that do bounds checking. And I assume that a micro controller Pascal or Basic dialect will have some kind of peek/poke from/to arbitrary memory addresses that can be misused just as a pointer access in C. Safety is hard to quantify and measure and calling one language safer than another sounds more like an opinion than a factual claim, especially in this context.
      - acqq 13y ago
        The "out of the box" defaults of Pascals are something you have to explicitly develop, test and maintain in your C. Which means that even during the maintenance cycle, long after it's originally implemented, it can still break in your C.
        exDM69 13y ago
        > The "out of the box" defaults of Pascals are something you have to explicitly develop, test and maintain in your C. Which means that even during the maintenance cycle, long after it's originally implemented, it can still break in your C. Let's not confuse languages and libraries/apis here (that may or may not be shipped with the compiler). There are libraries for C and related languages (e.g. Arduino) that actually do give you a "safe" way to deal with the hardware on microcontrollers. It's still easy to shoot yourself in the foot in C with a bad pointer access (esp. because there are no helpers to work with strings) but I don't really see how a Pascal dialect with peek/poke would be inherently better. I do agree that buying one of these Pascal/Basic software products that come with a fancy standard library that does safe access to the hw may help writing safer software but I don't see how that is an inherent quality of the language.
- weland 13y ago
  However, they are far more wanting on the tooling side.
  - pjmlp 13y ago
    Not when buying a commercial version of such tools.
- csmithuk 13y ago
  In some cases we don't want safety. C can be safe or unsafe depending on how you approach a problem.
  - userbinator 13y ago
    In some cases, we want freedom... and that's something that has been neglected a bit too much with new programming languages IMHO. Safety/security feels like it's the latest of the dumbing-down "let's treat programmers like idiots" fad.
    - Allan_Smithee 13y ago
      I submit as evidence 99.44% of software that has been released that programmers are, in fact, idiots.
    - scott_s 13y ago
      I think the approach of languages like Rust, which enforce strict safety by default, but allow "unsafe" regions of code, is the correct way to go. See http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety
      - Allan_Smithee 13y ago
        Or if you have any sense of history, languages like Modula-2/2+/3. (And undoubtedly a few (dozen?) others I'm unaware of.) Nothing new in software development. All the "new" shinies are decades (!) old.
        pjmlp 13y ago
        Somehow young developers seem to think only C and C++ offer native features. I wonder how we got sidetracked like that.
  - deletes 13y ago
    Can you give an example where you don't want safety and you aren't trying to hack? //curious
- FigBug 13y ago
  Yuk. I'd rather program in assembly than ever use those buggy compilers again.
- coldtea 13y ago
  Hehe, as soon as I read the comment, I knew who it would be!

by diydsp 13y ago

pjmlp 13y ago

Except there are other safer languages to choose from, like Pascal and Basic compilers. http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikrobasic/ http://www.mikroe.com/mikrobasic/

brokenparser 13y ago
And they're all way too slow for what I'm doing.
- pjmlp 13y ago
  Why are they slow? If you are going to invoke the usual C FUD about bounds checking and such, you can disable them on parts where performance REALLY matters. Plus all compilers share the same backend.
exDM69 13y ago
> Except there are other safer languages to choose from, like Pascal and Basic compilers. I'm curious, why do you say "safer"? These are languages for microcontroller programming. The things you do there are bound to be "unsafe", like peeking and poking memory for memory mapped i/o and disabling/enabling interrupts. Unless, of course, all the possible things (i/o, timers, interrupts, etc) are wrapped in some kind of "safe" api so you essentially don't have access to low level facilities any more. The Arduino programming environment is kinda like this but you can still cause bad things to happen and if all else fails, hang the device with an infinite loop. Is there any backing for such claims of "safety"?
- weland 13y ago
  > I'm curious, why do you say "safer"? These are languages for microcontroller programming. The things you do there are bound to be "unsafe", like peeking and poking memory for memory mapped i/o and disabling/enabling interrupts. There are things which are inherently safe by design in languages like Pascal -- e.g. in a naively-written program you can't write past the boundary of the UART RX buffer and thrash some other array in your program -- but your observation is fair.
  - exDM69 13y ago
    > There are things which are inherently safe by design in languages like Pascal -- e.g. in a naively-written program you can't write past the boundary of the UART RX buffer and thrash some other array in your program -- but your observation is fair. Which, of course, you can accomplish in C by wrapping your UART buffer handling code in functions that do bounds checking. And I assume that a micro controller Pascal or Basic dialect will have some kind of peek/poke from/to arbitrary memory addresses that can be misused just as a pointer access in C. Safety is hard to quantify and measure and calling one language safer than another sounds more like an opinion than a factual claim, especially in this context.
    - acqq 13y ago
      The "out of the box" defaults of Pascals are something you have to explicitly develop, test and maintain in your C. Which means that even during the maintenance cycle, long after it's originally implemented, it can still break in your C.
      - exDM69 13y ago
        > The "out of the box" defaults of Pascals are something you have to explicitly develop, test and maintain in your C. Which means that even during the maintenance cycle, long after it's originally implemented, it can still break in your C. Let's not confuse languages and libraries/apis here (that may or may not be shipped with the compiler). There are libraries for C and related languages (e.g. Arduino) that actually do give you a "safe" way to deal with the hardware on microcontrollers. It's still easy to shoot yourself in the foot in C with a bad pointer access (esp. because there are no helpers to work with strings) but I don't really see how a Pascal dialect with peek/poke would be inherently better. I do agree that buying one of these Pascal/Basic software products that come with a fancy standard library that does safe access to the hw may help writing safer software but I don't see how that is an inherent quality of the language.
weland 13y ago
However, they are far more wanting on the tooling side.
- pjmlp 13y ago
  Not when buying a commercial version of such tools.
csmithuk 13y ago
In some cases we don't want safety. C can be safe or unsafe depending on how you approach a problem.
- userbinator 13y ago
  In some cases, we want freedom... and that's something that has been neglected a bit too much with new programming languages IMHO. Safety/security feels like it's the latest of the dumbing-down "let's treat programmers like idiots" fad.
  - Allan_Smithee 13y ago
    I submit as evidence 99.44% of software that has been released that programmers are, in fact, idiots.
  - scott_s 13y ago
    I think the approach of languages like Rust, which enforce strict safety by default, but allow "unsafe" regions of code, is the correct way to go. See http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety
    - Allan_Smithee 13y ago
      Or if you have any sense of history, languages like Modula-2/2+/3. (And undoubtedly a few (dozen?) others I'm unaware of.) Nothing new in software development. All the "new" shinies are decades (!) old.
      - pjmlp 13y ago
        Somehow young developers seem to think only C and C++ offer native features. I wonder how we got sidetracked like that.
- deletes 13y ago
  Can you give an example where you don't want safety and you aren't trying to hack? //curious
FigBug 13y ago
Yuk. I'd rather program in assembly than ever use those buggy compilers again.
coldtea 13y ago
Hehe, as soon as I read the comment, I knew who it would be!