The 22/11/11, Magnus Therning wrote:
On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht <nsebrecht@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