Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Large projects in OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Eric Stokes <eric.stokes@c...>
Subject: Re: [Caml-list] Large projects in OCaml
A small clarification (see embedded).

On May 19, 2004, at 2:33 PM, Jon Harrop wrote:

>
> I have been using ocaml to write a vector graphics library over the 
> past four
> months. I intend to commercialise it. However, I am not yet sure 
> exactly how
> I can do that...
>
> From my experiences, I would say that you are likely to find 
> programming in
> ocaml to be vastly more productive than programming in C++. In the 
> case of my
> project, for example, I would say that development in ocaml is about 
> 10 times
> faster than in C++ and code density is about 4 times greater. I would 
> also
> say that your programming style (if you are used to imperative style) 
> is
> likely to change significantly over the first month of using ocaml. It 
> may be
> worth noting that I had already dabbled in functional programming as an
> undergrad.
>
> I think it is important to emphasise that the efficiency of developing 
> in
> ocaml goes a long way to offsetting the (relatively minor) drop in
> performance. This is because a given project has a finite lifetime 
> and, in
> that lifetime, you can try a much wider variety of approaches and 
> algorithms
> using ocaml than you could in C++.
>
> If you want to see examples of good ocaml code to learn from then I'd
> recommend looking at the core library (in the ocaml distribution) and a
> select few third party libraries. However, you are unlikely to 
> appreciate the
> way in which the code is written without some more intricate knowledge 
> of the
> language itself.
>
>> a) Are there examples of
>> commercial s/w developed in OCaml?
>
> I am not aware of any existing commercial software written in ocaml.
>
>> b) Is the native compiler/runtime/tools mature for
>> large commercial projects?
>
> Primarily due to the clean design of the language itself (I believe) 
> the tools
> are already of extremely high quality. I have found several bugs in 
> gcc but
> none in the ocaml compilers, for example. Having said that, I pushed 
> gcc to
> its limits (e.g. gratuitous template partial specialisation) but I 
> have never
> used the more risque features in ocaml.
>
> However, if you are planning on using external libraries in other 
> languages
> then, I think, it is highly likely that you will need to develop your 
> own
> interfaces to them (which you could then productively distribute for 
> free!).
> This is mildly tricky as (I would say) there is relatively little
> documentation and it involves the use of several magic C macros. You 
> could
> also try some of the automated tools (SOAP, camlidl).
>
>> We would really appreciate feedback from folks who
>> have worked on large projects with OCaml. If this
>> has been answered earlier, we appreciate pointers
>> to the thread(s).
>
> There are some other, important aspects which you haven't covered:
>
> The type-safe linking offered by ocaml makes for a very brittle 
> interface
> between objects (see Xavier Leroy's post to this list on 17 May 2004 
> entitled
> "Ocaml shared libraries"). Therefore, I don't believe it is feasible to
> distribute commercial code in object form. If you intend to sell your 
> code to
> programmers and you don't want them to have your source (like me!) then
> you're a bit stuck. I suspect that selling executables for the 
> end-user would
> be comparatively trouble-free.
>

There is no issue at all distributing object code. You do not have to 
distribute source.
The issue is, that the language does not support creating shared 
libraries written in Ocaml
(though it can link to C shared libs), so all the object code you 
distribute will be statically
linked. If you are planning to sell a library written in Ocaml, it will 
necessarily be a static
library. For application code, static linking is probably preferred in 
some cases, and
acceptable in most.

> There are some issues with libraries too. The compiler comes with a 
> "core"
> library which the compiler itself uses. Although these are extremely 
> well
> written, they can be a little quirky and their functionality is quite 
> limited
> (e.g. data structures). Although there are other libraries, such as 
> Extlib
> and "the library formerly known as Extlib":
>
> http://sourceforge.net/projects/ocaml-lib
> http://raevnos.pennmush.org/code/annexlib/index.html
>
> for example, there is no "Standard library". Part of this problem 
> stems from
> the fact that, the INRIA team is intended for research and not for the
> development of such (mundane) code and although they may recieve great 
> code
> snippets for contribution to the "core" library, they cannot accept 
> them due
> to copyright issues:
>
> http://caml.inria.fr/archives/200403/msg00171.html
>
> Additionally, people who know about external libraries often aren't 
> very good
> at designing/writing ocaml code and vice-versa.
>
> Finally, I am not sure how well ocaml runs under Windows.
>
> HTH.
>
> Cheers,
> Jon.
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners