4 ms·

Very cool, and very persistent. Good job! I can see myself losing a month on something like this. <rant> Now, I like the tech and hacker side of it, but it ma

by eggy 10y ago

Very cool, and very persistent. Good job! I can see myself losing a month on something like this. <rant> Now, I like the tech and hacker side of it, but it made me think again of how complicated modern hardware and software have become compared to staying with plain C, not even C++. This is not wholly due to more complicated hardware, but so many people building stuff without going back to first principles. I think the Rust crowd are doing their homework here though. I understand the benefits of Rust, since I am learning it at the moment, but I guess at my age it is a harder sell for something like this micro. It is so easy to just drop into C for small micros. The BBC micro:bit has a C/C++ interface, of which I bet the C interface is cake. It's small enought that all a good programmer has to do is dot their 'i's and cross their 't's anyway (or they should). </rant>

StavrosK 10y ago
It's become more complicated because C is much more cumbersome to write than a higher-level language, so everyone prefers the latter. If I'm working on a project for fun on my spare time, I don't want to spend an hour fighting the compiler figuring out why array bounds are being weird, or why the compiler is complaining about the type, or whatever. Python is much more do-what-I-mean, for example, and it's much more appealing to me when I want to write something quickly. I've tried other languages and, with the exception of Rust, I always feel like development shouldn't have to be this yak-shavy.
- yoklov 10y ago
  I've written a good amount of rust, and a ton of C/C++, and, well, the compiler complaining about the type, or, well, anything really, is far more likely in Rust than C or C++
  - bitwize 10y ago
    That's a feature -- not a bug.
  - StavrosK 10y ago
    It is, but there's usually an easier (or more obvious) way to fix it in Rust.
- ue_ 10y ago
  Doesn't the compiler only complain about the type when you're doing something wrong anyway? C is only cumbersome when you don't already have the data structures you want implemented, which is why there are usually many libraries for any one data structure you want to represent, and operations on it. As for array bounds, it should work so long as you don't access out of bounds, and you can do that by making sure you know what you're accessing. It's not that hard - but even if you want, you can get your compiler to tell you when you do out of bounds access at runtime.
  - pcwalton 10y ago
    > As for array bounds, it should work so long as you don't access out of bounds, and you can do that by making sure you know what you're accessing. It's not that hard Judging by the flood of out of bounds array accesses in shipping code over several decades, actually it is pretty hard to consistently get it right. > even if you want, you can get your compiler to tell you when you do out of bounds access at runtime. At the cost of making your program slower than Java. So at that point why not use a memory safe language?
  - StavrosK 10y ago
    > C is only cumbersome when you don't already have the data structures you want implemented, which is why there are usually many libraries for any one data structure you want to represent, and operations on it. I suspect this is the mistake I'm making, because 90% of my time is spent writing code to do data structure manipulation. I'll look around and try to find some libraries for things, but I'm usually constrained to the ecosystem of the particular flavor of C I write (for the Arduino, which is really C++, but still). I guess most general-purpose libraries will work there too, though. > As for array bounds, it should work so long as you don't access out of bounds, and you can do that by making sure you know what you're accessing. No, they do work, it just takes me ages to find the correct thing to tell the compiler so it understands what I want to do. Don't get me started on the ten types of string, though :(
    - yoklov 10y ago
      If you're writing C code, the right way to think about data structures in a lot of cases is that they're an optimization. You can implement a map using an array of struct { key, value }, and O(n) search. If you keep it sorted, that becomes O(n log n). A hash table is a further optimization. Most of the time you don't need these.
- eggy 10y ago
  I used to think similarly to you about C, or even Python for that matter, but after years of leaving C, I am back at it. This is while also learning Rust. Why? Because the easy languages are never self-contained to perform a specialized task, and you wind up going through dependency hell, or rolling your own libraries. C takes work, but you stay in the same arena while sussing it out. And, in the end, it is truly portable and usually the fastest of any other implementation. Horses for courses I guess.
  - moosingin3space 10y ago
    I don't understand how using C lets you avoid dependency hell or rolling your own libraries. This comment doesn't make sense to me - dependency management/rolling your own libraries seems to be there in all languages.
    - eggy 10y ago
      I am specifically referring to it in the context of the OP about an embedded device. For general computing, your objections may hold. In all my years of doing small devices, Python's libs wouldn't fit in the space of the unit if you could find the exact library to run on different architectures. The only other languages I have used aside from C for the small devices is Forth or assembler. There are usually ready-made libs or interfaces from the manufacturer. I haven't seem much provided in Python or other high-level languages. The NodeLua project is an exception, and it is promising. I have already began work on a Lisp of mine (written in C) for this device. Others have done so too. I guess if you have a Raspberry Pi or other, you can afford the space, and it is basically a small Linux box, so you can run anything you like. I was sticking to a discussion of small, embedded devices where those are not yet options. In the future, I am sure they will be big enough to fit high-level languages.
  - StavrosK 10y ago
    > And, in the end, it is truly portable and usually the fastest of any other implementation It definitely is, and, when I need these things, I will write the program in C. It's very rare for me.

by eggy 10y ago

StavrosK 10y ago

It's become more complicated because C is much more cumbersome to write than a higher-level language, so everyone prefers the latter. If I'm working on a project for fun on my spare time, I don't want to spend an hour fighting the compiler figuring out why array bounds are being weird, or why the compiler is complaining about the type, or whatever. Python is much more do-what-I-mean, for example, and it's much more appealing to me when I want to write something quickly. I've tried other languages and, with the exception of Rust, I always feel like development shouldn't have to be this yak-shavy.

yoklov 10y ago
I've written a good amount of rust, and a ton of C/C++, and, well, the compiler complaining about the type, or, well, anything really, is far more likely in Rust than C or C++
- bitwize 10y ago
  That's a feature -- not a bug.
- StavrosK 10y ago
  It is, but there's usually an easier (or more obvious) way to fix it in Rust.
ue_ 10y ago
Doesn't the compiler only complain about the type when you're doing something wrong anyway? C is only cumbersome when you don't already have the data structures you want implemented, which is why there are usually many libraries for any one data structure you want to represent, and operations on it. As for array bounds, it should work so long as you don't access out of bounds, and you can do that by making sure you know what you're accessing. It's not that hard - but even if you want, you can get your compiler to tell you when you do out of bounds access at runtime.
- pcwalton 10y ago
  > As for array bounds, it should work so long as you don't access out of bounds, and you can do that by making sure you know what you're accessing. It's not that hard Judging by the flood of out of bounds array accesses in shipping code over several decades, actually it is pretty hard to consistently get it right. > even if you want, you can get your compiler to tell you when you do out of bounds access at runtime. At the cost of making your program slower than Java. So at that point why not use a memory safe language?
- StavrosK 10y ago
  > C is only cumbersome when you don't already have the data structures you want implemented, which is why there are usually many libraries for any one data structure you want to represent, and operations on it. I suspect this is the mistake I'm making, because 90% of my time is spent writing code to do data structure manipulation. I'll look around and try to find some libraries for things, but I'm usually constrained to the ecosystem of the particular flavor of C I write (for the Arduino, which is really C++, but still). I guess most general-purpose libraries will work there too, though. > As for array bounds, it should work so long as you don't access out of bounds, and you can do that by making sure you know what you're accessing. No, they do work, it just takes me ages to find the correct thing to tell the compiler so it understands what I want to do. Don't get me started on the ten types of string, though :(
  - yoklov 10y ago
    If you're writing C code, the right way to think about data structures in a lot of cases is that they're an optimization. You can implement a map using an array of struct { key, value }, and O(n) search. If you keep it sorted, that becomes O(n log n). A hash table is a further optimization. Most of the time you don't need these.
eggy 10y ago
I used to think similarly to you about C, or even Python for that matter, but after years of leaving C, I am back at it. This is while also learning Rust. Why? Because the easy languages are never self-contained to perform a specialized task, and you wind up going through dependency hell, or rolling your own libraries. C takes work, but you stay in the same arena while sussing it out. And, in the end, it is truly portable and usually the fastest of any other implementation. Horses for courses I guess.
- moosingin3space 10y ago
  I don't understand how using C lets you avoid dependency hell or rolling your own libraries. This comment doesn't make sense to me - dependency management/rolling your own libraries seems to be there in all languages.
  - eggy 10y ago
    I am specifically referring to it in the context of the OP about an embedded device. For general computing, your objections may hold. In all my years of doing small devices, Python's libs wouldn't fit in the space of the unit if you could find the exact library to run on different architectures. The only other languages I have used aside from C for the small devices is Forth or assembler. There are usually ready-made libs or interfaces from the manufacturer. I haven't seem much provided in Python or other high-level languages. The NodeLua project is an exception, and it is promising. I have already began work on a Lisp of mine (written in C) for this device. Others have done so too. I guess if you have a Raspberry Pi or other, you can afford the space, and it is basically a small Linux box, so you can run anything you like. I was sticking to a discussion of small, embedded devices where those are not yet options. In the future, I am sure they will be big enough to fit high-level languages.
- StavrosK 10y ago
  > And, in the end, it is truly portable and usually the fastest of any other implementation It definitely is, and, when I need these things, I will write the program in C. It's very rare for me.