caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Max Skaller <skaller@ozemail.com.au>
To: Dave Berry <dave@kal.com>
Cc: Markus Mottl <mottl@miss.wu-wien.ac.at>, OCAML <caml-list@inria.fr>
Subject: Re: JIT-compilation for OCaml?
Date: Fri, 12 Jan 2001 19:23:32 +1100	[thread overview]
Message-ID: <3A5EBF04.FF4B72E0@ozemail.com.au> (raw)
In-Reply-To: <3145774E67D8D111BE6E00C0DF418B663AD717@nt.kal.com>

Dave Berry wrote:
> 
> By "component", I mean an object with methods, asynchronous events, and
> settable properties, working in containers that know how to embed these
> components.  The origin of this approach was (I think) the Andrew project at
> CMU, many years ago.  ML modules are different.

	OK. I think we'd agree roughly on what a 'component' is.

> As for whether these are "right" or "wrong", this depends on whether you
> want to work in a small purist community or interact with the wider world.

	That isn't how I see it. Pragmatically, we must use available
technology, even if it is faulty, since _all_ the available technology
is faulty.

	For me, the issue is to recognize the flaws, and work 
towards fixing them, or finding a better solution -- probably at 
the same time as continuing to use better understood but flawed
technology when the commerical risks don't justify trying something
more experimental.

	To this end, I can understand why you might choose Java 
as an implementation language: but I think a large part of that choice
is driven by non-expert perceptions (of, for example, shareholders and
clients), rather than by technical evaluations.

	Perhaps by expertise biases my opinion. For example,
a lot of Windows code is developed using MFC, which I believe
is pretty bad. I'd never bother, since I can develop similar but
better functionality as required more quickly than learn the
quirks of an ugly system.

	Except in the case of applets, I'd never use Java,
since I know C++ well enough that I'd gain almost nothing
from it's 'advantages', and lose a lot of the advantages
of C++. More likely, I'd use Ocaml if at all possible :-)

> To date, OCaml has emphasised interoperability (e.g. with C), which is one
> of the reasons that its been successful.

	Yes, I agree. And this is one of the major components
of the design of C++: it is simultaneously a strength and a serious
weakness. My Felix language generates C++, but provides a saner
syntax/semantics (at least, that is the idea); it provides
much better interoperability than Ocaml. Some things are lost
of course!

	 But Java is not compatible with C or C++, so there was no need 
to make a language with so many of the faults it has. IMHO. :-)
Instead, the designers should have looked at the kinds of languages
researchers were working with (like ML), and provided as version of
them with a 'simplified' syntax. At least that's what I would have done,
(and indeed _is_ what I'm doing with Felix :-)

-- 
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



  reply	other threads:[~2001-01-12  9:17 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-11 12:45 Dave Berry
2001-01-12  8:23 ` John Max Skaller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-01-09 17:18 Dave Berry
2001-01-11  7:00 ` John Max Skaller
2001-01-11 10:01   ` Alain Frisch
2001-01-12  7:55     ` John Max Skaller
2001-01-09 17:09 Dave Berry
2001-01-11  6:38 ` John Max Skaller
2001-01-03 15:24 Jerry Jackson
2001-01-04 14:12 ` Alan Schmitt
2001-01-02 16:07 Markus Mottl
2001-01-02 18:16 ` Mattias Waldau
2001-01-02 19:30   ` Markus Mottl
2001-01-03 12:15     ` Alain Frisch
2001-01-04  8:37       ` Fabrice Le Fessant
2001-01-04  9:04         ` Alain Frisch
2001-01-03 13:23     ` Mattias Waldau
2001-01-03 14:25       ` Markus Mottl
2001-01-03 14:40       ` STARYNKEVITCH Basile
2001-01-03 15:51     ` John Max Skaller
2001-01-03 17:50       ` Markus Mottl
2001-01-05  0:30         ` Michael Hicks
2001-01-08  9:59           ` Xavier Leroy
2001-01-09  6:40         ` John Max Skaller
2001-01-03 17:49     ` Joseph R. Kiniry
2001-01-03 18:19       ` Markus Mottl
2001-01-03 18:38         ` Joseph R. Kiniry
2001-01-03 18:58           ` Markus Mottl
2001-01-03 19:06             ` Joseph R. Kiniry
2001-01-04 22:32               ` Jonathan Coupe
2001-01-07  0:16                 ` Chris Hecker
2001-01-05 12:52               ` Sven LUTHER
2001-01-05 20:08                 ` Joseph R. Kiniry
2001-01-09  7:14             ` John Max Skaller
2001-01-09  6:50         ` John Max Skaller
2001-01-05 12:39   ` Sven LUTHER
2001-01-05  5:48 ` Vitaly Lugovsky

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=3A5EBF04.FF4B72E0@ozemail.com.au \
    --to=skaller@ozemail.com.au \
    --cc=caml-list@inria.fr \
    --cc=dave@kal.com \
    --cc=mottl@miss.wu-wien.ac.at \
    /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).