Re: top-down design + nevermind

Re: top-down design + nevermind

[cr88192 sydney]

>
>this is related to recent guile-snarf weirdness but could be said to
>apply generally to ends such as setting guile's direction.  top-down
>design values interface elegance more than implementation elegance.  the
>implementation does what it needs to support the interface and in return
>for bearing this burden is given the freedom to evolve.
>
>this is obviously in contrast to bottom-up design which i believe can
>get a lot of unfocused work done but often presumes to know the future
>too much in practice, eventually causing re-design, because elegance is
>measured in the implementation and guesses are made about usage.
>
>either style of design is fun.  people write books about their own
>personal design philosophies and how it helps you (10min a day).  in any
>case, what users perceive determines their happiness w/ the result.
>
>so how to choose the style that fits best for the job?
>
I use both, for my os I use bottom up design and for my compiler I used top 
down.
main difference: top down is a lot faster it would seem (a few hours vs. 
months), however top down becomes increasingly harder as complexity 
increases (at least in my experience).
also top down tends to yeild code which is quite difficult to reuse in 
another project (my compiler + my os), and quite difficult to change later 
or maintain...

>
>what is guile's direction, btw?
>
I think it is more bottom up...
no one started coding an ide and came up with guile/scm in the process. just 
now are ide's starting to form... (as far as I know).

in a whole cs and science in general seem to be a bottom up process, with 
occasional "products" that are built in the top down manner...

I support bottom up in general, but would not recommend it if time is a big 
issue...


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[Bill Gribble]

On Sun, 2002-04-07 at 23:29, Thien-Thi Nguyen wrote:
> this is obviously in contrast to bottom-up design which i believe can
> get a lot of unfocused work done but often presumes to know the future
> too much in practice, eventually causing re-design, because elegance is
> measured in the implementation and guesses are made about usage.

What's wrong with redesign?  In my experience, there's no such thing as
a software design that's correct from the start.  Redesign should be
built into the process, because it *will* be required.  

Top-down design takes the closed-loop process of software engineering
and tries to make it open-loop.  The only way to do this is to assert by
fiat that implementation experience does not feed back into design. 
IMO, that's dumb.   

Customer needs, developer experience, and strategic (management) goals
all are parts of the design process.  None of these things can be
completely specified in advance.  Design and implementation must proceed
together and iteratively in order to use resources most efficiently,
IMO.  

Software "architecture" is not like building "architecture"... if it
was, there would be no need for programmers to be more educated than
construction workers.  All the interesting work would be in the design
phase, and no code would be written until the "blueprint" was complete. 
That might be a management jerk-off fantasy, but it's a recipe for a
train wreck. 

Why?  Lots smarter people than me have taken that on.  My understanding
is rooted in the construction analogy.  Why can an architect design a
building completely up front?  Well, part of it is that we know more
about the material properties of reinforced concrete than any other
substance.  There are shelves of books devoted to the ways in which
reinforced concrete behaves in every imaginable condition of
temperature, moisture, composition; ways in which different patterns of
reinforcing bars affect flexibility, strength, strain and shear
properties; failure modes, etc, etc.  

When it comes to software, our equivalent level of knowledge is "if you
mix cement, sand, and water, and pour it in a form with metal bars, you
can build things".  It's just not reasonable to design a bridge with
that level of knowledge.  Thankfully, '$ cd bridge; make check;' takes a
lot less time than building a bridge. so it's reasonable to have
prototyping, redesign, and implementation feedback built in to the
process. 

b.g.




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[news]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> so how to choose the style that fits best for the job?

It probably depends on the people, and their inclinations at a
given time.  In a good case, it sorts naturally, and enough
people are architecting, enough people are library building and
enough are auditing test suites and generating docs.

> guile-user cc'ed, to also mention how little reponse there was to the
> mailinglist unification (5 resp., 4 yes).  perhaps the question was not
> worthy of the survey idea.  damn, i knew i was nuts.

Oops, I must have missed that questionnaire.

> what is guile's direction, btw?

What do you think?

Chris

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[Thien-Thi Nguyen]

   From: (Chris Beggy ) news@kippona.com
   Date: Mon, 08 Apr 2002 19:08:48 -0400

   What do you think [re guile direction]?

i think guile is moving towards a federated development model.  whatever
people's inclinations and abilities are, they can band together and fork
a "guile design instance" (and code, presumably) that is candidate for
integration using due process.

basically, SIGs like for python, but recognizing plurality.  the goal
remains to please the users, but the users have to take responsibility
to communicate precisely what pleases them, and work the system to get
their desired results.  incompatible branches are somewhat frowned upon,
but should not be denied berth.  emacs/xemacs watchers wag their fingers
but maybe they can help prevent similar long-term pain.

"due process" sounds heavy but the hint here is to get one of your SIG
members write privs early on (to get write privs you have to follow some
slackful methods so presumably your repo insider can find the balance
points for your SIG on the tightrope across the chaos).

the overall effect is that specific designs will be implemented for
their proponents' benefit, and maybe busy bees will cross-pollinate the
good bits into the common base, as is their style.  all guile users are
programmers and all programmers who use guile are encouraged to expand
their usage of guile to include changing guile and telling others about
it.

(guile is not an application -- it is a framework for ("extensive" :-)
experimentation in language and runtime implementation -- how's that for
an ad blurb?)

"but what if i just want to use (the standard) Guile?".  well, figure
out what is "standard" and form a Standard Interest Group.  :->

btw, perhaps there are other interesting grouping terms besides BOF and
SIG -- be creative!

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[Thien-Thi Nguyen]

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 08 Apr 2002 07:47:28 -0500

   What's wrong with redesign?  In my experience, there's no such thing as
   a software design that's correct from the start.  Redesign should be
   built into the process, because it *will* be required.  

redesign is fine (and i concur that it should be built into the
process), but forced redesign is not so fun.

   Top-down design takes the closed-loop process of software engineering
   and tries to make it open-loop.  The only way to do this is to assert
   by fiat that implementation experience does not feed back into
   design.  IMO, that's dumb.

   Customer needs, developer experience, and strategic (management)
   goals all are parts of the design process.  None of these things can
   be completely specified in advance.  Design and implementation must
   proceed together and iteratively in order to use resources most
   efficiently, IMO.

well wouldn't you agree that customer-driven development is indeed a
form of top-down design?  rather than set up an exclusive-or algorithm
to choose top-down or bottom-up, i'm hoping to entice discussion to
learn other people's heuristics on how they effectively use these two
approaches concurrently.

   Software "architecture" is not like building "architecture"... if it
   was, there would be no need for programmers to be more educated than
   construction workers.  All the interesting work would be in the design
   phase, and no code would be written until the "blueprint" was complete. 
   That might be a management jerk-off fantasy, but it's a recipe for a
   train wreck. 

most "programmers" are not as well educated as construction workers,
actually, in the craft of their choosing.  there are certain organizing
principles programmers can learn from construction workers: regularity,
the the plumb and the square, using orthogonal units, choosing (or
creating) the right tool for the job, saving leftover pieces of good
material for fun later... generally, how to live comfortably taking
advantage of the physical world's simple constraints.

any profession can learn to code, evidently.  the code is of course
specific to that profession.  what is the programming profession but the
art of translating vague requirements (like "the release must be
stable") into code, and knowing where to put the interpretive hooks?

programmers who can manage themselves don't need additional professional
managers, although many might want one (who can program, too!).

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[news]

Bill Gribble <grib@linuxdevel.com> writes:

> What's wrong with redesign?  In my experience, there's no such thing as
> a software design that's correct from the start.  Redesign should be
> built into the process, because it *will* be required.  

Maybe you just disagree on the definition of redesign vs. bug
fixes/maintenance.

A good flow is design, test, code, test, fix bugs, release, fix
bugs, maintenance release. If you redesign from scratch, you lose
the old bug fixes, and introduce the same or different ones. In
addition, the code base loses the history of maintenance releases.

A good rule of thumb is that the redesign from scratch is
justified if it will lead to a 10x improvement of some sort
(speed, ease of use, cost, maintainability, reduced bugginess.)

> Top-down design takes the closed-loop process of software engineering
> and tries to make it open-loop.  The only way to do this is to assert by
> fiat that implementation experience does not feed back into design. 
> IMO, that's dumb.   

I've never seen a project that didn't have a large portion of
top down design, unless it was a "make from" derivative.

> Customer needs, developer experience, and strategic (management) goals
> all are parts of the design process.  None of these things can be
> completely specified in advance.  Design and implementation must proceed
> together and iteratively in order to use resources most efficiently,
> IMO.  

Does the list above apply to guile?  I mean, there is a spec,
r5r, and SRFIs.  Beyond that, someone programming in guile should
at least be able to do some fancy math, some regexps, some unix
system programming, nice IO on MS/Mac/*nix, easy connection to
SQL databases.  That's the *minimum* for usefulness, I'd say.
Beyond that, guile needs an extension method (module, package,
etc.), a method of sharing like CPAN or CTAN, and a community.

I think guile has a special feature, it can be an embedded
scripting language for C programs.  I suspect that this is a
harder problem, which can be in a module, separate from the
easily specified parts of a scheme implementation.

Chris

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[MJ Ray]

(Chris Beggy ) news@kippona.com <news@kippona.com> wrote:
> Beyond that, guile needs an extension method (module, package,
> etc.), a method of sharing like CPAN or CTAN, and a community.

It has modules, doesn't it?  Or did someone remove them?

If by CPAN you mean an archive, surely it has that with the projects list? 
If you mean an automated extension install system I say "noooooooooo".

Is there a community?  #scheme is quite quiet, but this list and the cls
newsgroup are quite chatty.

> I think guile has a special feature, it can be an embedded
> scripting language for C programs.

Is that really that special?  It's a nice feature, but hardly a Unique
Selling Point.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[Christopher Cramer]

On Wed, Apr 24, 2002 at 04:59:50PM +0000, MJ Ray wrote:
> Is there a community?  #scheme is quite quiet, but this list and the cls
> newsgroup are quite chatty.

There's also #guile, on Open Projects Net (irc.openprojects.net).

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
On résiste à l'invasion des armées; on ne résiste pas à l'invasion
des idées.  -- Victor Hugo

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[MJ Ray]

Christopher Cramer:
> There's also #guile, on Open Projects Net (irc.openprojects.net).

Bah, why factionalise?  It's not like there are so many schemers that guile
people can't talk to MIT people talking to PLT users, is it?  #guile seemed
quiet too.  What is this "people's front of Judea" syndrome?
-- 
MJR

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: top-down design + nevermind

[news]

MJ Ray <markj@cloaked.freeserve.co.uk> writes:

> (Chris Beggy ) news@kippona.com <news@kippona.com> wrote:
>> Beyond that, guile needs an extension method (module, package,
>> etc.), a method of sharing like CPAN or CTAN, and a community.
>
> It has modules, doesn't it?  Or did someone remove them?
>
> If by CPAN you mean an archive, surely it has that with the projects list? 
> If you mean an automated extension install system I say "noooooooooo".
>
> Is there a community?  #scheme is quite quiet, but this list and the cls
> newsgroup are quite chatty.

Thanks for pointing this out.

I wasn't contending that these features do or do not exist, only
that they should be in guile, from one user's viewpoint.  Another
way to say it is, if these features do exist, please don't drop
support for them!

>> I think guile has a special feature, it can be an embedded
>> scripting language for C programs.
>
> Is that really that special?  It's a nice feature, but hardly a Unique
> Selling Point.

I was unclear.  My point was, I hope work on this special feature
isn't causing changes to guile-core which affect backward
compatibility of scheme code.

Chris

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

top-down design + nevermind

[Thien-Thi Nguyen]

this is related to recent guile-snarf weirdness but could be said to
apply generally to ends such as setting guile's direction.  top-down
design values interface elegance more than implementation elegance.  the
implementation does what it needs to support the interface and in return
for bearing this burden is given the freedom to evolve.

this is obviously in contrast to bottom-up design which i believe can
get a lot of unfocused work done but often presumes to know the future
too much in practice, eventually causing re-design, because elegance is
measured in the implementation and guesses are made about usage.

either style of design is fun.  people write books about their own
personal design philosophies and how it helps you (10min a day).  in any
case, what users perceive determines their happiness w/ the result.

so how to choose the style that fits best for the job?

guile-user cc'ed, to also mention how little reponse there was to the
mailinglist unification (5 resp., 4 yes).  perhaps the question was not
worthy of the survey idea.  damn, i knew i was nuts.

what is guile's direction, btw?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user