Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

["Sylvain LE GALL" <sylvain.le-gall@polytechnique.org>]

Hello,

On Fri, Jul 18, 2003 at 04:21:14PM -0500, Chris Clearwater wrote:
>     I have come across the Ocaml language several months ago and after much
> investigation and trial coding I have come to several conclusions. Most
> importantly I think Ocaml is a wonderful language to program in. It has all
> the features I would expect from a modern language and on top of that it's
> compiled native code appears to rival that of C in many areas. It truly is
> the language of the future. 

Well said, you get the essence of the a powerful language, which is
ocaml.

> Now that I have expressed how much I am growing
> to love Ocaml I would like to share with you my initial experiences as a new
> user. First I would like to single out some issues that I believe threaten
> Ocaml from being taken seriously and then i would like to offer some
> solutions that would improve the usability of ocaml greatly.
> 
> - Support on win32 could certainly be much better
> - Compiling and distributing Ocaml source is a very delicate process
> - There exists much fragmentation among usage of different GUI toolkits
>   and they are limited to C/C++ conventions. (Is it possible to create your
>   own custom GTK widgets within ocaml?)
> 
> And without further ado I present to you 10 steps to world domination:
> 
> 1) Support for Ocaml on win32 (both as a development and target enviroment) is
> very crucial for the adoption and practicality of Ocaml. For example, look at
> the trouble some developers must go through to get their application running
> under win32: http://groups.yahoo.com/group/unison-hackers/message/31.
> Forutnately this doesn't have to be the case. The mingw32 toolset allow
> compilation and linking to be done very similarily to how it is done on Unix.
> Also, it enables one to develop win32 apps without shelling out hundeds of
> dollars to Microsoft: http://msdn.microsoft.com/visualc/howtobuy/pricing.aspx
> I propose mingw32 be made the default compiler/linker for native win32 binaries
> (or even drop MSVC support entirely).
> 
> 2) Take the idea of ocamlmklib further to generalize the compilation of both
> Ocaml programs and libraries into a module called "Ocamlmake". Also create a
> binary of ocamlmake which makes use of the module for command line compiling
> and include these in the standard distribution on all platforms.
> 
> 3) Now that we have a easy cross-platform way to compile ocaml applications we
> can just distibute our code with Makefiles that call ocamlmake! WRONG.
> Makefiles suck. Now we standardize on the idea of an Ocaml "package". Each
> package would include in it's toplevel directory a file called setup.ml (This
> is starting to resemble python's distutils indeed). setup.ml would make use of
> the Ocamlmake module by building a record and passing it to Ocamlmake.setup.
> This record might be static or it might be created by self-configuration.
> For example, the ocamlsdl package would call sdl-config to retrieve some
> compilation flags. You _would_ rather configure in ocaml than "portable shell
> script", right? Then to build the application you would execute "ocamlrun
> setup.ml build" and "ocamlrun setup.ml install" to install it. Also the record
> would contain meta-information such as the author, copyright, etc.
> 

I totally agree. What would be very useful will be a good tool to
compile ocaml source ( and C stubs ). But take a look at :
http://caml.inria.fr/humps/index_framed_caml.html Section Makefile

> 4) Change the ocaml distribution to compile using Ocamlmake :) (except for
> bootstrapping if you dont already have a previous version of ocaml installed)
> 
> 5) Create a module called Framebuffer which parallels the primtives found in
> OpenGL/DirectX. The Graphics module is close, but the design doesn't match
> well with these two APIs (We want hardware acceleration). Implement for each
> platform a Framebuffer module (DirectX or OpenGL where available, Xlib or
> other native graphics system otherwise). Include this in the standard
> distribution.
> 
> 6) Create a cross-platform Event module. Include this in the standard
> distribution.
> 
> 7) Create a cross-platform Font module (wrap freetype or create an Ocaml
> implementation). Include this in the standard distribution.
> 
> 8) Create a GUI on top of the Framebuffer, Event, and Font modules,
> implemented in Ocaml :) Include this in the standard distribution.
> 

As gui : there is lablgtk ( binding of gtk ). As Framebuffer, there is a
binding for SDL && OpenGL && Xlib (but i am not sure of this last ).

> 9) Now the big payoff, we write a standard Ocaml IDE, to be included with the
> Ocaml distribution. It would be well integrated with the distribution. Ocamlmake
> module for compiling, the ocaml lexer for syntax highlighting, exporting packages
> (setup.ml). This would make it incredably easy to get started creating
> cross-platform libraries and modules. Realating to point #1, now a win32 user
> need only grab the mingw32 and Ocaml distributions and they are set. They can
> even easily export their code to a ocaml package for distribution. Obviously the
> benefit extends to all other platforms as well.
> 

Take a look at a project called cameleon, written in ocaml for ocaml...

> 10) World domination.
> 

World domination when hundred of fortran, C, C++, cobol, java programmer will
loose the castle of programmation ( not yet, and not for the 20 next
years ).

Regard
Sylvain LE GALL

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