caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Chris Tilt <cet@webcriteria.com>
To: "'John Max Skaller '" <skaller@ozemail.com.au>,
	"'fabrice.le_fessant@inria.fr '" <fabrice.le_fessant@inria.fr>
Cc: "'caml-list@inria.fr '" <caml-list@inria.fr>
Subject: RE: [Caml-list] RE: OCaml on CLR/JVM?
Date: Fri, 23 Feb 2001 08:33:47 -0800	[thread overview]
Message-ID: <6B2758E78474D411958F00D0B78906006A689B@kenny.gaggle> (raw)

 This is a valuable discussion and I appreciate both views
on the subject. I am using OCAML in a commercial development
with great success and continue to benefit from the excellent
work by the research community. The OCAML team and it's
contributors have always been friendly and helpful to industry.

In addition, we have employed recently a prominent researcher
in functional programming. It was very valuable for both our
commercial entity and the visiting researcher to share perspectives
in a collaborative environment. We gained insight and high
quality code while the researcher gained an inside view into
the needs and activities of a recent commercial effort where
functional programming has strong merit.

On the subject of who leads long term research (industry vs.
institutions), I am dissapointed with the lack of functional
programming exposure taught in undergraduate studies. It is
very difficult to find programmers who have any history at
all with this approach.

Until institutions give equal time to functional, industry
will be unaware of it. Further, research funding in that
area will suffer. Microsoft, etc., will have no pressure to
support it in work such as .NET. To my understanding, there
were functional programmers employed on that project, but
the pressure from industry is too small to influence the
outcome.

The process of adopting long-term a functional approach is
going to be slow, but can be sped up if institutions produce
graduates who have higher expectations of productivity
through exposure to modern languages. I will help in any way
that I can as I feel much appreciation to this community
for our success, however it must start in education.

Thank you for listening.

-Chris

http://www.webcriteria.com

-----Original Message-----
From: John Max Skaller
To: fabrice.le_fessant@inria.fr
Cc: caml-list@inria.fr
Sent: 2/16/01 8:54 AM
Subject: Re: [Caml-list] RE: OCaml on CLR/JVM?

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
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


             reply	other threads:[~2001-02-24 17:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-23 16:33 Chris Tilt [this message]
2001-02-24 12:02 ` John Max Skaller
  -- strict thread matches above, loose matches on Subject: below --
2001-03-05  6:00 Arturo Borquez
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-15  9:33 [Caml-list] " Fabrice Le Fessant
2001-02-15 10:19 ` Fabrice Le Fessant
2001-02-16 16:54 ` John Max Skaller
2001-02-14  7:31 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=6B2758E78474D411958F00D0B78906006A689B@kenny.gaggle \
    --to=cet@webcriteria.com \
    --cc=caml-list@inria.fr \
    --cc=fabrice.le_fessant@inria.fr \
    --cc=skaller@ozemail.com.au \
    /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).