RE: [Haskell-cafe] Non-technical Haskell question

-------- Original Message -------- Subject: Re: [Haskell-cafe] Non-technical Haskell question From: "Keith Wansbrough" Date: Mon, December 06, 2004 9:00 am To: "Georg Martius" Cc: "Jason Bailey" , "Jules Bean" , Haskell-Cafe@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-)