On Mon, 02 Mar 2015 00:16:52 -0600
"T.J. Duchene" <t.j.duchene@???> wrote:

> Frankly, I've also believe that
> interpreted languages should never be used for anything other than a
> teaching tool. If you must use something like that, at least use
> something that supports JIT to native code.

If I were the king of all open source, and a programmer asked to write
a program in C, I would ask them to justify that. Will their
performance bottleneck be the code itself rather than the typist's
fingers? Will the time taken by their program materially affect the
overall performance of the computer? Do they need special access to the
metal that Python doesn't give them? Do they need to deal with a
library not accessible via Python, or even Lua?

Because here's the thing. We all say we're great programmers, but
somehow, on lots of software, buffers get overrun. Pointers go errant.
Programs proceed after failed mallocs. Malloc/free loops somehow start
to accumulate more allocation than freeing. None of this is an issue in
Python. In Python, programmer mistakes tend to affect the data, not the
system. Python long ago solved the vast majority of security problems:
It's secure, and when it's not, because of its millions of users, you
find out fast.

Yes, I know that Python's got that 2.x vs 3.x problem. Yes, I know that
a lot of people hate Python's significant whitespace. Yes, I know that
a Python import is a dependency, just as sure as
libarbitraryfunctionality.so. But most Python needs are covered by its
standard imports, and they are subject to "many eyes" quality assurance.

You might wonder why I picked Python over Perl, Ruby and Lua. After
all, most of the "interpreter" benefits I stated are equally applicable
to all four. Here's why. So far, only Perl and Python are truely
intertwined with Linux. I'd like to keep that number to a minimum.
Throughout the past two decades, Perl's "many ways" philosophy has
fallen into disfavor, as more and more shaky, indeterminant and
unreadable code gets written in "many ways". And CPAN's a menace, and
its tendancy to compile C code is failure waiting to happen. Lastly, as
far as I know, among the four "interpreters" I mentioned, only Perl and
Python have a stable of known good, well known and capable add-ons to
assure one that any project you start in the language you can finish in
the language.

I'm not the king of Open Source, so I don't get to make others conform
to what I say above. But when I develop something, I don't do it in C
unless I can justify C: Otherwise I fall back on my default, Python.


SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance