Designing Packages and programs for a newbie.

Designing Packages and programs for a newbie.

[Stapler]

Recently I've had a series of epiphanies concerning just how crummy my designs,
specs, and type systems actually were/are.

Hence I'm doing research on proper procedures and considerations for
designing small applications and packages. I havent delved into very
large applications because I havent had a need to.

First, I'm looking for perhaps some good introductory docs/texts on the
design process and the different approaches taken.

Because my applications are limited in scope, performance isn't a
problem. However I like to see just how small I can make the binary
executable. Are there any design pointers you would suggest that might
help in this regard?

Any pointers or information would be appreciated. Thanks.


Stapler

Re: Designing Packages and programs for a newbie.

[achrist]

Here's one link to something we discussed here some year or three back:

http://www.therationaledge.com/content/jan_01/f_craftsci_kb.html

It was simple enough for me to like.  Note that there are a couple
of other connected articles in the same series at that site.


Al Christians

Re: Designing Packages and programs for a newbie.

[Jeffrey Carter]

Stapler wrote:
> First, I'm looking for perhaps some good introductory docs/texts on the
> design process and the different approaches taken.

Good design is the process of creating useful abstractions. Examples 
include abstracting entities external to the software that the software 
must interact with (external interfaces) and major data structures 
internal to the software.

An Ada package is usually an implementation of an abstraction. As such 
its specification should hide the implementation of the abstraction and 
only expose what is necessary for the client to use that abstraction.

My experience indicates that creating useful abstractions is a skill 
that cannot be taught or learned. In addition, it's a fairly rare skill. 
That you recognize deficiencies in your early designs is a good sign. 
Those who have the skill seem to realize what is needed from seeing good 
examples, while those who don't never do.

This is a major cause of the poor state of software. Anyone who can 
write code is considered qualified to design software. This is why we 
see major projects that are designed around a types package, a variables 
package, a hardware package, and a processing package.

> Because my applications are limited in scope, performance isn't a
> problem. However I like to see just how small I can make the binary
> executable. Are there any design pointers you would suggest that might
> help in this regard?

This is an irrelevant consideration. For certain applications you may be 
constrained by the amount of memory available to hold the application, 
but executable file size is often not a good measure even of that.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Designing Packages and programs for a newbie.

[Chad R. Meiners]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3DDEDC0F.60903@acm.org...

> My experience indicates that creating useful abstractions is a skill
> that cannot be taught or learned. In addition, it's a fairly rare skill.

You realize that you are suggesting that only a few people are BORN with the
ability to make useful abstractions AND that the skill is inherent in these
people when you state the skill cannot be taught or learned.

-CRM

Re: Designing Packages and programs for a newbie.

[Georg Bauhaus]

Stapler <spam.magnet@yahoo.com> wrote:
: Hence I'm doing research on proper procedures and considerations for
: designing small applications and packages.

A good question to ask yourself (which I haven't invented) is,
`How do you build a house'?

Try to find answers, find things mentioned in answers, ponder.
Then ask a similar question about software project X.

This will likely take some time.

-- georg