On Mon, 02 Mar 2015 00:16:52 -0600 "T.J. Duchene" <t.j.duch...@gmail.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
