[Haskell-cafe] Non-technical Haskell question

[azrael at demonlords.net]

> -------- Original Message --------
> Subject: Re: [Haskell-cafe] Non-technical Haskell question
> From: "Keith Wansbrough" <Keith.Wansbrough at cl.cam.ac.uk>
> Date: Mon, December 06, 2004 9:00 am
> To: "Georg Martius" <mai99dgf at studserv.uni-leipzig.de>
> Cc: "Jason Bailey" <azrael at demonlords.net>, "Jules Bean"
> <jules at jellybean.co.uk>, Haskell-Cafe at haskell.org
> 
> > >  When I compile it I get three files, an actual runnable binary (at only
> > > 5M in size), a .o file and a .hi file. I'm sure these additional files
> > > are usefull in someway and as soon as I come across the right piece of
> > > documentation everything should make sense. But as a person new to the
> > > language I'm just left wondering why.
> 
> gcc of course leaves .o files lying around, so this is no different than C.
> 
> javac often creates tens or hundreds of .class files, some with
> strange names like MyClass$1.class, MyClass$2.class, and so on (yes, I
> know what they are for), and doesn't even generate a native binary.

The original observation was that the compiler seems archaic. When
asked, I gave some general comments. What I should have just said was
that it was to much like a C compiler. Which, no matter how neat you
think it is, is archaic.

 When I use javac every file that is created is necessary for the
application to run. This can't be said of the ghc compiler. Having an
excuse that this is way the C compiler does it or that this is the way
its always been done is to poor of a reason to even argue against. If a
file isn't needed then it shouldn't be left there. 


> I don't think the output of ghc is any more surprising than these; I'm
> surprised it bothers you.
> 

Does this bother me? Not in particular, its just an indication that this
is an old design.


> The static vs dynamic linking question has been discussed many times.
> The summary is: GHC is a highly-optimising compiler, and the binary
> interface _necessarily_ changes with every minor revision (even
> patchlevel revision) of the compiler and each library.  So you can't
> sensibly share libraries between apps.  Anyway, disc is cheap.
> 

I design and build business applications. I'm very good at this. Part of
being very good at something like that is acknowledging that that there
are some areas where I can't be as good.. such as compilers. The reason
I say this is that if your telling me that no one here can figure out
how to make it work then I will take your word for it. I'm certainly
not in a position to argue :)

The whole disc is cheap argument is a cop out. Certainly for a single
application this is true. But your inherently limiting yourself.  This
means no one would consider haskell for embedded devices, or an OS, and
it would even impact to a certain degree the decision to use it for a
commericial product. You can see how this is reflected today in the
fact that you can find almost no binary programs available for
download.

Programs and applications are out there but almost exclusivly as source
code and yes a few of the website even mention that the binary size is
the reason why they aren't making it available. (bandwith costs time
and money) 

However this is just a  view of a rank and file programmer who's new to 
haskell. Some of my concerns and issues are probably not valid just
because I am not familiar with the language as a whole. However if
there is a desire to make Haskell more accessible to the majority of
programmers then the first impressions that I, and those like me have
is important. 

Jason

> HTH.
> 
> --KW 8-)