From: Kuba Ober <ober.14@osu.edu>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Re: Hash clash in polymorphic variants
Date: Fri, 18 Jan 2008 00:19:15 -0500 [thread overview]
Message-ID: <200801180019.15434.ober.14@osu.edu> (raw)
In-Reply-To: <1200424809.2564.95.camel@flake.lan.gerd-stolpmann.de>
On Tuesday 15 January 2008, Gerd Stolpmann wrote:
> Jon Harrop wrote:
> > Incidentally, 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
> > recently:
> >
> > "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.
>
> What 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). GUIs are seen as standard tools where nothing new
> happens where OCaml could shine. If you need one, you develop it in one
> of the mainstream languages.
>
> IDEs aren't interesting right now because OCaml is mainly used by
> (computer & related) scientists (and I include scientists working for
> companies outside academia). IDEs 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).
>
> > Xavier 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?
>
> I 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 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.)
>
> > OCaml will continue to go from strength to strength regardless but its
> > uptake would be vastly faster if these problems are addressed. To take
> > them point by point:
> >
> > . 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 :-)
>
> GTK 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.
>
> > . 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?
>
> I don't think that selling libraries in binary form is that important...
> It is difficult anyway to do that, and why do you expect you could be
> successful in a niche language? As customer I would demand to get the
> source code - to lower the risks of the investment into a small
> platform.
Yeah, I wouldn't be using Qt if there was no source code for it. Quite a few
times over the years I had to tweak away at the implementation details.
In fact, I would never specify *any* mission-critical libraries or frameworks
if they didn't come with full sources.
Cheers, Kuba
next prev parent reply other threads:[~2008-01-18 5:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 17:09 Jon Harrop
2008-01-10 20:35 ` [Caml-list] " Eric Cooper
2008-01-10 21:24 ` Jon Harrop
2008-01-10 21:40 ` David Allsopp
2008-01-11 13:30 ` Kuba Ober
2008-01-11 13:48 ` Jon Harrop
2008-01-11 16:14 ` Kuba Ober
2008-01-11 18:40 ` David Allsopp
2008-01-14 12:20 ` Kuba Ober
2008-01-14 14:44 ` Stefan Monnier
2008-01-14 14:56 ` [Caml-list] " Kuba Ober
2008-01-14 15:37 ` David Allsopp
2008-01-14 15:44 ` Kuba Ober
2008-01-14 16:03 ` David Allsopp
2008-01-14 15:45 ` Stefan Monnier
2008-01-15 3:36 ` [Caml-list] " Jacques Garrigue
2008-01-15 4:59 ` Jon Harrop
2008-01-15 9:01 ` Jacques Garrigue
2008-01-15 18:17 ` Jon Harrop
2008-01-15 19:20 ` Gerd Stolpmann
2008-01-15 22:04 ` Jon Harrop
2008-01-16 13:48 ` Kuba Ober
2008-01-16 15:02 ` Dario Teixeira
2008-01-16 19:00 ` Jon Harrop
2008-01-17 13:09 ` Kuba Ober
2008-01-18 5:33 ` Kuba Ober
2008-01-18 5:19 ` Kuba Ober [this message]
2008-01-18 5:39 ` Kuba Ober
2008-01-16 3:26 ` Jacques GARRIGUE
2008-01-16 3:34 ` Yaron Minsky
2008-01-16 3:42 ` Jon Harrop
2008-01-16 4:40 ` Jon Harrop
2008-01-16 16:03 ` Eric Cooper
2008-01-16 10:50 ` Richard Jones
2008-01-14 17:14 ` Jon Harrop
2008-01-14 17:36 ` Alain Frisch
2008-01-11 0:15 ` [Caml-list] " Jacques Garrigue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801180019.15434.ober.14@osu.edu \
--to=ober.14@osu.edu \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox