[arch-general] pacman new generation

[Magnus Therning]

On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht <nsebrecht at piing.fr> wrote:
> The 22/11/11, Magnus Therning wrote:
>
>> I am somewhat allergic to the kind of statements you make.
>
> Don't be. We are only _discussing_ the advantages/disadvantages of the
> current language, aren't we?
>
> Please, don't be allergic from talking.

I'm allergic to often-repeated statements that are born out of naivite ;)

>>                                                             It sounds
>> like you are alluding to Haskell (and other hi-level languages,
>> whatever _that_ means) as some sort of magic pixie dust that can be
>> taken out in order to spray good-ness on a software project.  There
>> are dozens of other things to consider.  In this particular case these
>> are the most pertinent IMNSHO:
>>
>> - Many of these languages improve the ability to reason about the
>> behaviour of the program.  This _can_ improve quality. HOWEVER, pacman
>> doesn't strike as a tool that suffers from bad quality,
>
> But it's missing advanced features.
>
> OP raised rollbacks, I'd rather talk about simultaneous/concurrency
> pacman calls and mutli-threading to handle packages installation where
> applicable (handling pools of per-package fetch, uncompress & install
> processes), for example. Or even a _three-way merge_ tool for
> configuration files (think of dispatch-conf), /etc snapshoting, check
> for conflicting path namespaces of files over packages at installation
> time (not sure this check is already done for every file), or whatever
> smart thing could be implemented.
>
> I'm not saying all of this should be implemented. At least, allowing
> wide contributions (from the technical POV, with a more simple language)
> permits nicer discussions and by the end, interesting features to be
> implemented.

"Simple language"?  Even if there was such a thing you'd find that the
problem is essentially difficult.

>>                                                         there seems to
>> be a development team that fully understand the crucial role that
>> pacman plays in Arch and they behave accordingly in relation to
>> rolling out updates.
>>
>> - Many of these languages allow for quicker development; by raising
>> the abstraction level it's possible to express more complex ideas in
>> fewer lines of code and given that the lines/hour written by a
>> developer is fairly static across languages it leads to quicker
>> development.  HOWEVER, pacman doesn't suffer from slow development,
>> there are new releases with new features fairly frequently (probably
>> as frequently as the community can stand them).
>
> According to what _you_ expect from a package manager to do.

Indeed.  It's correct (well tested, has stood the test of time, etc)
and reliable.  That's what I expect of a package manager.  Re-writing
it in another language would mean starting over with something that's
essentially difficult with something a tool that reduces accidental
difficulty.

>> - Finally with each language comes a pool of possible contributors,
>> the group of people who already know, or are willing to learn the
>> language.  For C this pool is huge, for most of these hi-level
>> languages not so.
>>
>> So my conclusion is that when you say "I do think pacman could much
>> better if rewritten in one of these languages", then I say that you
>> most likely are completely wrong.  The more likely effect of rewriting
>> pacman in one of these languages is that the current development team
>> would disperse, there wouldn't be as large a pool of programmers to
>> recruit from to replace them, and in the end pacman would turn out to
>> be worse.
>
> Oh, come on. You're kidding me, right? Did anyone talked about spreading
> in the wild the current team?

You can't possibly misunderstand me to that extent.  What I'm trying
to say is that you are suggesting something that you haven't thought
through properly, if you were to stop and ponder a little you would
realise that your suggestion would have the _unintended_ consequences
of

 1. reduce the pool of possible contributors
 2. push away the current contributors who don't know language X and
don't want to learn it

In other words, the current team would be dispersed.

Please read Brook's No Silver Bullet and then return to the
discussion. http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus