November 29, 2007
Robert Fraser wrote:

> IMHO, the bigger the standard library, the better in most cases. Standard library code is well-reviewed and tested, so you can generally count on it more than 3rd party libraries, open source or not. Arguably more importantly, having a standard way of doing things makes code more consistent, reducing incompatibilities and portability issues. Further, if everyone knows the standard library (or a piece of it), a new developer can join the team and be instantly familiar with how to craft their code, and what the existing code does, without reading extensive documentation.

These arguments are undeniable, but taken to the extreme there are problems. First, when specifying a standard library one runs the risk of making a mistake and standardizing a poor design. Then everyone is stuck with the error "forever." With a large library the probability of this happening is greater. Then, of course specialized applications need specialized methods. Thus attempting to put everything in the world into a standard library results in lots of things that only a few people really want to use. This just bulks up the standard for no particular reason and makes life needlessly difficult for implementors (resulting in fewer implementations that also have lower quality than would otherwise be the case). Finally, standardization tends to inhibit innovation; new library ideas might be left unexplored if the standard has already claimed too much territory.

All that said, the trend today is for large standard libraries and experience shows that they are helpful. However, I believe there is a limit. It is not necessarily the case that bigger is better.

Peter
November 29, 2007
Peter C. Chapin wrote:
> 
> Still, as was mentioned elsewhere, since D is garbage collected
> targetting extremely small machines such as 8 bit microcontrollers with
> 16K of RAM (for example) is probably not in D's future anyway. Thus
> standard library size might not be that big a deal for it.

D doesn't have to be garbage collected, though I suppose not doing so may violate the standard.  The Tango tree, for example, includes a stub GC that simply calls malloc and free and performs no actual collection.  My motivation for creating this GC was to provide an example for kernel developers and the like, who may well not want to use an actual garbage collector in their code.

Kernel and embedded development were the primary user-oriented motivation for making not only a modular library but a modular runtime as well.  Targeting a system that doesn't support preemptive multitasking?  Just stub out threading support.  etc.  The Tango runtime actually consists of three entirely separate libraries that are bundled together for convenience, but they can be replaced individually as well if the user actually cares to go that route.


Sean

P.S. I apologize for talking about Tango in a Phobos thread.  This is one aspect of Tango's design most people don't seem aware of and I wanted to address it.
December 01, 2007
Bill Baxter wrote:
> Alexander Panek wrote:
>> On Mon, 26 Nov 2007 11:07:40 -0800 (PST)
>> Brad Roberts <braddr@puremagic.com> wrote:
>>
>>> For the short term (and quite possibly long term), I don't expect to
>>> use dsource for much more than it's svn repository.  There's already
>>> the d bugzilla instance which is doing a perfectly good job. 
>>
>> Fair enough, but Trac is way easier to use than bugzilla. And, the
>> probably more weighing point: it interfaces with the underlying source
>> control in such a way that tickets can be associated to changesets and
>> revisions. I think this is one very big advantage over bugzilla. That
>> way it would even be possible to submit patches in tickets and see
>> how they've been applied, etc.
> 
> That may be, but you have to weigh that benefit against the cost of having the bug database split across two trackers and/or migrating all the existing bugzilla entries over to trac.
> 
> --bb

# python trac/contrib/bugzilla2trac.py

Let me know if you would like to run this script on the existing BZ database and port existing bugs over.  It isn't quite that simple, of course, but I've done it at a previous job.

Also, I'm sure we could work something out as far as NG notifications.

All of this being said, I would rather use my time in Dec, Jan, which is historically very active DSource work, for completing the new version of the site in general, as I discussed at the conference.  Plus, finishing off Mercurial support (we are very close), and adding git support.

Cheers,
BA
December 01, 2007
Brad Anderson wrote:
> Bill Baxter wrote:
>> Alexander Panek wrote:
>>> On Mon, 26 Nov 2007 11:07:40 -0800 (PST)
>>> Brad Roberts <braddr@puremagic.com> wrote:
>>>
>>>> For the short term (and quite possibly long term), I don't expect to
>>>> use dsource for much more than it's svn repository.  There's already
>>>> the d bugzilla instance which is doing a perfectly good job. 
>>>
>>> Fair enough, but Trac is way easier to use than bugzilla. And, the
>>> probably more weighing point: it interfaces with the underlying source
>>> control in such a way that tickets can be associated to changesets and
>>> revisions. I think this is one very big advantage over bugzilla. That
>>> way it would even be possible to submit patches in tickets and see
>>> how they've been applied, etc.
>>
>> That may be, but you have to weigh that benefit against the cost of having the bug database split across two trackers and/or migrating all the existing bugzilla entries over to trac.
>>
>> --bb
> 
> # python trac/contrib/bugzilla2trac.py
> 
> Let me know if you would like to run this script on the existing BZ database and port existing bugs over.  It isn't quite that simple, of course, but I've done it at a previous job.
> 
> Also, I'm sure we could work something out as far as NG notifications.
> 
> All of this being said, I would rather use my time in Dec, Jan, which is historically very active DSource work, for completing the new version of the site in general, as I discussed at the conference.  Plus, finishing off Mercurial support (we are very close), and adding git support.
> 
> Cheers,
> BA

No, please don't.  I want to continue using the existing bugzilla instance.
December 02, 2007
Dejan Lekic wrote:
> 
> I honestly hope Phobos will remain what it is - a simple, core library, and I hope it will not "evolve" into a huge framework of JAVA API, or .NET 2 size.
> 
> I would gladly see Phobos remain as the core, and emerging of some higher-level, huge library (framework) on top of it, with all modern features of frameworks mentioned above.
> 
> Kind regards
> 
> Dejan Lekic

I think we need Phobos Lite and Phobos (Which is Phobos Lite + components).  I wouldn't want to discourage making Phobos huge because that simply means its more useful for more people.

-Joel
1 2 3 4
Next ›   Last »