Comparison of various functional languages?
David N. Welton
Hi, I'm looking for information about functional languages. It looks
like something that might be interesting to play with a bit... So,
the question is, where to start, as there seem to be a number of
implementations that have various features. Can anyone recommend a
good source of comparison information, possibly keeping in mind these
things:
I want something that has a free (open source) implementation (OCAML
is out, for instance, because the implementation is not free
software).
I want something that may have some practical applications - a niche,
maybe, that isn't too small, where it shines.
I want something that is not too hard to get a handle on (ie,
sufficient documentation, decent sized user community..).
I don't really need to be told "this is the best because of blah blah"
- I'd rather read some good comparisons, and hear about features, and
draw my own conclusions.
Thanks,
--
David Welton
http://www.efn.org/~davidw/
Wilkes Joiner
> Hi, I'm looking for information about functional languages. It looks
> like something that might be interesting to play with a bit... So,
> the question is, where to start, as there seem to be a number of
> implementations that have various features. Can anyone recommend a
> good source of comparison information,. . .
I have also been very curious, I seem to get the impression that
Haskell, ML variants and Lisp variants are the most advicated. But I
have to decide which to persue. I already have a basic understaning of
Lisp, but I am more interested in Haskell or ocaml. Any recommidations
would be appreciated.
> I want something that has a free (open source) implementation (OCAML
> is out, for instance, because the implementation is not free
> software).
I haven't read the license for ocaml, but almost all languages (I can't
think of any that don't) have an free/open source implementation. That
does not preclude you from writing software to sell.
mo...@miss.wu-wien.ac.at
> I want something that has a free (open source) implementation (OCAML
> is out, for instance, because the implementation is not free
> software).
I am not a lawyer, but reading through the licence of the OCAML-sources,
I would say it allows you quite much. In my eyes it can be more or less
considered as free software. Here a short excerpt of the relevant points:
a- Extent of the rights granted by the INRIA to the user of the software:
INRIA freely grants the right to use, modify and integrate the
software in another software, provided that all derivative works are
distributed under the conditions described in point b- below.
b- Reproduction of the software:
INRIA grants any user of the software the right to reproduce it so as
to circulate it in accordance with the same purposes and conditions as
those defined at point a- above. Any copy of the software and/or relevant
documentation must comprise reference to the ownership of INRIA and
the present file.
The user undertakes to distribute the software either as unmodified
source files, identical to those originally made public by INRIA, or as
executable binaries obtained by compiling the original source files.
Distribution of derivative works obtained by modifying the sofware or
integrating it in another software is allowed only if the distribution
consists of the unmodified, original source files for the software,
along with difference files (patches) to be applied by the user of the
derivative work.
As regards any other type of distribution, the user undertakes to
apply to obtain the express approval of INRIA.
> I want something that may have some practical applications - a niche,
> maybe, that isn't too small, where it shines.
> I want something that is not too hard to get a handle on (ie,
> sufficient documentation, decent sized user community..).
> I don't really need to be told "this is the best because of blah blah"
> - I'd rather read some good comparisons, and hear about features, and
> draw my own conclusions.
Before I would call a language implementation "the best", it would have
to be better than other implementations in every respect - I have not
found such an implementation so far.
But my language of choice is OCAML, because I have so far not found
any apparent weakness that might rule it out. All other language
implementations I have tried so far suffer from some deficiency that I
won't like to bear when doing real development work. This includes such
aspects as restricted distribution policies (e.g. CLEAN - binary only),
slow (Haskell - GHC) or missing (Erlang) native code compilers or little
documentation (Mercury - though, a rather logic programming language)
- just to mention some aspects I dislike when I want to do something
serious.
To make sure that other people don't start a flame war on the languages
mentioned: I like the speed of and the high-quality output of the
CLEAN-compiler and the syntax and semantics of both CLEAN and Haskell,
the great possibilities for distributed computation with Erlang and
the formally extremely interesting semantics of Mercury. Unfortunately,
this alone doesn't help...
OCAML gives a very good overall picture: high-quality programming
environment (compilers, interpreter, debugger, ...) with a sensible
distribution policy (see above) and a very mature language design.
That's what I like :-)
Best regards,
Markus Mottl
--
Markus Mottl, mo...@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
Jeffrey Mark Siskind
> like something that might be interesting to play with a bit...
> I want something that has a free (open source) implementation (OCAML
> is out, for instance, because the implementation is not free
> software).
Stalin, an optimizing compiler for Scheme, is free and open source. It is
available from my Web page. The next version of Stalin, which I plan to
release in a few weeks, will be GPL.
Antti-Juhani Kaijanaho
> I am not a lawyer, but reading through the licence of the
> OCAML-sources, I would say it allows you quite much. In my eyes it
> can be more or less considered as free software. Here a short
> excerpt of the relevant points:
The excerpt you gave does not grant the right to distribute binaries
built from modified sources. In fact it is quite clear that this is
not allowed.
My definition of "free software" is identical to the Debian Free
Software Guidelines (DFSG), from which the Open Source Definition is
derived. This license violates DFSG point 4.
This makes OCAML non-free.
--
%%% Antti-Juhani Kaijanaho % ga...@iki.fi % http://www.iki.fi/gaia/ %%%
Good Times are back again!
http://www.iki.fi/gaia/zangelding/
Jacques Garrigue
> mo...@miss.wu-wien.ac.at writes:
>
> > I am not a lawyer, but reading through the licence of the
> > OCAML-sources, I would say it allows you quite much. In my eyes it
> > can be more or less considered as free software. Here a short
> > excerpt of the relevant points:
>
> The excerpt you gave does not grant the right to distribute binaries
> built from modified sources. In fact it is quite clear that this is
> not allowed.
>
> My definition of "free software" is identical to the Debian Free
> Software Guidelines (DFSG), from which the Open Source Definition is
> derived. This license violates DFSG point 4.
>
> This makes OCAML non-free.
This is a pretty restrictive interpretation of free-ness. Like if
somebody would be able to decide for everybody what is free and what
is not.
By the way, if you read carefully you realize that distributing
derivatives in binary form is not prohibited, but subject to
authorization from INRIA.
For instance there has been at some point some binary RPMs for
Objective Label, which is clearly a derivative work.
My personal definition of free, which I just keep for my own use, is
* sources are available (this is paramount)
* no fee needed (important if you want other people to use it)
* modifying sources is allowed, even restricted to patch distribution
(this is the only point which was probablematic with Qt-1, for those
who now)
* the original author is not too narrow-minded (means that the
restrictions might be left when really needed and justified)
Of course complete freedom may be better for the modifier, but there
are many good practical reasons which may make the original author
choose restricting policies. The two most frequently cited are
* the risk to see derivative works not clearly distinguished from the
original. This is potentially confusing for users.
* the desire to keep a "moral" copyright on what is one's personal
work. After all, you give plenty of your time to create a software
and may not want to be denied any right on it.
Finally I believe that if one believes in freedom, (s)he should also
believe in the freedom to define it.
Regards,
Jacques
---------------------------------------------------------------------------
Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
Matthias Blume
Jacques Garrigue writes:
> Finally I believe that if one believes in freedom, (s)he should also
> believe in the freedom to define it.
It depends on what you mean by the word "is".... :)
With this, you may see Microsoft "define" their software as being free...
Oops... I was trying to speak hypothetical, but reality has already
caught up. Microsoft _has_ recently tried to redefine the meaning of
"open source".
Matthias
--
Matthias Blume <blume@k_u_r_i_m_s.k_y_o_t_o-u.a_c.j_p>
Kyoto University, Research Institute for Mathematical Sciences
(remove underscores in mail address; they are there for spam-fighting)
Lynn Winebarger
Jacques Garrigue <s...@my.signature> wrote:
>This is a pretty restrictive interpretation of free-ness. Like if
>somebody would be able to decide for everybody what is free and what
>is not.
Not really. I tend to think the FSF has done a pretty good job of
defining what free software is.
>By the way, if you read carefully you realize that distributing
>derivatives in binary form is not prohibited, but subject to
>authorization from INRIA.
But this is always a route - asking the copyright holders for
permission. Software that is free (or, perhaps, doesn't subtract
freedom from the user) does not require bowing to a king (so to speak).
>Of course complete freedom may be better for the modifier, but there
>are many good practical reasons which may make the original author
>choose restricting policies. The two most frequently cited are
>
>* the risk to see derivative works not clearly distinguished from the
> original. This is potentially confusing for users.
This is valid and can be easily handled by trademark restrictions,
rather than restricting the code.
>
>* the desire to keep a "moral" copyright on what is one's personal
> work. After all, you give plenty of your time to create a software
> and may not want to be denied any right on it.
>
How does allowing other people to modify software you wrote restict
your rights on the software you originally wrote?
Mind you, I don't count the power to restrict others' freedom as a
freedom. That would be similar to saying that removing a tyrant is
removing his freedom to oppress people. Makes no sense (to me, anyway).
>Finally I believe that if one believes in freedom, (s)he should also
>believe in the freedom to define it.
>
You can talk whatever language you want, just don't expect others to
hold to it.
Lynn
mo...@miss.wu-wien.ac.at
>> I am not a lawyer, but reading through the licence of the
>> OCAML-sources, I would say it allows you quite much. In my eyes it
>> can be more or less considered as free software. Here a short
>> excerpt of the relevant points:
> The excerpt you gave does not grant the right to distribute binaries
> built from modified sources. In fact it is quite clear that this is
> not allowed.
I guess you conclude this from the following part of the licence:
Distribution of derivative works obtained by modifying the sofware or
integrating it in another software is allowed only if the distribution
consists of the unmodified, original source files for the software,
along with difference files (patches) to be applied by the user of the
derivative work.
If I were to interpret this with my limited knowledge of law, I would
conclude that it is allowed to distribute binaries of modified sources if
the sources (with original + patches) are contained in the distribution.
This can be derived by applying the "teleologic principle": what's the
purpose of this definition (licence)? It is obvious that it is not the
intention of INRIA that people have to compile modified sources (after
having applied the patches) everytime when they want to distribute it on
another machine/give it to someone else. This would be complete nonsense
(why the extra work of compiling everytime??).
What they obviously want is to ensure that every user gets the unmodified
sources together with the patches - with or without the binary.
This leads us to another aspect of freedom - here the four main points
of the GNU-philosophy (definition of freedom):
* The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and adapt it to your needs
(freedom 1).
* The freedom to redistribute copies so you can help your neighbor
(freedom 2).
* The freedom to improve the program, and release your improvements
to the public, so that the whole community benefits. (freedom 3).
The licence of INRIA does not violate any of these points. Even more -
its distribution policy actually ensures "freedom 1":
If you were allowed to distribute only the binaries of the modified
sources, this would deprive people of freedom 1 - to study how the
(modified) program works.
I am (in this respect) a Stallman-purist. His primary intention is that
knowledge is (stays) free. This is not violated by the OCAML-licence -
it is guaranteed!
> My definition of "free software" is identical to the Debian Free
> Software Guidelines (DFSG), from which the Open Source Definition is
> derived. This license violates DFSG point 4.
For those who have not read the DFSG, here point 4:
4.Integrity of The Author's Source Code
The license may restrict source-code from being distributed in
modified form _only_ if the license allows the distribution of "patch
files" with the source code for the purpose of modifying the program
at build time. The license must explicitly permit distribution of
software built from modified source code. The license may require
derived works to carry a different name or version number from
the original software. (This is a compromise. The Debian group
encourages all authors to not restrict any files, source or binary,
from being modified.)
Yes, you are right, the OCAML-licence probably violates this part,
but due to a minor mismatch: the licence would have to *explicitely*
permit distribution of the system built from modified sources (i.e. the
binaries).
> This makes OCAML non-free.
I think it would be a bit pedantic to view the licence in such a
strict way. But I am quite sure that INRIA will update their licence
and explicitely allow distribution of modified binaries (together with
sources, of course), because (as interpreted above) this seems to be
their intention.
Jacques Garrigue
> Jacques Garrigue writes:
>
> > Finally I believe that if one believes in freedom, (s)he should also
> > believe in the freedom to define it.
>
> It depends on what you mean by the word "is".... :)
>
> With this, you may see Microsoft "define" their software as being free...
>
> Oops... I was trying to speak hypothetical, but reality has already
> caught up. Microsoft _has_ recently tried to redefine the meaning of
> "open source".
Ok, more explanations for those who couldn't hear us over lunch.
What I essentially intended to say is that I want the freedom to
define what is free for me, as a user, and act according to my
choices. I certainly do not want Microsoft to define it for me, but I
do not necessarily agree with FSF's definition either.
Why? Just because different people have different priorities, and
among the several freedoms that one can be granted you can choose the
ones you really need. And remember that absolute freedom is public
domain, not GPL.
Best regards, Jacques
Tony Finch
>Jacques Garrigue <s...@my.signature> wrote:
>>This is a pretty restrictive interpretation of free-ness. Like if
>>somebody would be able to decide for everybody what is free and what
>>is not.
>
> Not really. I tend to think the FSF has done a pretty good job of
>defining what free software is.
They started it off, yes, but many people dislike the evangelical
nature of the FSF's idea of free software. The Open Source Definition
was intended to be a more inclusive definition of free software, and
there are quite few licences that fall outside it that don't cause
genuine problems.
Tony.
--
f.a.n.finch d...@dotat.at fa...@demon.net
Arthur: "Oh, that sounds better, have you worked out the controls?"
Ford: "No, we just stopped playing with them."
Antti-Juhani Kaijanaho
gnu.misc.discuss or some such.
Jacques Garrigue <s...@my.signature> writes:
> This is a pretty restrictive interpretation of free-ness.
Nevertheless, it has been adopted by many in the free software
community. Even the Open Source people use it as their definition.
> By the way, if you read carefully you realize that distributing
> derivatives in binary form is not prohibited, but subject to
> authorization from INRIA.
I can always ask Microsoft for an authorization to distribute binaries
I've built from modified sources to Microsoft Office. I'm pretty sure
I can get that authorization if I pay enough.
> * the risk to see derivative works not clearly distinguished from the
> original. This is potentially confusing for users.
Name change requirements do not make the license non-free by
DFSG-standards.
> * the desire to keep a "moral" copyright on what is one's personal
> work.
According to Finnish law, you cannot let go of your moral copyright,
and no-one can take it away from you. As the copyright legislation is
moderated by international treaties, I suppose this holds in other
countries too.
> Finally I believe that if one believes in freedom, (s)he should also
> believe in the freedom to define it.
Of course you are free to define freedom as you like, as long as you
don't try making me use your definition.
Antti-Juhani Kaijanaho
> I guess you conclude this from the following part of the licence:
Yes, and from the following sentence: "As regards any other type of
distribution, the user undertakes to apply to obtain the express
approval of INRIA."
Let me explain my reasoning.
"Distribution of derivative works obtained by modifying the sofware or
integrating it in another software is allowed only if ..."
This means that satisfying the following condition is the only way
to distribute modified software under this license.
"... only if the distribution consists ..."
The condition is that distribution contains the following
and nothing else.
"... consists of the unmodified, original source files for the
software, along with difference files (patches) ..."
The distribution must contain original source and patches.
"... difference files (patches) to be applied by the user of the
derivative work."
The patches are allowed in the distribution with the intent
that the distributee builds the software hereslf using these
patches.
"As regards any other type of distribution, the user undertakes to
apply to obtain the express approval of INRIA."
The only way to disregard these rules is getting separate approval
from INRIA.
> If I were to interpret this with my limited knowledge of law, I would
> conclude that it is allowed to distribute binaries of modified sources if
> the sources (with original + patches) are contained in the distribution.
In my limited understanding of English, the verb "consist of"
expresses the both directions of containment, ie. "A consists of B"
means that "A contains B" and "B contains A" (to abuse the verb
"contain" a bit).
> This can be derived by applying the "teleologic principle": what's the
> purpose of this definition (licence)?
It is dangerous to guess when reading a license, unless you are a
lawyer and know what you are doing.
> It is obvious that it is not the intention of INRIA that people have
> to compile modified sources
This is not obvious. In fact, I know a similar case (qmail about a
year or two ago) where distribution of original source + patches was
allowed but derivative binaries could not be distributed without the
author's approval - and I know for a fact that this was the author's
intention.
> The licence of INRIA does not violate any of these points. Even more -
> its distribution policy actually ensures "freedom 1":
In other words, it denies the higher levels of freedom. And no, my
complaint isn't addressed in the GNU explanation. This is because its
purpose is to explain, not to define, or guide a definition. And the
GNU explanation does not even touch the issue of source vs binary.
> I think it would be a bit pedantic to view the licence in such a
> strict way.
I'm accustomed to read a license this way, becase as a Debian
developer, I must at all times be certain that those files that I
distribute can be distributed. I cannot second guess the authors of a
license - I cannot assume that they have written something else than
what they actually mean.
> But I am quite sure that INRIA will update their licence and
> explicitely allow distribution of modified binaries
This would satisfy me. *And* it would allow us to move OCAML from
Debian non-free distribution to the main distribution. And I might
begin learning OCAML :-)
crippa
>
> Hi, I'm looking for information about functional languages. It looks
> the question is, where to start, as there seem to be a number of
> implementations that have various features. Can anyone recommend a
> things:
>
> is out, for instance, because the implementation is not free
> software).
This counts for Erlang.
> I want something that may have some practical applications - a niche,
> maybe, that isn't too small, where it shines.
This counts for Erlang and the niche could be applications making heavy
use of a network.
> I want something that is not too hard to get a handle on (ie,
> sufficient documentation, decent sized user community..).
The language itself (Erlang) is quite small and you will grasp it in
notime.
There is a vast amount of software, libraries, applications etc. well
documented.
> I don't really need to be told "this is the best because of blah blah"
> - I'd rather read some good comparisons, and hear about features, and
> draw my own conclusions.
I suppose you don't need a comparsion you just need to site down and
play around
a little bit with some languages.
Good luck!
> Thanks,
> --
> David Welton
> http://www.efn.org/~davidw/
/Christofer
---------------------------------------------------------------
Christofer Törnkvist Phone: +46 8 719 96 99
Software Architecture Lab. Fax: +46 8 719 89 88
Ericsson Telecom AB http://www-sarc.ericsson.se/
S-126 25 Stockholm, Sweden Email: cri...@erix.ericsson.se
---------------------------------------------------------------
David N. Welton
> Jacques Garrigue writes:
>
> > Finally I believe that if one believes in freedom, (s)he should also
> > believe in the freedom to define it.
Well, certainly, but a large bunch of people have defined it in a
certain way, and OCAML doesn't meet the grade, unfortunately.
Ciao,
--
David N. Welton | Fortune rota volvitur - descendo minoratus
dav...@prosa.it | alter in altum tollitur - nimis exaltatus
http://www.efn.org/~davidw | rex sedet in vertice - caveat ruinam!
www.debian.org - www.prosa.it | nam sub axe legimus - Hecubam reginam
Jerzy Karczmarczuk
> Stalin, an optimizing compiler for Scheme, is free and open source. It is
> available from my Web page. The next version of Stalin, which I plan to
> release in a few weeks, will be GPL.
>
> Jeff (http://www.neci.nj.nec.com/homepages/qobi)
Would you mind explaining your choice of the name "Stalin"?
I tried to look it up on your Web pages, I didn't find anything.
I am of Polish origin and I am afraid to touch it.
Perhaps the internal documentation provides the clues, but
the tar.Z file takes 15M.
Jerzy Karczmarczuk
Caen, France.
Adam P. Jenkins
> Matthias Blume <bl...@kurims.REMOVE.kyoto-u.ALLCAPS.ac.PARTS.jp> writes:
>
> > Jacques Garrigue writes:
> >
> > > Finally I believe that if one believes in freedom, (s)he should also
> > > believe in the freedom to define it.
>
> Well, certainly, but a large bunch of people have defined it in a
> certain way, and OCAML doesn't meet the grade, unfortunately.
It's not really this black and white. Can you name ONE supposedly
free software license that doesn't have a bunch of people who don't
consider it to be free? Certainly the GPL doesn't meet the grade.
Nor does the BSD license. It's all about compromises. The GPL does
not give you the freedom to hoard your modifications to a GPLed
program, thereby making it more difficult for someone to effectively
coopt a GPLed product. The BSD license makes the opposite compromise.
CAML makes a third compromise. There's no easy general answer, you
just need to decide if a particular license or definition of "free" is
suitable in a particular context.
--
Adam P. Jenkins
ajen...@netway.com
Craig Dickson
>Stalin, an optimizing compiler for Scheme ...
What a charming name. Will you also be offering some companion product
called Hitler?
Craig
mo...@miss.wu-wien.ac.at
> Yes, and from the following sentence: "As regards any other type of
> distribution, the user undertakes to apply to obtain the express
> approval of INRIA."
I should have taken this part into account - it is indeed a complete
restriction to the distribution types mentioned in the preceding
paragraph and thus does not allow the one I regarded as possible (binary
+ sources + patches). Maybe I should have cut'n'pasted a larger part of
the licence ;-)
> "As regards any other type of distribution, the user undertakes to
> apply to obtain the express approval of INRIA."
> The only way to disregard these rules is getting separate approval
> from INRIA.
I have asked people at INRIA through the mailing list to explain the
intention of this licence. Xavier Leroy was so kind to shed some light
upon this and why they indeed want to restrict distribution of the
modified system to source + patches only with good reason. Here his
answer which clarifies a lot about the attitude of INRIA towards other
ways of distribution which are not explicitely mentioned in the licence:
---------------------------------------------------------------------------
The point of the license that is discussed on comp.lang.functional is
how modified versions of OCaml can be distributed.
What the INRIA license states (not very clearly, I agree), is that
public distribution of modified versions is allowed in the form of
source diffs only. Other forms of distribution (in particular as
precompiled binaries) require prior authorization from INRIA.
The intent of this clause is to prevent "unfair" reuse of OCaml code
in projects that could be harmful to the whole OCaml effort. e.g. in
competitors' projects. For instance, I believe one could make a killer
Java compiler by taking the OCaml native-code generators and garbage
collector and bolt them onto a Java front-end. We feel this would be
an unfair use of the OCaml sources, and would compromise our research
effort in the field of functional programming.
A license such as the GPL doesn't address this concern: it would allow
this unfair use as long as the modified version is distributed under
the GPL and with source code. This is better than distribution without
source code at all, but is still damageful to us.
By requiring distribution as source diffs, we force users of modified
versions to download the OCaml source code and apply the patches
themselves. This way, they are made sufficiently aware that what they
are using is nothing but a modified version of OCaml. If we allowed the
distribution of precompiled binaries, this would be no longer the case.
My personal feelings is that this point of the license is a bit too
restrictive. However, the alternatives we know of are not restrictive
enough: the classic free licenses (GPL, BSD, etc) don't protect
the authors at all against unfair reuse. The INRIA license errs on
the conservative side, that's all. If we could find something less
restrictive but still protecting us against unfair reuse, we would
gladly change the license.
It should be pointed out that the current license has (as far as I know)
never prevented any reasonable use of OCaml. As a case in point, Debian
has an OCaml binary package because they didn't have to modify anything
in the source to make their package. Similarly, the license didn't
hamper the development of OLabl, which is clearly a derivative work.
Finally, INRIA has never refused any requests for license exemptions
that have been submitted in the past, and there are no indications
that this will change in the future.
> It would be a real pity if people ran away /
> didn't look at OCAML due to some unclear licencing issues.
It's hard to please everyone. The GPL makes some other people run
away (mostly industrial users who don't want to release the source for
their modifications). My hope is that while the current license might
drive away a few license ayatollahs, it should not be an obstacle to
all other OCaml users.
---------------------------------------------------------------------------
> It is dangerous to guess when reading a license, unless you are a
> lawyer and know what you are doing.
Well, if licences are not very explicit on some things, one cannot do
more than guess - though in this case thorough reading would have lead
to a better interpretation... ;-)
[snip]
>> I think it would be a bit pedantic to view the licence in such a
>> strict way.
> I'm accustomed to read a license this way, becase as a Debian
> developer, I must at all times be certain that those files that I
> distribute can be distributed. I cannot second guess the authors of a
> license - I cannot assume that they have written something else than
> what they actually mean.
As Xavier has pointed out, Debian has no problems distributing OCAML as
binary: if you don't want/have to change the system, that's ok.
>> But I am quite sure that INRIA will update their licence and
>> explicitely allow distribution of modified binaries
> This would satisfy me. *And* it would allow us to move OCAML from
> Debian non-free distribution to the main distribution. And I might
> begin learning OCAML :-)
It seems that INRIA would also prefer a distribution licence which is a
bit less restricitive, but only if it doesn't violate their intention
of not having "competitors" (probably rather in an intellectual than
commercial respect) making use of their sophisticated technology.
This could indeed harm their project: they could lose users to other
languages/systems which could make it more difficult to them to justify
funding of their project.
To quote Xavier's last sentence:
My hope is that while the current license might drive away a few license
ayatollahs, it should not be an obstacle to all other OCaml users.
I indeed wonder what you want to do with OCAML which isn't allowed and
thus violates your definition of freedom. As it seems, INRIA is very open
to other forms of binary distribution on request as long as it doesn't
violate their definition of freedom, i.e. it doesn't harm their project.
Why don't you just ask them whether the way you want to distribute
possibly modified binaries is ok to them? I don't believe you are
intending to use their code generators in a JAVA-backend ;-)
Lynn Winebarger
<mo...@miss.wu-wien.ac.at> wrote:
>Antti-Juhani Kaijanaho <gaia...@iki.fi> wrote:
> [part of email from Xavier]
> The intent of this clause is to prevent "unfair" reuse of OCaml code
> in projects that could be harmful to the whole OCaml effort. e.g. in
> competitors' projects. For instance, I believe one could make a killer
> Java compiler by taking the OCaml native-code generators and garbage
> collector and bolt them onto a Java front-end. We feel this would be
> an unfair use of the OCaml sources, and would compromise our research
> effort in the field of functional programming.
>
benefit everybody, not just the people who did the research. I would
think this Java example would be an excellent example of fairly using
the results of research (assuming the Java compiler credited OCaml and
remained as free as the OCaml distribution they used).
I really fail to see how that would compromise their research efforts.
> It's hard to please everyone. The GPL makes some other people run
> away (mostly industrial users who don't want to release the source for
> their modifications). My hope is that while the current license might
> drive away a few license ayatollahs, it should not be an obstacle to
> all other OCaml users.
"license ayatollahs"? Sounds more like a term I would use for the
people who use restrictive licenses, than those who insist upon
retaining their own freedoms.
>It seems that INRIA would also prefer a distribution licence which is a
>bit less restricitive, but only if it doesn't violate their intention
>of not having "competitors" (probably rather in an intellectual than
>commercial respect) making use of their sophisticated technology.
>This could indeed harm their project: they could lose users to other
>languages/systems which could make it more difficult to them to justify
>funding of their project.
Being open to competition is one of the intents of the GPL (though it
doesn't seem to work out that way very often). If they've published
research about their algorithms, they've already opened themselves up to
"competitors" in the intellectual sense anyway. This looks like a
situation where funding battles have warped the academic purpose of the
enterprise.
>
>I indeed wonder what you want to do with OCAML which isn't allowed and
>thus violates your definition of freedom. As it seems, INRIA is very open
>to other forms of binary distribution on request as long as it doesn't
>violate their definition of freedom, i.e. it doesn't harm their project.
Presumably, be able to freely redistibute modified versions
(including source and binary) and allow their users to do the same,
without permission-seeking.
Lynn
pat...@c837917-a.potlnd1.or.home.com
: In article <7f8bot$1...@cantine.wu-wien.ac.at>,
: <mo...@miss.wu-wien.ac.at> wrote:
: >Antti-Juhani Kaijanaho <gaia...@iki.fi> wrote:
: > [part of email from Xavier]
: > in projects that could be harmful to the whole OCaml effort. e.g. in
: > competitors' projects. For instance, I believe one could make a killer
: > Java compiler by taking the OCaml native-code generators and garbage
: > collector and bolt them onto a Java front-end. We feel this would be
: > an unfair use of the OCaml sources, and would compromise our research
: > effort in the field of functional programming.
: I must be missing something. Last time I checked, research was to
: benefit everybody, not just the people who did the research. I would
: think this Java example would be an excellent example of fairly using
: the results of research (assuming the Java compiler credited OCaml and
: remained as free as the OCaml distribution they used).
: I really fail to see how that would compromise their research efforts.
I agree. What a great way to spread the word about OCaml!
--
Patrick D. Logan mailto:patric...@home.com
mo...@miss.wu-wien.ac.at
> I must be missing something. Last time I checked, research was to
> benefit everybody, not just the people who did the research. I would
> think this Java example would be an excellent example of fairly using
> the results of research (assuming the Java compiler credited OCaml and
> remained as free as the OCaml distribution they used).
> I really fail to see how that would compromise their research efforts.
And you think it would be beneficial to the world if people used faster
JAVA-compilers instead of a much better language? Why provide food to
dinosaurs? Just to have some more companies produce trash for the masses
in return for huge sums of money?
As was said: if you can convince INRIA that your code changes should
also be distributable as binaries, you can ask them - they claim that
they have so far never declined any request.
> "license ayatollahs"? Sounds more like a term I would use for the
> people who use restrictive licenses, than those who insist upon
> retaining their own freedoms.
So you really feel so restricted by their licence?? I know not a single
user of OCAML that has ever complained that he wasn't allowed to do with
it what he wants.
> Being open to competition is one of the intents of the GPL (though it
> doesn't seem to work out that way very often). If they've published
> research about their algorithms, they've already opened themselves up to
> "competitors" in the intellectual sense anyway. This looks like a
> situation where funding battles have warped the academic purpose of the
> enterprise.
They are open to competition - everyone can get the sources. But it's a
difference whether you just copy the sources to speed up your otherwise
bad product or if you want to improve OCAML itself (or an even better
language). Do you like OLabl? Does it seem that INRIA discourages
this development?
>>I indeed wonder what you want to do with OCAML which isn't allowed and
>>thus violates your definition of freedom. As it seems, INRIA is very open
>>to other forms of binary distribution on request as long as it doesn't
>>violate their definition of freedom, i.e. it doesn't harm their project.
> Presumably, be able to freely redistibute modified versions
> (including source and binary) and allow their users to do the same,
> without permission-seeking.
If someone has asked about permission, I guess that everyone else may
distribute this specific version in its modified form. Actually, I don't
understand what you are getting at. Do you really believe that there
are so many people who would want - or better: who have the competence
to write their own version of OCAML??
Discouraging the use of OCAML because of this part of the licence
which might be interesting to just a handful of people is in my eyes
an overreaction.
Rolf-Thomas Happe
Jeffrey Mark Siskind:
> Stalin, an optimizing compiler for Scheme, is free and open source. It is
Would you mind explaining your choice of the name "Stalin"?
I tried to look it up on your Web pages, I didn't find anything.
I am of Polish origin and I am afraid to touch it.
Perhaps the internal documentation provides the clues, but
the tar.Z file takes 15M.
Indeed, the internal doc (stalin-0.7/README) expands the acronym:
Stalin - a STAtic Language ImplementatioN
Finally, a Lisp compiler that does what it should...
(Stalin does global compile-time analysis of a single Scheme source
file, provided the code stays away from Scheme's dynamic features:
LOAD, EVAL, and the like.)
rthappe
Lennart Augustsson
> Indeed, the internal doc (stalin-0.7/README) expands the acronym:
>
> Stalin - a STAtic Language ImplementatioN
> Finally, a Lisp compiler that does what it should...
>
Regardless of where the name comes from, I don't think
it's a good name. Would you want to name a language Hitler?
I don't want to get into politics, but I think Stalin was,
in many ways, as bad as Hitler, but he was among the winners
of the war.
--
-- Lennart Augustsson
[This non-signature is unintentionally not left unblank.]
Lynn Winebarger
<mo...@miss.wu-wien.ac.at> wrote:
>And you think it would be beneficial to the world if people used faster
>JAVA-compilers instead of a much better language? Why provide food to
>dinosaurs? Just to have some more companies produce trash for the masses
>in return for huge sums of money?
You've missed the point. A license like the GPL allows all kinds of
side development that might or might not seem promising to anyone "in
the know". Whether or not a particular development is worthwhile is not
the question. The question is whether or not the overall ability to
freely develop on the base knowledge would result in better software.
And I tend to think it would. For the same reasons that publishing
papers that allow anyone to build on what's been published encourages a
wider academic developments.
That said, I think it's pretty horrific to see this sort of
judgement from on high regarding java. I'm not a java fan myself, but I
still don't see it as your (or anyone else's) place to say that it's
just "trash for the masses." It's this sort of short-sighted looking
down the nose that gives academics a bad name.
>> "license ayatollahs"? Sounds more like a term I would use for the
>> people who use restrictive licenses, than those who insist upon
>> retaining their own freedoms.
>
>So you really feel so restricted by their licence?? I know not a single
>user of OCAML that has ever complained that he wasn't allowed to do with
>it what he wants.
First, I'm not a user of OCAML (or ML at this point). While I might
use OCAML to learn how to use it (and ML does look very interesting),
I wouldn't base any software on it until there was a truly free compiler
for it. For example, I wouldn't distribute software that used Chez
Scheme specific features, precisely because of this problem.
>They are open to competition - everyone can get the sources. But it's a
>difference whether you just copy the sources to speed up your otherwise
>bad product or if you want to improve OCAML itself (or an even better
>language). Do you like OLabl? Does it seem that INRIA discourages
>this development?
Don't know what OLabl is. And once again, I don't see why you (or
INRIA) should get to judge whether a given product is bad.
>
>If someone has asked about permission, I guess that everyone else may
>distribute this specific version in its modified form. Actually, I don't
>understand what you are getting at. Do you really believe that there
>are so many people who would want - or better: who have the competence
>to write their own version of OCAML??
But that isn't sufficient ("this specific version"). What would be
sufficient is if users could then freely work on it (without
permission-seeking), and incorporate it into other (equally free)
software. While I don't doubt that there aren't many people who
currently have the competence to write their own version of OCAML, if
there were a free version available, you might see more widely
distributed software based on it, and eventually some people would gain
that competence. (By "based on it", I'm including software written in
OCAML).
>Discouraging the use of OCAML because of this part of the licence
>which might be interesting to just a handful of people is in my eyes
>an overreaction.
>
The fact that it a product is freely modifiable and reusable is of
interest to everybody, even if they do not directly take advantage of
it, because it opens that software to all the benefits of real
competition (in the intellectual sense) and cooperation (as it usually
turns out in practice). Of course, I also consider preserving these
freedoms to be worthwhile in their own right, regardless of how many
folks actually take advantage of them.
Lynn
Klaus Schilling
> (Stalin does global compile-time analysis of a single Scheme source
> file, provided the code stays away from Scheme's dynamic features:
> LOAD, EVAL, and the like.)
I can't do without those dynamic features. What am I doing wrong?
Klaus Schilling
Rolf-Thomas Happe
rth...@leonce.mathematik.uni-freiburg.de (Rolf-Thomas Happe) writes:
> Indeed, the internal doc (stalin-0.7/README) expands the acronym:
>
> Stalin - a STAtic Language ImplementatioN
Regardless of where the name comes from, I don't think
it's a good name. Would you want to name a language Hitler?
This issue has been discussed in comp.lang.lisp at some length.
(As for me, I don't see that a compiler named "Stalin" furthers
purges, mass starvation, etc. I find that the Stalinist policy
of forced industrialisation relates rather well to an aggressively
optimising compiler. Besides, the more harmless "Stakhanov" or
so would hardly make acronymic sense, and it would lack the flair.
-- No, I wouldn't want to name a language (nor a compiler) "Hitler".)
rthappe
Rolf-Thomas Happe
rth...@leonce.mathematik.uni-freiburg.de (Rolf-Thomas Happe) writes:
> file, provided the code stays away from Scheme's dynamic features:
> LOAD, EVAL, and the like.)
I can't do without those dynamic features. What am I doing wrong?
You probably do other things than the people willing to trade some
dynamism for better efficiency. That you can't do without LOAD, ...
doesn't imply that all other people can do without supreme efficiency.
Different needs, different tools.
rthappe
pat...@c837917-a.potlnd1.or.home.com
It would seem like in the future a system like STALIN would be able to
perform a static analysis of a partial program. It would seem like the
application developer would be able to specify where the system should
remain dynamic and where it can be statically analyzed.
Jason Trenouth
>
> Hi, I'm looking for information about functional languages. It looks
> like something that might be interesting to play with a bit... So,
> the question is, where to start, as there seem to be a number of
> implementations that have various features. Can anyone recommend a
> good source of comparison information, possibly keeping in mind these
> things:
>
> I want something that has a free (open source) implementation (OCAML
> is out, for instance, because the implementation is not free
> software).
>
> I want something that may have some practical applications - a niche,
> maybe, that isn't too small, where it shines.
>
> I want something that is not too hard to get a handle on (ie,
> sufficient documentation, decent sized user community..).
>
> I don't really need to be told "this is the best because of blah blah"
> - I'd rather read some good comparisons, and hear about features, and
> draw my own conclusions.
>
> Thanks,
Take a look at Dylan: http://www.gwydiondylan.org/
__Jason
Rolf-Thomas Happe
It would seem like in the future a system like STALIN would be able to
perform a static analysis of a partial program. It would seem like the
application developer would be able to specify where the system should
remain dynamic and where it can be statically analyzed.
Not the very near future, I guess. The Stalin compiler at least is a
one man part time effort (if this hasn't changed by now).
rthappe
Fergus Henderson
>dav...@prosa.it (David N. Welton) writes:
>> Matthias Blume <bl...@kurims.REMOVE.kyoto-u.ALLCAPS.ac.PARTS.jp> writes:
>>
>> > Jacques Garrigue writes:
>> >
>> > > Finally I believe that if one believes in freedom, (s)he should also
>> > > believe in the freedom to define it.
>>
>> Well, certainly, but a large bunch of people have defined it in a
>> certain way, and OCAML doesn't meet the grade, unfortunately.
>
>It's not really this black and white. Can you name ONE supposedly
>free software license that doesn't have a bunch of people who don't
>consider it to be free? Certainly the GPL doesn't meet the grade.
>Nor does the BSD license.
Sure, BSD-style without the advertising clause. If you want a concrete
example, the license for the Boehm (et al.) conservative garbage
collector. Or public domain, for that matter.
GPL advocates criticise BSD-style licenses because they don't
ensure continuing freedom of all derivative code. But they
don't say that code licensed under BST-style license (without
the advertising clause) or public domain code is not free.
>It's all about compromises.
Yes, but some compromises are better than others.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Andrew Koenig
Fergus Henderson <f...@cs.mu.oz.au> wrote:
> GPL advocates criticise BSD-style licenses because they don't
> ensure continuing freedom of all derivative code. But they
> don't say that code licensed under BST-style license (without
> the advertising clause) or public domain code is not free.
I think you're mistaken.
My understanding, for example, was that the FSF has refused
to distribute the Icon programming language implementation
because it is public-domain code and therefore not under their
definition of `free.' Similarly, they objected to Keith Gorlen
incorporating their regular-expression library into his C++
class library, because as a government employee, Keith is required
to put his work in the public domain.
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Lynn Winebarger
He's correct. If you look at the "categories of free software" on the
GNU web page, you'll see that public domain counts as free. However, it
can't be effectively GPL'ed (since there is no copyright), so that might
be a reason for their not distributing Icon. Also, I _think_ the
regular expression library is under GPL (not LGPL) which means anything
it's linked to has to be GPL'ed.
Lynn
Fergus Henderson
>I have asked people at INRIA through the mailing list to explain the
>intention of this licence. Xavier Leroy was so kind to shed some light
>upon this [...]:
>
>---------------------------------------------------------------------------
> What the INRIA license states (not very clearly, I agree), is that
> public distribution of modified versions is allowed in the form of
> source diffs only. Other forms of distribution (in particular as
> precompiled binaries) require prior authorization from INRIA.
>
> The intent of this clause is to prevent "unfair" reuse of OCaml code
> in projects that could be harmful to the whole OCaml effort. e.g. in
> competitors' projects.
Hmmm, do you think the maintainers of GNU Emacs ever considered XEmacs to
be a competing project? Do you think the maintainers of GNU Emacs were
happy about that development split? And do you think we ever would have
gotten a user-friendly menu-driven GUI version of Emacs without it?
Do you think the maintainers of GNU C ever considered EGCS to be a competing
project? Do you think they were happy with that development split?
And do you think we would have a decent free C++ compiler now without it?
I don't know the answers to these questions.
But I can make some good guesses.
mo...@miss.wu-wien.ac.at
> You've missed the point. A license like the GPL allows all kinds of
> side development that might or might not seem promising to anyone "in
> the know". Whether or not a particular development is worthwhile is not
> the question. The question is whether or not the overall ability to
> freely develop on the base knowledge would result in better software.
> And I tend to think it would. For the same reasons that publishing
> papers that allow anyone to build on what's been published encourages a
> wider academic developments.
> That said, I think it's pretty horrific to see this sort of
> judgement from on high regarding java. I'm not a java fan myself, but I
> still don't see it as your (or anyone else's) place to say that it's
> just "trash for the masses." It's this sort of short-sighted looking
> down the nose that gives academics a bad name.
As was already said, anyone may take a look on the code of OCAML and
learn from it. This is fine.
My criticism about JAVA is not so much related to the language itself
(although there would be enough to say about this) - rather to the
movement behind. Industry is just trying to make it a "standard language"
(if it has not already succeeded by now). This is really bad. The next
software crisis is "programmed" with this hype and I think it would
be a bad idea to support this movement with means to achieve its goal
even faster.
If any commercial firms were trying to develope a "good" language (=
with the intention to make life easier for programmers and users), but
they didn't have the know-how, I think it would be ok to support them
with such code. But in the case of Java, industry would without mercy
just exploit the effort of a lot of people to make more money.
> First, I'm not a user of OCAML (or ML at this point). While I might
> use OCAML to learn how to use it (and ML does look very interesting),
> I wouldn't base any software on it until there was a truly free compiler
> for it. For example, I wouldn't distribute software that used Chez
> Scheme specific features, precisely because of this problem.
I have so far never found any point in the licence which restricts my
intentions as a programmer and I can hardly imagine that people need a
different licence so desperately. If you have a better idea for a licence,
then tell us - INRIA might change it.
> Don't know what OLabl is. And once again, I don't see why you (or
> INRIA) should get to judge whether a given product is bad.
"Bad" can be used in a normative and a rational way. In the latter case it
just sums up clear points of technical shortcomings (there are quite some
about Java). In the first case it can also involve normative judgements
as I used above (I consider hype creation about a "technically bad"
product as irresponsible).
By the way: OLabl is a dialect of OCAML - it's distributed as binary
although it's not a product of INRIA. As you can see, it isn't this
difficult to get permission of INRIA.
Here a link:
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl
> But that isn't sufficient ("this specific version"). What would be
> sufficient is if users could then freely work on it (without
> permission-seeking), and incorporate it into other (equally free)
> software. While I don't doubt that there aren't many people who
> currently have the competence to write their own version of OCAML, if
> there were a free version available, you might see more widely
> distributed software based on it, and eventually some people would gain
> that competence. (By "based on it", I'm including software written in
> OCAML).
You shouldn't forget that there is no fair competition on most software
markets - this includes languages. So what about the "free" software you
are talking about? Even if the commercial firms would have to distribute
their compilers in a free way because of components taken e.g. from
OCAML, they would still make a lot of money with the "rest" (books,
consulting,...) Thus, languages like OCAML would at some point vanish
from the scene, because industry will not let these developments replace
their products. I speak from (sad) experience: one of our professors
(a very commercially oriented head of a department) was asked, why we
didn't teach functional languages. Answer: industry doesn't need it
(want it). He didn't even listen to other arguments.
> The fact that it a product is freely modifiable and reusable is of
> interest to everybody, even if they do not directly take advantage of
> it, because it opens that software to all the benefits of real
> competition (in the intellectual sense) and cooperation (as it usually
> turns out in practice). Of course, I also consider preserving these
> freedoms to be worthwhile in their own right, regardless of how many
> folks actually take advantage of them.
Agreed. But who would have in the case of another licence of OCAML have
the "profit"? People who want to use OCAML or firms that want to sell
other products? And in the long run: will it be more profitable for
all people if developments like OCAML are squished under the wheels
of industry?
Craig Brozefsky
> from the scene, because industry will not let these developments replace
> their products. I speak from (sad) experience: one of our professors
> (a very commercially oriented head of a department) was asked, why we
> didn't teach functional languages. Answer: industry doesn't need it
> (want it). He didn't even listen to other arguments.
I think that's a cue to get the hell out of that place. It's not
interested in giving you an education, it is interesting in having you
pay tremendous sums to be trained the way some corporations want you
to be trained for their own profit. I suppose this is becoming a more
prevalant mindset in higher education, but there are certainly still
universities where this is not the mode of thought. Really, if you
want a vocational education, I'm sure you can get it alot cheaper than
what a university is gonna charge you.
Do you really want to be trained in whatever the current top dawg
companies call real programming languages, so that in 5 years when
they release their next "hot thang" language you're left high and
dry.
--
Craig Brozefsky <cr...@red-bean.com>
Less matter, more form! - Bruno Schulz
ignazz, I am truly korrupted by yore sinful tzourceware. -jb
The Osmonds! You are all Osmonds!! Throwing up on a freeway at dawn!!!
kin...@sp2n21.missouri.edu
Andrew Koenig <a...@research.att.com> wrote:
>
>In article <7ffbdd$loi$1...@mulga.cs.mu.OZ.AU>,
>Fergus Henderson <f...@cs.mu.oz.au> wrote:
>>
>> ensure continuing freedom of all derivative code. But they
>> don't say that code licensed under BST-style license (without
>> the advertising clause) or public domain code is not free.
>
>
>My understanding, for example, was that the FSF has refused
>to distribute the Icon programming language implementation
>because it is public-domain code and therefore not under their
>definition of `free.'
Perhaps I'm confused. I would have thought that the FSF doesn't
distribute Icon because it has a (non)-license that could lead to
incompatibilities with the GPL, which is the license they prefer (or
insist on?) in their software distributions. What does that have to
do with the definition of "free"?
>Similarly, they objected to Keith Gorlen
>incorporating their regular-expression library into his C++
>class library, because as a government employee, Keith is required
>to put his work in the public domain.
And this kind of problem is probably why the FSF probably didn't want to
take on ICON. Linking against (or incorporating) the FSF regular-
expression library makes requirements on the resulting code because of the
way the (L)GPL works. As you point out, code produced by a US Government
employee might not be able to be released under a license consistent with
the (L)GPL. What does that have to do with freeness? Just because you
can't fulfill the terms of the license doesn't mean you have the ability
to ignore it.
Of course, you could argue that the GPL and the LGPL were silly things
for the FSF to create in the first place, but once code is so licensed,
the behavior of the FSF doesn't seem to me to be any different than I
would have expected.
Not all free software is distributed by the FSF (some would add: Thank
God), and why should it be? But the free software that *is* distributed
by the FSF does have a license that arguably fosters the development of
more free software. And, Lord knows, people do argue about this.
But that's okay; as more and more software is released, we will get more
and better evidence about what licenses really do best encourage the
development of free software, or whether enough people care about free
software to make much of a difference. Similarly, we'll find out whether
hardware companies that release programming specs under the terms
preferred by outfits like the XFree86 Project Inc do better or not in the
marketplace.
Me, I have no idea how this will all work out or what the best policy
really is, although I do have my opinions and preferences. What I *do*
know si that the current discussion has Zero to do with functional
languages, so I've set the follow-ups to gnu.misc.discuss.
jking
Klaus Schilling
> I have so far never found any point in the licence which restricts my
> intentions as a programmer and I can hardly imagine that people need a
> different licence so desperately. If you have a better idea for a licence,
> then tell us - INRIA might change it.
I suggest the GNU GPL, the best of all possible licenses. But the INRIA
is most likely deaf on that ear, especially ever since Alain Bensoussan
is no longer boss over there.
Klaus Schilling
mo...@miss.wu-wien.ac.at
> mo...@miss.wu-wien.ac.at writes:
>> from the scene, because industry will not let these developments replace
>> their products. I speak from (sad) experience: one of our professors
>> (a very commercially oriented head of a department) was asked, why we
>> didn't teach functional languages. Answer: industry doesn't need it
>> (want it). He didn't even listen to other arguments.
> I think that's a cue to get the hell out of that place. It's not
> interested in giving you an education, it is interesting in having you
> pay tremendous sums to be trained the way some corporations want you
> to be trained for their own profit.
The university I was talking about is in Austria - Austrian students don't
have to pay the universities for education. This does not necessarily
mean that the education is bad, but unfortunately our system makes it
quite easy to let incompetent and "commercially (=they want to make
money) oriented" (this often goes together) people accumulate at the top
(e.g. professors cannot be fired unless they do something criminal).
I do not want to generalize this, because this would be unfair to many
researchers and university teachers who try their best in their field.
But it is a bitter reality...
Having unsuccessfully tried really hard for one year to introduce
functional programming at a large university department has taught me that
rational arguments which, of course, favour FP are completely useless.
Unless you can make quick money (better: more money) with it or unless
incompetent managers (professors) get fired, people in the "real world"
won't look at it.
> I suppose this is becoming a more
> prevalant mindset in higher education, but there are certainly still
> universities where this is not the mode of thought. Really, if you
> want a vocational education, I'm sure you can get it alot cheaper than
> what a university is gonna charge you.
This certainly strongly depends on the country/university you look at. I
know that there are places where it is not this severe (I am trying to
get to one... ;-)
> Do you really want to be trained in whatever the current top dawg
> companies call real programming languages, so that in 5 years when
> they release their next "hot thang" language you're left high and
> dry.
Another problem is the mentality of students / programmers. There is a
certain inclination to follow the latest trend which is not necessarily
the best one. A problem combined with this one is that they want to
produce things that "look great". Customers demand this. To quote a
colleague who works as a consultant for an international IT-consulting
firm: "If it is colourful and if it moves, customers will buy it."
You will definitely not win many by explaining them what is cool about
side-effect-free programming.
mo...@miss.wu-wien.ac.at
> Hmmm, do you think the maintainers of GNU Emacs ever considered XEmacs to
> be a competing project? Do you think the maintainers of GNU Emacs were
> happy about that development split? And do you think we ever would have
> gotten a user-friendly menu-driven GUI version of Emacs without it?
> Do you think the maintainers of GNU C ever considered EGCS to be a competing
> project? Do you think they were happy with that development split?
> And do you think we would have a decent free C++ compiler now without it?
I am not sure whether we can compare these two developments with OCAML. I
would consider "OCAML" and most (all?) other functional languages as
quite "fragile": their "market share" is extremely small. If commercial
firms were allowed to just rip out all good stuff to brush up their
inferior products (in this case: Java compilers) this could well lead
to a problem. It could draw away the still low attention of the public.
If there is hardly any competition, this does not apply. E.g. I'd say
there is/was no real competition to Emacs - the split didn't hurt,
better: it helped the project. In the case of GNU C / EGCS: both are
just direct substitutes for commercial products and there are a lot of
better commercial C/C++-compilers. C/C++ (unfortunately?) wouldn't die
out if EGCS / GNU C ceased to exist. But if people used Java instead of
OCAML because of technology-transfer (OCAML->Java), I'd regard this as a
loss not only to the FP-community but to software development in general.
mo...@miss.wu-wien.ac.at
> mo...@miss.wu-wien.ac.at writes:
>> I have so far never found any point in the licence which restricts my
>> intentions as a programmer and I can hardly imagine that people need a
>> different licence so desperately. If you have a better idea for a licence,
>> then tell us - INRIA might change it.
> I suggest the GNU GPL, the best of all possible licenses. But the INRIA
> is most likely deaf on that ear, especially ever since Alain Bensoussan
> is no longer boss over there.
To state it right here at the beginning: I also believe that the GNU
GPL is a very clever licence which guarantees a great deal of freedom
to people and I would want to see it used even more often.
But thinking about the concerns of Xavier Leroy (that parts of OCAML
could be used in mainstream systems) shows me that in this case it
is not necessarily this easy. This could really harm their project,
because their intention is to provide an alternative to mainstream -
not to support it. We should not forget that what we want is to teach
more people the uncountable benefits of FP over IP.
The intention of the GNU GPL is to provide for a maximum degree of
"knowledge freedom". Overhyped mainstream languages are in my eyes in
conflict with this idea: they restrict the choice of the programmer.
There should be a way to provide a GPL-like licence to the general public
without this potential vulnerability to "mainstream attacks". I have to
admit, I don't know any better idea than to restrict the distribution
of modified binaries (-> to allow it only on request). Does anyone have a
better idea?
Best regards,
Markus Mottl
P.S.: In economics it is widely accepted that developing countries should
be allowed to be somewhat "protectionist" (= to restrict imports
of foreign goods). If this were not the case, foreign goods could
spill their markets and the local economy would never have a chance
to develope. I think that this is somehow analogous to OCAML/FP,
which are "developing languages" that should be allowed to be more
"protectionist".
Lynn Winebarger
<mo...@miss.wu-wien.ac.at> wrote:
>Lynn Winebarger <owin...@ezinfo.ucs.indiana.edu> wrote:
>As was already said, anyone may take a look on the code of OCAML and
>learn from it. This is fine.
>
>My criticism about JAVA is not so much related to the language itself
>(although there would be enough to say about this) - rather to the
>movement behind. Industry is just trying to make it a "standard language"
>(if it has not already succeeded by now). This is really bad. The next
>software crisis is "programmed" with this hype and I think it would
>be a bad idea to support this movement with means to achieve its goal
>even faster.
>
>If any commercial firms were trying to develope a "good" language (=
>with the intention to make life easier for programmers and users), but
>they didn't have the know-how, I think it would be ok to support them
>with such code. But in the case of Java, industry would without mercy
>just exploit the effort of a lot of people to make more money.
I'm having a little trouble seeing how commercial firms incorporating
GPL'ed code (and thus having to GPL the entire product) would be
exploiting the effort of a lot of people to make more money. I mean,
yes, they would try to make money off it, but as long as they
redistribute it with the same freedoms they recieved with it, I don't
think I'd call it "exploitation." It's probably still the most
effective way to get the code distributed.
I guess I don't see this as a battle of "standard languages" because
I consider trying to force use of one ("true") language as the best is a
wrong-headed thing to do in the first place. This applies whether or
not I think the language has merits over other languages in particular
or in general. That's why I'm not very sympathetic to this argument
that OCAML needs to be non-free to encourage its adoption. If you make
it good and free, it will be adopted by those who are willing and able
to use it. If people want to use Java, that's their business, not
anyone else's. (obviously, I'm not working in a corp, so I have
considerable latitude to say this ;-)).
>I have so far never found any point in the licence which restricts my
>intentions as a programmer and I can hardly imagine that people need a
>different licence so desperately. If you have a better idea for a licence,
>then tell us - INRIA might change it.
I can't distribute something under the GPL if there aren't freely
available (free in the sense of the GPL, or BSD-type if necessary)
compilers/interpreters , when there are plenty of languages with such
compilers. This is because not having the compiler available in the
same way can prevent users from using the source effectively. Consider
that if someone is trying to compile it for a platform that INRIA
doesn't provide support for, he adds the support for that platform, but
can't (very effectively) offer the changes to others (by offering both
source and pre-compiled binaries) without seeking permission from INRIA.
I consider that permission seeking to be unacceptable.
>"Bad" can be used in a normative and a rational way. In the latter case it
>just sums up clear points of technical shortcomings (there are quite some
>about Java). In the first case it can also involve normative judgements
>as I used above (I consider hype creation about a "technically bad"
>product as irresponsible).
But everybody knows that there's more to product selection than
technical merit alone. Do you (or INRIA) seriously think that people
will migrate to a functional language from an imperitave one simply
because better compiler technology exists? I don't. And I think it's a
mistake to try and force these conversions by withholding the compiler
technologies -- that's the sort of heavy-handed technique that makes
people _less_ likely to use the language. The only realistic way to
have someone start using a functional paradigm over imperative is to
educate them in both while they're students, so they'll be able to make
an informed decision.
Yes, I pretty much consider it to be a person's right to use a bad
product without being harrassed by people who think they know what's
best for them. I have a fundamental dislike of parochial attitudes.
>> But that isn't sufficient ("this specific version"). What would be
>> sufficient is if users could then freely work on it (without
>> permission-seeking), and incorporate it into other (equally free)
>> software. While I don't doubt that there aren't many people who
>> currently have the competence to write their own version of OCAML, if
>> there were a free version available, you might see more widely
>> distributed software based on it, and eventually some people would gain
>> that competence. (By "based on it", I'm including software written in
>> OCAML).
>
>You shouldn't forget that there is no fair competition on most software
>markets - this includes languages. So what about the "free" software you
>are talking about? Even if the commercial firms would have to distribute
>their compilers in a free way because of components taken e.g. from
>OCAML, they would still make a lot of money with the "rest" (books,
>consulting,...) Thus, languages like OCAML would at some point vanish
>from the scene, because industry will not let these developments replace
>their products. I speak from (sad) experience: one of our professors
>(a very commercially oriented head of a department) was asked, why we
>didn't teach functional languages. Answer: industry doesn't need it
>(want it). He didn't even listen to other arguments.
>
I'm not sure why making money with the rest is a bad thing, or why
INRIA would consider it part of it's job to protect the masses in this
regard. And I don't know why OCAML would vanish from the scene -
indeed, making a product GPL'ed virtually guarantees it will never die,
as long as someone wants to use it.
As regards your professor, maybe you should consider Indiana
University in Bloomington. I think you'd find the faculty's tastes more
to your liking here ;-).
>Agreed. But who would have in the case of another licence of OCAML have
>the "profit"? People who want to use OCAML or firms that want to sell
>other products? And in the long run: will it be more profitable for
>all people if developments like OCAML are squished under the wheels
>of industry?
How would it be "squished under the wheels of industry"? I mean,
it's not like it has wide spread adoption now. And it's already been
stated that OCAML would be incorporated into the main distribution of
Debian if its license were compliant with the DFSG. You don't think
that would be a bonus, considering CS students are often users of
GNU/Linux systems? It seems like that would help dissemination quite a
bit.
Lynn
Lynn Winebarger
<mo...@miss.wu-wien.ac.at> wrote:
>But thinking about the concerns of Xavier Leroy (that parts of OCAML
>could be used in mainstream systems) shows me that in this case it
>is not necessarily this easy. This could really harm their project,
>because their intention is to provide an alternative to mainstream -
>not to support it. We should not forget that what we want is to teach
>more people the uncountable benefits of FP over IP.
>
>The intention of the GNU GPL is to provide for a maximum degree of
>"knowledge freedom". Overhyped mainstream languages are in my eyes in
>conflict with this idea: they restrict the choice of the programmer.
>
the programmer (unless you're referring to corporate standards adoption,
in which case I'd say they still restrict the choice of programmer). I
don't see any benefit in exchanging one overhyped language for another,
regardless of various technical merits. It all sounds like "language
nazism" to me.
Lynn
Lynn Winebarger
<mo...@miss.wu-wien.ac.at> wrote:
>I am not sure whether we can compare these two developments with OCAML. I
>would consider "OCAML" and most (all?) other functional languages as
>quite "fragile": their "market share" is extremely small. If commercial
>firms were allowed to just rip out all good stuff to brush up their
>inferior products (in this case: Java compilers) this could well lead
>to a problem. It could draw away the still low attention of the public.
Frankly, I don't consider forking to be a major danger unless the
maintainers are unfriendly to patches (I believe this was the problem
that caused the fork in GCC) or the maintainers have difficulty
interacting with people (witness OpenBSD). Even if the maintainers were
somewhat averse to patches, I don't think you'd get a full-blown fork
until the language had a wide-enough base to support it. (What you
might get is one or two people who maintain a port to a machine, or
incorporate some nonstandard features, and try to keep their release in
sync with the official distribution).
>
>If there is hardly any competition, this does not apply. E.g. I'd say
>there is/was no real competition to Emacs - the split didn't hurt,
>better: it helped the project. In the case of GNU C / EGCS: both are
>just direct substitutes for commercial products and there are a lot of
>better commercial C/C++-compilers. C/C++ (unfortunately?) wouldn't die
>out if EGCS / GNU C ceased to exist. But if people used Java instead of
>OCAML because of technology-transfer (OCAML->Java), I'd regard this as a
>loss not only to the FP-community but to software development in general.
>
I think it's interesting to note that in the case of text editors,
Emacs (and vi for vi-lovers) has been around a very long time (I count
it as being around since it's original creation in the mid-70's) and has
been ported to FSF knows how many machines and used by most programmers,
though it's certainly not "hyped". It's availabilty and superiority
(for a certain class of users) have given it dominance. Likewise, vi
has been adopted by masses of programmers. What you have are
essentially two juggernauts, each of which represents its users think a
text editor should be (the barebones vi or the full-bodied Emacs). I
submit that this is very analogous to the situation with languages -
some people are going to prefer imperative, and no amount of arguing is
going to make them change their minds, and likewise with functional. If
you make a superior free implementation of your preferred paradigm
(OCAML in this case) the users you can hope to get will come to you.
The people who use imperative languages are not very likely to jump over
to functional languages just for the technology, so I see no reason to
prevent their enjoying the benefits of the compiler technology.
Lynn
Craig Brozefsky
> the programmer (unless you're referring to corporate standards adoption,
> in which case I'd say they still restrict the choice of programmer). I
> don't see any benefit in exchanging one overhyped language for another,
> regardless of various technical merits. It all sounds like "language
> nazism" to me.
^^^^^^^^^
Thank you, thread over, everyone back to their respective corners.
Jerzy Karczmarczuk
> * GPL advocates criticise BSD-style licenses because they don't
> * ensure continuing freedom of all derivative code. But they
> * don't say that code licensed under BST-style license (without
> * the advertising clause) or public domain code is not free.
>
> I think you're mistaken.
>
> My understanding, for example, was that the FSF has refused
> to distribute the Icon programming language implementation
> because it is public-domain code and therefore not under their
> definition of `free.'
...
Yes. Unfortunately. (See also Lynn Winebarger posting). Here's their
credo:
> | Public domain software is software that is not copyrighted.
> | It is a special case of non-copylefted free software, which means
> | that some copies or modified
> | versions may not be free at all.
>
> | Sometimes people use the term ``public domain'' in a loose fashion
> | to mean ``free'' or ``available gratis.'' However, ``public domain''
> | is a legal term and means, precisely, ``not copyrighted''. For
> | clarity, we recommend using ``public domain'' for that meaning only,
> | and using other terms to convey the other
> | meanings.
Yeeeaaaah! I always knew that not copyrighted is a special case of
non-copylefted... Now it is too late not only for Icon, but also for
Koran.
I must say that I am personally annoyed by all this legalese. Human
language is full of traps and paradoxes. The freedom to restrict
somebody else's freedom, the right to accord the rights, etc. -
there is no clear-cut solution to all those arguments which the
Americans call sometimes the "semantics", although it goes against
the true semantics of the word "semantics".
What should be underlined are the positive aspects of some initiatives.
For example Icon is a wonderful, useful language, made and
distributed by people who did everything they could in order to make
it freely accessible, easy to learn and to install. And Griswold is
a fabulous pedagogue! Playing with words and calling it "not free" is
silly and harmful.
I remember when Simon Peyton Jones was surprised when somebody put
forth the question about the legal status of Haskell. The authors
did not think about that, and THIS IS GOOD. When all the academic
software creators begin their work by hiring lawyers, it will be
the end of all. (It is worse than the perspective of having all the
clever people being hired by Microsoft).
Jerzy Karczmarczuk
Caen, France
******************************************************************
* Confucius might have said:
* "The people may divided into two distinct categories:
* = The members of the first, divide the people into two
* distinct categories;
* = Those belonging to the second one never do that, and claim
* that it is silly and harmful.
*
* Obviously, only the members of the second category are right!"
******************************************************************
Fergus Henderson
>I must say that I am personally annoyed by all this legalese.
Yes, indeed, the legalese is a pain. In many ways it would be much
better if everything was free by default, and legalese was required
only in cases where the intent was to restrict distribution.
However, that's not the way things are.
>I remember when Simon Peyton Jones was surprised when somebody put
>forth the question about the legal status of Haskell. The authors
>did not think about that, and THIS IS GOOD.
If not thinking about it meant that the Haskell implementations were
free, and would remain free, then not thinking about it would be good.
But unfortunately that is not the case. If freedom could be guaranteed
without the authors having to think about it, then not thinking about
it would be good. But that's just not the way it works.
>When all the academic
>software creators begin their work by hiring lawyers, it will be
>the end of all.
You don't need to hire a lawyer to make your software free.
If the software is in fact yours, then making it free is really very easy.
Tyson Richard DOWD
>I am not sure whether we can compare these two developments with OCAML. I
>would consider "OCAML" and most (all?) other functional languages as
>quite "fragile": their "market share" is extremely small. If commercial
>firms were allowed to just rip out all good stuff to brush up their
>inferior products (in this case: Java compilers) this could well lead
>to a problem. It could draw away the still low attention of the public.
This would be a shame, perhaps, but nowhere near as much of a shame as
if OCAML disappears, taking all the good stuff with it, never to be
seen again until someone reinvents the wheel.
IMHO far too many research projects die and take all the work done on
them with them. Far too many papers are published on systems that
several years later are completely abandoned. The source code remains
under a restrictive copyright, and so is useless to future researchers.
>If there is hardly any competition, this does not apply. E.g. I'd say
>there is/was no real competition to Emacs - the split didn't hurt,
>better: it helped the project. In the case of GNU C / EGCS: both are
>just direct substitutes for commercial products and there are a lot of
>better commercial C/C++-compilers. C/C++ (unfortunately?) wouldn't die
>out if EGCS / GNU C ceased to exist. But if people used Java instead of
>OCAML because of technology-transfer (OCAML->Java), I'd regard this as a
>loss not only to the FP-community but to software development in general.
I would hope that OCAML has more to offer the FP-community than a
few implementation features that can be transferred into Java.
If all OCAML has to offer to the FP community is technology that can
be transferred into other languages, then it's obvious that the language
itself is not important -- probably the best thing that can happen for
anyone is technology transfer. It would certainly save other
researchers working on other languages from re-implementing those
features.
If you are really concerned about one-way technology transfers, than GPL
your code. Anyone who takes your technology and uses it will have to
license their changes under the GPL so you can also use their changes.
--
Tyson.
Buday Gergely
> rth...@leonce.mathematik.uni-freiburg.de (Rolf-Thomas Happe) writes:
> > Indeed, the internal doc (stalin-0.7/README) expands the acronym:
> >
> > Stalin - a STAtic Language ImplementatioN
> >
> Regardless of where the name comes from, I don't think
> it's a good name. Would you want to name a language Hitler?
> in many ways, as bad as Hitler, but he was among the winners
> of the war.
>
> -- Lennart Augustsson
I agree.
But some people who spent their life in a democracy cannot imagine why does it
hurt other people that a program is called 'Stalin'.
Stalin made some million people starve and die, sent some million people to
GULAG, and occupied whole eastern Europe where democracy was just a dream for
40 years.
So, I don't like even to argue with those assholes who named 'Stalin' their
program.
- Gergely
Ketil Z Malde
> So, I don't like even to argue with those assholes who named
> 'Stalin' their program.
Then don't. Let's drop this, shall we?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
mo...@miss.wu-wien.ac.at
> This would be a shame, perhaps, but nowhere near as much of a shame as
> if OCAML disappears, taking all the good stuff with it, never to be
> seen again until someone reinvents the wheel.
> IMHO far too many research projects die and take all the work done on
> them with them. Far too many papers are published on systems that
> several years later are completely abandoned. The source code remains
> under a restrictive copyright, and so is useless to future researchers.
I don't know whether you follow the OCAML-mailing list. The developers
just mentioned that in the (very unlikely) case that INRIA stops the
development of OCAML, they would release the sources under a less
restrictive licence. This would allow other people to make full use of
their work (sources).
> I would hope that OCAML has more to offer the FP-community than a
> few implementation features that can be transferred into Java.
It certainly has ;-)
But speed of language implementations is also one of the criterias for
choosing a language. Why should INRIA want to have an even stronger
competition from the IP-side? The high speed of OCAML-compiled code and
the fast interpreter are definitely a big plus for people taking a look
at FP.
> If all OCAML has to offer to the FP community is technology that can
> be transferred into other languages, then it's obvious that the language
> itself is not important -- probably the best thing that can happen for
> anyone is technology transfer. It would certainly save other
> researchers working on other languages from re-implementing those
> features.
It seems you are not very convinced of OCAML ;-)
What a pity! It has indeed much to offer (not only the implementation
but also the language itself!)...
> If you are really concerned about one-way technology transfers, than GPL
> your code. Anyone who takes your technology and uses it will have to
> license their changes under the GPL so you can also use their changes.
This is not the problem - it's not only a question of source freeness
but we also try to promote the idea of FP. So why support a technology
(IP) we consider inferior?
Best regards,
Markus Mottl
Tony Finch
>ajen...@netway.com (Adam P. Jenkins) writes:
>>
>>Can you name ONE supposedly free software license that doesn't have
>>a bunch of people who don't consider it to be free?
>
>example, the license for the Boehm (et al.) conservative garbage
>collector.
It's also known as the MIT or X consortium license. The "beer-ware"
license is another.
Tony.
--
f.a.n.finch d...@dotat.at fa...@demon.net
Arthur: "Oh, that sounds better, have you worked out the controls?"
Ford: "No, we just stopped playing with them."
Neil Schemenauer
>f...@cs.mu.oz.au (Fergus Henderson) wrote:
>>ajen...@netway.com (Adam P. Jenkins) writes:
>>>
>>>Can you name ONE supposedly free software license that doesn't have
>>>a bunch of people who don't consider it to be free?
>>
>>Sure, BSD-style without the advertising clause. If you want a concrete
>>example, the license for the Boehm (et al.) conservative garbage
>>collector.
>
>It's also known as the MIT or X consortium license. The "beer-ware"
>license is another.
The Python license is very liberal. I don't know of anyone who
has a problem with it. The Perl artistic license is also very
liberal.
Neil
Ketil Z Malde
>> I would hope that OCAML has more to offer the FP-community than a
>> few implementation features that can be transferred into Java.
> It certainly has ;-)
> But speed of language implementations is also one of the criterias for
> choosing a language. Why should INRIA want to have an even stronger
> competition from the IP-side?
When learning about C++, there is one thing that stuck in my mind, and
that probably will stick long after C++ is dead and buried: Bjarne
Strostrup was aked why he decided to free C++, instead of
keeping it within AT&T. His answer was that AT&T was a lot larger as
a consumer of software than a manufacturer, and having the language
used as widely as possible would benefit them more than just using it
internally[0].
> The high speed of OCAML-compiled code and the fast interpreter are
> definitely a big plus for people taking a look at FP.
Of course, the first languages to borrow things would probably be the
closest family members - other FP languages.
> This is not the problem - it's not only a question of source freeness
> but we also try to promote the idea of FP. So why support a technology
> (IP) we consider inferior?
Why not? Or, more to the point, why not allow that technology to
evolve better by utilizing modern technology where appropriate?
I don't think Java and OCAML are much in competition, most people turn
to Java by default, and probably haven't heard of OCAML at all. I
think you'll agree that the number of projects considering both, and
ending up choosing OCAML because of performance, are negligible.
If mindshare is what it's about, why not release your code but require
an ad clause, akin to the BSD license?
-kzm
[0] Okay, we all know that the real reason was to trick their
competitors into wasting countless resources on their stone age
language. They're probably secretly using OCAML internally. :-)
Lynn Winebarger
Ketil Z Malde <ke...@ii.uib.no> wrote:
>I don't think Java and OCAML are much in competition, most people turn
>to Java by default, and probably haven't heard of OCAML at all. I
>think you'll agree that the number of projects considering both, and
>ending up choosing OCAML because of performance, are negligible.
Really, they actually turn to Java? I woulda thought C or C++ for
sure.
>
>If mindshare is what it's about, why not release your code but require
>an ad clause, akin to the BSD license?
>
Please, no. We'll never get a GPL'ed version then.
Frankly, I don't see much to be gained by the sort of "language
nazism" (ok, I've been flamed for using that "nazi" term before, but
it's in scare quotes. If there's a better term, let me know). All it
means is that someone has to go to the literature, implement what's
there, and then OCAML's code will be irrelevant anyway.
Lynn
Fergus Henderson
>mo...@miss.wu-wien.ac.at writes:
>
>> The high speed of OCAML-compiled code and the fast interpreter are
>> definitely a big plus for people taking a look at FP.
>
>Of course, the first languages to borrow things would probably be the
>closest family members - other FP languages.
Yes. I have an example of that kind of thing.
The Mercury implementation is released under the GPL/LGPL, which means
that other languages can borrow our implementation technology and adapt
it to their needs, with the confident knowledge that they won't need
our permission. The first language to make use of this is HAL, a new
constraint programming language currently being developed by a group at
Monash University.
The Mercury group and the HAL group do not share the same philosophy.
For example, we believe it is important to clearly separate pure and
impure code, whereas they are (I believe) not really concerned about
that issue. And I think we have different views about what is the
best approach to things like type inference and mode inference, and
about how much "distributed fat" is acceptable, and so on.
We in the Mercury group would certainly much prefer it if the HAL group
worked on extending Mercury to better support constraints, rather than
on developing a new programming language using Mercury's implementation
technology. But despite this, I think it is good that Mercury is
released under a license that allows the HAL group to do what they
are doing without our permission. We're all researchers in the same
general field, and although I don't agree with all of the HAL group's
decisions, what they research is up to them, and I think they should be
entitled to pursue their chosen line of research, even if that means
making use of the products of our group's research in ways that we did
not originally intend and which we might not agree with. Of course we
in the Mercury group strongly believe the _our_ way is the _right_ way,
but we don't have a monopoly on good ideas, and so we don't intend to
monopolize our implementation technology.
In the end, peer review and success in the marketplace of ideas,
or indeed even in the commercial market, is a much better judge
of quality and of usefulness to society than any one individual
or group can be.
P.S. I think Java is actually a pretty good language.
It has its flaws, certainly, but all languages have flaws,
and Java has a lot of advantages to make up for its flaws.
P.P.S.
I was happy to hear that initial benchmarking of the HAL implementation
has shown very good results.
mo...@miss.wu-wien.ac.at
> When learning about C++, there is one thing that stuck in my mind, and
> that probably will stick long after C++ is dead and buried: Bjarne
> Strostrup was aked why he decided to free C++, instead of
> keeping it within AT&T. His answer was that AT&T was a lot larger as
> a consumer of software than a manufacturer, and having the language
> used as widely as possible would benefit them more than just using it
> internally[0].
Certainly true for AT&T - but probably not for INRIA...
> Of course, the first languages to borrow things would probably be the
> closest family members - other FP languages.
Restricting the licence in such a way so as to prevent people from
exploiting the development effort of OCAML has of course the disadvantage
of making it difficult for other FP-developers to make immediate and
full use of this technology. But in such cases INRIA can give special
permission - and they do (e.g. OLabl).
>> This is not the problem - it's not only a question of source freeness
>> but we also try to promote the idea of FP. So why support a technology
>> (IP) we consider inferior?
> Why not? Or, more to the point, why not allow that technology to
> evolve better by utilizing modern technology where appropriate?
This is also a psychological/marketing question - unfortunately. Many
(mostly bad) programmers are very open to buzz words like "speed".
If they hear that there is some language implementation around which
is even faster than their newest JIT-compiler they are definitely more
likely to take a look at it. Or what do you think why Intel can sell
tons of their latest chip developments? - Definitely not because people
need more CPU-power to run their text processors...
> I don't think Java and OCAML are much in competition, most people turn
> to Java by default, and probably haven't heard of OCAML at all. I
> think you'll agree that the number of projects considering both, and
> ending up choosing OCAML because of performance, are negligible.
The word is spreading... and it's also the speed that attracts people.
As I said, the performance question is not so much a technical one.
No matter what fine technology you develope, if you don't succeed in
getting the attention of the public, it will vanish in the dust of
history. Even if you (and I) don't like it: people have to be attracted
with the words they like to hear (politicians do this every day).
They will definitely not listen to theoretic/rational arguments - I have
tried this too often just to see that it doesn't work this way. In the
case of FP we wouldn't even lie - from a technical point of view most
people here will probably agree that FP holds what IP+OO promises.
> If mindshare is what it's about, why not release your code but require
> an ad clause, akin to the BSD license?
Well, it's not my code (what a pity... ;-) and I don't work for INRIA.
But what concerns my source codes (not this good and not many), GPL is ok.
I am not a lawyer so I don't know whether this licence (BSD) would really
guarantee that the intentions of INRIA are filled. As was stated by INRIA,
they are open to proposals concerning a better licence. So if you know
the details of this licence variant, just post it to the mailing list -
maybe they like it...
> [0] Okay, we all know that the real reason was to trick their
> competitors into wasting countless resources on their stone age
> language. They're probably secretly using OCAML internally. :-)
Hm, maybe Sun has just made a strategically very clever move when they
hyped Java - do they want to leave their competitors playing with this
toy while they are doing research on FP instead? :-)
Ed Avis
>we also try to promote the idea of FP. So why support a technology
>(IP) we consider inferior?
Surely you want to give your competition a sporting chance. It's not
very convincing to withold useful code from your competitors, then
claim that FP is superior because it has these features and imperative
languages don't. After all, I'm sure that many ideas which originated
in imperative programming are useful for FP as well. (Interpreters
and optimizing compilers, for a start.)
Better to let as many people as possible use the technology, so it can
be refined and improved upon. But I'd guess that it would make the
most difference in FP, so you can still (fairly) point out advantages.
--
Ed Avis
mo...@miss.wu-wien.ac.at
> P.S. I think Java is actually a pretty good language.
> It has its flaws, certainly, but all languages have flaws,
> and Java has a lot of advantages to make up for its flaws.
Java is certainly a big step forward compared to C++ (which has a really
ill semantics). But the point, why I (and I guess this is true for many
other readers) am not very content with it is the hype going on around it.
There are quite some graduated computer scientists who have not the
slightest idea of what FP is about. I would say the reason is to a
large part that the FP-community speaks whereas "industry" shouts.
We are simply not heard!
To stay on topic: in order to approach our goal of bringing FP closer
to the "average programmer", it is necessary to develope appropriate
licences - licences which prevent industry from shouting even louder into
the "wrong" direction, but which let the users benefit from developments
in FP. This is certainly not an easy thing to do...
When we consider FP generally better than IP then this does not mean
that all implementations of imperative languages are necessarily bad
(in the technical sense of the word). But if we want that our opinion
is heard, there are just two possibilities:
* speak louder (dangerous - I don't want to hype FP; this could have
unwanted side-effects ;-)
* don't let industry shout too loud
mo...@miss.wu-wien.ac.at
>>we also try to promote the idea of FP. So why support a technology
>>(IP) we consider inferior?
> Surely you want to give your competition a sporting chance. It's not
> very convincing to withold useful code from your competitors, then
> claim that FP is superior because it has these features and imperative
> languages don't. After all, I'm sure that many ideas which originated
> in imperative programming are useful for FP as well. (Interpreters
> and optimizing compilers, for a start.)
We shouldn't create the impression that someone is withholding code /
technology. The source code is *freely* available! No doubt about this -
everyone can learn from it.
The question is, whether commercial enterprises may actually just
cut'n'paste the code into their projects. I think this is what INRIA does
not want to have. Otherwise the researchers would have to explain to
their superiors, why they "work" for industry - without any payoff for
their research (maybe the opposite if people keep using the commercial
products).
> Better to let as many people as possible use the technology, so it can
> be refined and improved upon. But I'd guess that it would make the
> most difference in FP, so you can still (fairly) point out advantages.
There is even an online CVS-repository for OCAML where you can get the
latest developer version:
And if you carefully read through the archive of the mailing list, you
will see that there are sometimes user contributions ("sometimes" only,
because compiler development is probably not common knowledge to most
programmers), which eventually find their way into the main-distribution.
Even if I wanted to distribute an own (binary) version of OCAML, INRIA
would probably grant the permission to do so. People who just want
to do research and try new methods on already well-developed systems
very surely do not have to fear that permission is refused. E.g. the
"O'Labl"-project: http://pauillac.inria.fr/olabl
Steven G. Johnson
> The question is, whether commercial enterprises may actually just
> cut'n'paste the code into their projects. I think this is what INRIA does
> not want to have. Otherwise the researchers would have to explain to
> their superiors, why they "work" for industry - without any payoff for
> their research (maybe the opposite if people keep using the commercial
> products).
So why not use the GPL, like gcc uses? (I assume by "commercial" you mean
"proprietary." Non-proprietary commercial use, similar to what Cygnus
does with gcc, would benefit you because you would get to see and use any
enhancements they make.)
Cordially,
Steven G. Johnson
PS. I am a happy user of OCaml (see http://theory.lcs.mit.edu/~fftw). Thanks!
mo...@miss.wu-wien.ac.at
> So why not use the GPL, like gcc uses? (I assume by "commercial" you mean
> "proprietary." Non-proprietary commercial use, similar to what Cygnus
> does with gcc, would benefit you because you would get to see and use any
> enhancements they make.)
Three points should be noted on this:
Cygnus produces a compiler for a main stream language. It's not a
problem for them if the competition makes use of e.g. new optimization
algorithms - simply because the competition cannot be cheaper than
Cygnus already is...
If a firm wanted to improve Ocaml (or help improving it), there
wouldn't be any problem for INRIA. But Ocaml is not main stream -
if competitors from this (= the main stream) side made direct use of
their algorithms (by copying the code), INRIA could get problems -
you shouldn't forget that it is a research institution that has to
report about the usefulness of their developments. If their intention
is to provide an alternative product (not just a substitute), they
are probably well-advised not to indirectly support the competition
(competition = producers of main stream products).
In the main stream market money is made with development environments,
books, consulting, etc... The competition would have a strong interest
in getting a better compiler if this could help them sell more of
the rest (Cygnus also has to earn money...). So GPL will definitely
not distract them from grabbing INRIA's code (to INRIA's possible
disadvantage).
Best regards,
Markus Mottl
> PS. I am a happy user of OCaml (see http://theory.lcs.mit.edu/~fftw). Thanks!
PS. That's fine!
By the way - I have just taken a look at "genfft": really nice! I like
the application of monads in your simplification algorithms...