On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote:
> I spoke with the author of the fork a bit in IRC around the time it happened
> and my understanding is that:
> 1) John sternly objects to using cabal as the build system for JHC
This is a fairly silly reason to fork a project, especially jhc, for a
number of reasons.
It is important to me that jhc be as widely accessible at possible. The
number of machines './configure && make install' will work on outnumbers
those that cabal install will work on hundreds or thousands to
one. I am pleased to have anyone experiment with jhc in the first place, I
don't want to make things harder for my users. This alone would be
enough of a reason all other things being equal, but other things arn't
equal to boot.
The command './configure && make install' only works in Windows if the user bother to install some form of unix environment emulation like msys or cygwin. I don't know if windows platform support matters to jhc, but if it does that's one reason to want to provide an alternative to the autotools build option.
The quality of support I can provide is diminished with cabal. Someone
tries to compile jhc, they get a moderately tricky build error. they
send it to me, I take a look, figure out the workaround and release a
new version that same day. one day turnaround. A bug is found in the way
cabal does something. I track down the bug, hope it is something
fixable, then further hope when I send a fix it is accepted. Maybe it
takes a week or two. Now, do I release a new version of jhc that
requires a development version of cabal? do I hold off and tell the user
they need a personalized workaround? do I demand that to use jhc you
have to use the latest cabal snapshots? Do I then have to support them
when the latest snapshots break something else of theirs? In any case.
it is not a situation I want to be in.
Cabal just isn't elegant. let's put it in perspective, cabal has 4 times
as many lines of code as mk (a superset of make)*. That is four times as
many lines of haskell code as C. Given how much more dense and
expressive haskell code is than C, that is a huge amount. Yet cabal
can't handle what even mildly complicated make scripts can do.
Cabal is not flexible. I decide I want to include a nice graph of code
motion in jhc, so I add the following 2 lines to my makefile
> %.pdf: %.dot
> dot $< -Tpdf -o$@
and done! my build system now understands how to create pdf documents
from graph description files. now, I _could_ add support for this to
cabal, I _could_ wait several months for the new version to propagate to
users. And I _would_ fully expect to have to go through the whole
process again the next time I want to do something slightly unorthodox.
Cabal is just a huge dependency I don't need. Every dependency I add to
a project is a bigger hassle for my users and for me. A fairly
complicated dependency like cabal would have to have fairly compelling
benefits.
Your arguments make it sound as though providing an option for building with cabal is out of the question. Since I'm not invovled with JHC or LHC in any way I don't know how you would answer this question: Would you consider a cabal based build inaddition to the autotools one?
Personally, I look at it this way. Both build systems have different advantages that the other cannot provide but they are not mutually exclusive. Also, the effort to keep them both working for the respective groups of users is rather small in practice.
Now, I am saying these things so people don't think I am just being
stubborn. I have valid, compelling, and logical reasons to not want to
use cabal. I think it is the wrong tool for the job and it is that
simple. If you want me to switch to cabal, address its issues, and
then _in addition_ add a killer feature on top to put it ahead of other
systems to make the work involved in switching worth it. I have a goal
with jhc, to write a kick ass haskell compiler. Not to fight a build
system that is not suited to my task and that made some dubious design
decisions. Not to promote an agenda.
The reason to provide a .cabal file is exactly the one Don wrote about. This is possible both using make as the build system or in a way that is independent of the make based build system.
And before you respond, think about this. What if the ghc developers
were constantly bombarded with whining from the perl people that ghc
doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What
would your impression of the perl community be?
I don't recall if I've expressed this publicly before or not, but I'm not fond of the language specific reimplementations of make. I think it's silly that every language has 2-3 language specific build systems and package formats. But, it's too late for me to stop Cabal from existing. Hackage is too useful to ignore. Using it increases my productivity. Tools that use the Cabal format save me time and give me cool features for free. I can easily run haddock or module graphs for example. So, in short, if the perl community had a compelling argument based on what GHC is missing out on, then I think it would be fine for them to bring that to the attention of GHC HQ.
Now, the next point. I think you're getting carried away here. This fork was created without you being aware of it. That makes me think the author of the fork didn't bombard you with whining. So, I think we need to keep some perspective on that. It's natural that you should have a fair bit of emotional attachment to the JHC -- you'd be weird if you didn't -- but as I've said before, I don't think any of this is an attack on you or JHC. Rather I think it's a fondness for JHC plus a desire to try different things.
What if people kept trying to convince _you_ to rewrite your haskell
project in java _and_ provide support for it because "they never had to
use referential transparency, so it can't be that important to you".
When this comes up on the Darcs mailing list we tend to explain why we like Haskell and then encourage them to try a reimplementation in their favorite language if they want to. I think that parallels the situation here. Someone thought he could do better by doing X and Y and instead of expecting you to support that went off and made a fork where he can support that.
Sometimes that is what it feels like, which is disapointing from this
community. We all came to haskell because we thought it was the better
choice at some point. The hegemony was pushing java, C++, or worse but
we didn't bite (or at least were still hungry). Just because something
is popular, it doesn't mean it is good, just because it is written in
haskell, it doesn't mean it is elegant. So don't begrudge me for holding
out for something better. Perhaps franchise will be it, perhaps some
future version of cabal, perhaps nothing will replace make/autoconfs
sweet spot (though I would hope there is still some innovation in this
area the OSS community can explore).
Well, I came to Haskell because I had university courses that introduced me to it, then I started using Darcs and realized I wanted to contribute to Darcs so I learned more Haskell. In the process, my old favorite language Common Lisp was replaced by my new favorite Haskell. I tell people that I now prefer Haskell because: a) The static guarantees you can get really are useful b) the language and paradigm fit the way I think c) the community is full of exteremely intelligent people that care about the quality of the code they write d) the community is friendly and growing. I think animonsity towards Java and C++ is silly. Those languages have their merit, their strengths and their place.
I don't see how using Cabal for it's strengths today and make for its strengths prevents you from using the next cool thing when it gets here.
> I hope John doesn't take the fork as any sort of aggressive or insulting
> action. He's made a compiler that is sufficiently interesting to have users
> that want to take over.
I am still actively working on jhc for the record. Actual code checkin
tends to be very spurty, but don't think the project is dead. More in a
design phase than anything else. There is no surer way to instigate
another spurt than by submitting some patches or bringing up discussion
of an interesting topic or paper on the jhc mailing list.
That's good to hear.
Thanks for your time, and I wish both projects well with lots of collaboration!
Jason