
John Lato
writes: Brandon Allbery wrote:
On 2009 Feb 21, at 20:47, Jonathan Cast wrote:
On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:
Not showing platform-specific packages by default *might* make package writers more likely to develop cross-platform packages.
You're saying a developer would think, oh, I need to test this on windows, or else Hoogle won't index it?
I think it is way more likely that not showing platform-specific packages will result in yet another platform-specific library duplicating (the necessary) part of the functionality.
On the other hand, displaying platfom-specific libraries might lead to them being more used, and in turn being ported.
I agree with both of these points. I think at least the first would be adequately addressed if Hoogle categorized results by platform compatibility in some way. Then a person looking for, e.g. a BSD-Sockets package should be able to find it more quickly.
We've heard many times someone say, "I don't know if it works on Windows, never really thought of that."
I'd say it. I'd be happy to accept patches for Windows compatibility, but I'm not going to go out and buy an OS, install it, install all the required software and so on - just to tick a checkbox I'm not sure anybody - a potential user of software, that is, not a user of checkboxes - even cares about.
I certainly don't expect every developer to run out and buy Windows just to test their stuff. I have access to a Windows box, and I hate testing my code on it because I have to reboot to do so. I'll freely admit it's a pain. That's not the point, though. In my experience, most haskell code works on windows, unless you have a Unix or FFI dependency. In those cases, yes, it's a lot more work to port and test. But if you don't, or could use a cross-platform equivalent, then there's a good chance your code will work on Windows *with no extra effort.* That's what I'm arguing for: making it easier to make cross-platform choices without any extra work on the developer's part.
1. It's often easier (and almost never more difficult) to design for cross-platform support from the beginning than to add it later.
I don't entirely agree. I have no particular experience writing cross-platform software, and no way to test it - chances are I'd just mess it up anyway. Better that an expert, with a real need to cater to, do this later on.
I didn't phrase this well. In the context of my argument, "design for cross-platform" meant "avoid platform-limiting choices in the absence of any compelling reasons otherwise", which really isn't the same. In the specific case of Haskell software, I argue that this goes a long way to ensuring ease of porting (if necessary at at all). Again, with very little impact on the actual work that you need to do. Note that "compelling reasons" would include better features, better API, industry standards compliance, etc. I wouldn't say that a half-implemented, poorly documented cross-platform library is functionally equivalent to an alternative well-supported product.
2. As of now, the "Windows Group" seems to be mostly Duncan. And while I greatly appreciate all the time and effort he continues to put into Windows support, he's got a lot to do and could use some help. If you can't help by joining the Windows group, at least you could make your own packages cross-platform.
If you care about Windows support, the least you can do is to install my stuff, and mail me the required patches to make it work - or let me know if it works already.
I am most definitely not a Windows programmer, so I'm in only a slightly better position than you to make such patches if necessary. I will test your code, though.
As far as I know, none of those 80% of users even know I exist.
In your case, I suppose that >80% of users don't care about bioinformatics, which seems to be your area of specialization. Fine. Even when coding for a broad audience, as opposed to coding for oneself, it's not true that you're coding for *everyone*.
4. Cross-platform concerns are something that responsible developers need to consider, just like localization and i18n. I.e., why *shouldn't* you think of that?
I don't consider those other two either, for about the same reasons. I don't need it for the software I'm writing, and I have no reason to believe anybody else does either.
I suppose that one might think that my views here are quite selfish. Where's the community spirit? Where is social responsibility? In a way you'd be right, but I also think that if you start *imposing* this kind of responsibility and community spirit, you'd start to se less free software out there. The cost of releasing software is low, but hell, if I'm going to be flamed for it, the cost of *not* releasing it is not any higher.
I'm really not trying to argue that this should be imposed upon developers, for exactly the reasons you give. One of the great things about hackage is the extremely low barrier to entry. I think that the "publish stuff and see what gets used" model is very effective, and I certainly don't want that to change. I do apologize if you think I'm flaming you (or anyone else). That was certainly not my intent. Honestly, I'm quite surprised that so many experienced Haskellers, all of whom have made far more contributions than I have, responded so strongly to my comments. I'm certainly not saying that I think every developer should go out of their way to actively support OS's they don't even have access to. I'm not even asking anyone to write any more code than they already feel like doing. I'm simply saying that, in the cases in which Windows compatibility can be had *for free*, the community should encourage it. I also thought that most developers would be happy to take advantage of such a situation, but it seems I was mistaken. Sincerely, John Lato