Proposal: overhaul System.Process

Frederik Eaton frederik at ofb.net
Sun May 25 20:16:14 EDT 2008


Dear Curt,

Well, I thought the exact same thing when I started using Haskell. Then I
found that nothing I wrote lasted for more than a year or so. I would put a
lot of time into a project, it would be done, and then soon it wouldn't
compile anymore. So whereas with other languages I had to deal with less
slick interfaces, but got code that is still useful to me, many of the
things I wrote in Haskell are bit-rotted. This doesn't seem strictly
necessary, for instance, I improved on the System.Process interface in my
own libraries, and nobody had to change their code as a result. The problem
is that when Simon Marlow improves on System.Process, everyone has to change
their code. Why not release the new interface as a new library with a new
name? Changing the standard is an easy way to point new users to whatever
the current best interface is, but it is destructive as well, it defeats the
purpose of "standard" by breaking old code. We could accomplish the same
thing constructively with a web page that lists currently recommended
libraries. Then, new users could use the new libraries, but code that
depends on the old libraries would still work. I want to write code that
lasts for a long time. I don't want everything I write to become a
maintenance hassle, I have found that I don't have time for that. It seems
strange that the Haskell language, being "pure", doesn't allow destructive
updates of data; but the standard module interfaces are being constantly
subject to destructive updates, i.e. names change meaning or disappear,
which can make it just as hard to reason about what my code is doing.

Frederik


Curt Sampson-2 wrote:
> 
> On 2008-05-25 16:27 -0700 (Sun), Frederik Eaton wrote:
> 
>> ...but updating it whenever the standard interface changed and broke
>> my code. So I'd like to cast my vote for backwards compatibility. The
>> standard libraries will never be perfect, but constantly deprecating
>> and removing functionality can really impair their usefulness for
>> large projects.
> 
> Just as a counterpoint, I have to say that one of the things that
> impressed me a lot about Haskell over the last two months as I've
> started using it for real work is that the library interfaces are of
> noticably higher quality than other languages I've used (in the main, C,
> Java and Ruby). Part of this may be due to having smarter people working
> on things in the first place, but I suspect a reasonable amount is due
> to the ability to change interfaces as one discovers how libraries
> are really used and better ways to design them. I wouldn't want to
> lose this, and end up with the kind of cruft that everybody knows is
> broken but will never go away that exists in the Java and (to a lesser
> degree) Ruby libraries. I'm willing to put up with a fair amount of
> interface-change pain to this end.
> 
> cjs
> -- 
> Curt Sampson       <cjs at starling-software.com>        +81 90 7737 2974   
> Mobile sites and software consulting: http://www.starling-software.com
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 
> 

-- 
View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p17463932.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.



More information about the Libraries mailing list