[Caml-list] Estimating the size of the ocaml community

[Michael Walter <michael.walter@gmail.com>]

On Fri, 4 Feb 2005 02:33:40 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > On the other hand, I cannot just have e.g. a function like
> > POSITION-IF that returns a number or nil. (Either one has to work with
> > exceptions, or wrap things up using the Maybe monad. Exception techniques
> > may interfere badly with tail recursion in some cases.)
>
> I think you will find that "int option" does exactly what you want whilst also
> statically type checking the result.
Although you can certainly disagree with the judgement (which I will
freely paraphrase with "using Maybe is inelegant"), I cannot see how
you are able to judge Thomas' knowledge of the usefulness of static
type checking based on a statement which you comment by partly
repeating what he said ;-)

> Let me recite my personal experience with static type checking. A couple of
> years ago, C++ was my latest language. I developed a significant project in
> C++ until I realised that the core of my implementation was fundamentally
> flawed and needed rewriting in order to achieve my objectives. This rewrite
> would have taken over a month. Thus, I gave up. Later, I decided to learn
> ocaml and porting my project seemed like a worthy task. The ported code was
> 1/4 as long and almost as fast. I've made two more fundamental changes since
> then, both of which would have been infeasible in C++.
Interesting. In my experience it's similarly simple to refactor in C++
as in languages with more sophisticated type systems (to answer the
obligatory question, yes, I'm working on large projects). I've had
similar experiences with dynamic languages like Scheme and Python,
though (compared to statically typed ones).

> When using C++, I always had to restrain myself from making major changes, as
> they were bound to break the program and were often irreparable. In contrast,
> when I make a fundamental change to the ocaml implementation, the static type
> checker immediately leads me to all of the new misuses of the altered code.
> This allows me to make much deeper changes without having to worry about
> spending months debugging the surrounding code. The last time I made such a
> change it took a day to get the program working again, rather than a month.
Are you using heavy casting and such without proper abstractions in
your C++ code? Pr what kind of changes did you want to make? How did
you feel that the static type checker of C++ didn't provide you with
similar help?

> Thanks to all these major changes, the latest ocaml version is vastly faster
> than the old C++. :-)
>
> > (4) There are a few other minor issues, such as a lack of
> > multiple-value-bind, which I personally find slightly annoying, but
> > not essential.
>
> I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1,
> 2, 3".
It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also
does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c
is bound to nil).

> > (9) It really annoys having +, +., and +/.
>
> There is a trade-off between type checking and operator overloading. This has
> been discussed at great length before and a lot of interesting information
> can be found by perusing the mailing list archives.
>
> I shall remain skeptical that GCaml improves upon this solution this until I
> get to write a decent-sized project in GCaml. I am keen to see GCaml though.
FWIW, I find this works lovely in Haskell. :-)

Michael

[1] http://www.lisp.org/HyperSpec/Body/mac_multiple-value-bind.html