[arch-general] Re: pacman new generation
The 22/11/11, Norbert Zeh wrote: but it's not an easy language to learn to use effectively. For that reason, the pool of Haskell developers out there is much smaller than the pool of C programmers. Furthermore, from my own experience I know that writing good Haskell code poses its own set of challenges Agreed. I don't think Haskell is the best language for the purpose. Go language may fit much better. -- Nicolas Sebrecht
[arch-general] Re: pacman new generation
The 21/11/11, Thorsten Töpper wrote: Seriously, it's probably meant like this but your mail reads like a Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system. I've not participated in pacman development myself so I guess I should stfu myself, but for me this proposal just reads like a kick into the faces of Allan, Dan and all the other people who did so. I don't think, so. Or nothing could be discussed because some others did another choice some time ago. OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages. -- Nicolas Sebrecht
[arch-general] Re: pacman new generation
The 22/11/11, Karol Blazewicz wrote: On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages. Isn't pacman written in C? Yep, sorry. s/shell scripting/low-level progrmming languages like C/g :-) -- Nicolas Sebrecht
[arch-general] Re: pacman new generation
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
[arch-general] Re: pacman new generation
The 22/11/11, Magnus Therning wrote: On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht nsebre...@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
[arch-general] Re: pacman new generation
The 22/11/11, Rodrigo Amorim Bahiense wrote: On 11/22/2011 13:36, Taylor Hedberg wrote: You can't seriously be suggesting that switching to Haskell would increase the size of the pacman developer pool. Notice I didn't support Haskell. I'm talking about high-level languages in general. Not all of these languages are widely used nor very scalable for a package manager. I don't think there's any compelling reason to rewrite pacman in another language. I already gave some good reasons in this thread, though. Code language should not be chosen based on popularity. C is used in most unix-like software because of its quality and not as a consequence of the available developer pool for it. I tend to agree. -- Nicolas Sebrecht
[arch-general] Re: pacman new generation
The 22/11/11, Taylor Hedberg wrote: Maybe not, but the person I was replying to was making the specific argument that higher-level languages like Haskell would be more suitable for a tool like pacman because a larger number of people would be able to contribute. I was simply pointing out the fact that that is certainly not the case for Haskell in particular. I don't think popularity is irrelevant, either, assuming you are interested in increasing the volume of contributions to your project. If you pick a relatively obscure language to work in, you are just creating another barrier that makes it harder for new people to become acquainted with the codebase. Here is a very good resume of this aspect of the discussion and we fully agree, here. -- Nicolas Sebrecht
[arch-general] Re: pacman new generation
The 22/11/11, Piyush P Kurur wrote: Many here will agree to almost all the points that you raised about Haskell. However the way the you introdued might have irked some. I'm sorry about that. Poor circumstances might give this wrong impression. Here is how one would go about suggesting such a changes: Hi folks I was interested to know whether implementing rollbacks like NixOS is interesting for people here. Since I feel that C is too low level as a first step I am attempting a port of pacman to Haskell. The code is available under darcs at http://somewhere.org/me/ Patches are welcome. The current version does nothign but prints package meta info. Regards me Notice I'm not the OP show suggested porting pacman to Haskell. I came into this thread after the facts and tried hard to make the original suggestion as a part of the larger POV in favor of high-level languages. Also, I don't want to flame and rather keep the discussion out of free attacks against the current team of developers. I took part of this thread only because I've already been faced to pacman limitations in its current form. -- Nicolas Sebrecht
