Browse thread
Estimating the size of the ocaml community
-
Yaron Minsky
-
Christopher A. Watford
-
Frédéric_Gava
-
skaller
-
Erik de Castro Lopo
- Olivier_Pérès
-
Thomas Fischbacher
-
Frédéric_Gava
-
Thomas Fischbacher
- Paul Snively
- josh
- Richard Jones
-
Jon Harrop
-
Michael Walter
-
Jon Harrop
- Damien Doligez
- Thomas Fischbacher
- Michael Walter
-
Radu Grigore
- Gerd Stolpmann
- Jon
-
Jon Harrop
-
Thomas Fischbacher
-
Andreas Rossberg
- Thomas Fischbacher
- Oliver Bandel
- Christophe TROESTLER
-
Andreas Rossberg
- Richard Jones
-
Michael Walter
- Ville-Pertti Keinonen
- Oliver Bandel
- Basile STARYNKEVITCH
-
Thomas Fischbacher
- ronniec95@l...
- skaller
- chris.danx
-
Frédéric_Gava
-
Erik de Castro Lopo
- sejourne_kevin
- Stefano Zacchiroli
-
skaller
-
Frédéric_Gava
- Kenneth Knowles
- Michael Jeffrey Tucker
- Richard Jones
- Nicolas Cannasse
- Evan Martin
- Eric Stokes
- chris.danx
- Sylvain LE GALL
- sejourne_kevin
- Sven Luther
- Johann Spies
-
Christopher A. Watford
[
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: | Thomas Fischbacher <Thomas.Fischbacher@P...> |
| Subject: | Re: [Caml-list] Estimating the size of the ocaml community |
On Fri, 4 Feb 2005, Andreas Rossberg wrote: > > (1) Prevent the programmer from "accidentally plugging an electrical > > shaver into a power high-voltage outlet". > > In my personal experience, this is absolutely essential when you go > higher-order in non-trivial ways - dynamic type errors won't give you > the slightest clue when you screw up some combinator plugging. Here, I might disagree. Pretty much of what I've been doing in LISP so far involved higher order functions in nontrivial ways, to the extent of passing anonymous functions which are themselves passed into anonymous functions. I never experienced any serious difficulty with it. But that might perhaps be just because I previously got used to deep higher-order programming by doing a lot of SML/NJ. > (Incidentally, Lisp also isn't very well suited for higher-order > programming, because of its syntax issues: no light-weight application > syntax and currying.) Yes, it required some getting used to it, and ML syntax looks somewhat nicer here. But this I do not experience as a big issue. Whatever I can do in terms of currying in ML I can just as well do in Lisp. > > (2) Give the compiler hints how to optimize certain manipulations in terms > > of machine instructions. > > The latter is actually the least important point. More significant are: Depends. For quite many applications, speed is an issue. After all, many people today go in the direction of doing low-level stuff in C, implementing functionality in form of a library, and using Perl or Python as a high level scripting language for flexibility. Of course, it's somewhat more convenient not to have such an artificial barrier in the system. This can be achieved, with a language that is both highly performant and flexible. Both Lisp and Ocaml satisfy this criterion, and hence are quite cool systems. > Type abstraction may not be powerful enough to fully capture units, but > it goes a long way. And you cannot seriously argue that something is > useless because it does not cover everything. I don't say it's useless. I just say that as it is it's useless _for me_ personally. I don't want to speak for anyone else here. I'm pretty sure many people out there will benefit from ocaml's type system. I, however, do not. -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)