Why don't use batteries

Why don't use batteries

[Julien Signoles]

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

Re: [Caml-list] Why don't use batteries

[Richard Jones]

On Fri, Sep 04, 2009 at 02:49:52PM +0200, Julien Signoles wrote:
> 3) It makes my executables too big
> Yes, even if it seems to be improved in a close future.

Is this a complaint against Batteries in particular or OCaml in
general?  OCaml binaries in general are rather large, and it appears
to be because the runtime / GC is statically linked.  Do you know how
much this would improve with dynamic linking of libasmrun.a (which
IIRC was a feature added in 3.11)?

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Why don't use batteries

[David Rajchenbach-Teller]

I take it to be a complaint against Batteries in particular
(helloworld.native is several Mb, when linked statically) and agains the
compiler in particular (in any given program, most of this is dead code
which the compiler fails to remove).

Xavier Leroy is aware of the issue. Maybe either he or Xavier Clerc will
be able to look at it someday.

Cheers,
 David

On Fri, 2009-09-04 at 15:00 +0100, Richard Jones wrote:
> On Fri, Sep 04, 2009 at 02:49:52PM +0200, Julien Signoles wrote:
> > 3) It makes my executables too big
> > Yes, even if it seems to be improved in a close future.
> 
> Is this a complaint against Batteries in particular or OCaml in
> general?  OCaml binaries in general are rather large, and it appears
> to be because the runtime / GC is statically linked.  Do you know how
> much this would improve with dynamic linking of libasmrun.a (which
> IIRC was a feature added in 3.11)?
> 
> Rich.
> 

Re: [Caml-list] Why don't use batteries

[Dmitry Bely]

On Sat, Sep 5, 2009 at 11:35 AM, David
Rajchenbach-Teller<David.Teller@ens-lyon.org> wrote:
> I take it to be a complaint against Batteries in particular
> (helloworld.native is several Mb, when linked statically) and agains the
> compiler in particular (in any given program, most of this is dead code
> which the compiler fails to remove).
>
> Xavier Leroy is aware of the issue. Maybe either he or Xavier Clerc will
> be able to look at it someday.

Returning to an old discussion

http://caml.inria.fr/pub/ml-archives/caml-list/2005/11/048f8f60868cf31d27d7fd66e3914023.en.html

I don't think it can be (and will be) done. We should live with these
big executables with considerable amount of dead code.

> Cheers,
>  David
>
> On Fri, 2009-09-04 at 15:00 +0100, Richard Jones wrote:
>> On Fri, Sep 04, 2009 at 02:49:52PM +0200, Julien Signoles wrote:
>> > 3) It makes my executables too big
>> > Yes, even if it seems to be improved in a close future.
>>
>> Is this a complaint against Batteries in particular or OCaml in
>> general?  OCaml binaries in general are rather large, and it appears
>> to be because the runtime / GC is statically linked.  Do you know how
>> much this would improve with dynamic linking of libasmrun.a (which
>> IIRC was a feature added in 3.11)?
>>
>> Rich.

- Dmitry Bely

Re: [Caml-list] Why don't use batteries

[David Rajchenbach-Teller]

On Fri, 2009-09-04 at 14:49 +0200, Julien Signoles wrote:
> 8c) Not homogeneous enough.

I agree on most of your points. However, we are trying very hard to be
homogeneous. So if you feel that we're not homogeneous enough, it means
that we're failing somewhere. Do you have details?

> 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?).

Ok, that's a good point. The main focus is having a set of high-level
libraries. This can benefit both students and most developers (probably
not developers who intend to squeeze the last bit of performance from
the compiler, though).

Now, let's be clear: the primary audience is *developers*, but this does
not mean only OCaml hackers. This also means people from the Java/C#
world, for instance.

I hope this lifts part of the confusion.

Cheers,
 David