From: Julien Signoles <Julien.Signoles@cea.fr>
To: caml list <caml-list@inria.fr>
Subject: Why don't use batteries
Date: Fri, 04 Sep 2009 14:49:52 +0200 [thread overview]
Message-ID: <4AA10CF0.7070403@cea.fr> (raw)
Hello,
Here are my personal reasons:
2) It's not 1.0 yet, I'll try it then
Changing "try" by "have another look at" ;-)
3) It makes my executables too big
Yes, even if it seems to be improved in a close future.
4) It's too hard to install (dependencies, godi failures)
Yes: pretty sure that it's not an issue for me but one for users of my
own libraries/tools.
5) It's difficult to compile against
See point 4.
6) It doesn't work on my platform
See point 4.
7) It uses camlp4
Yes. I'm not a camlp4's fan (mostly for the same reasons that I'm not a
batteries' fan and also because it's look like another dsl I prefer to
don't use whenever possible).
8) Other (please explain)
8a) Not mature enough, so not usable for developing (what I would like
to be) mature libraries/tools. I'm even not sure that "not yet 1.0" are
the key point here since maturity is not just a question of naming: the
latest Jane Street's core library is 0.5.3, I'm pretty sure it is mature
enough and I'm pretty sure that batteries 1.5.3 will not be... I hope
I'm wrong for the last part of the last sentence.
8b) I'd like to see what is stable, what is experimental, especially for
big libraries like batteries.
8c) Not homogeneous enough.
8d) Not clear enough for me what is the targeted audience: seem to be
first for students, now for any developers but still with a dedicated
focus for students (hum, maybe not after all?).
8e) My point of view is that the Jane Street's core library looks like
what I would like to have as an extension of the caml stdlib: mature
enough, well tested, documented enough, homogeneous (with excellent
conventions), easy to use, not too big, big enough to provide useful
features.
Well guys, sorry: I'm quite critical with batteries here... But
hopefully batteries will be improved in the future. I know that
designing and implementing such a library is a very hard and
time-consuming task. So thank's for your work and for doing your best
for the caml community.
--
Julien
next reply other threads:[~2009-09-04 12:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-04 12:49 Julien Signoles [this message]
2009-09-04 14:00 ` [Caml-list] " Richard Jones
2009-09-05 7:35 ` David Rajchenbach-Teller
2009-09-07 14:42 ` Dmitry Bely
2009-09-05 7:33 ` David Rajchenbach-Teller
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=4AA10CF0.7070403@cea.fr \
--to=julien.signoles@cea.fr \
--cc=caml-list@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