Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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


  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