www.digitalmars.com         C & C++   DMDScript  

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

reply Guilherme Vieira <n2.nitrogen gmail.com> writes:
--00163628488031f38e0498fdba68
Content-Type: text/plain; charset=ISO-8859-1

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?

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.

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.

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.

So, what do you think?

   - Is it viable?
   - Would it be useful?
   - Improvements?


-- 
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira

--00163628488031f38e0498fdba68
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 sol=
utions to ridiculously small problems or actually reinventing the wheel.<di=
v>
<br></div><div>For example, what do you do if you want to create a window j=
ust for use with OpenGL in a cross-platform way? You have to write differen=
t versions of the window creation procedure for the different systems you&#=
39;re targeting. Or you could use SDL, but if you really just want the wind=
ow that&#39;s a waste. Right?</div>
<div><br></div><div>At times like this I wish people would really break the=
ir code in smaller parts in a way you could really just pick what you want =
from it.</div><div><br></div><div>So I thought, since D has such a compact =
community and the codebase is still small, maybe you would like to attack t=
he &quot;problem&quot; (dunno if many will agree with me this is a problem,=
 but then I&#39;d like to know what they do in the case I described) togeth=
er.</div>
<div><br></div><div>I&#39;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 hierar=
chy, though.</div>
<div><br></div><div>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&#39=
;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).</div>
<div><br></div><div>I would then engage into writing what&#39;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-c=
ase.</div>
<div><br></div><div>The core notion here is that D libraries could be the c=
ommunity&#39;s, not the author&#39;s. I wonder if merging people&#39;s effo=
rts 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 inter=
faces, essentially making two user-libraries, each using one of the first o=
nes, incompatible when in a perfect world they really shouldn&#39;t be, etc=
.</div>
<div><br></div><div>So, what do you think?</div><div><ul><li>Is it viable?<=
/li><li>Would it be useful?</li><li>Improvements?</li></ul></div><div><br><=
/div><div>-- <br>Atenciosamente / Sincerely,<br>Guilherme (&quot;n2liquid&q=
uot;) Vieira<br>

</div>

--00163628488031f38e0498fdba68--
Jan 03 2011
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.

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?

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
Jan 04 2011