jean-marc alliot wrote:
>
> John Max Skaller wrote:
>
> >
> > > > 1. Current functional languages do not have enough library support:
> > >
> > > Please. ocaml has the most wonderful standard library that any other
> > > language has ever had. Have a look in the reference manual before
> > > stating such non-sense.
> >
> > Oh come on. Have a look at a real library before making
> > such non-sense claims. Considerable functionality is missing,
> > the library is inconsistent, the documentation is incomplete,
> > and it is less generic than C++
>
> I don't think there are lot of things missing in the STANDARD library. I
> don't see why it is inconsistent. I don't see why documentation is
> incomplete. Things might be missing in the general library, yes.
The order of arguments is perverse. Obvious functions are missing,
such as finding the number of elements in a map. The documentation
fails to tell how fast the functions are, and the specifications are
sometimes imprecise.
> > Show me a functional programming language that is as fast
> > as C++ and I will give up C++. :-)
> >
> CAML. Just try programming the fibonacci function in both languages... -:)
:-)
> CAML becomes slow when you use some of the nice functional features of the
> language.
It's one heck of a lot slower using the imperative features,
and even slower using object oriented ones. My not very carefully
coded Python interpreter (which uses a combination of all these
features)
is at least 10 times slower than CPython.
Mind you -- it implements a much better language. :-)
> But if you write CAML as you write C code you won't lose much
> speed.
Sorry. You lose HEAPS. Even 10% is significant, CAML can
be over a decimal order of magnitude slower. C++ generics are
generally much faster (being automatically specialised -- which
also causes code bloat :-(
> Over the years, students and development programmers have developped
> thousand of lines of code in many different languages in my team and
> writing or rewriting in CAML had a limited impact on the speed of the
> program.
No doubt the compiler I'm writing in Ocaml will be fast enough.
But there is no way CAML will compete with the C++ code the compiler
generates.
[At least not the way the CAML bytecode interpreter is written]
> Again, I don't like religious opinions, but I am anyway going to explain a
> few things. I am sorry to use personal examples, but I know them very well
> -:)
> I understand that for highly time critical fragment of codes that are
> extremely closed to machine architecture, C is a reasonable choice.
> Even when
> the code is documented, the program is extremely complex, and when I stop
> working on it for a few months, it is almost impossible to re-enter the
> code. I am too old and too busy now to work on it anymore. And I don't like
> programs core dumping anymore either.
No dispute. [I'm an 'old' game programmer too]. I'd write
the main game play engine of a strategy game in ocaml in preference
to C/C++, but there's no doubt I do the graphics in C/C++.
There, every ounce of performance is absolutely critical.
> C should be only used by experienced programmers, who are extremely careful
> of everything they write, with unitary tests for each and every function,
> and only for time critical functions.
Sure. And that is what the company I work for does.
Almost all the code being written is time critical: when you're
talking huge volumes, every percentage point of extra performance
is a many percentage points of lower CPU costs.
> I am extremely sorry to say that I don't understand people using C++when
> they have a choice.
> This language is, according to me, a collection of every little thing that
> should never be done.
Sure: it is mainly a consequence of the abysmal base language, C.
>Templates are, from a theoritical point of view, a
> matter of laugh,
No. They're not perfect. They generate very fast code.
On the contrary, it is the boxed values of functional languages
which are the laugh: they kill performance.
> and generally not compatible between different compilers
> (I have examples every year with students coming back from training periods
> with programs written in C++, and who speend hours to make them compile
> with the University compilers and machines). For people knowing object
> theory and its EIFFEL implementation, the C++ object system looks at least
> shaky.
What object theory? There isn't one. Object orientation
is a mess. Eiffel is every bit as bad as C++ here: the fact is that
C++ trades off beauty and correctness for speed and compatibility.
It is faster than C though, and much easier to use.
> I could write endlessly about C++ problems ; I had to use it for a few
> years for development purpose, and, if I first began to like it, I soon
> learned to hate it.
So could I, I worked on the design of it :-)
> JAVA has corrected many problems, such as memory allocation or the infamous
> core dumping behaviour. But it is not that fast...
Java is rubbish. It is a compromise: bad type system, poor performance.
C++ is not a compromise: no features was added that compromised
performance.
> I went back to University to learn
> computer science when I was 26, and I had then lot of bad programming
> habits.
Sigh. I never wasted my time with so-called computer science.
I learned a lot more doing mathematics than any silly CS course. :-)
[This is more a reflection of the local academic institutions than
anything else :-(
> It took me a long time to understand that there were more proper ways to
> write programs.
Sure. And hopefully, that no one has the faintest idea what these
ways are. But at least now, theorists finally have a tool to begin
a serious study (category theory).
So I can put to you that Ocaml is a mish-mash and grab bag
of functional, imperative, and OO features, just like C++: C++ is
faster,
whereas Ocaml provides better -- but by no means perfect -- structure.
Remember -- I _like_ Ocaml. I do _not_ like C++.
I did my best to make it better, with little result.
But the fact remains, it is the language of choice for most applications
simply because it provides reasonable power, reasonable safety,
and there is an assurance that it can be as fast as you can bother
to take care to make it.
C++ breaks down with higher order problems, where Ocaml excels.
But it stands up to large scale programming of complex tasks, which
Ocaml does not. Most of the problems I encounter are annoying
implementation details such as the requirement to link things in order,
with lousy diagnostics when the order is wrong (why doesn't the
diagnostic tell me which module requires the one with the
'missing' implementation?)
So, in my view, Ocaml is reasonable for the purpose
I've been writing it -- compiler development. But it isn't
so hot at numerical programming, operating system interaction,
or high speed communications.
It would be nice to have some real genericity,
of the kind that FISh promises, or some real integration
of stateless (functional) and stately (object oriented),
programming, of the kind Charity promises.
-- 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
This archive was generated by hypermail 2b29 : Mon Apr 17 2000 - 21:18:38 MET DST