caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* RE: When functional languages can be accepted by industry?
@ 2000-04-17 12:57 FALCON Gilles FTRD/DTL/LAN
  2000-04-17 15:35 ` Xavier Leroy
  0 siblings, 1 reply; 67+ messages in thread
From: FALCON Gilles FTRD/DTL/LAN @ 2000-04-17 12:57 UTC (permalink / raw)
  To: 'John Max Skaller'; +Cc: caml-redistribution

translation after:

Je suis aller suivre un cour Java la semaine dernière, je dois dire
que l'on sent tout de suite la taille de la communauté derrière ce langage.
La documentation est quelque chose qui existe, les librairies pour
faire de l'informatique de gestion aussi (SGBD, gestion de la machine,
IHM, ...)
Trouver un livre sur java autre que la documentation de référence,
c'est possible,  un livre sur Ocaml, non.
La documentation de l'inria est bien mais insuffisante (elle n'offre
qu'un point de vu, chose qui ne gène pas quand on a eu des cours sur
le sujet, certes).

D'autres petits détails :
  L'interface graphique: pour ceux qui aime camltk, c'est apprendre tcl
avec (pour les exemples) puis faire le tri entre ce que propose le
langage graphique, ce qui est implémenté avec caml et ce que l'on
envisage d'ajouter.(et toujours une documentation qui renvoie vers une
autre doc)
  On veut generer un programme documenté,
     avec java il y a tout ce qu'il faut déja configuré
     avec ocaml, on peut faire du "literate programming",
     mais il faut se faire une configuration (rien n'est proposé en standard)
  On a besoin de quelques choses, avec java on cherche d'abord dans la
documentation, ou on regarde s'il n'y a pas quelque chose de fait et
on a de forte chance de trouver. Avec Ocaml, beaucoup moins

Globalement les gens qui développent en ocaml me donne le sentiment
qu'ils maîtrisent plutôt bien les concepts informatiques, théorie
des langages ainsi que les utilitaires à coté pour palier à ce
qui n'est pas fourni en standards; qu'en à ceux qui ne sont pas issu
de cette souche il semble avoir été sauvagement oublié.

J'aime bien Ocaml, le style fonctionnel est sympa, il est possible de
faire de l'impératif et de l'objet.
Une chose est certaine, s'il y avait un plus pour l'interface graphique
et les connections aux sgbd (dans un monde idyllique, le tout bien
documenté) il serait plus facile d'utiliser ocaml dans plus de projet.


Last week, i learn java and i feel the community behind this language,
The documentation is something real. You have library for SGBD acess,
the I/O, the graphics.
You can find a book easily on java, not on ocaml. Inria documentation
is fine, but with only one point of view.
Some other details:
The IHM : if you like camltk, you learn tcl too ( for the example)
  after, you have to look between the graphics language possibility,
what you can access with caml and eventually  what you would like to
add ( naturaly the documentation send you on an other documentation)
 We want to have generated documentation
   with java, no configuration to do: javadoc
   with ocaml, you can do it, but nothing in the package.
  You need something, with java you search in the documentation or you
look if someone done it, you fill more lucky than with ocaml
 Generaly people who use ocaml, master well computer, langage theory.
  The question is for the other who need a more generalist langage,
they are totally forgotten

I like ocaml, fonctional style, it is possible to do impérative or
object code. One thing is sure, if the IHM was better and with SGBD
connection (in the ideal world all with good documentation) it would
be easier to use ocaml on more project.

sincerely

> ----------
> De : 	John Max Skaller[SMTP:skaller@maxtal.com.au]
> Date :	samedi 15 avril 2000 23:17
> A :	caml-redistribution@pauillac.inria.fr
> Objet :	Re: When functional languages can be accepted by industry?
>
> One barrier to acceptance of ocaml in industry:
> lack of programmers. This requires training.
> Who can help?
>
> --
> 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
>



^ permalink raw reply	[flat|nested] 67+ messages in thread
* Re: When functional languages can be accepted by industry?
@ 2000-04-20 12:45 Gerd Stolpmann
  2000-04-21 19:56 ` John Max Skaller
  0 siblings, 1 reply; 67+ messages in thread
From: Gerd Stolpmann @ 2000-04-20 12:45 UTC (permalink / raw)
  To: caml-list

On Mon, 17 Apr 2000, John Prevost wrote:
>Perl has it's problems, and the quality of modules varies
>immensely--but when I find a module, I can install it and try it out
>in about 20 seconds.  That lets me get on to the more important
>problems of writing code.

I had the simplicity of installing a Perl module in mind when I designed
findlib. But of course the approach is different, mostly because Perl's loader
works completely dynamically, but for OCaml the order of linking/loading must be
determined at compile/link time.

>While this sort of thing might, by a number of arguments, not be the
>sort of thing that should be considered part of the "core language",
>I'd like to argue that such an official blessing would be enough to
>get people to start using the tools consistantly, rather than
>everybody doing things their own way.  And it's only when everybody's
>working in approximately the same way that this kind of simplicity of
>working with third-party modules becomes possible.

I agree, but it is hard to achieve. The first problem are the different
"development" environments ( - an industrial term, better we say build
environment); there is some lowest common denominator for Unix systems (make;
file commands such as cp, mv, rm; text tools such as sed) but the Windows
and Macintosh worlds are completely different, and most people running these
systems do not have build environments. I would say: let's begin with realistic
goals, and that would be presuming the Unix-like environment.

Another problem is that the command-line interface of the OCaml compilers has
a too low abstraction niveau. It is more or less what a C compiler provides;
the difference is that reusing components was never a goal of the C language,
so I think that the CLI should be improved to better support components.
Findlib is my suggestion for this. You can simply link your program with add-on
components by naming the components, i.e. you specify *what* you want and not
*how* the compiler should proceed to get the result. For example,

ocamlc -o program -package x,y -linkpkg program.ml

compiles program.ml and links it with the components x and y. You need not to
specify

- where the components are installed
- which files must be linked 
- which components must be additionally linked because x or y need them
  (directly or indirectly)
- if there is a dependency between x and y, you need not to specify the linking
  order 
- additional system libraries

Findlib finds it for you.

On the first glance, this looks just like being some luxury that is not really
necessary. I am currently working on an (industrial) project where an OCaml
module is part of a bigger program. Typically, the sources are compiled with
something like

ocamlc -package markup,netstring,str,unix,dynlink,pcre ...

which is much more descriptive than

ocamlc -I /opt/ocaml-2.04/site-lib/markup 
       -I /opt/ocaml-2.04/site-lib/netstring 
       -I /opt/ocaml-2.04/site-lib/pcre
       markup.cma str.cma netstring.cma unix.cma dynlink.cma pcre.cma
       -cclib -lpcre -cclib -lunix -cclib -lstr 
       ...

and also more portable; you can simply compile without having to know where all
the necessary packages are installed on a particular system. I think it is not
luxury, it is a necessary abstraction that simplifies notation and hides the
peculiarities of the system installation. I think, these points are important
for industrial usage, too (note that Findlib resulted (partly) from
personal experience in industrial development).

Of course, the current Findlib implementation has some weaknesses. First, it is
not integrated into the compilers. That is not a big problem, but you must in
fact write

ocamlfind ocamlc -o program -package x,y -linkpkg program.ml

- the extra "ocamlfind" is the command that transforms the new options such as
-package into traditional options. - There is another problem with missing
integration, as Findlib tries to find out the configuration of an OCaml system
when it is compiled itself. For example, Findlib must know if POSIX or
bytecode-only threads are used, and it inspects the files in the stdlib
directory for this purpose. This may not work with future OCaml versions.

Second, Findlib depends a bit (but not much) on Unix. This is simple to fix
(for the Findlib core).

Third, Findlib cannot handle name clashes. If the same (toplevel) module M
occurs in two components x and y, and component z refers to M, findlib normally
knows which M is meant (because it knows the module on which z depends), but
it has no chance to tell the linker its knowledge. If the linker knew the
component dependencies the linker could almost always resolve name clashes in
the right way.

Furthermore, Findlib does not address at all:

- Versioning components. You cannot refer to specific versions of components,
  because I have no idea how this could be semantically cleanly solved.
  Especially, this seems to be in contradiction with automatic
  dependency analysis. 

- The build process. You need a "make" tool, and Findlib does not support you
  in writing Makefiles.

Especially, at least conventions about the latter would be necessary to get a
standard installation procedure for OCaml components.

>Mmm.  I actually have one minor gripe about the I/O stuff--not being
>able to turn a set of functions into an in_channel or out_channel has
>bit me a number of times.  It's not so bad, until you want to do
>something like implement an encrypting network stream and then use
>stuff from Printf to write to it.

Interesting idea, and not very expensive, because the basic I/O operations are
normally performed for bigger chunks. Perhaps in/out_channel should be defined
as classes such that you can easily define a new implementation. The old
functional style could be retained, i.e.

let output chan buff ofs len = chan # output buff ofs len

and so on for all basic functions. This means that you CAN take advantage from
the new class-based channel definition, but you can also continue preferring the
functional style.

>I think that if you took something like, say, Findlib, and asked if
>you could integrate it into O'Caml, you'd discover at least a few
>people who would make time to go over things looking for issues and
>warts to clean up.  It's hard to be enthused if it's not going to be
>"official".
>
>Even though I've been waiting for a good solution for consistent
>handling of third party modules almost as long as I've been using
>O'Caml, the fact that only a few people use findlib cuts down on its
>usefulness to me.  If Findlib were accepted into O'Caml, I would go
>out of my way to send findlibifying patches to authors of various
>packages, instead of just getting depressed.

I have no objections to the integration of Findlib into the OCaml core.

Perhaps it is possible to make it at least "semi-official". I can put the
sources into the CVS tree, and the distribution tarball could be downloadable
from the Caml FTP server. It would be still a separate distribution with
separate responsibility, but it looks like the "preferred" way of handling
components; comparable to camltk or camlp4. 

But this is only a suggestion. Perhaps people want a different tool? I do not
know. I designed Findlib primarily for my own problem constellation; and
although I think it is quite general, other people might have different
priorities (for example, versioning might be more important than handling
component dependencies).


Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
Germany                     
----------------------------------------------------------------------------





^ permalink raw reply	[flat|nested] 67+ messages in thread
* Re: When functional languages can be accepted by industry?
@ 2000-04-17 22:24 bdb-as-camluser
  0 siblings, 0 replies; 67+ messages in thread
From: bdb-as-camluser @ 2000-04-17 22:24 UTC (permalink / raw)
  To: Xavier.Leroy; +Cc: caml-list

I think the issue between Java and O'CaML is not primarily a question of language. Both Java and O'CaML have their strengths and weaknesses. 
Actually, the Sun Java compiler is still buggy at this point. So what makes it so popular? The standard APIs and libraries. While O'CaML standard APIs and libraries are focused on data structures -- with very effective implementations --, java has put focus on other domains which seem to have more success.

The java 2 APIs contain stuff to handle windows, overall GUI look-and-feel, drag-and-drop, en/decryption, databases, remote method invocation, complex 2D graphics, and finally data structures. If you want to do all that with O'CaML, you have to bolt everything on it yourself, find every library binding if they exist...

One problem is that with O'CaML, it does take some time to get you started and find the right options to invoke to compile your code with custom libraries support. On the other hand, with java you state a few "imports" and it's over. Examples in the documentation are numerous, too.

But also, there is a huge difference between standard libraries and library bindings. Standard APIs are written independently of existing libraries; library bindings often provide a mere translation of functions that has been initially written for C. Also, documentation is kept in separate files and compiling a working executable is much more difficult.

I see a definite advantage that O'CaML could take in development of standard APIs (at least APIs!) covering the needs of the industry identified by Java's success. The later development of those libraries, starting from APIs, potentially using other graphic libraries, could more easily be implemented by O'CaML users...

But certainly, the primary problem will be human resources then...

Best regards,
Benoît de Boursetty.

----- La messagerie itinérante sans abonnement NetCourrier -----
Web : www.netcourrier.com     Minitel : 3615 et 3623 NETCOURRIER
                  Tél : 08 36 69 00 21



^ permalink raw reply	[flat|nested] 67+ messages in thread
* When functional languages can be accepted by industry?
@ 2000-04-03  1:27 Dennis (Gang) Chen
  2000-04-06 16:51 ` Jean-Christophe Filliatre
  2000-04-07 15:44 ` John Max Skaller
  0 siblings, 2 replies; 67+ messages in thread
From: Dennis (Gang) Chen @ 2000-04-03  1:27 UTC (permalink / raw)
  To: caml-list

Hi,

Functional languages have not been very successful in industry. Why?

When writing database applications, we use Access, Oracle and languages
which support interfeaces to these database systems.

When writing an application which needs user friendly interface,  one can use Delphi,
or Java,  Visual Basic, Visual C++, C++ Builder etc.

When writing text manipulation programs, perl is a good choice.

For internet application, one use Java, perl, Deplhi, Visual C++ etc.

When higher order functions are required, we can use any OO language, because
an object with one method can be viewed as a function, so if a function can accept
objects as  inputs and output an object, then this function is a higher order function.

To write polymorphic functions, one can use templates in C++.

For data structures which require dynamic memory allocation, one can consider
Standard Template Library (STL) in C++.  From STL, you can choose list, set,
map, tree templates, which are sufficient for most purposes.

The templates in STL are more efficient than list in functinal languages.  For example,
if you use list to implement  set, then a deletion of an element from a set will require
reconstruction of a part of the list, which has  significant memory cost. In STL
templates, this is a simple pointer operation.

To write a parser, I prefer to use ocaml as I'm aware  of its adavantage
in this aspect. But I've learnt that there are other compiler tools available.

Functional languages in ML family are equiped with a much better type system
than C++, this reduce errors in programs, but industry has its own procedure to
ensure the reliability of program. So the weakness in C++ does not bother too
much.

Module in ocaml is an attractive feature.  Large applications are built in a refinement
way,
and different implementations for a given interface will be experimented. Module
should be good  for this, and it is not available in C++.

The size of functional language program is usually small, this feature probably would give
a chance
for functinal language to enter industry. A program stored in a smart card or in a mobile
phone
can not be a big one.

Are there other features of functional language which will attract industry?

--
Dennis Gang CHEN    Senior Software Engineer
Motorola Australia Software Centre, Electronic Design Automation
2 Second Avenue, Mawson Lakes, SA 5095, Australia
phone: +61 8 8203 3560,  mailto: Dennis.G.Chen@motorola.com





^ permalink raw reply	[flat|nested] 67+ messages in thread

end of thread, other threads:[~2000-04-28  9:43 UTC | newest]

Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-17 12:57 When functional languages can be accepted by industry? FALCON Gilles FTRD/DTL/LAN
2000-04-17 15:35 ` Xavier Leroy
2000-04-18  5:54   ` Francois Pottier
2000-04-19 14:53     ` Vitaly Lugovsky
2000-04-19 15:17       ` Claude Marche
2000-04-20  1:44       ` Max Skaller
2000-04-20  3:01         ` Vitaly Lugovsky
2000-04-21  0:41         ` Jacques Garrigue
2000-04-21 19:35           ` John Max Skaller
2000-04-21 20:53           ` Michael Hohn
2000-04-25 10:50           ` Remi VANICAT
2000-04-20  1:52       ` Max Skaller
2000-04-20  3:08         ` Vitaly Lugovsky
2000-04-20  2:51           ` Max Skaller
2000-04-20 17:17       ` Jean-Christophe Filliatre
  -- strict thread matches above, loose matches on Subject: below --
2000-04-20 12:45 Gerd Stolpmann
2000-04-21 19:56 ` John Max Skaller
2000-04-22 18:30   ` Gerd Stolpmann
2000-04-23  3:20     ` John Max Skaller
2000-04-17 22:24 bdb-as-camluser
2000-04-03  1:27 Dennis (Gang) Chen
2000-04-06 16:51 ` Jean-Christophe Filliatre
2000-04-07  5:27   ` Dennis (Gang) Chen
     [not found]     ` <14574.1721.508470.790475@cylinder.csl.sri.com>
2000-04-11  0:24       ` Dennis (Gang) Chen
2000-04-11 17:58         ` Pierre Weis
2000-04-12  1:45           ` Dennis (Gang) Chen
2000-04-12 17:27             ` Daniel de Rauglaudre
2000-04-13 15:40               ` John Max Skaller
2000-04-14 19:16                 ` John Max Skaller
2000-04-12 18:06             ` David Brown
2000-04-13  1:23               ` Dennis (Gang) Chen
2000-04-13 14:36                 ` Pierre Weis
2000-04-13  6:53             ` Jean-Christophe Filliatre
2000-04-13 12:20               ` Frank Atanassow
2000-04-13 17:28                 ` John Max Skaller
2000-04-13 12:28               ` Steve Stevenson
2000-04-13 13:38               ` jean-marc alliot
2000-04-13 16:00                 ` William Chesters
2000-04-13 14:29               ` T. Kurt Bond
2000-04-13 17:23                 ` Julian Assange
2000-04-16 16:33                   ` John Max Skaller
2000-04-17 15:06                   ` Markus Mottl
2000-04-17 19:55                     ` John Prevost
2000-04-24  2:36                       ` Chris Tilt
2000-04-13 16:59               ` John Max Skaller
2000-04-15 22:29                 ` William Chesters
2000-04-16 22:24                 ` Nickolay Semyonov
2000-04-18  6:52                   ` Max Skaller
2000-04-17 12:51                 ` jean-marc alliot
2000-04-17 17:49                   ` John Max Skaller
2000-04-17 22:34                     ` Brian Rogoff
2000-04-19 15:31                       ` John Max Skaller
2000-04-19 18:30                       ` Michael Hicks
2000-04-20 16:40                       ` Markus Mottl
2000-04-20 17:58                         ` Brian Rogoff
2000-04-20 18:52                           ` Markus Mottl
2000-04-21 20:44                             ` Michael Hohn
2000-04-21 19:22                           ` John Max Skaller
2000-04-21 19:09                         ` John Max Skaller
2000-04-21 19:45                           ` Markus Mottl
2000-04-21 19:56                           ` Brian Rogoff
2000-04-21 19:18                         ` John Max Skaller
2000-04-18 10:53                     ` Sven LUTHER
2000-04-19 15:57                       ` John Max Skaller
2000-04-13  7:05             ` Pierre Weis
2000-04-13 17:04               ` Julian Assange
2000-04-07 15:44 ` John Max Skaller

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