Something to remember: Scientists are more likely to know Python as a result of statistical/graphing know-how.
Quite besides which, the old "all languages are the same" gimmick doesn't hold that much water. If it were meaningfully true outside of a purely rhetorical case, then all programmers would be equally comfortable in all languages, yet we find that programmers have strongly held opinions on which language lets them do what they need at the pace and convenience they need.
Even leaving aside the compiled/interpreted thing for minute, look at the enthusiasm from C++ devs (present and past) about the rapid maturation of Rust. The warm comparisons are made here between two languages at the same level of development and (if we don't discard externalities like correctness, security, and reliability) the same level of difficulty. Despite appearances, Rust is not a C-family language and has some semantic differences to C++. Yet if you asked me which I'd prefer coding in... I have a very strong opinion on the subject. And though I won't, I could reel off the reasons for that opinion. It's not just "preference".
So, yunno, not all languages are alike.
And, if part of the goal of a project is to make a device customisable by end users, there are plenty of reasons to pick a more expensive, interpreted-language chip. Even if it means you need to maintain some low-level "crunchy bits" in C++ to enable them.
If easy hackability is not a great concern, then for cost and energy-efficiency reasons it _does_ make sense to go with a C++ (or Rust, soon) solution. The people who really need to modify may still learn the language and clone the codebase, it's just a trade-off of difficulty and efficiency.
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.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
0 comments:
Post a Comment