:: Re: [Dng] [OT] Debian problems with…
Top Page
Delete this message
Reply to this message
Author: T.J. Duchene
Date:  
To: dng
Subject: Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds

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

>
>