On Friday 09 May 2008 02:11:33 Matthew William Cox wrote:
> On Fri, May 09, 2008 at 01:39:54AM +0100, Jon Harrop wrote:
> > 5. Strings: pushing unicode throughout a general purpose language is a
> > mistake, IMHO. This is why languages like Java and C# are so slow.
>
> This is simply ridiculous. Using heavy-weight unicode-aware functions
> for character operations may slow down string-intensive operations in
> those languages, but the only alternative is to be broken.

Your definition of "broken" is broken.

> See items 3 and 4 here:
>
> http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html
>
> In both cases, we need locale-aware character processing. That means
> Unicode these days. Unless you code your own routines for processing
> every 8-bit character set out there. I don't.

That is not a justification for pushing Unicode throughout a programming 
language. You can support Turkish and Arabic without degrading the 
performance of my software.

For us, this is about two things:

1. Profit.

2. Performance.

Our sales already correlate with the world distribution of wealth even though 
we only support English. There is literally no value in us supporting other 
languages. So we have no need of unicode.

What you call "Using heavy-weight unicode-aware functions for character 
operations" refers to all lexing and parsing. OCaml provides incredibly fast 
lexers and parsers and our customers make heavy use of that. Other languages 
do not. This is a major advantage of OCaml, IMHO. So imposing unicode upon us 
is not only unnecessary but is actually damaging.

> > 8. Exceptions: I love OCaml's extremely fast exception handling (6x
> > faster than C++, 30x faster than Java and 600x faster than C#/F#!). I
> > hate the "exceptions are for exceptional circumstances" line promoted by
> > the advocates of any language implementation with cripplingly-slow
> > exception handlers. I really miss fast exception handling in F#. Brian
> > gives an example of exception handling with recursive IO functions
> > failing to be tail recursive here and advocates option types. But
> > recursion is the wrong tool for the job here and option types are even
> > worse. You should use mutation and, failing that, CPS.
>
> I suspect his reaction to exceptions comes from an unfamiliarity with
> their uses in Ocaml.

Except Brian has been using OCaml for many years.

> > 9. Deforestation: Brian says "Haskell has introduced a very interesting
> > and (to my knowledge) unique layer of optimization, called
> > deforrestation". True, of course, but useless theoretical piffle because
> > we know that Haskell is slow in practice and prohibitively difficult to
> > optimize to-boot. Deforesting is really easy to do by hand.
>
> Yes, its easy to do by hand. It's also time consuming.

Do you spend >1% of your time deforesting?

> Don't you make a living off ocaml?

I use OCaml professionally in industry but our OCaml-based sales have declined 
since Q3 2007 to only £6k p.a. now.

> I'm surprised you can justify using your time on such a mechanical task.

By my estimates, <<1% of my time is spent deforesting. It is irrelevant, just 
like all of the other "benefits" of Haskell that have debilitating hidden 
costs.

> Granted, deforesting something like map f . map g into 
> map (f . g) is trivial, but we can come up with both trivial and
> nontrivial examples for almost anything.

Predictable performance and memory consumption are infinitely more valuable 
than the odd trivial rewrite.

Incidentally, I forgot a couple of things for my wish list:

. Overloading.
. IDE-friendly, e.g. Intellisense for GUI code.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e