The Arduino IDE uses a full-blown version of the GNU C++ compiler.
It was free, and all of the chip manufacturers port it to their chips during development, so it was there to use.
People tend to like the language they are most familiar with.
That just makes sense, since the learning curve has already been paid for.
In the case of a language that needs a C++ programmer to do the fiddly bits close to the machine, what you end up with is a system that no one is completely comfortable with since they need to be familiar with two languages, and people are bound to use one language more than another, just by chance.
When you already have a powerful, widely known language supported on a platform, with lots of example code to steal, lots of libraries full of code for dealing with all of the hardware you might want to attach to it, the only reason for choosing an interpreted subset of another language is that you are more familiar with that other language, and feel more comfortable there.
That's OK.
The original post said as much, simply that he preferred Micropython. And there is nothing wrong with that.
I felt the need to point out that there are significant tradeoffs being made due to that decision, and that if he had preferred a language that was faster, produced smaller code, was supported on more hardware, had more hardware libraries available and could do real-time programming, those tradeoffs disappear.
Cathal's point about data scientists being more likely to know Python is relevant and has support from other sources.
But the Python libraries they are used to using won't fit onto a microcontroller.
And the language #9 on the list in that link (C, not C++) is described as being largely used in embedded systems, which is what we are discussing. The largest programming systems I have worked on (several million lines of code) such as operating systems, browsers, compilers and IDEs, have all been written in C++, and there are lots of excellent tools available to work with in that language for supporting very large systems. But we are talking about very small systems.
I also like Cathal's other point about all languages not being the same. He seems to favor picking a language based on its suitability for the task at hand, instead of using the programmer's favorite language. As someone who has spent much of his career writing compilers for dozens of different languages, I have had to learn many different languages. This makes me biased towards just telling people to learn the language that is best for the task, as once you know one or two, becoming competent in another is really pretty easy, especially if the new language is based on C, as Python, Java, Javascript, PHP, C#, and so many others are.
The case for an interpreted language on microcontrollers is easily debunked.
In a small memory, slow processor environment, stuffing your editor and compiler into the same memory footprint as your target code means that none of the three will be what it could be. Cheap microcontrollers that are programmed via USB are very easy to modify using a laptop computer with a good IDE. Push a button and your program downloads onto the chip, while you get the advantages of a powerful editor, a very powerful full-blown compiler with impressive optimization capabilities, and often a simulator that makes debugging and learning all that much easier (check out the simulator for the BBC Micro:bit, built into the IDE. You can learn all about how to program the device before you even buy one.)
On Mon, Mar 18, 2019 at 11:01 PM Gerald Trost <gerald.trost@mail.com> wrote:
--
Hi!
just some programmer's thoughts:
1.)
could it be that "C++" on Arduino is merely a C interpreter ?
So far I never extended a class and never implemented an interfaceand I never saw generic types ...
Well, it might be that I am less familiar with C++ on Arduino compared
to C++ on Windows but it it still worth considering that it might not be
a proper and full "C++" compiler.2.)
As you said:
"Now after some thought, maybe these folks wouldn't be able
to handle Python either..."
I fully agree with this.
And I think it might be even worse:
Just BECAUSE Python seems to be easier at first glance will
they most probably write less structured code any doing so
they might soon come to a point where source code gets
over-complicated and no longer managable ...
I strongly encourage everybody to first deeply dive into
programming larger projects before deciding what language
is to be preferred.as I said - just a programmer's thoughts
Gerald
_________________________________________________________________________
<experience comes shortly after it was needed>
Gerald Trost
Software Developer / Programmierer
phone: +43 (0)650 2311057
skype: gerald.trost
https://xing.com/profile/Gerald_Trost
https://linkedin.com/in/gerald-trost-57ba80ab
https://facebook.com/gerald.trost.3
_________________________________________________________________________Sent: Monday, March 18, 2019 at 8:04 PM
From: "Nathan McCorkle" <nmz787@gmail.com>
To: diybio <diybio@googlegroups.com>
Subject: Re: [DIYbio] Micropython vs C++ for microcontrollersOn Wed, Mar 13, 2019 at 10:35 AM Simon Quellen Field <sfield@scitoys.com> wrote:
>
> I don't wish to hijack this thread, so I changed the subject line.
>
> John didn't say why he preferred micropython to C++ (which he called "the arduino language"). But the compactness and speed of C++ code over an interpreted subset of Python gives it a substantial advantage on small processors, where both CPU execution speed and memory space are both limited.
I think the bigger reasoning for choosing Micropython to deploy on
programmable lab gear is the end-users often lack reasonable coding
skills. For example many biologists I knew in my undergrad stuggled
with email and Excel spreadsheets... biologists John and I have tried
interfacing with as beta testers for the open-source electroporator
have struggled with deleting and copying files from a github clone to
a Micropython 'drive'.
So I don't have a sliver of hope that the **average** biologist or
chemist would be able to handle hacking on C++ to automate or alter
lab gear. Now after some thought, maybe these folks wouldn't be able
to handle Python either... but I think there's certainly less barrier
and an easier ramp to climb.
As you said, Micropython itself is written in C++... so performance
really isn't an issue since their documentation provides good examples
of writing C modules for Micropython.
This is exactly what I did to use the DMA feature of the
microcontroller John chose for the culture-shock electroporator, when
I wanted to collect ADC samples from the High-Voltage output while
actively pulsing, and to start working on an automated solution to
voltage-limiting (so the user didn't have to specify the low-level
pulse-width timings, which is unlike any existing electroporation
protocol which just deal with overall time-scale and max voltage).
--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diybio@googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diybio+unsubscribe@googlegroups.com.
To post to this group, send email to diybio@googlegroups.com.
Visit this group at https://groups.google.com/group/diybio.
To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CA%2B82U9JdrkCDpVfguCMc0vh8m8HsApL-VebHr7conZQzfKi8gQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diybio@googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diybio+unsubscribe@googlegroups.com.
To post to this group, send email to diybio@googlegroups.com.
Visit this group at https://groups.google.com/group/diybio.
To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/trinity-468181b5-c870-45d0-94da-9caa2967d873-1552975316260%403c-app-mailcom-lxa05.
For more options, visit https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diybio@googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diybio+unsubscribe@googlegroups.com.
To post to this group, send email to diybio@googlegroups.com.
Visit this group at https://groups.google.com/group/diybio.
To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CAA0yOM484Kvw2rP%2BG9cYNdGwSELqzOSoRVOQmgrZpERuaZsxmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
0 comments:
Post a Comment