Post by Gerd StolpmannPost by Jon HarropIncidentally, Xavier made a statement based upon what appears to me to be
a similar logical error in the CUFP notes from last year that I read
"On the other hand, certain features seem somewhat unsurprisingly to be
unimportant to industrial users. GUI toolkits are not an issue, because
GUIs tend to be built using more mainstream tools; it seems that
different competencies are involved in Caml and GUI development and
companies "don't want to squander their precious Caml expertise aligning
pixels". Rich libraries don't seem to matter in general; presumably
companies are happy to develop these in-house. And no-one wants yet
another IDE; the applications of interest are usually built using a
variety of languages and tools anyway, so consistency of development
environment is a lost cause."
- http://cufp.galois.com/CUFP-2007-Report.pdf (page 3)
An interesting thesis, right? Although I wouldn't get that far, there is
some truth in it. The point, IMHO, is that OCaml will never replace
other languages in the sense that a company who uses language X for
years in product Y rewrites the code in OCaml. For what reason? The
company would run into big educational problems (learning a new
environment), would have high initial costs, and it is questionable
whether the result is better. Of course, for rewriting existing software
the company would profit from GUIs, from rich libraries etc. But I think
this does not happen.
I believe many more companies would migrate to OCaml if it had well-documented
GUI APIs and rich libraries. Indeed, Microsoft are gambling on people
migrating to F# in exactly the same way.
Post by Gerd StolpmannWhat I see, however, is that OCaml is used where new software is
developed, in ambitious projects that start from scratch. It is simply a
fact that GUIs are not crucial in these areas (at least for the
companies I know).
But the companies you know were already self-selected to be the ones who do
not care about OCaml's limitations, so it is a biased sample?
Post by Gerd StolpmannGUIs are seen as standard tools where nothing new happens where OCaml could
shine.
I have no doubt that OCaml would shine in GUIs just as it does elsewhere.
Post by Gerd StolpmannIf you need one, you develop it in one of the mainstream languages.
Actually I would either choose F# on Windows or give up on any other OS.
Post by Gerd StolpmannIDEs aren't interesting right now because OCaml is mainly used by
(computer & related) scientists (and I include scientists working for
companies outside academia).
Many of the world's most sophisticated IDEs are targetted solely at technical
users. Look at Mathematica's notebook interface, for example. I believe that
is a great example to aspire to.
Post by Gerd StolpmannIDEs are nice for beginners and for people
who do not want to know what's happening inside. They are not
interesting for companies that invent completely new types of products,
because they've hired experts that can live without (and want to live
without).
I couldn't disagree more. Pharmaceuticals are a trillion dollar industry where
many scientists would benefit enormously from being able to use a tool like
OCaml without knowing anything about how it works in order to create their
next generation products (drugs). The same is true of most industries where
scientists and engineers work and there are many such industries and there
are extremely profitable.
Post by Gerd StolpmannPost by Jon HarropXavier appears to have taken the biased sample of industrialists who
already use OCaml despite its limitations and has drawn the conclusion
that these limitations are not important to industrialists. I was really
horrified to see this because, in my experience, companies are turning
away from OCaml in droves because of exactly the limitations Xavier
enumerated and I for one would dearly love to see them fixed.
Which companies?
General Electric, Microsoft, Wolfram Research and various bioinformatics
institutes for example.
Look at General Electric. They build some of the world's most sophisticated
medical scanners and that large-scale embedded market is ideal for using
languages like OCaml for its high-performance numerics because you have
complete control over the environment. However, they desperately need GUI
toolkits to provide a front-end for users.
I'd like to know what Alex Barretta makes of this, for example. His glass
cutters must have the same characteristics in this respect...
Post by Gerd StolpmannI fully understand that OCaml is not well-suited for the average
company. But it is not because of missing GUIs and IDEs, but because the
language itself is too ambitious. Sorry to say that, but this is not the
mainstream and it will never be.
I still think OCaml has the best chance of any FPL to become a mainstream tool
in technical computing.
Indeed, I recently tried to quantify how far OCaml has already come and I
believe it is already as popular as C# among technical users, for example.
That is quite an achievement!
Post by Gerd Stolpmann(I have a good friend who works for an average company, so I know what
I'm talking of. They program business apps for a commercial platform
from CA. A horrible language, but they can manage it. They are experts
for the models they use, and simply take a platform from industry.)
Yes. I do not believe OCaml will make significant inroads into displacing
COBOL and relatives but there are a lot of other big opportunities out there
for such a language.
Post by Gerd StolpmannPost by Jon HarropOCaml will continue to go from strength to strength regardless but its
uptake would be vastly faster if these problems are addressed. To take
. GUIs are incredibly important (LablGTK is the world's favorite OCaml
library!) and tens of thousands of OCaml programmers are crying out for
proper LablGTK documentation as a first priority, many of whom are in
industry.
See this as opportunity for your next book :-)
Indeed. Even after the announcement that Microsoft are productizing F#, OCaml
for Scientists continues to be our biggest earning product. Consequently, I
am very tempted to write a "sequel" that covers many of the important aspects
of the language that I did not cover in the original, including GUI
programming, XML, parallelism and so forth. If anyone has ideas for subjects
they would like to see covered, please e-mail me!
Post by Gerd StolpmannGTK is already poorly documented, so this is not only the problem of the
LablGTK creators. Nevertheless, GTK is widely used. I don't think it's a
real problem.
Yes. I'm really not sure what the best course of action would be here. Would
Qt bindings be preferable? Is it worth the hassle? How long would it be
before they reached the maturity of GTK?
I think we would really need more high-profile open source programs with
hundreds of thousands of users testing the bindings (as GTK has had) before
you could really gamble on it.
Post by Gerd StolpmannPost by Jon Harrop. Rich libraries are incredibly important and OCaml has the potential to
become a hugely successful commercial platform where people can buy and
sell cross-platform libraries but OCaml needs support for shared run-time
DLLs (or something equivalent) this before this can happen.
Do you dream or what?
One man's reality is another man's dream. :-)
Post by Gerd StolpmannI don't think that selling libraries in binary form is that important...
If it were possible then it would be important to me because I could earn a
living from it. I'm sure the same is true for many other people.
Post by Gerd StolpmannIt is difficult anyway to do that, and why do you expect you could be
successful in a niche language?
Because I already am. :-)
Post by Gerd StolpmannAs customer I would demand to get the source code - to lower the risks of
the investment into a small platform.
Nobody ever got fired for buying IBM.
Historically, we've made a lot more money from sales of binaries than from
sales of source code. Consequently, I would be more than willing to gamble on
selling shared run-time DLLs for OCaml users if it were possible.
Post by Gerd StolpmannPost by Jon HarropYes. A better FFI could also be enormously beneficial. Improving upon
OCaml's FFI is one of the most alluring aspects of a reimplementation on
LLVM, IMHO.
A general question to you: When you are complaining about so many
aspects of OCaml, why don't you invest time & money to fix them?
An excellent idea!
So I wrote to Xavier Leroy and asked about contributing to INRIA's OCaml
distribution. Xavier explained that French copyright law makes it
prohibitively difficult for him to include my code contributions so this will
never be possible. The best I could think of was to suggest that they make it
possible for users to pay to get certain bugs fixed or functionality
implemented. I'm not sure that will happen though.
I wrote to Pierre Weis and asked what the likelihood of getting some tweaks
into the language was. He said that it is unlikely I could even get a "try ..
finally" construct put in.
So there's no way I can improve INRIA's OCaml distribution. Next, I thought
perhaps a complete fork of OCaml would be a viable alternative. This is
complicated by OCaml's license which requires variants to be distributed with
the core sources intact and everything else as patches to it. This is not an
insurmountable problem, of course, you just distribute the core and a giant
autogenerated patch instead. So I asked Sylvain about getting Debian to adopt
the fork rather than INRIA's upstream. He said this will almost certainly not
happen.
So I can't develop or contribute to INRIA's OCaml implementation and I can't
fork it without starting with zero users. What about reimplementing it?
So I wondered what I could build upon that would make this as painless as
possible. This led me to the Smoke VM, Mono, the JVM and LLVM. I enumerated
each of these in turn and came to the conclusion that LLVM is preferable, not
least because several other people had already drawn the same conclusion and
started work on similar projects themselves.
That's when I wrote my 100LOC test program calling LLVM from OCaml. Since
then, Gordon has been working hard on the OCaml bindings and example
programs, which are now nothing short of incredible. Dozens of people have
e-mailed me expressing their desire to contribute to such an effort.
This will take time, of course, but I believe it is the future of the OCaml
language.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs