Browse thread
Hash clash in polymorphic variants
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Kuba Ober <ober.14@o...> |
| Subject: | Re: [Caml-list] Re: Hash clash in polymorphic variants |
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