[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 22/11/11, Magnus Therning wrote:
> On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht <nsebrecht at piing.fr> wrote:

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

I admit it's not the best words. I should rather say

  "language with a higher level of abstraction letting us to express
  more complex ideas in fewer lines of code, sometime relying on very
  small and atomic units of a more low-level language like C for critical
  pieces of code, giving us the advantages we all know for software
  maintenance, scalability and adaptability, even for less experienced
  programmers such as advanced admins"

but this is not very concise.

>                     Even if there was such a thing you'd find that the
> problem is essentially difficult.

Trying to solve a difficult problem, say ones that would need a good
level of abstraction, is harder with a language like C than with a
high-level language. ,-)

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

It's a bit in contradiction with your previous statements. As you said,
code source is changing, pacman is moving. Playing with C makes no help
to reduce accidental difficulty; it's the exact opposite.

Reliability is managed with good software development practices such as
development cycle and keep control on too much stressed pieces of code.

Starting with another language doesn't mean it should not be well tested.

> 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

I don't think, so. IMHO, the pool of contributors is bigger with a
high-level language than for C, simply because the learning curve of
a good high-level language is much shorter.

>  2. push away the current contributors who don't know language X and
> don't want to learn it

With statements like that, even C language would not have become what it
is today and we were all running of softwares in B language alone, or so.

-- 
Nicolas Sebrecht