Dejan Jelovic wrote:

Jerzy Karczmarczuk wrote:

...

Over and over again the same silly song, by a person who - visibly - had never anything to do with functional languages, who thinks now about hiring some C and java programmers living in Belgrade

I don't understand how you deduced I "never had anything to do with functional languages"? Any how is it relevant to the subject at hand that I'm hiring Java and C++ (not C) programmers in Belgrade?

Well, I managed to annoy you. Sorry. I exploded. I still think you merited a good part of it, although I might reformulate it more calmly today. 1. I didn't find ANYTHING about FP on your pages, only that accusations. 2. I don't remember any of your eventual contribution to discussion lists, newsgroups, etc. I might be wrong. Please give some references, publications, functional software, etc. I will apologize then immediately, with regret, but also with satisfaction that the Truth won. 3. Personally you don't care about Haskell. Your page *explicitly* discourages local people from touching functional languages, the category of people you want to hire is a very strong signal. A potential employer who does what you did serves the devil, don't try to suggest that this isn't relevant.

...

but who writes such silly, incompetent things as:

...

And there is an air of staleness: where new versions of these other languages appear frequently, the Haskell community is offering you Hugs98.

I don't see why what I said is silly or incompetent? The Haskell Compiler and Interpreters page at haskell.org suggests Hugs98 for newcomers. While you and I know that the latest version of Hugs has been released two weeks ago, a curious visitor will wonder why there isn't Hugs 2001.

And the Haskell website is updated rarely in contrast with, say, the Python website.

1. Saying that the Haskell community offers Hugs98, and not mentioning neither GHC, nor NHC is either incompetent or provocative. Sorry. It is not my intent to quarrel, nor to offense anybody. But presenting such limited information on your page is a very bad job for the community. Very bad and not too moral. 2. A decent programming language *must* be stable. If the main criterion of the "quality" you attribute to programming languages is the speed of its modifications, I wonder what don't you accuse of staleness your favourite languages: Java and C++. 3. The fact that Hugs is suggested as a good introductory implementation - because it is inexpensive in resource consumption and interactive - is a very good point, not an argument against. It has nothing to do btw. with your opinion of the *language*, just another pretext to say nasty things. Hugs 2001???? Are you sure that you really know what does it mean a STANDARD? Show me C++2001, please.

...

Delovic points out that some languages became "immensely" popular, as e.g. Ruby, and that Haskell is marginal. Hm. this extremely orthodox Japanese essence of O-O programming may have some practical merits, especially those which come from shameless borrowing from Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal" or "obscure" informs us not what is Haskell, but who is Jelovic.

Compared to the usage of C++, Java or Python, the usage of Haskell is _marginal_. Visit the computer section of your local bookstore if you need to be reminded of that.

[Sorry for the error in your name. Fingerslip.] 1. Oh yes. Thousands of books about Ruby. Actually one, in Japanese. Have you looked here: http://www.haskell.org/bookshelf/ This is comparable with Python. Of course, Python IS more popular, but - - 2. You neglect, and I suspect that you do it on purpose, that the main driving force behind the evolution of Haskell is *RESEARCH*. An issue absent from many "popular" languages which are meant to be immediately exploitable with very flat learning curve. Haskell is vivid at universi- ties, almost every decent higher-education establishment has its imple- mentation. The documentation on line is sufficiently good that e.g. - my students won't even think about going and trying to buy a book. Money... [[University libraries, at least in France is another issue. We are *not* doing a good job here...]] Still, there are more publications on FP every month that I can digest. What about Python? Java?

BTW, you seem to be well-informed about who this Jelovic is. Why don't you share that knowledge with us? :)

Oh, but I did. You seem to be a self-appointed specialist on functional languages, who expresses in public some very dubious truths, which I find harmful. That's all. I know nothing about your status nor the colour of your tongue, I am speaking about your image in *this* context. Most of people reading this forum will shrug, and throw to the waste-paper basket both postings, yours and mine, and this is good. Nothing more to say about you, and if you wish, I may reformulate my statements: "Such biased and incomplete assessment of functional languages should be treated not as an information about those languages, but as an information about the competence and/or good will of the Author".

...

He accuses the Haskell community of not providing libraries...

Two errors here:

1. I didn't accuse anybody of anything. I was just curious about why people aren't using Haskell and started to think about it.

I understood this in such a way. You didn't ask questions "why", I haven't seen this curiosity. Perhaps I missed something vitally important between lines. You are explicitly negative in your *judgement*.

2. I didn't say that the Haskell community has not provided the libraries. I said the Haskell community hasn't provided the libraries together with the compiler in one standard distribution. I think that's needed in order to lower the barrier to entry.

There are hundreds of libraries of Java classes and C++ classes and procedures which are distributed separately. The "standard" GNU distribution of C++ is quite limited, there is no point in overloading the standard environment by things whose usage is limited. The ease of installation is also important. BTW. the GHC "standard" distribution has an adequate amount of runtime support for normal tasks. It worked for me without any problem. (And, the "standard" libraries of platform-specific C distributions: M.Soft, Borland, Solaris etc. are quite different...)

...

Perhaps there is *one* point worth mentioning: the necessity to publish papers about Haskell far from such journals as JFP or HOSC, but to try to reach DrDobbs etc.

Funny. You said at the beginning of your message that there is "NOTHING" serious there. :)

RRight. I found one point worth mentioning. Wonderful, splendid, and original. Hereby I declare that you are the winner of this discussion, and I am the loser. Complete KO. ===================== Bill Halchin defends D. J.:

I think Dejan has written in a good spirit and has many cogent points, especially for example with regard to Python. I guess the bottom line is don't be too think-skinned about what seems to me to be constructive criticism. In the FPL community, it is easy to maintain a siege mentality.

I scratch my head, and I cannot understand how could I recognize from the incriminated page the "constructive criticism" and "good spirit". What I have seen is a total negation, not a single good word, some cheap pieces of advice (about the publications), and plenty of misunderstanding (about the relation between the liveness and the frequency of changes of a language). It is very easy to criticize a programming language, especially the one you don't like nor use personally. This is so cheap, that I find it simply disgusting. (So, I have even *defended* PERL on another forum, although I don't like it.) I have nothing personal against Dejan Jelovic. My "contribution" to the FP community is - in this context - to show that our opponents are, hmm, how to say it, in order to avoid offensive words - basing their criticism on false premises, and they perhaps should learn what is the current status of the proposed implementations, before publishing their "analyses". Jerzy Karczmarczuk Caen, France

On Tue, 3 Apr 2001, Brian Boutel wrote:

they do the job better that the proprietary competition. Why then has Haskell not done as well as sendmail or apache? Perhaps because the battleground is different. To get people to adopt Haskell (or any other

brian

IMO, what's also important, is an infamous memory consumption. Everybody seems to ignore it, but by now I wouldn't use Haskell in a commercial product, because of this little inconvenience. For me, it doesn't matter much if a language is slow - as far as it's not very slow, it's ok. More important for me is the predictability. I have to know how much memory my program will eat. And in Haskell, with ghc the only sure answer is: "Very much". Things are better with nhc, true, though I haven't tried yet to use its impressive profiling tools. Hbc isn't alive, so there's no point in speaking about it. The other thing, which somebody has mentioned, is a steep learning curve. Most of us has understood and embraced the monads - in fact, I consider do notation as one of the more important things in Haskell. Yet it took me some time to understand it - and when I tried, I was a CS student. IMVHO monads are a difficult concept to grasp. And simple writing to the screen or reading text from keyboard enforces us to use IO. I don't know what to do to make them easier to understand. Perhaps these new papers make it better. The lack of standard arrays, with update in O(1) time, and hashtables is another thing. Every time I write a larger program, I use lists - with an unpleasant feeling that my favourite language forces me to use either nonstandard extensions or uneffective solutions. I think that IO arrays/hashtables should be in standard. Because they are in IO - they could work efficiently. Yes, I know about MArray/IArray. Yet I couldn't find information in sources about complexity of array operations. And they aren't Haskell 98 compliant. I'm also curious about what you think about the purpose of Haskell. I personally consider it *the* language to write compilers. But what can you do in it besided, that wouldn't be as easy in other languages? (I'm talking about large projects, we all know about polymorphism, higher-order function, etc.) Wojciech Moczydlowski, Jr

On Tue, 3 Apr 2001, Manuel M. T. Chakravarty wrote:

"Wojciech Moczydlowski, Jr" wrote,

...

IMO, what's also important, is an infamous memory consumption. Everybody seems to ignore it, but by now I wouldn't use Haskell in a commercial product, because of this little inconvenience. For me, it doesn't matter much if a language is slow - as far as it's not very slow, it's ok. More important for me is the predictability. I have to know how much memory my program will eat. And in Haskell, with ghc the only sure answer is: "Very much".

After profiling and removing space leaks? In what kind of applications did you encounter this problem?

I tried to profile my toy C compiler. The profiles simply didn't work - the graph didn't convey any informations. I've informed about the bug and let it go. And besides, after rough testing, it seemed that memory usage grows linear with a compiled program size. It was OK. But during the compilation of 200KB program, my compiler ate AFAIR about 30MB of memory.

This is - again - the problem of a lack of standard libraries. This is a problem, a very serious one, and it is being worked on. More hands => more solutions, faster.

I know that almost every problem Haskell has is caused by lack of people.

I found Simon Marlow's http server a quite convincing example of how Haskell can shine in an application that is very far from the typical applications in which functional

In a "Advanced functional programming" class at Warsaw University this year, the group is striving to write a DNS server in Ocaml. I'm curious whether they'll succeed.

Manuel

Wojciech Moczydlowski, Jr

"Wojciech Moczydlowski, Jr" wrote,

On Tue, 3 Apr 2001, Manuel M. T. Chakravarty wrote:

...

"Wojciech Moczydlowski, Jr" wrote,

...

IMO, what's also important, is an infamous memory consumption. Everybody seems to ignore it, but by now I wouldn't use Haskell in a commercial product, because of this little inconvenience. For me, it doesn't matter much if a language is slow - as far as it's not very slow, it's ok. More important for me is the predictability. I have to know how much memory my program will eat. And in Haskell, with ghc the only sure answer is: "Very much".

After profiling and removing space leaks? In what kind of applications did you encounter this problem?

I tried to profile my toy C compiler. The profiles simply didn't work - the graph didn't convey any informations. I've informed about the bug and let it go. And besides, after rough testing, it seemed that memory usage grows linear with a compiled program size. It was OK. But during the compilation of 200KB program, my compiler ate AFAIR about 30MB of memory.

How much memory is gcc eating for a 200KB program? If you were to a write a toy C compiler in C++ or Java, do you think, it would eat significantly less memory without seriously tuning of the memory management? Manuel