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