caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Max Skaller <skaller@ozemail.com.au>
To: fabrice.le_fessant@inria.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] RE: OCaml on CLR/JVM?
Date: Sat, 17 Feb 2001 03:54:48 +1100	[thread overview]
Message-ID: <3A8D5B58.436721C0@ozemail.com.au> (raw)
In-Reply-To: <14987.41596.904886.588474@cremant.inria.fr>

Fabrice Le Fessant wrote:

> There is an HUGE difference between open source and standards. The
> first one can always freely evolve, while being used freely by many
> users. Standardized ones cannot evolve anymore, or need the company
> agreement to be modified. Compatible software will always have to
> follow the company new developments, and thus will never be truely
> achieved. This is one of the -many- drawbacks of Java.

	I do not agree, although you seem to be using a wrong example.
Standardised systems can and do evolve. The evolution consists of
experiment, discussion and consensus formation, followed by
implementation
by many parties, followed by error reporting (Note I mean
errors in the specification: the 'standard')

	But what you describe as drawbacks of Java (with which I might
agree), but Java is _not_ a Standardised language, at least in the
sense of being approved by a standards processes within a recognized
standards body (such as ISO, IEC, ...).

> The problem is that .NET is a commercial product. So, the question is:
> should we spend our time porting Ocaml to all new commercial VMs (not
> only MS ones, of course) ? 

	Of course not. But .NET is being sponsored by a major player
and we can expect a significant number potential of Ocaml users.

	Please do not forget that programming is principally
a commercial activity, and that those of us who
indulge -- even part-time -- in research activities, is 
relatively small (and lucky :-)

 
> One time again, commercial issues have dominated scientific
> reasons.

	Of course: science requires funding: it too
is a commercial activity, it must compete, and it doesn't
always win the competition. :-)

> CLR has been released too early, and will be standardized too
> early, while big problems are still remaining: no polymorphism,
> object-oriented approach in the bytecode, ... This should have been
> discussed first, not in the next version !

	I agree.

> Of course, it won't change my mind. I will always think that public
> research and commercial research have different goals...

	Of course they do, because they differ in their funding models.
Generally, public institutions can be more long sighted than commercial
ones, whereas commercial ones have more dynamic growth patterns and
so must be more short-sighted.

	However, one should be rightly annoyed at larger corporations,
since they rival public institutions in size and stability, but seem
still
to lack the capacity for long term research. And perhaps this is partly
the fault of the public institutions for remaining too aloof from
the commerical world.

	I believe this creates a tension in which the commercial players
put pressure on public institutions (like ISO, academia), for a more
'commerical' approach. And perhaps one could ask how to best direct
pressure on those companies, to take a more long sighted view in return,
and work with the public intitutions better in the area of research.

	The only way I know how to do this is for those who see 
commerical merit in research to work in and for the commercial entities,
since they are organisations of people too. :-)

	To put this argument another way: we will do better to 
convince the commercial programmers of the world that the Ocaml way is
better if it is actually available on the platform they use to
implement commercial solutions. 

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  parent reply	other threads:[~2001-02-17  7:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-15  9:33 Fabrice Le Fessant
2001-02-15 10:19 ` Fabrice Le Fessant
2001-02-16 16:54 ` John Max Skaller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-03-05  6:00 Arturo Borquez
2001-02-23 16:33 Chris Tilt
2001-02-24 12:02 ` John Max Skaller
2001-02-16 19:06 Dave Berry
2001-02-16 21:16 ` Marcin 'Qrczak' Kowalczyk
2001-02-16 18:38 [Caml-list] " Dave Berry
2001-02-14  7:31 [Caml-list] " Don Syme
2001-02-14 19:44 ` Xavier Leroy
2001-02-09 22:05 Don Syme
2001-02-14 17:24 ` [Caml-list] " Anton Moscal
2001-02-16 15:45   ` John Max Skaller
2001-02-09 15:49 Dave Berry
2001-02-14 19:30 ` [Caml-list] " Xavier Leroy
2001-02-15 12:12   ` Sven LUTHER
2001-02-06  0:03 OCaml on CLR/JVM? (RE: OCaml <--> ODBC/SQL Server) Don Syme
2001-02-08 19:03 ` OCaml on CLR/JVM? Xavier Leroy
2001-02-09  9:06   ` David Mentre
2001-02-14 19:32     ` [Caml-list] " Xavier Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A8D5B58.436721C0@ozemail.com.au \
    --to=skaller@ozemail.com.au \
    --cc=caml-list@inria.fr \
    --cc=fabrice.le_fessant@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).