On 03/02/2015 11:05 AM, Steve Litt wrote:
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?
We just see things differently. My first question would be: is there
are a justified reason NOT to use C?
In opensource, more often then not, small tasks get combined into big
tasks, via scripting or whatever - into huge morasses of complex
complicated scripts. It can lead to serious problems, which I personally
prefer to avoid. I suppose in that way I am somewhat more BSDish than
your average Linux user. My concern is usually what maximizes
efficiency over the long term.
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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
