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

Dmitry Olshansky dmitry.olsh at gmail.com
Tue Jan 4 03:06:23 PST 2011


On 04.01.2011 7:30, Guilherme Vieira wrote:
>  I may sound daring or even foolish proposing this, but here goes
>  nothing.. one of the things that bothers me about software
>  development is that people always tell you not to reinvent the
>  wheel, but the libraries available are generally not fine-grained
>  enough, so you end up either using overkill solutions to ridiculously
>  small problems or actually reinventing the wheel.
>
>  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.
>
>  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.
>
Dependencies are the main problem here I think. E.g. library A fit the 
bill but uses it's own matrices lib B and quaternions lib C  and so on. 
And what's worse quite another useful library D has it's own set of 
reinvented wheels. In such cases you can tear down library in small 
pieces but then you'd have to resolve dependencies.

>  So I thought, since D has such a compact community and the codebase
>  is still small, maybe you would like to attack the "problem" (dunno
>  if many will agree with me this is a problem, but then I'd like to
>  know what they do in the case I described) together.
>
>  I'd like to propose a community-written, community-reviewed
>  hierarchy of modules anybody could (and should :)) contribute to.
>  Necessities would be factored and layered before entering the actual
>  hierarchy, though.

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

>
>  For example, right now I really wanted a cross-platform way of using
>  OpenGL. AFAIK, OpenGL usage is normalized across many systems and
>  only its initialization is platform-depedent (to begin with, there's
>  WGL, GLX and AGL; plus, you have very different ways of creating
>  windows in those systems, so you need to do a lot of work to really
>  use OpenGL in a cross-platform manner).
>
>  I would then engage into writing what's needed and, when done, I
>  would send it for the community to review. The modules would be
>  fragmented, trying not to compromise its usability in any possible
>  use-case.
>
>  The core notion here is that D libraries could be the community's,
>  not the author's. I wonder if merging people's efforts can be a good
>  idea. I mean, you would avoid reinventing the wheel, you would avoid
>  having many libraries doing the same thing with different
>  interfaces, essentially making two user-libraries, each using one of
>  the first ones, incompatible when in a perfect world they really
>  shouldn't be, etc..

The only problem with it : people still can't invent the best way to do 
something, plus the matter of taste.
Two libraries no problem, two big frameworks - bound to be incompatible 
and overkill for most uses.
>
>  So, what do you think?
>
>  * Is it viable?
* Would it be useful?
Yup ! :)
* Improvements?
May be require the modules in this hierarchy to reduce cross-dependency 
unless absolutely needed?

What I would like is  "D2 reconnaissance  project" i.e. maintain a list 
of all actively developed D2 projects.

-- 
Dmitry Olshansky



More information about the Digitalmars-d mailing list