[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

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.

>                                                             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.

>                                                         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.

> - 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?

-- 
Nicolas Sebrecht