Kenneth Tilton escreveu:
> writing is designing

exactly!

On Feb 5, 10:44 am, namekuseijin <namekusei> wrote:
> Kenneth Tilton escreveu:
>
> > writing is designing
>
> exactly!

cells-qx?

On 5 Feb, 03:05, p...@informatimago.com (Pascal J. Bourguignon) wrote:
> Jason <jasonlillywh> writes:
>>
> This is true.  But what people don't often realize, is that programs
> (sources) are not end-products: they are the design themselves!

No, since sources can be executed by interpreters (compilation can be
considered an optimization) they are already the finished product.
The rest is mostly packing.
[..]

On 4 Feb, 21:20, Jason <jasonlillywh> wrote:
[..]
> weeks planning it
> beforehand.
>
> I've always heard "design is 90% of the job. You have to have a good
> design in place before writing anything."
>
> This quote from OnLisp is a radical paradigm for me (being an engineer
> who designs things). My question to you is does this apply in
> practice? In the real world when the rubber hits the road, can you
> program this way and develop good software used by lots of people?

I suppose that languages with static typing and other forms of program
verification are better suited to design-centric approachs, while
dynamic languages fit more easly with "jury-rigging".

Anyway, I think that at least the requirement analisys phase must be
done before one starts coding.

Xah Lee wrote:
> Pascal Constanza is a Common Lisp fanatic.

It's Costanza, not Constanza.


Thank you,
Pascal

Vend <vend82> writes:
> Anyway, I think that at least the requirement analisys phase must be
> done before one starts coding.

That's where you start wrong. The problem being that the user cannot
establish requirements before seeing the program running. If he
could, Software Engineering would have been finished 30 years ago.

On 6 Feb, 20:03, p...@informatimago.com (Pascal J. Bourguignon) wrote:
> Vend <ven> writes:
> > Anyway, I think that at least the requirement analisys phase must be
> > done before one starts coding.
>
> That's where you start wrong.  The problem being that the user cannot
> establish requirements before seeing the program running.  If he
> could, Software Engineering would have been finished 30 years ago.

Do you think this problem is intrinsic to software development or is
it due to bad engineering processes (and perhaps little computer
expertise in the general population)?

In other fields of engineering the requirements are largely set before
anything is built (there are still development cycles with prototypes,
but that in no way approaches the level seen in software engineering).

Maybe software is fundamentally different from other products, but
why?

On Feb 6, 10:19 am, Vend <ven> wrote:
> On 4 Feb, 21:20, Jason <jasonlillywh> wrote:
>>
>>
>
> I suppose that languages with static typing and other forms of program
> verification are better suited to design-centric approachs, while
> dynamic languages fit more easly with "jury-rigging".

No, you write a language on top of Lisp to express your design.

> Anyway, I think that at least the requirement analisys phase must be
> done before one starts coding.

No, that's waterfall. There are quite a few ways to interleave
requirements analysis and coding. The strengths of
Lisp is that you can prototype partly working applications
in a short time and then you can demo what you have.
Customer is constantly giving feedback, expanding on
the requirements, refining requirements, etc. You can
sit together with the customer and change the prototype
while it is running.

On 2009-02-06 14:41:24 -0500, Vend <vend82> said:

> Do you think this problem is intrinsic to software development or is
> it due to bad engineering processes

IMHO the problem is intrinsic to human language. Language gives us the
false sense that we have precisely specified something when usually we
have said something extremely vague which could correspond to a large
number of real world situations.

When considered in the context of a software client specifying program
behavior this means that the client thinks that precise behavior has
been specified but hasn't actually done so, and the developer, unless
that developer is careful, likewise thinks that precise behavior has
been specified (though often a different precise something than the
client thinks!) when of course nothing truly precise has been specified.

The remedy is to build working software based on the admittedly vague
outline given by the client, show the client the prototype, discover
how it differs from client expectations, revise the software to conform
to client expectations, rinse, repeat.

On Feb 6, 8:41 pm, Vend <ven> wrote:
> On 6 Feb, 20:03, p...@informatimago.com (Pascal J. Bourguignon) wrote:
>>
> Do you think this problem is intrinsic to software development or is
> it due to bad engineering processes (and perhaps little computer
> expertise in the general population)?
>
> In other fields of engineering the requirements are largely set before
> anything is built (there are still development cycles with prototypes,
> but that in no way approaches the level seen in software engineering).
>
> Maybe software is fundamentally different from other products, but
> why?

There are for example domains where the implemented requirements
are no longer valid, because the business has changed during
analysis, development, testing and deployment. As a rule
of thumb one might say that 30% of the requirements change
during that time. Then there are the requirements that are
simply incomplete or wrong - because the real experts were not
available, there are no real experts or writing down the thing
was to expensive and stopped somewhere. Sometimes
requirements are also not implementable. In these cases
you NEED a prototype to verify crucial architectural features
to determine alternatives and being able to choose among them.
For example can you design a web-based user interfaces
that is usable by the end user? You can assume that.
But with a prototype you might verify the poor usability in some
typical scenario and then the alternative is to use a local 'fat'
client
(or something else).

Vend wrote:
> On 6 Feb, 20:03, p...@informatimago.com (Pascal J. Bourguignon) wrote:
>
> Do you think this problem is intrinsic to software development or is
> it due to bad engineering processes (and perhaps little computer
> expertise in the general population)?
>
> In other fields of engineering the requirements are largely set before
> anything is built (there are still development cycles with prototypes,
> but that in no way approaches the level seen in software engineering).

Depends on the field. For some things (bridges, nuclear weapons) you get
a set of requirements, build to them and that's that. For many, many
other engineered products (buildings, high-performance aircraft) you get
a revision cycle limited only by the time needed to assemble and test
the new version and the client's budget.

paul

Vend <vend82> writes:

> On 6 Feb, 20:03, p...@informatimago.com (Pascal J. Bourguignon) wrote:
>
> Do you think this problem is intrinsic to software development or is
> it due to bad engineering processes (and perhaps little computer
> expertise in the general population)?
>
> In other fields of engineering the requirements are largely set before
> anything is built (there are still development cycles with prototypes,
> but that in no way approaches the level seen in software engineering).
>
> Maybe software is fundamentally different from other products, but
> why?

Yes, software is fundamentally different.

First, for almost all other "products", people already have them.
When you order a new house, you already have lived in houses all your
life, so you can specify rather exactly what you want, and once built,
it is in general rather close to what you expected.

But foremost, a new house, or a new product of any usual kind doesn't
change you in a systemic way. Even if the new product is a tool, you
already have used such a tool (you already even have words for these
tools: hammer, screwdriver, etc).

On the contrary, when you order a new software, it will be
fundamentally different from the existing things, tools or other
software (or you would just buy the existing software). The use of
this new software will change how you function, systemically. It is
harder to preview how the new software will change your environment,
since there was nothing like it before. To check all the systemic
consequences of the new software, you would have to make it first.
One way to approximate it is to use a prototype, or various
prototypes. Well we deduce that we need to use a spiral development
cycle instead of a waterfall development cycle.


Have you read EGB? "Gödel, Escher, Bach: an Eternal Golden Braid" is
exactly relevant to this question.

On Fri, 06 Feb 2009 14:32:21 +0100, Pascal Costanza wrote:

> Xah Lee wrote:
>> Pascal Constanza is a Common Lisp fanatic.
>
> It's Costanza, not Constanza.
>> Thank you,
> Pascal

+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
================================================== ================

(f'up set to comp.lang.lisp)

On Feb 4, 3:20 pm, Jason <jasonlillywh> wrote:
....does this apply in
> practice? In the real world when the rubber hits the road, can you
> program this way and develop good software used by lots of people?

In the real world this is the only way software ever gets written, as
far as I can see. Some people sit down and write it. Then they start
thinking about how to make it pretty enough that people might use it.

In theory what works in theory works in practice. In practice... not
so much. When the rubber hits the road what you describe is the _only_
"process" (what a pretentious word) that I've seen produce working
systems.

Xah Lee wrote:
[..]
>
> See also:
> • Why Software Suck
> [..]
>
> looking at the eXtreme Programing fuckheads's traffic history:
> [..]
>
> for those who are not aware, it was one of the snake oil wildly
> popular in around 2001.

Today, i happened to run across a blog on the eXtreme Programing FUCK.

http://www.yosefk.com/blog/extreme-p...explained.html

Great article!

Xah
∑ http://xahlee.org/

☄