That sounds great. It seems rather strange that although Clean is very fast, it does not seem used very much in comparison with such other functional languages as Haskell and Scheme.
Although this has been discussed on this mailing list before, one possible reason that I can think of is the lack of an interactive environment, which tends to be more important with an academically-oriented functional language than with an industry-oriented one. In many other functional languages that are widely used, such as Haskell, Scheme, OcaML, and Erlang, the presence of a REPL encourages so-called "exploratory programming," in which students of the language who are taking courses in college try out code snippets interactively before including them in the program proper. Clean comes with an IDE, instead of a REPL, and while this is sufficient for industry use, it tends to discourage exploratory programming, in turn discouraging the use of Clean in an academic context, in particular in college courses. This orients Clean more toward an industrial programming language; however, since people in industry tend to prefer widely-used languages with good library support, in addition to a fast language, the fact that Clean is not already sufficiently widely used then leads people to compare Clean with the very similar language Haskell, which is also a non-strict, purely functional programming language. Previously, Clean was much faster than GHC, the main Haskell compiler, but GHC has been narrowing the margin with each update while releasing a great number of libraries, so speed is becoming less and less a distinguishing factor. On the other hand, ease of use is one of the main advantages that functional programming languages tend to have over procedural and object-oriented programming languages, but when compared to most other functional programming languages, Clean lacks the REPL that most other such languages have. If the development of a REPL for Clean would be too expensive for the developers in terms of time and resources, would there be any possibility of starting some kind of open-source project to create a REPL for Clean? With logic programming languages, although Mercury is relatively fast when compared to Prolog, perhaps one reason that many users prefer SICStus Prolog, which is also fast, to Mercury is the existence of a REPL. SICStus costs 153 euros for a personal license, yet manages to hold its own against SWI-Prolog, a free version, because it is fast, reliable, well-documented, and has a REPL. If cost is an issue, perhaps you could follow the example of the Swedish Institute of Computer Science and charge a similar fee (with a free evaluation period) for a similar version of Clean with a REPL? That would enable you to offset the development costs. -- Benjamin L. Russell On Thu, 6 Nov 2008 13:02:08 +0100, "rinus plasmeijer" <[EMAIL PROTECTED]> wrote: >Hi Bejamin, > >Very good question! > >John van Groningen is working hard on the new version of the compiler. >The idea is that this new system will accept Haskell '98 source code and >that one can mix Haskell with Clean modules as well. >This is quite a big change in the (front end of) the compiler. >To be able to mix modules has lot's of consequences: In Haskell one can use >Clean stuf (like uniqueness typing) and in Clean one can use Haskell stuf >(eg Haskell records which are different from Clean records). Since one has >to be able to call one from another, there have to be denotations for each >feature in each language as well. >Also one has to be able to mix libraries (Clean's StdEnv and Haskell's >prelude). >Finally the IDE has to be adjusted to deal with the new situation. >Haskell's lack of a good module structure does not make life easy... > >And John likes to make things reliable, but also fast... >We hope to achieve a compiler which compiles fast and produces excellent >code, also for the new features.. >This takes time. > >Before the end of the year we hope to have a beta-version which we can use >here internally. > >Before we can release it externally we need to add documentation. >The list of added features will be long.... > >We have indeed made some bug fixes, but there are not that many. >So, we will not release a new compiler just for that. > >greetings, > >Rinus > > > > > > >"Benjamin L. Russell" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> Actually, come to think of it, the data, in addition to the date, >> might also be useful; specifically, the following: >> >> * bug fixes (if any) >> * changes/added features >> * changes in the documentation >> * a new weekly "Clean Report" on what's happening in the Clean >> community >> >> So, in light of the above which just came to mind, and just to be >> pedantic, let me reinstate my original subject: >> >> "Any scheduled release data for Clean 2.3?" >> >> and include the predicted date as chronological data. There: It >> wasn't a typo after all. ;-) >> >> -- Benjamin L. Russell >> >> On Wed, 05 Nov 2008 13:39:13 +0900, "Benjamin L. Russell" >> <[EMAIL PROTECTED]> wrote: >> >>>Sorry; the subject should have been as follows: >>> >>>"Any scheduled release date for Clean 2.3?" >>> >>>(I.e., replace "data" with "date" in the original subject.) >>> >>>Sorry for the typo. >>> >>>-- Benjamin L. Russell >>> >>>On Wed, 05 Nov 2008 11:36:09 +0900, "Benjamin L. Russell" >>><[EMAIL PROTECTED]> wrote: >>> >>>>Since there hasn't been much activity here lately, I just wanted to >>>>check if there was any tentative release date for Clean 2.3, and if >>>>so, what changes, if any, might be scheduled. >>>> >>>>-- Benjamin L. Russell >> >> _______________________________________________ >> clean-list mailing list >> [email protected] >> http://mailman.science.ru.nl/mailman/listinfo/clean-list >> _______________________________________________ clean-list mailing list [email protected] http://mailman.science.ru.nl/mailman/listinfo/clean-list
