Is this a viable effort? The DRY principle, community-wide

[Guilherme Vieira]

On Tue, Jan 4, 2011 at 11:13 AM, spir <denis.spir at gmail.com> wrote:

> On Tue, 4 Jan 2011 02:30:24 -0200
> Guilherme Vieira <n2.nitrogen at gmail.com> wrote:
>
> > At times like this I wish people would really break their code in smaller
> > parts in a way you could really just pick what you want from it.
>
> I guess this is a dream generations of programmers, language designers and
> computer scientist have run after. Say, Lego programming. Bulding bricks
> which are _really_ autonomous.
> Maybe there is a flaw in the implicite reasoning behind that vision: as a
> client, one wants the (library) building blocks they use to be autonomous,
> right; but at a higher-level the software one is designing is precisely
> using other software, thus creating a system of dependancies... which makes
> this new piece of code unusable in an autonomous manner by yet another
> client who would enjoy reusing it as a brick. The same applies to the
> (library) bricks: they have to use other building blocks which prevent them
> to be autonomous.
>
> This is how I see the point. And it gets even more unavoidable because of
> generality. For a brick to have any chance to meet one client's needs it
> must be as general/abstract as possible. This means for instance abstract
> away issues of OS idiosyncrasies, actual types, sizes and loads of other
> annoying aspects, think at how write*, map, or file opening work. To do
> this, using yet another bunch of tools is often necessary. The more a brick
> gets general and thus useful, the more chances it has _not_ to be
> autonomous. I guess.
> This, to the point that if Phobos (2) would be rewritten from scratch using
> everywhere D2's newer style (more general/abstract, as I see it), most of
> its modules would import a load of other modules such as algorithm,
> contracts, functional, range, possibly type*, traits, variant; which
> themselves import...
>
> I don't logically there can be a solution. I would like to try to define a
> minimal subset D lib functionality, say the standard toolkit. (I have one
> for my personal, a dozen elements systematically imported, and most commonly
> actually used, in every of my modules.) Then, make this a kind of
> auto-import (à la python) for user code, except if other wise stated; and
> see if it's enough, overkill, whatever.
> Then, struggle to make (other) lib modules depend on these toolkit
> elements, and only and them, as much as possible. (Even when it's not the
> best design/code solution.) Could such an approach work?
>
>
> Denis
> -- -- -- -- -- -- --
> vit esse estrany ☣
>
> spir.wikidot.com
>
>
Yes, I don't see how could each module not depend on each other, but that's
not the point. It would be a hierarchy, after all; there would have to be
dependencies. But I don't particularly care if a C++ library depends on
Boost, for example. Boost is behemoth, but it is well-modularized (you can
really pick just a pretty small subset of it) and, more importantly, it's so
widely accepted it's almost a standard library. So who cares?

On Tue, Jan 4, 2011 at 9:06 AM, Dmitry Olshansky <dmitry.olsh at gmail.com>wrote:

> Sounds a lot like std lib. Maybe an incubator project for Phobos?
> (was discussed sometime ago) Also check scrapple on Dsource.
>

I don't think it could get into Phobos. I think of relatively bigger things,
too, such as cross-platform mouse, keyboard and gamepad input library done
right to be the definitive way of doing that on D. That just doesn't seem
fit for a true standard library, does it?

 For example, what do you do if you want to create a window just for
>>  use with OpenGL in a cross-platform way? You have to write different
>>  versions of the window creation procedure for the different systems
>>  you're targeting. Or you could use SDL, but if you really just want
>>  the window that's a waste. Right?
>>
>
> For that particular case GLUT may fit just fine. Or GLAux.
>

I see GLUT solves the problem for OpenGL, but then we get to the granularity
point: the input library I told you above also needs a window. To make it
depend on GLUT would be stupid. And then we get back to the wheel
reinvention problem.

The only problem with it : people still can't invent the best way to do
> something, plus the matter of taste.
>

The "best way" of doing something is always a subjective matter. But, as
usual, one can define rules that, when fully respected, result in something
that can be tagged at least as "pretty good". Make those rules
community-reviewed and you normalize people's needs. I'm pretty sure much of
D was decided this way.

Also, if you are really thorough in deciding how to break the pieces of the
system, then maybe people won't be too bothered if it's a bit off their
tastes.

-- 
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110104/02be3e36/attachment.html>