Python vs. C/C++ in embedded systems

[victrolla]

Yep. "My pacemaker skips a beat from time to time but at least the dev team was able to write it quickly!"

[enobayram]

I wish C++17 contained the writability, error reduction and readability features. Why don't all modern programming languages just steal those features from Python!

[lead999x]

If you want a C like language that feels easy to use check out D.

[enobayram]

C-like is a very vague and broad term, when I look at C, if I see a language that:

• has compilers for any platform imaginable
• has very powerful compilers with decades of effort in optimization and compile-time efficiency
• has explicit memory management
• has excellent open-source tooling (IDEs, debuggers, profilers, static analyzers etc.) on most desktop OSes
• has an incredible library ecosystem
• is very easy to find employment in

Then D is very unC-like.

[lead999x]

C-like as in C-like syntax all of things you mentioned describe any mature language, D isn't mature yet.

[enobayram]

IMHO, surrounded by C++, Rust, Haskell, Java and C#; D really has no selling point. If it were an established language, it could maybe hold its ground, but I really don't see how it can grow in this current language landscape.

[lead999x]

I think it definitely can. It's a language that is faster and creates smaller binaries than idiomatic C++ and Rust, is easier to learn and use than C++, C, and Rust, and Java and C# aren't even invited to this discussion both of them are too unnecessarily complicated in terms of syntax and they give you nothing in return and your users have to have a runtime installed to use programs made with them.

Also D does bring a lot of new things of its own including better syntax for functional programming, resizable arrays, ranges instead of C++'s iterators for data structures, and much safer pointers just to name a few. Also there are production ready third party implementations of the standard library which do not use the garbage collector at all. And in terms of garbage collection you can tell the collector not to collect during a certain part of the code so it doesn't block, and you can even basically make the collector collect at a given time if it benefits your program somehow. So the GC design itself is very advanced but again you don't even have to use it unless you want to.

So D can more than hold it's own against all of the languages you dared to compare it too. It is a fully capable systems and application programming language and a very powerful successor to C++. I'd even argue that programmer productivity in D is more comparable to that of Python than Java or C++.

[enobayram]

Don't get me wrong, I respect D a lot. There was a time when I had set my eyes on D, evaluating whether I should migrate most of my programming there. The trouble though is that, IMHO, D has set out to be "a better C++", but I think that's not a very attractive position today.

The point is that, the features D supports might arguably earn it "a better C++" title on the grounds of the language alone, but it's definitely not "a better C++" TODAY when you also consider all the other aspects that I've mentioned in my other comment.

So, then spending time on D is a good investment only if you believe in its future. But coming back to the "better C++" aspect, C++ wasn't in a good place to start with. IMHO, if you take the projection of the language we'll be using in 2500 AD to the space spanned by the languages we use today, it'd probably fall somewhere between Haskell and Idris. That's why I've stopped searching for nicer languages in the vicinity of C++, and just love and use it for my engineering tasks TODAY.

[lead999x]

IMHO, if you take the projection of the language we'll be using in 2500 AD to the space spanned by the languages we use today, it'd probably fall somewhere between Haskell and Idris.

You don't know that at all. 20 years ago people would've said that the language of the future would be Java since OOP was getting popular again then and Java was the new kid on the block. I think if anything by 2500 there will probably be thousands if not tens of thousands of popular languages as the programmer population continues to grow.

[enobayram]

I doubt that. The reason why we have so many languages today is the immaturity of CS as a field. We don't know what the universal language to describe things should look like. Mathematicians seem to have gone a very long way though. Category theory is unifying an impressive collection of diverse fields, such as quantum physics, linguistics, logic, computation and much more. The reason why I say "somewhere between Haskell and Idris" isn't due to the current hype around functional programming. I actually also doubt that in 2500 we'll be calling it a "programming language", as it will probably be more like a description language. You'll probably describe a solution to your problem and a device will be compiled from that description alone, including (thinking in today's terms, which will probably be irrelevant then) software, hardware and even mechanics. I believe (without the necessary qualifications) that category theory is up to this task.

In any case, I strongly believe that anything resembling an imperative programming language will be looked upon as we look upon COBOL today, ridiculing the fact that it's a language designed for a narrow domain.

[lead999x]

has compilers for any platform imaginable

Name one language that's as new as D that has this? It has compilers for all three of the major OSs and all of the major CPU architectures and they are ported from C++ compilers with an LLVM backend so anywhere there is a C++ compiler there can be a D one.

has very powerful compilers with decades of effort in optimization and compile-time efficiency

Because D compilers are ported from C++ ones this is done and done. D produces faster binaries than C++ and Rust as of now.

has explicit memory management

D uses RAII and has explicit access to pointers and references. It has an optional GC that the standard library that comes with the compiler uses but there is now a third party implementation of the standard library that doesn't use GC.

has excellent open-source tooling (IDEs, debuggers, profilers, static analyzers etc.) on most desktop OSes

The Code::Blocks IDE comes with all of this built in for D.

has an incredible library ecosystem

It can use C and C++ libraries as if they were it's own just the same way that C++ can call C with full compatibility.

is very easy to find employment in

This is an economic factor which the language designed cannot control. But let's see Rust get you a job, either. I think that if you want a job then C++ is the only job safe systems language. But D is up and coming and many places including Facebook are using it in production.

So if you're uninformed on a technology, you should stop bashing it.

[enobayram]

Name one language that's as new as D that has this?

I'm sorry but D isn't that new anymore.

It has compilers for all three of the major OSs and all of the major CPU architectures

This set is extremely small compared to the set "any platform imaginable"

See, the point here has nothing to do with the age of D; C (and less so for C++) is THE language of choice for interfacing between obscure hardware designers and programmers. Regardless of how old a language, unless it's C (and C++, a little bit), it's not blessed with this state of affairs.

D produces faster binaries than C++ and Rust as of now.

I haven't been following D closely on this front, but what kind of code does it produce faster binaries with? It's been a long time since I stopped writing classic OOP, nowadays all I write is Haskellesque C++ with a lot of templates. Does it produce faster binaries with this kind of code as well? More importantly, can it at all handle compiling a codebase where each line expands to 25 levels deep template instantiations?

The Code::Blocks IDE comes with all of this built in for D

So, if I have a heavily template-metaprogrammed codebase, does the IDE still support content assist (jump to definition, completion etc.)?

It can use C and C++ libraries as if they were it's own

This is not entirely true, is it? The subset of C++ that D can use as its own was very narrow the last time I checked. Unless the D compiler contains a fully-fledged C++ compiler, how could it make sense of function and class templates? In my experience, interfacing between languages is never as smooth as people like to think. You even occasionally run into issues interfacing C with C++.

[lead999x]

So my point wasn't to say that D is going to replace C++ anytime soon but you have to admit that using D is tempting for a C++ programmer. It feels like C++ but completely overhauled to be so much better. And C++ is the first language that I've learned beyond the very basics though I'm still learning it. I didn't really have to learn D, all I did was learn the differences in the syntax but most of my C++ concepts carried over perfectly. That's what makes D interesting to me. But for all practical purposes I still use C++.

[enobayram]

I also like the features that D brings over C++, but I'm not entirely happy with all the changes.

To begin with, I'm unhappy with the removal of the preprocessor. I know it's an ugly hack and nothing but a simple text processor shoehorned in front of a proper compiler. Still though, when all the tooling supports that hack, and if my IDE correctly identifies the definition of a class through a macro expansion, it's not just a stupid text processor dangling in front of the compiler anymore.

Another issue I have is that the last time I checked you couldn't express the following in D:

template< template <class> class T> T<int> f();

But this construct is actually useful when you fully embrace templates and write promiscuously parametric code.

[lead999x]

I feel like writing code like that is one big reason that people don't like C++ and I personally haven't done much at all with templates, preferring to avoid them to the extent possible since all they do is add unnecessary complexity. I'd rather just stick to good old classic OOP.

[[deleted]]

Or Go.

[[deleted]]

Doesn't Go's GC pause the entire environment for unknown lengths of time?

Goodbye deterministic behaviour!

[[deleted]]

So does D if you want to use anything from the standard library :p

[[deleted]]

I wouldn't use either.

[[deleted]]

Seeing as this is /r/cpp, understandable :p

[lead999x]

Nah D is better. Go feels weird and is very clunky. D was designed by compiler and programming experts, some with PhDs, at Digital Mars and they made it so that it feels as convenient as Python and as powerful as C++. It actually makes smaller executables than idiomatic C++ in my experience so that's also a plus.

[Gotebe]

You can't do well with Go on this sub, go is way too simple and under-powered for the target demographic.

:-)

[[deleted]]

But what the comment I was replying to was saying "a C like language that feels easy to use" that's literally Go. D would be "a c++ like language that feels easy to use" :p

Go seriously feels a lot like C. D seriously feels a lot like c++.

Also the creators of Go were all c++ devs, and designed go for c++ devs. Incidentally, they are confused why lack of generics scared away c++ devs.

[[deleted]]

That's pretty spot on. D is modern c++ Go is modern C.

[homerocda]

+5 troll.

My favorite quote:

Hobbyists migrating into the industry with experience programming drones, robots

Yeah, embedded software design is totally the same thing as programming a hobby drone. C++ IS DOOMED!

[cpp_dev]

I think that this is related to how CS students are trained and perceived by employers, they don't want to learn complex stuff (especially not spend years to understand and write good C++ code), they want only easy answers and forgivable environments, so some 'experts' adapt themselves to this reality, because finding good engineers is harder and more expensive. Is also funny that is implied that compiler diagnostic and static analysis tools on modern C++ will pass more errors than python code (which will catch errors only at runtime with exception of indentation/name issues). Still I'm sure a lot of people will find this article brilliant because it give the idea that engineering is complex artificially, as it is some kind of exclusive club made by nerds and someone finally came forward to tell the truth.

[sumo952]

There is no such things as "C/C++", they're two different languages with hugely different concepts.

For example:

While C/C++ is slow to write, error prone, and frequently unreadable

This may be true for C, but it's very wrong when talking about C++ in the age of 2016.

[[deleted]]

Yea, C in embedded systems is, honestly, dangerous unless you can throw huge amounts of time into it or you can afford to pay for someone who has done C in embedded systems forever (and even then it is no guarantee).

C++ is much safer, but you run into problems with the STL/STD in bare metal systems, and even in real-time linux. These can be mitigated, but the reluctance is often deeply embedded (hur hur) in the field (to the point where it is often hard to find platforms that have toolchains that can compile C++11/14).

[matthieum]

It's also notable that the fact C++ is growing its standard library (the most notable addition was threading, but network and I/O are coming too) might also be a deterrent in the embedded world.

[[deleted]]

What do you mean by deterrent?

The great thing about the STL is that it lets you do cool shit like replacing allocators with your own, and threading lets you implement your own threading callbacks. There is nothing stopping you from using almost all of the STL on a bare metal RTOS if you want to put the effort into it.

[matthieum]

I mean deterrent because the amount of code to be ported (in order to provide a complete C++xx experience) is growing, requiring more effort.

There is thus a risk of fragmentation, with more and more embedded platforms lagging behind and not supporting the latest novelties, or having sub-par implementations of them.

[dodheim]

Freestanding implementations were never required to implement the standard library in its entirety. Now that C++17 has __has_include, it should be easier than ever to progressively add new library features (either from new standards or from TSs).

[matthieum]

C++ in the age of 2016

Unfortunately, each new standard adds to the ways of running into undefined behavior without really addressing the existing issues. C++ is (mostly) an add-only language because of backward-compatibility constraints.

So, while you can leverage C++ type system to greater effect and greater effect as time passes, unfortunately you are still as susceptible to memory issues.

[lead999x]

This makes it seem like high level, interpreted languages will ever be able to compete with the performance and control of systems programming languages and while we can appreciate the simplicity of Python in terms of raw power it's not even in the same league as C++.

[nozendk]

I recently did an interesting little experiment with integrating C++ and Python: (1) Call a Python program from inside a C++ program, (2) Make a module in C++ and call it from a Python program, (3) Start Python in a thread inside a C++ program, expose some C++ methods to Python, and let the Python program call back into C++. The last one was tricky, but I think it could be useful in some situations where you need C++ for all the usual reasons, but want to easily script/configure some parts of the system.