On Mon, 2 Mar 2015, T.J. Duchene wrote:

>
> On 03/01/2015 05:56 PM, Tor Myklebust wrote:
>>
>> The perl-base package pre-depends on libc6 and dpkg. And nothing else.
>
> I was not referring to all the software that depends on them when using
> Debian/Devuan. I've never believed that they make good choice for a
> required component. 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.

I'm even more confused by your position than I was before. The things
that depend on perl-base that you'd want in any minimal system are
adduser, linux-base (indirectly via libuuid-perl), and debconf. adduser
depends on perl-base because adduser and friends are perl scripts.
linux-base depends on perl-base because /usr/bin/linux-version is a perl
script. debconf depends on perl-base because debconf is implemented as a
collection of perl scripts and perl modules.

I do not see why anybody would insist that something like adduser is
written in either a compiled language or a language with an effective
just-in-time compiler available. Very little time is spent running
adduser on any system I am aware of. The same goes for linux-version.

>> You can write programs in Perl or Python that do not depend on any modules
>> that are not installed in the base Perl and Python packages.
>
> I never suggested otherwise. In fact, I went out of my way to say that the
> community attitude of overuse and the extensions specifically were the
> problem, not the core.

What "community attitude of overuse"? There is a long tail of available
perl modules and quality tends to taper off as you get to lesser-used
libraries. This is true of libraries in every language I am aware of.

>>> c) In both languages, modules are usually something of a "black art" and
>>> notorious for being unreliable at unexpected times.
>>
>> Are you claiming that perl's module system does not always work as
>> expected? Or just that some perl modules are poorly-written?
>
> My remarks about Perl stem from poor QA in many Perl modules, and issues
> with the community/CPAN.

Why pick on perl? Why not pick on the huge number of low-quality C
libraries that are out there?

You gave MailScanner as a concrete example of a perl package that pulls
in, in your view, too many dependencies. But consider what MailScanner
does; it integrates MTAs with several different pieces of filtering
software and does some of its own scanning as well. (I suppose you could
argue that its scope is too broad, but you weren't arguing that.)

That means it has to be able to parse emails (some of which are HTML),
extract attachments, uncompress archives, and ask some external programs
what they think about various things. If you're writing software like
this, it makes perfect sense to rely on someone else's code for handling
mail, MIME, HTML, compressed archives, and so forth---you won't get it
right yourself and you don't want to spend your time maintaining those
components when you could be making your package better at its core task.

>>> In my experience, while you can generally expect things like the Perl core
>>> language to act reliably,you can't expect the same of the rest of the Perl
>>> ecosystem to do the same. The QA simply is not there. Not to mention that
>>> all of this can massively impact performance.
>>
>> This reads like FUD to me. Yes, it's possible to write Perl modules. Like
>> anything else, it's possible to do slipshod work. Why are you trying to
>> paint this as a *bad* thing?
>
> Just because my opinions may not be conventional, does not mean that I am
> "painting" anything.

Convention does not have much to do with it. You tried to attribute a
perceived lack of software quality in perl libraries to perl itself, or to
perl's ecosystem, or to the fact that perl is interpreted. (I'm still not
sure which one you're claiming.) It is straightforward to write
low-quality software in every language I have heard of, interpreted or
not, so the problem is clearly not with perl, or with perl developers as a
community, or with interpreting code as a concept.

> Personally, I think you missed the crux of what I was trying to say
> about the piling one layer of interpreted software, one abstraction, on
> top of another.

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.