:: Re: [Dng] [OT] Debian problems with…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Joel Roth
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 04:12:02PM -0600, T.J. Duchene wrote:
>
> On 03/02/2015 09:11 AM, Tor Myklebust wrote:
> >
> >I'm even more confused by your position than I was before.
> >
> >
> I can see your point. I'll try to explain more concisely.
>
> When I call something "overuse", I am referring to the ideas that an
> interpreted language must be used as "glue" between two bits of C code, that
> C is to be used "only as needed" or that interpreted languages are the
> preferential language choice for writing basic system utilities. These
> ideas has become more and more acceptable. They didn't used to be. I
> remember when interpreted languages were either hobbyist playtoys or
> teaching tools. Perl was used only for small jobs, and while shell was used
> extensively in System 5 init files, you were expected to do all serious work
> in C.
>
> A respectable percentage of today's Linux distribution is a kludge of rapid
> pre-existing hacks that do not always work well when layered. You have
> something like adduser or other command utilities written in Perl, which are
> then called by init scripts, which can then be called by still more
> scripting in the form of a X GUI application to manage users. At any stage
> it can be prone to unforeseen interpretation problems.
>
> I'm just asking at what point would it be more beneficial to simply code a
> library in something like C, and be done with it?
>
>
> Perl, Python, and Java,and a number of other languages just do not function
> well for certain kinds of tasks that require efficient resource management
> over time, yet they are constantly being used by the opensource community
> today in places were it might be advisable to reconsider.


Hi TJ,

The languages you mention are used in industry, extensively,
in heavily loaded applications. Even the much derided PHP,
has continued to hold a huge niche. Perl has DBI and
friends, making it possible to create pluggable
backend-independent database applications. Booking.com is
an example of large-scale user that is a perl house.

Access to external libraries from within dynamic languages
can bring in the advantages of compiled langauges. One can
develop an application in Python or Perl, then later use
profiling to know where to optimize, and to move hotter
parts of the code to C or C++. I'm reading that Python has a
better foreign call interface than Perl.

There is an issue of finding the best modules for a purpose
on CPAN, however there are excellent modules for many, many
purposes, often well documented and with good test coverage.

Personally, I am pleased that I can use sockets through a
dynamic language like Perl without having to be an expert,
write terminal applications without being a cognosenti on
the intricacies of managing terminals, read and write files
without extensive knowledge of file-system minutae.
Lower-level expertise in a developer is usually an
advantage, however I don't think we should blame dynamic
langauges for making it possible for people to code without
knowing all the gory details at the lowest level.

When I think of Apache with mod_perl, which at one point
served a lot of pages, and the current work in Catalyst I am
sure that one can develop heavily loaded applications in
dynamic languages that don't leak resources/memory.

Was I being trolled? ^^

cheers,

Joel


> >
> >Why pick on perl?
> Only because Perl makes itself the biggest target for example. I don't HATE
> Perl. I've even written a lot of Perl code in my day. I also recognize it
> for what it is. Perl is something that should be restricted to unimportant,
> small user jobs that won't be used too often, and most certainly never used
> with root permission. As everyone knows, Perl has a very ugly history of
> permissions flaws, that can rear its head if someone does not compile it
> properly.
>
> >Why not pick on the huge number of low-quality C libraries that are out
> >there?
> Yes, there can be low quality libraries in C. The main argument for using
> Perl, or other similar languages, instead of C is that there is less chance
> of errors (and thus better software) and you spend less time using it. If
> as you point out you can have can have crappy code anywhere so that tosses
> out the first argument. The second, that Perl is a timesaver is entirely
> subjective. With the right libraries, and enough actual use, anyone can
> write a small utility just as efficiently in C or a similar language.
> .
> >
> >I don't think you said what you were trying to say. Judicious use of
> >abstraction is what lets us write useful software in the first place.
>
> True, however, there also comes a point where writing software in highly
> abstracted languages (usually the interpreted sort) has diminishing returns.
> I feel that they have been overused in the Linux ecosystem as whole. My
> whole rant is really just chatting with the community and seeing if anyone
> else shares that opinion. If you don't personally, that's just fine by me.
> =)
>
>
> Have a great day!
> t.j.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


--
Joel Roth