[Haskell-cafe] Re: Hoogle and Network.Socket

John Lato jwlato at gmail.com
Thu Feb 26 07:41:35 EST 2009

> John Lato <jwlato at gmail.com> 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.

John Lato

More information about the Haskell-Cafe mailing list