broad range of use, alternative to Perl, R, etc.

Of course. Its in the same category as Ruby and Lua. Hence the question on “getting out of the way”, which Lua is much better at and which Ruby surpasses by also making programming easier. But Python was first at surpassing even Perl at growing library bindings.

Maybe you are replying to the other comments, but what I am getting is Python is good glue and doesn’t get in the way. That is fine, but not getting in the way is little help with any of the programming.

I did you the courtesy of replying with a bit of info about Erlang, even though you weren’t addressing the actual point about lack of language features like Erlang’s. BTW, by conceding that the argument for C++ on microcontrollers is weak given other languages doing better on that front, you are conceding that C++ doesn’t have features to help systems programming.

Arguments are being made for language platform features when the question of language features comes up. I doubt it has to do with people not understanding the question.

More likely just scratching heads to find atleast 1 useful C++ (or any other mentioned language) feature that actually is useful to the domains professed to be “supported”. This isn’t an attack, I am in this boat too! The utility of its language features seems to be no more than “atleast it is not assembly”.

I wasn’t thinking not needing a runtime is a language feature. After all, needing a runtime hasn’t prevented Erlang from running on microcontrollers (Atom VM, GriSP); or Python either.

Basically, C++ and its ilk have no language feature for their purported stronghold of systems programming. Inertia isn’t a language feature unless the language has actual features (like, say, Common Lisp).

Interesting. What is useful in Python other than the effort put into the bindings to fast libraries? I thought alternatives like Go, Julia and Ruby are appreciated over Python for programming utility.

There are many easy-to-learn languages, and others actually have useful software development ideas (immutable by default, for example). I understand if expectations are lower, though, from the language talk, and if any language with the required libraries is fine.

Inane features a language happens to have, like object-orientation, are marketed that are not backed up by any argument or example beyond homework-level code.

What language features do users say helped them? Existence of libraries didn’t make C a good language, and providing a binding to those libraries does not make Python a good language. Hard work must go into bindings, whether for Python or for Ruby or for Lua, but Ruby and Lua make convincing cases for themselves.

Counterexamples.

A simple language like Lua, whose advantages in actually building software rather than homework-level coding are well-documented, and borne out by well-received web servers, editor extensions, network software like Snabb (and Adobe something).

A platform language like Erlang that is not just simple to code in, but also has a mighty capable runtime. Demonstrating the value of that combination are the impressive networking and storage apps shipped with the platform, apart from actual software wins in the wild like ejabberd, Pleroma/Akkoma, etc.

An idea like Objective Smalltalk, which tackles software architecture head-on. https://objective.st/

You are right Python and C++ have a huge amount of collateral available going for them. But is the utility of their language features backed up by any examples or explanations? Rigid object-orientedness as seen in Python, C++, Java, modern Javascript is not conducive to good software in practice, and we are just muddling along.

Ditto for Smalltalk and Lisp.

Squeak Smalltalk and its evolutions, Pharo and Cuis, get talked up for being easy to program and re-program, but the closest to being a useful app is recent: the DrGeo rewrite. Others like Glamorous Toolkit and various proprietary developments with Cuis don’t lead to any useful outcome.

Lisp with its macrology is deified, but its most used variant, Elisp in Emacs, is confounding in terms of comprehending the runtime behaviour of features and in the debugging of what doesn’t work. Guile Scheme has so much written about it, but Guix is just about its only success.

Just as an example, neither the C++ documentation nor its sagely bloggers have ever shown why it is a good fit for, say, systems programming. A really neat way of handling bit-level data is actually in Erlang’s bit syntax.

Separately, I spluttered when I realized that Boost includes 2 statechart libraries which proclaim the approach is widely useful, but nothing else in Boost uses it - not asio or its ilk, not the parser libraries, not the graph library.