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.

My 2020 goal is to learn Haskell, so beginner here.

Is there a way other people can contribute to documentation ? Also how to generate documentation like found in Hoogle ?

Hm, I'm afraid to say that I can't find a good resource on how to write and build docs for Haskell libraries. Maybe that's a tutorial you could write once you've figured it out?! ;)

Here are a few links though:

* https://ndmitchell.com/downloads/slides-drive-by_haskell_con...

* https://haskell-haddock.readthedocs.io/en/latest/markup.html

* https://docs.haskellstack.org/en/stable/build_command/#synon...

Also, maybe join the #haskell-beginners channel on Slack: https://fpchat-invite.herokuapp.com/

There are other platforms too though, e.g. https://www.reddit.com/r/haskellquestions/, https://discourse.haskell.org/

The Haskell documentation generation tool is named haddock. It comes with GHC. I've never run it standalone, so I don't know how involved that is. But I frequently run it with the command "cabal haddock", which takes care of telling it where all your source files are and where to drop the output.

Thank for reply. I'll dig into it. Kind of documentation I am thinking about not only description of what method do, but also include example of 'how to use' it.

Doctests are often useful to briefly demonstrate how something works: http://hackage.haskell.org/package/doctest

They are a bit finicky to set up though.

Another good resource: http://yannesposito.com/Scratch/en/blog/Haskell-Tutorials--a...

I think the biggest stumbling block is going to be that most of my complexity is in wiring the Arduino to something else. That and you don't even start with a system that can log.

This is strictly for Arduino/embedded. For general purpose programming? I don't know.

> if Python can be used with it

Which Arduino models are people running Python on? Surely not the most common models?

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.

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.

Copilot is an EDSL that generates a C program, so the Haskell runtime is not in the final binary running on the Arduino.

I recently tried out uLisp which was trending on HN the other day on an Uno. It left me with ~500 bytes of memory and ~1000 bytes of storage. Unfortunately that’s not enough to do many interesting things!

Great points, thanks.

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();
    }

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.

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).

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!

It's not running Haskell on the Arduino, you are building a C program for Arduino using a DSL in Haskell.

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?

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

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.

Is developer preference not important?

What advantages does C have over processor specific assembly?

Developer preference is a very big deal. Almost all other factors are secondary.

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.

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.

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".

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.

They both made billions DESPITE their technology choice, and both systems had to undergo a serious rewrite later. There are dozens of other projects out there almost noone ever hears of because they turn out to be a disaster and are cancelled (I was consulting a few such cases which ended up in court, because developers were not able to deliver the product with the required level of capabilities and performance, despite using their preferred, but seriously suboptimal technology). Or they are even a business success but then their users are constantly cursing while using them. Users are often not the same people who buy software, so sometimes you can make business success despite technical inferiority of the product. Marketing often beats technical features.

> You must be very immature to think these are not technical reasons

Sorry, but this ends the discussion for me. I thought we were discussing on merits, not ad hominem arguments.

At some point you have to learn to take critical feedback about yourself and not shut yourself down or vehemently keep repeating the same thing using different words.

You are making immature statements like - Time to learn a technology and familiarity with a stack are not technical considerations. I expect a junior engineer to make such statements but not a senior engineer or a hiring manager. These are critical technical considerations when choosing a technology. Your statements show immaturity - period. If a director of engineering asks an engineering manager if he will consider the tech stack familiarity and learning curve for the team when choosing a tech stack and the manager responds in the negative, trust me - he will start looking for a new engineering manager. You are fixated on picking the "right technology" while your team loses momentum and attrition sets in. You sound like you think your technical decisions are unbiased, but Zuckerbergs decision to use PHP was biased. It is obvious why Zuckerberg used php. He was familiar with php and that was the fastest way for him to build a website. But according to you he made a terrible technical decision and he should have used something else. This is an immature statement. BTW, Facebook still runs on php.

A piece of advice, do not try to impose your biases - technical or otherwise on other engineers. They will do what they want to do. If you join a team and they do not share your technical biases - you have 2 options 1. Show them why the technical choices you propose will help those developers in the long run. 2. Join a different team which shares your bias

Badgering them with your opinions is not an option. Your options are - Show the developer why building Arduino copilot is not in his long term interests. The other option is - Galois is making tons of money by building copilot for safety critical embedded projects for NASA. May be you can also talk to NASA and get them to shut down the project. Otherwise you are just wasting your time and everyone else's time.

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).

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).

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.

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.