Re: Java, and so?...

Markus Mottl <>
4 Mar 1999 12:15:06 -0500

          From comp.compilers

Related articles
Java, and so?... (Denis Bredelet) (1999-03-02)
Re: Java, and so?... (Derek Ross) (1999-03-04)
Re: Java, and so?... (1999-03-04)
Re: Java, and so?... (Markus Mottl) (1999-03-04)
Re: Java, and so?... (Greg Haynes) (1999-03-09)
| List of all articles for this month |

From: Markus Mottl <>
Newsgroups: comp.compilers
Date: 4 Mar 1999 12:15:06 -0500
Organization: University of Economics and Business Administration, Vienna, Austria
References: 99-03-006
Keywords: Java

Denis Bredelet <> wrote:
> Do you think it's fair that Java is the only competitor in its
> category? It *does* have many advantages, and I'm wondering why I
> don't have a choice when I need a Write Once-Run Anywhere,
> cross-platform, industry-elected (...) high-level language that
> doesn't make me amazed by its strangety.

Especially, because you are from France, you should definitely take a
look at OCAML, which is developed by INRIA (Institut National de
Recherche en Informatique et en Automatique).

Address (for OCAML):

This language is very high-level (certainly much higher-level than JAVA),
because it is a functional language. The programming environment features:

  * interpreter
  * byte code compiler
  * native code compiler
  * portability to many, many platforms/architectures
  * debugger (seldom needed - it's quite easy to write correct programs
      in OCAML in comparison to imperative languages)
  * profiler
  * scanner generator (if you want to do string processing you are
      probably interested in that).
  * LALR(1) - parser generator
  * good libraries (also for string processing)
  * good documentation
  * ... and much more than I could ever tell you ...

The compiler (and the interpreter, too) are *incredibly* fast - not only
what concerns compilation speed, but also the resulting code. It easily
leaves JAVA in the dust and the native code can sometimes even beat C/C++
for the same algorithm (honestly).

> Other question : what would you suggest to ease the linking and the
> modularity of a language? For now, I'm still thinking of C-like
> #include model...

Do yourself a favour and forget the "#include" model. Its invention/use
as a means of creating modularity was probably one of the most brain-dead
deeds in the history of programming languages.

OCAML has (IMHO) at the moment the best module-calculus you can get. It
fully preserves seperate compilation, even allows inlining across modules
(where appropriate) and still has the full power of parameterization
(via functors).

But the best about the language (programming environment): you can have
it for free! Even for commercial purposes! Including the sources!

> Another one : Do you know a powerful, simple and elegant way to manage
> strings? I'm looking at Perl, but I feel it isn't well-suited for
> generic languages.

PERL is certainly hard to beat when it comes to string processing. But
it is a real pain for large projects, even more so if these require
complex data structures. If you want to do something big, use OCAML
instead. The "Str"-library allows regular expressions for string
matching and if you have some heavy-duty tasks, you can always rely on
the scanner generator (ocamllex), which produces *very* efficient

> Last but not least, I'll have to think about graphics and
> presentation... Any references?

Here a nice little OCAML-program drawing different (random size and color)
circles all over a window until a key is pressed ;-)

    open Graphics
    open Random

    let main () =
        open_graph "";
        let sx, sy = size_x (), size_y () in
        let maxr = min (sx/2) (sy/2) and maxc = 256 in
        while not (key_pressed ()) do
            let x, y, r, color = int sx, int sy, int maxr,
rgb (int maxc) (int maxc) (int maxc) in
            set_color color; fill_circle x y r

    let _ = Printexc.catch main ()

Short and clear enough?

Best regards,
Markus Mottl
Markus Mottl,,

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.