Hacker News Reader

Comment by jscholes | Hacker News Reader

I've used CircuitPython for one production hardware project which is in the wild. Safe to say that the increased draw on the included battery and higher memory usage weren't a concern here, but they are both significant. Developer productivity is through the roof though.

I'd say the biggest pain points for me (unless I'm missing something/they've added more stuff recently) were created by the lack of support for what feel like production standards in software development. For example, the logging library is a toy, and unit testing is non-existent unless you isolate all your CircuitPython-specific code and run tests on your dev machine using CPython.

View on HN

"Developer productivity is through the roof though."

I learned Python after I learned C, C++, Java, Scala, Rust and a few others. I fail to see my productivity going through the roof with Python. It's quite the opposite. Writing initial code is fast, but making it work well - not so much.

Presumably the parent is comparing Python to C. There’s no way anyone is more productive in C than in Python.

I’ve been working on altimeters for model rockets using both C and Micropython on Adafruit’s feather series and a couple other boards. The thing with C is the tool chain setup is 3/4 the battle. It’s a huge LOE to go from nothing to a blinking led (the embedded hello world) with C. With micropython it’s 5 lines, drag/drop a file, and reboot.

I appreciate C and I’ve learned a lot of things like peripheral clock multipliers and all the work that has to be done before you can even jump to main. However, I set out to make an altimeter heh.

Edit: oh and with C, writing your own device driver for every single thing is a pit of a pita too. There are open source drivers for some breakouts but they all seem to require serious hand fitting.

Have you tried PlatformIO? New projects get set up in about 30 seconds.

If you are forced to write pure C (or a very low level subset of C++) , then that is often because:

- you need every tiny bit of performance,

- you optimize for low executable size or low memory footprint (e.g ATTiny13)

- you have an exotic architecture that offers only a C compiler or ancient C++ compiler from 90s,

- you need to use C for other reasons like safety certification, e.g. MISRA C.

In all of these cases Python wouldn't work at all.

And in the others your can use modern C++ which can be just as productive as Python (in my case it is more productive, but I have probably spent more time with it than with Python, so I'm biased).

For twiddling GPIO pins, I can be most productive in C (or the C subset of c++ for pedants).

Twiddling GPIO pins and doing other bit gymnastics is a fair bit of simple sensor interface microcontroller projects, which is a large overlap with the target for CircuitPython.

That's a really disappointing attitude to see in the wild.

How so?

I've been plenty productive in C, as are a multitude of people who would pick type safety over the lack of it.

I know a lot of people for whom both are much more productive in python than in any other language, including myself. If that's not true for you, you must have different preferences.

Let's just find our own language each one and not bash others' choices, maybe?

This is for embedded programming which is totally different to the sort of programming your thinking of.

Surprised you didn't use at least MicroPython. I think Python on embedded in general is not great in a production setting, but at least MicroPython has widespread usage; CircuitPython is aimed at being a toy language for beginners.

CircuitPython describes itself a fork of MicroPython, with the major difference being its deployment workflow. What makes it a “toy” by comparison in your book?

Out of curiosity, what about this particular project made you opt for CircuitPython? Was it something targeting hobbyists and wanting to allow them to tinker with it? I'm not trying to put it down because I like CircuitPython, but I would not even consider it for a general production device.

> Out of curiosity, what about this particular project made you opt for CircuitPython?

It was a nonprofit-style project without much wiggle room. We wanted to prove that an idea would or would not work in a small amount of time, which happily overlapped with the fact that the target environment for the device wouldn't require long periods of battery life. I'm happy to say that the project was a success so who knows, maybe one day we'll have someone port it to C and continue from there.

Sorry I can't be more specific.

No worries, that was plenty of detail, thank you. I fully understand working on things you can't discuss the specifics of.

It would be very interesting to hear more about your project and, if you did some benchmarks, about the increased draw on the battery.

Reply on news.ycombinator.com