* Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)
2003-07-18 21:21 [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities) Chris Clearwater
@ 2003-07-19 12:32 ` Sylvain LE GALL
2003-07-19 15:38 ` Richard Jones
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Sylvain LE GALL @ 2003-07-19 12:32 UTC (permalink / raw)
To: Chris Clearwater; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)
2003-07-18 21:21 [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities) Chris Clearwater
2003-07-19 12:32 ` Sylvain LE GALL
2003-07-19 15:38 ` Richard Jones
@ 2003-07-21 15:18 ` William Lovas
2003-07-24 16:40 ` Eray Ozkural
2003-07-26 20:14 ` [Caml-list] Roadplan for world domination Warren Harris
3 siblings, 1 reply; 10+ messages in thread
From: William Lovas @ 2003-07-21 15:18 UTC (permalink / raw)
To: caml-list
On Fri, Jul 18, 2003 at 04:21:14PM -0500, Chris Clearwater wrote:
> 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".
> [...]
I have to disagree with you on this idea. I've been working recently on a
project written in SML, and one of the things i miss most about O'Caml is
its nice interaction with the standard tools (not to mention its separate
compilation strategy! *sigh*).
The one thing not standardized by the Standard ML definition is compilation
strategy, and as a result, every SML implementation has its own idea of the
"right" way to compile a project. One can write standards-conformant code
and still have to write a bunch of specific build-scripts, each one in its
own arcane language, and quite possibly each one adhering to a vastly
different *philosophy* of compilation -- learning them all may well be a
lifetime's work. In my humble opinion, this is a major fault of SML.
As a concrete example, SML/NJ has a built-in "Compilation Manager" module,
and to compile a project, you have start up a top-level and run the
`CM.make' function. It was quite a shock to me not to be able to compile
something from the command line, coming from the O'Caml world, where the
compiler is mature, simple, and idiomatic (at least from a Unix user's
perspective).
For O'Caml to come up with its own incompatible compilation philosophy
seems like a step backwards. We *already have* nice, simple ways of
interacting with the standard tools (like `make', and `ld') -- throwing all
that away smacks of "not-invented-here" syndrome. It may be tempting to
climb up into our ivory tower and say, "We can do better than the status
quo!", but i think that attitude is better reserved for improving and
extending the language itself.
If you want a better `make', then write a better `make' -- but keep it
general purpose, and keep the O'Caml compiler's interface simple enough to
interact with *either* `make'.
cheers,
William
-------------------
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Caml-list] Roadplan for world domination
2003-07-18 21:21 [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities) Chris Clearwater
` (2 preceding siblings ...)
2003-07-21 15:18 ` William Lovas
@ 2003-07-26 20:14 ` Warren Harris
2003-07-28 14:39 ` Guillaume Marceau
2003-07-29 12:38 ` Damien Doligez
3 siblings, 2 replies; 10+ messages in thread
From: Warren Harris @ 2003-07-26 20:14 UTC (permalink / raw)
To: Chris Clearwater - chris@sharkzone.com; +Cc: caml-list
[-- Attachment #1: Type: text/plain, Size: 10488 bytes --]
Chris Clearwater - chris@sharkzone.com 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. 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.
I agree that ocaml is a beautiful language and first-class
implementation, and I sincerely hope that it sees its way to world
domination. I too am a relative newcomer to ocaml, so I've been
reluctant to throw in my comments and criticism of the language/system
until I had a little more experience with it, but your message has
prompted me to resurrect this message that I began composing some time
ago in response to the thread "OCaml popularity (long)". Please take it
as a constructive criticism.
Warren
[Caml-list] OCaml popularity (long)
I know this is an old thread, but I can't help but throw in my 2 cents
on ocaml's popularity. I'm relatively new to ocaml, but I have
experience with many other languages, and think that I have a good sense
for the new-comer's perspective. Here's my take:
1. I agree that the major factor is lack of industry backing. Java is
successful because of Sun's marketing muscle. Same goes for C#/Microsoft.
2. Lack of university backing. Although there is a lot more support for
ocaml at universities, there's still a large degree of fragmentation in
terms of languages used for teaching: java, scheme, haskell, etc. Lack
of knowledgeable students leads to a lack of demand for ocaml by
industry people.
3. Difficulty to learn. I don't really think ocaml is that difficult to
learn, but there are two main factors:
(a) it's "different enough" from most languages that people are
familiar with and many people are too lazy or impatient to wade through
the differences to make it to the rewards, and
(b) often the introductory treatments have an academic slant rather
than a get-things-done approach (already mentioned in this thread --
need for "cookbook"). Ocaml is really much better than other "academic"
languages in this regard (I find the O'Reilly book very pragmatic and
not sure why so many people seem to love to hate it). I mean at least
you don't need to understand monads to get useful work done in ocaml.
4. Tools. Lack of proper tools is the downfall of many languages.
Although ocaml is really quite good in this dept, the major flaws are
lack of a debugger on win32, and lack of an IDE (yes, there's emacs, and
some integration with VC6, but it's far from what your typical Visual
Studio guy is looking for).
About the debugger:
First I'll say that the debugger isn't nearly as necessary in ocaml for
several reasons:
(a) There's a read-eval-print loop (REPL) that can be used for
interactive testing and development. This allows programs to be built
from the bottom-up, verifying the smallest pieces first before building
things that depend on them. This is the same as
lisp/scheme/python/perl/js, and in stark contrast to C++/Java/C# where
you often need to write a large part of the program (and lots of
boilerplate) to get to the point where you can test anything.
(b) The fact that in the REPL you don't need to specify types
further lends itself to interactive development (again, in contrast to
Java).
(c) All data types can be used as literals, and printed to the
console further aids interactive development.
(d) Pretty-printing and the formatter are great tools, make things
easier to read, and are very easy to use.
The reason for the lack of the debugger on Windows is the lack of
fork/exec primitives, and these are used to implement checkpoints
(ability to roll back to a previous debugger state). Although this is a
nice feature, I for one don't find it that useful -- primarily because
with every other debugger I've used I get used to putting breakpoints in
places where I need to begin paying attention, or at least, I can
restart the computationfrom the beginning to get back to an earlier
point. I think most programmers would agree with this.
(I'm not sure if there isn't a slight anti-Windows bias in the ocaml
community, but I think there are two potentially conflicting goals for
ocaml: (1) promoting an alternative to the dominant platform by offering
ocaml as a better tool/language for Linux and open source development,
or (2) promoting wide-scale adoption of ocaml language in general, which
means making it work well on the dominant platform.)
5. Learning the language. Here's where I'll list what I think is
"different enough" about the language that keeps people from using it:
(a) Syntax of types -- in particular use of * and ->. I know where
they come from, why they're good, etc, but I know they put some people
off. This is compounded by type variables prepended with apostrophes and
postfix type functions. Also currying is foreign to most people -- the
fact that functions return functions that take more arguments. On the
surface this must seem useless, and inefficient (although once you
understand the power you'll wonder how you lived without them).
At the very least, I think ocaml type expressions would benefit from the
ability to label arguments with symbolic names. This would aid in
understanding. E.g.
val assoc : 'a -> ('a * 'b) list -> 'b
might be expressed as:
val assoc(key:'a) : fun(l: list(key:'a, value:'b)) : (value:'b)
(Just a suggestion -- I know this is more verbose, but if it makes the
language easier to learn it might be a good thing.)
(b) Constructors, patterns and values. This is no doubt one of the
great things about ocaml -- the fact that these three things are
expressed uniformly, i.e. that I can construct one by saying Foo(x),
match and destructure by saying Foo(x), or return a value and see it
print out as Foo(x). But to the beginner these three distinct things
might be confused. People are very used to seeing "new" in front of
constructors, and pulling apart nested structures one dereference at a
time. So I believe this is one reason why ocaml is different/hard to learn.
(c) Union types. (Or do you call them sums?) It's probably also lost
on many newcomers how great unions are in ocaml -- the fact that the
compiler will tell you all the functions that need to handle a new
constructor of the union when it's introduced (as long as you don't add
catch-all patterns), and how the pattern-matching cases are checked
exhaustively. Unions seem to suffice for 99% of the things that people
use OOP for (representing cases as disjunctive function clauses rather
than methods on classes) -- but without all the boilerplate. Unions are
great, but foreign to newcomers, and unwelcome to those that think they
only want OOP.
(Perhaps some sort of document is in order that shows exactly the
class of problems that requires overloaded methods, distinguishing this
from the cases where choosing ocaml's object system over union types is
simply a matter of taste to the programmer. Or better yet, a document
that describes how numerous problems expressed in Java or C++ can be
better (more concisely and efficiently) expressed with unions.)
(d) Heavy reliance on recursion. Although ocaml provides some
iterative constructs, for many things you still need to write recursive
functions. Fortunately, due to tail recursion elimination and a very
good compiler, recursion is very efficient in ocaml, but nonetheless it
requires programmers to contort their normal way of thinking about
common program idioms. Higher-order functional library routines also
fill the gap when iterative constructs are often used, but for whatever
reason, most people don't think in terms of List.map or Array.iter. I
think ocaml would benefit from a little more syntactic sugar in this dept:
for x in l do e == List.iter (fun x -> e) l
for x in l collect e == List.map (fun x -> e) l
(e) Assignment and mutability. The first hurdle is that people often
think ocaml is a "functional language," doesn't have assignment, and
consequently isn't practical. If they get past this, they may find that
refs require some change in the way you think about assignment.
Programmers are used to dealing with references and dereferencing when
pointers are involved, but for ordinary data types like int, bool and
char they think of variables being mutable or "const". Although ocaml's
treatment of references is more consistent, it presents a slight
rethinking. Also, ocaml's mutable record fields further confounds the
problem because unlike ordinary lexical variables, they can be modified.
Perhaps ocaml should consider adding mutable local variables:
let sum_until n =
let mutable sum = 0 in
for i = 0 to n-1 do
sum <- sum + i
done;
sum
(f) Type-checker error messages. When something fails to type check
in ocaml, the error messages can be uninformative or confusing. Often
times the source of a type constraint is far removed from the location
where the problem is reported. Showing the source of the constraint
would be very helpful. Also, often times the type conflict that's
reported fails to narrow down the conflict sufficiently. It would be
very helpful if the expected and actual type expressions were unified in
some way to pinpoint the exact discrepancy.
(g) Module system. Once you become proficient in the base language,
you move on to the module system, with it's own learning curve. For
instance, the beginner may wonder why they need to redefine all the
types in the mli file again in the corresponding ml file (not something
you have to do with import/include file in Java/C++). They may also be
confused by the difference between a a functor that takes a type as a
parameter, and a module struct specialized by a 'with' type constraint
(ok, maybe I'm the only one confused by the difference here).
[-- Attachment #2: Type: text/html, Size: 11919 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread