9 ms·

Trying to keep an open mind here about this - but what does Haskell offer on an _arduino_ aside from developer preference? Surely C/C++ will be the better perf

• kryptiskt 7y ago
  It's not running Haskell on the Arduino, you are building a C program for Arduino using a DSL in Haskell.
  • jonny383 7y ago
    The argument is still kind of the same. What benefits does this have (aside from developer preference) over using flat out C/C++? What is the performance like using the DSL in Haskell?
    • tartoran 7y ago
      Not the OP but I suspect we’re not talking about any performance gains here, the arduino is still running binary. What you get by using a functional language like haskell is a way to structure your code differently and in many cases that could make your life a whole lot easier when you translate the solution that you have in your head to code. It is also easier to catch bugs
    • np_tedious 7y ago
      Is developer preference not important? What advantages does C have over processor specific assembly?
    • random314 7y ago
      Developer preference is a very big deal. Almost all other factors are secondary.
      • pkolaczk 7y ago
        If a developer wants to use a hammer for everything, because everything looks like nails to him, then I doubt in his professionalism. Sure, dev preferences matter, but only within the space dictated by the client requirements. Customers do not care if the thing they are using was created with C or Haskell. They care about price, performance and features. It might be harder to program in C++, but the final result can better fulfill the requirements.
        • random314 7y ago
          Devs prefer one language over the other, because they consider it to be better for their use case - it is not because of religious reasons. Clients typically don't have the technical expertise to dictate what technology the dev should use. If the client knows what technology they need, they should simply look for those devs who have expertise in that technology. Half the languages that you see succeed today(the other half are those pushed by megacorps as the only developer platform), are because of dev preferences - not because of client requirements.
          • pkolaczk 7y ago
            Yet they often choose wrong tool for the job. We often see games written in Java, big websites created in PHP, or processing huge amounts of data in Python. Here someone wants to do embedded in Haskell. These are not technical reasons. The reasons for these choices are frequently "this is the only tech stack I know" or "this is easier to learn".
            • random314 7y ago
              Facebook has been written in php, and minecraft in Java - because that was the language that the developer preferred. Are you saying this was wrong? Both developers made billions of dollars from it. If a client needs a particular technology then he should look for specialists in those technologies. Otherwise, just leave it to the developers preference. And reasons such as 'this is the only tech stack I know' or 'this is easier to learn' are perfectly good reasons. Reasons for a lot of things are not technical. You think Mark Zuckerberg created Facebook for technical reasons? In fact familiarity with a tech stack and simplicity of learning are seen as key technical considerations when choosing a technology for development. You must be very immature to think these are not technical reasons.
    • WJW 7y ago
      The advantage of CoPilot (the DSL this library is built upon) is that it builds verifiable constant-time constant-memory programs, which is quite important in some cases (like aerospace control programs). Whether that is an important property for Arduino is debatable of course.
• dragonsh 7y ago
  You are right C is a good choice for arduino, but if Python can be used with it, I believe Haskell can also be used in similar way. It will bring many high level features like type safety, immutability, runtime error free code and code that is easy to refactor, once the Haskell learning curve is climbed. I like Haskell for its brevity and pseudo code like syntax which really runs like Python with all the necessary safety. Given Haskell share in the overall eco-system of languages, I don’t expect it to have any significant impact. But this little steps are necessary to move forward Haskell. I think the biggest stumbling block Haskell need to overcome is to have good documentation like Python. I believe if instead of just features, language research Haskell community needs to put extraordinary efforts in documentation. In spite of Haskell being an old language more than 50% of packages on hackage do not have proper documentation and unless that do not go up to 90% or more Haskell won’t be able to be used effectively by programmers to solve computing problems. We all stands on giants of shoulders and for that to happen need documentation. I believe people underestimated the power of good documentation. It should be twice or thrice more efforts than the language feature development itself.
  • jonny383 7y ago
    Great points, thanks.
  • droithomme 7y ago
    > if Python can be used with it Which Arduino models are people running Python on? Surely not the most common models?
    • StavrosK 7y ago
      No, the Uno has nowhere near enough RAM to be useful with Python. However, MicroPython runs beautifully on an ESP8266, which everyone should always use instead of an Uno, in my opinion.
      • droithomme 7y ago
        I run Lua and compile C on my ESP8266's. I'm sure MicroPython could fit there as well. But even MicroPython doesn't run on a Arduino Uno, much less Haskell.
• deleted 7y ago
  [deleted]
• toast0 7y ago
  Performance may not matter that much, depending on the application. I've got some arduino capable boards monitoring temperatures once a minute, but I'm using lua because the documentation for my board was less handwavy for lua than for arduino (it's an esp8266 board; the c environment is a little weird).
  • pkolaczk 7y ago
    If performance doesn't matter, then most likely this is a sign of using too powerful hardware for the job. This is ok in a hobby project, but if you wanted to produce and sell these on mass market, then your competitor would get a smaller board with a less powerful chip and win by the price (or earn more per unit sold).
    • magicalhippo 7y ago
      True, though wifi and ethernet are quite demanding, so any uC capable of either will most likely be "too powerful" for things like doing simple I2C/SPI communication with a sensor or five and relaying it back.
• one-punch 7y ago
  My understanding is that the domain-specific language (which is embedded in Haskell) generates C code, which is then compiled to an arduino binary. The key sentence: > This whole example turns into just 63 lines of C code, which compiles to a 1248 byte binary, so there's plenty of room left for larger, more complex programs. What the eDSL (embedded domain-specific language) offers is a higher level of abstraction: by using functional reactive programming, the programmer can reason about the code at a more intuitive level (instead of C, assembly, or machine code). Usually people call this style of programming declarative instead of imperative: focusing on what to do instead of how to do it. In a more interesting example in the article, we see right away that the LED is on when, and only when, the button is pressed or when it is “blinking”, with “a longer and longer” delay (with lower level details deferred to the counter function, or with the timing logic handled by the functional reactive programming framework—to appreciate the abstraction ability of FRP, try to imagine how to implement the same LED (which is on when pressed or with a longer and longer delay) in other procedural languages, likely different concerns will be interleaved). When concerns are cleanly separated in Haskell, we understand what the code intends to do right away, making the code more maintainable. (And more fun to read and write!) As a side bonus, Haskell has a strong and expressive type system, and a pervasive use of laziness to enable purity, allowing local equational reasoning (e.g., no need to worry about hidden mutable global state, so functions could be understood on their own, etc.), making the code even easier to reason about and to maintain then some other procedural languages (what you write is what you intuitively mean). So I think the trade off is between developer productivity and performance (of the generated C code vs a handcrafted C code; very much like the trade off between a compiled machine code vs a handcrafted machine code).
• mindslight 7y ago
  What does C/C++ offer aside from developer preference, when compared to assembly? Squeezing every drop out of microcontrollers likely includes much bit-banging. Once you've given up perfect instruction cycle counting, they're all high level languages!
• pjmlp 7y ago
  Many of those tiny boards are better than most 60's computers, which had quite a few high level languages to choose from, before C was even born. So keeping an open mind is actually the key factor here.
• joeyh 7y ago
  It's worth looking at the C code that's generated from a simple blink example in haskell. It's not very idiomatic, but neither is it very slow. Much of the fluff should get optimised away by the C compiler. I've been generally very impressed with how readable the output is, as generated code goes, and how performant it seems. #include <stdint.h> #include <stdbool.h> #include <string.h> static bool s0[(2)] = {(false), (true)}; static size_t s0_idx = (0); bool s0_gen(void) { return (s0)[s0_idx]; } bool delay_guard(void) { return true; } int16_t delay_arg0(void) { return 100; } bool digitalWrite_guard(void) { return true; } int16_t digitalWrite_arg0(void) { return 13; } bool digitalWrite_arg1(void) { return (s0)[s0_idx]; } void step(void) { if ((delay_guard)()) { (delay)(((delay_arg0)())); }; if ((digitalWrite_guard)()) { (digitalWrite)(((digitalWrite_arg0)()), ((digitalWrite_arg1)())); }; ((s0)[s0_idx]) = ((s0_gen)()); (s0_idx) = ((++(s0_idx)) % (2)); } void setup() { pinMode(13, OUTPUT); } void loop() { step(); }
  • joeyh 7y ago
    Doing some constant folding, the C compiler would arrive at something like this: void loop(void) { delay(100); digitalWrite(13, s0[s0_idx]); s0[s0_idx] = s0[s0_idx]; s0_idx = (++s0_idx) % 2; } void setup() { pinMode(13, OUTPUT); } Only the s0[s0_idx] = s0[s0_idx] looks like extra work now. I don't know if a C compiler would optimise that away, but assuming it does not, one extra memory write per loop is not bad overhead.