I just started reading OnLisp and hit this quote:
Why wait for hindsight? As Montaigne found, nothing clarifies your
ideas like trying to write them down. Once you’re freed from the worry
that you’ll paint yourself into a corner, you can take full advantage
of this possibility. The ability
to plan programs as you write them has two momentous consequences:
programs take less time to write, because when you plan and write at
the same time, you have a real program to focus your attention; and
they turn out better, because the final design is always a product of
evolution. So long as you maintain a certain discipline while
searching for your program’s destiny—so long as you always rewrite
mistaken parts as soon as it becomes clear that they’re mistaken—the
final product will be a program more elegant than if you had spent
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?
Jason wrote:
> I just started reading OnLisp and hit this quote:
>
> Why wait for hindsight? As Montaigne found, nothing clarifies your
> ideas like trying to write them down. Once you�re freed from the worry
> that you�ll paint yourself into a corner, you can take full advantage
> of this possibility. The ability
> to plan programs as you write them has two momentous consequences:
> programs take less time to write, because when you plan and write at
> the same time, you have a real program to focus your attention; and
> they turn out better, because the final design is always a product of
> evolution. So long as you maintain a certain discipline while
> searching for your program�s destiny�so long as you always rewrite
> mistaken parts as soon as it becomes clear that they�re mistaken�the
> final product will be a program more elegant than if you had spent
> 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?
Yes. There are actually complete software development methodologies
built around these ideas. Google for "extreme programming" and "agile
software methodologies".
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal,
You have been getting me increasingly more interested in Lisp. What
about web app frameworks like Weblocks. Are people really building
good web applications using Lisp? I've never heard of such a thing
until today.
Jason wrote:
> Pascal,
>
> You have been getting me increasingly more interested in Lisp. What
> about web app frameworks like Weblocks. Are people really building
> good web applications using Lisp? I've never heard of such a thing
> until today.
Yes. See
http://p-cos.blogspot.com/2007/11/levente-mszros-posted-following-lisp.html
for example. There are many of such examples.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
> Yes. Seehttp://p-cos.blogspot.com/2007/11/levente-mszros-posted-following-lis...
> for example. There are many of such examples.
As a side / snide note to this, I'd really appreciate success stories
or simple howto's from people running lisp-based sites on shared hosts
(like Dreamhosts). I can't believe it'd be much worse than the
performance I'm seeing from Wordpress or RoR + FastCGI
thanks in advance,
Tom SW
On Wed, 04 Feb 2009 15:07:05 -0800, TomSW wrote:
> As a side / snide note to this, I'd really appreciate success stories or
> simple howto's from people running lisp-based sites on shared hosts
> (like Dreamhosts). I can't believe it'd be much worse than the
> performance I'm seeing from Wordpress or RoR + FastCGI
Probably not what you're looking for, but at the much lower-end of the
spectrum, I operated a site for my sailing club for a while, based on
bigloo scheme and the skribe package. It worked fine on a shared hosting
site because ultimately it was all static pages: I had no real need for
dynamic content. I just ran a scheme script once a week and that updated
the site with new results and info. YMMV. Was my introduction to scheme
(and lisp) btw.
Cheers,
--
Andrew
TomSW wrote:
>> Yes. Seehttp://p-cos.blogspot.com/2007/11/levente-mszros-posted-following-lis...
>> for example. There are many of such examples.
>
> As a side / snide note to this, I'd really appreciate success stories
> or simple howto's from people running lisp-based sites on shared hosts
> (like Dreamhosts). I can't believe it'd be much worse than the
> performance I'm seeing from Wordpress or RoR + FastCGI
>
> thanks in advance,
> Tom SW
Not quite what you're looking for, but this was also very interesting:
http://www.hackers-with-attitude.com/2008/01/22/european-common-lisp-meeting-2008-april-20-amsterdam/
Here are some of their customers (in German):
http://freiheit.com/projekte/referenzen.html
[This doesn't mean, of course, that Lisp is used in all these projects.]
You can probably find some more stories at
http://web.archive.org/web/20080208085828/http://wiki.alu.org/Success_Stories
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Jason wrote:
> Pascal,
>
> You have been getting me increasingly more interested in Lisp. What
> about web app frameworks like Weblocks. Are people really building
> good web applications using Lisp? I've never heard of such a thing
> until today.
we're kickin ass and taking numbers. Look for cells-qx in a week, the
world will never be the same.
as for designing before writing, writing is designing:
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
hth,kth
On Feb 4, 12:29 pm, Pascal Costanza <····@p-cos.net> wrote:
> Jason wrote:
> > I just started reading OnLisp and hit this quote:
>
> > Why wait for hindsight? As Montaigne found, nothing clarifies your
> > ideas like trying to write them down. Once you’re freed from the worry
> > that you’ll paint yourself into a corner, you can take full advantage
> > of this possibility. The ability
> > to plan programs as you write them has two momentous consequences:
> > programs take less time to write, because when you plan and write at
> > the same time, you have a real program to focus your attention; and
> > they turn out better, because the final design is always a product of
> > evolution. So long as you maintain a certain discipline while
> > searching for your program’s destiny—so long as you always rewrite
> > mistaken parts as soon as it becomes clear that they’re mistaken—the
> > final product will be a program more elegant than if you had spent
> > 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?
yes and no. The problem is that such opinion is not a scientific
opinion. It can't be verified or denied.
Any dynamic lang, such as Python, PHP, Ruby, Mathematica can be said
the same thing. And, prob more so for functional langs.
The langs that this cannot be done, is C, Java, where the lang is
inflexible, low level, or requires big structure that's hard to
change.
if you want software engineering books, i suggest try some books that
are based on statistical survey, as opposed to some dignitary's
“opinion” or current fashion & trends that comes with a jargon. These
type of books are a dime a dozen, every year, they come and go. The
stastical survey approach takes major understaking and cost. The
opinion type any motherfucking “guru” can write. e.g. Paul Graham has
you buy into certain concept of “hackers” fucker and claim they are
like “painters”. Certain Gabriel wants you to believe in poetry and C
is the last language. (see Book Review: Patterns of Software
http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
) et al. Certain Gosling wants you to believe Java is the last lang on
earth that'll wipe out Microsoft (circa 1998).
Pascal Constanza wrote:
> Yes. There are actually complete software development methodologies
> built around these ideas. Google for "extreme programming" and "agile
> software methodologies".
Pascal Constanza is a Common Lisp fanatic. Note here, that eXtreme
Programing is one of the snake oil, that ran like rampant wild fire in
the industry around 2002, with many books published on it on the
supposed motherfucking hip Software Engineering practices, but today
you don't hear much of it. I haven't looked at “Agile programing”
agile my ass, but it is probably a waste of time.
... what society overwhelmingly asks for is snake oil. Of course, the
snake oil has the most impressive names —otherwise you would be
selling nothing— like “Structured Analysis and Design”, “Software
Engineering”, “Maturity Models”, “Management Information Systems”,
“Integrated Project Support Environments” “Object Orientation” and
“Business Process Re-engineering” (the latter three being known as
IPSE, OO and BPR, respectively).” — Edsger W Dijkstra (1930-2002), in
EWD 1175: The strengths of the academic enterprise.
you want to be a good programer? Study math, the math of programing,
and master the langs and protocols and tools you use. You want to
climb the tech industry ladder? get better at people, learn politics.
You want to be rich? Study business. Chances are, you are a coding
geek, and at heart you dna is not geared to be interested in politics
or business, and you'll never be rich or big ceo just because of that.
See also:
• Why Software Suck
http://xahlee.org/UnixResource_dir/writ/why_software_suck.html
Plain text version follows:
--------------------------------------------
Why Software Suck
Xah Lee, 2001-12-02
I like to make a coherent summary of my views on the Design Patterns
and eXtreme Programing stuff.
In my previous articles and other posts posted here recently, their
contents are summarized and expanded as follows:
(1) Patterns and XP are wishy-washy, unscientific, unproven, and
without any mathematical basis.
(2) there are enough applied mathematics in computer science for a
life-time of study.
(3) The programers in computing industry lack sufficient training.
They lack sufficient discrete math background, lack mastery of their
tools (languages, protocols etc.), and their knowledge of their domain/
field are often poor.
(4) It is extremely easy and common for laymen to become a software
professional, who's codes are a significant percentage of codes in the
industry. (This is in contrast with other engineering disciplines. A
desk-top computer is sufficient to send a interested laymen into
software industry.)
(5) Software engineering is ten thousand times easier than physical
engineering such as the building of bridges, airplanes, tunnels,
buildings etc.
(6) Computers do not make mistakes, people do, and sloppiness is a
common attitude in software industry.
(7) software licenses are irresponsible. The vast majority of software
license agreements contains clauses that do not guarantee it works.
Software Quality And Programer Quality
The quality of software depends on primarily of two aspects:
• Programer's mastery of the craft. (Mathematics, programing
languages, protocols, operating systems and programing applications.)
• Programer's expertise/knowledge of his field/domain. (Example: a
programer writing software for Chemistry Industry should know
Chemistry. A programer writing software for Ecommerce should known
business transactions. A programer in aerospace industry should know
the basics and specifics of physics... etc. Not only in terms of pure
academics knowledge, but inside out knowledge of the field's dealings,
cultures, practices etc.)
Programers should master their tools. Know every detail of their
languages, protocols, libraries, specifications, standard bodies,
alternatives, real world discrepancies. Then, programers should strive
to accumulate knowledge of their respective domain. The academic
knowledge, and all associated actual practices and experiences.
When a programer masters his tools and domain expertise, he obtains
the expertise any Design Pattern tries to describe. Design Patterns is
a snake oil. Icing on the cake. Fluff. Wishful thinking. Slouch's
drug. Idiot's placebo. And that's not all.
Design Patterns is the opium of computing industry. From a addicted
individual or company, it may have improved a code or helped a team
thru psychology. But on the whole, it hinders the propagation of
quality languages. It stops advancements of language design. It
reduces the awareness of real education needs like mastering
mathematics and domain expertise. It is a fucking spoon-feeding
formula designed to retard the mundane and drug the smart. It curbs
creation ability. It is a plague, a bad-ass fashion phenomenon; a
jargon-riding dimwit-pleasing epidemic.
For the record, the “Gang of Four” mentioned in this thread who wrote
the Design Patterns book are:
Erich Gamma ← fucking ass one
Richard Helm ← fucking ass two
Ralph Johnson ← fucking ass too
John Vlissides ← fucking ass also
These people will be remembered as criminals in the computing history,
along with Larry Wall and those fucking jackasses who distributed
their home work now known as Unix. [criminals here is defined as those
who bring damages to society, including hampering progress in a
massive scale.]
[Disclaimer: any mention of real person is opinion only.]
Is Bridge Engineering Easier Than Software Engineering?
I have mentioned above that software engineering is significantly
easier then bridge engineering. Let's drill on this a bit.
When we say A is easier then B, we have to define what we mean by
“easier”. Before we can say what we mean by “easier”, we need to
understand the nature A and B comparably. We can consider Software
Writing versus Bridge Building. This would be a easy one. Anyone can
start to write a software, but cannot start to built a bridge. So
instead, we consider Software Engineering versus Bridge Engineering.
This will be a bit difficult. We'll need to further discuss what does
“engineering” really encompass here. Coming up with a good definition
can be quite involved. Instead of drilling on a sensible definition,
I'll simply mention a few comparisons of things in software
engineering and bride engineering below. The following items will be
somewhat hodgepodge.
• Material cost.
• Size of team.
• Cost of raising (educating/training) engineers.
• The nature involved.
In building bridges, there are lots of unknown factors. There's wind,
storm, flood, earthquake all of which we cannot fully control, and can
only predict in a limited way. It will involve many science
disciplines. geo-science, physics, aerodynamics. Software building
requires much lesser disciplines, and significantly much less people.
Building bridge is costly. It can only be done once, and the one time
must be right. It cannot go by trial-and-error. Software building on
the other hand, can trial-and-error all the way. It is in a sense
costless.
The essence of computers can be likened to a abacus. You push the
beads and you readout the values. There are no chance events. No storm
or flood to worry about. The information are one hundred percent known
to you, and you control it one hundred percent one hundred percent of
the time.
Which one is ten thousand times easier do you think? Is it bridge
engineering, or software engineering?
Responsibilities of Licensing
In the above, i have touched on the problem of software licenses.
Namely, they outright disclaims the functionality of the software.
I propose that we raise a awareness of this situation, so that the
public (consumer) will start to demand more responsible software
(licenses).
See: Responsible Software License.
Excerpt of Major Licenses in the Industry
Feast your eyes. Note the ominous all-caps.
Excerpt of License agreement from Apple Computer Inc's Mac OS 9:
4. Disclaimer of Warranty on Apple Software. You expressly
acknowledge and agree that use of the Apple Software is at your
sole
risk. The Apple Software is provided "AS IS" and without warranty
of
any kind and Apple and Apple's licensor(s) (for the purposes of
provisions 4 and 5, Apple and Apple's licensor(s) shall be
collectively referred to as "Apple") EXPRESSLY DISCLAIM ALL
WARRANTIES
AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED
TO,
THE IMPLIED WARRANTIES AND/OR CONDITIONS OF MERCHANTABILITY OR
SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OF THIRD PARTY RIGHTS. APPLE DOES NOT WARRANT
THAT
THE FUNCTIONS CONTAINED IN THE APPLE SOFTWARE WILL MEET YOUR
REQUIREMENTS, OR THAT THE OPERATION OF THE APPLE SOFTWARE WILL BE
UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE APPLE SOFTWARE
WILL BE CORRECTED. FURTHERMORE, APPLE DOES NOT WARRANT OR MAKE
ANY
REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE USE OF THE
APPLE SOFTWARE OR RELATED DOCUMENTATION IN TERMS OF THEIR
CORRECTNESS,
ACCURACY, RELIABILITY, OR OTHERWISE. NO ORAL OR WRITTEN
INFORMATION
OR ADVICE GIVEN BY APPLE OR AN APPLE AUTHORIZED REPRESENTATIVE
SHALL
CREATE A WARRANTY OR IN ANY WAY INCREASE THE SCOPE OF THIS
WARRANTY.
SHOULD THE APPLE SOFTWARE PROVE DEFECTIVE, YOU (AND NOT APPLE OR
AN
APPLE AUTHORIZED REPRESENTATIVE) ASSUME THE ENTIRE COST OF ALL
NECESSARY SERVICING, REPAIR OR CORRECTION. SOME JURISDICTIONS DO
NOT
ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION
MAY
NOT APPLY TO YOU. THE TERMS OF THIS DISCLAIMER DO NOT AFFECT OR
PREJUDICE THE STATUTORY RIGHTS OF A CONSUMER ACQUIRING APPLE
PRODUCTS
OTHERWISE THAN IN THE COURSE OF A BUSINESS, NEITHER DO THEY LIMIT
OR
EXCLUDE ANY LIABILITY FOR DEATH OR PERSONAL INJURY CAUSED BY
APPLE'S
NEGLIGENCE.
5. Limitation of Liability. UNDER NO CIRCUMSTANCES, INCLUDING
NEGLIGENCE, SHALL APPLE BE LIABLE FOR ANY INCIDENTAL, SPECIAL,
INDIRECT OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO
THIS
LICENSE. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OF
INCIDENTAL
OR CONSEQUENTIAL DAMAGES SO THIS LIMITATION MAY NOT APPLY TO YOU.
In
no event shall Apple's total liability to you for all damages
exceed
the amount of fifty dollars ($50.00).
We can see here, that Apple actually allowed a liability of $50, which
is about half of the price of the software this particular license is
sold for. (Mac OS 9, circa 1998.)
Excerpt of License agreement from Free Software Foundation's license,
known as GPL:
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/
OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU
ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
MODIFY
AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO
YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
THE
PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR
A
FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN
IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH
DAMAGES.
Free Software Foundation's software and many Open Source software
using this lincense are actually free of charge. In some respects, it
is reasonable because it is not sensible to stipulate warantees from
largess.
END-USER LICENSE AGREEMENT FOR MICROSOFT WINDOWS 98, excerpt:
LIMITED WARRANTY
LIMITED WARRANTY.
Microsoft warrants that (a) the SOFTWARE PRODUCT will perform
substantially in accordance with the accompanying written
materials
for a period of ninety (90) days from the date of receipt, and (b)
any
Support Services provided by Microsoft shall be substantially as
described in applicable written materials provided to you by
Microsoft, and Microsoft support engineers will make commercially
reasonable efforts to solve any problem. To the extent allowed by
applicable law, implied warranties on the SOFTWARE PRODUCT, if
any,
are limited to ninety (90) days. Some states/jurisdictions do not
allow limitations on duration of an implied warranty, so the above
limitation may not apply to you.
CUSTOMER REMEDIES.
Microsoft's and its suppliers' entire liability and your
exclusive
remedy shall be, at Microsoft's option, either (a) return of the
price
paid, if any, or (b) repair or replacement of the SOFTWARE PRODUCT
that does not meet Microsoft's Limited Warranty and that is
returned
to Microsoft with a copy of your receipt. This Limited Warranty is
void if failure of the SOFTWARE PRODUCT has resulted from
accident,
abuse, or misapplication. Any replacement SOFTWARE PRODUCT will be
warranted for the remainder of the original warranty period or
thirty
(30) days, whichever is longer. Outside the United States, neither
these remedies nor any product support services offered by
Microsoft
are available without proof of purchase from an authorized
international source.
NO OTHER WARRANTIES.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND
ITS
SUPPLIERS DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER
EXPRESS
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OR
CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE
AND NON-INFRINGEMENT, WITH REGARD TO THE SOFTWARE PRODUCT, AND THE
PROVISION OF OR FAILURE TO PROVIDE SUPPORT SERVICES. THIS LIMITED
WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHERS,
WHICH
VARY FROM STATE/JURISDICTION TO STATE/JURISDICTION.
LIMITATION OF LIABILITY.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT
SHALL
MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL,
INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, WITHOUT
LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS
INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNIARY
LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE
PRODUCT OR THE FAILURE TO PROVIDE SUPPORT SERVICES, EVEN IF
MICROSOFT
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN ANY CASE,
MICROSOFT'S ENTIRE LIABILITY UNDER ANY PROVISION OF THIS EULA
SHALL BE
LIMITED TO THE GREATER OF THE AMOUNT ACTUALLY PAID BY YOU FOR THE
SOFTWARE PRODUCT OR U.S.$5.00; PROVIDED, HOWEVER, IF YOU HAVE
ENTERED
INTO A MICROSOFT SUPPORT SERVICES AGREEMENT, MICROSOFT'S ENTIRE
LIABILITY REGARDING SUPPORT SERVICES SHALL BE GOVERNED BY THE
TERMS OF
THAT AGREEMENT. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW THE
EXCLUSION OR LIMITATION OF LIABILITY, THE ABOVE LIMITATION MAY NOT
APPLY TO YOU.
Among the 3 cited licenses of the largest software in terms of
quantity, it appears that Microsoft is the most responsible.
Xah
∑ http://xahlee.org/
☄
looking at the eXtreme Programing fuckheads's traffic history:
http://groups.google.com/group/comp.software.extreme-programming/about
for those who are not aware, it was one of the snake oil wildly
popular in around 2001.
Xah
∑ http://xahlee.org/
☄
Jason wrote:
I just started reading OnLisp and hit this quote:
Why wait for hindsight? As Montaigne found, nothing clarifies your
ideas like trying to write them down. Once you’re freed from the worry
that you’ll paint yourself into a corner, you can take full advantage
of this possibility. The ability to plan programs as you write them
has two momentous consequences: programs take less time to write,
because when you plan and write at the same time, you have a real
program to focus your attention; and they turn out better, because the
final design is always a product of evolution. So long as you maintain
a certain discipline while searching for your program’s destiny—so
long as you always rewrite mistaken parts as soon as it becomes clear
that they’re mistaken—the final product will be a program more elegant
than if you had spent 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?
-----------------
On Feb 4, 10:36 pm, Xah Lee <······@gmail.com> wrote:
yes and no. The problem is that such opinion is not a scientific
opinion. It can't be verified or denied.
Any dynamic lang, such as Python, PHP, Ruby, Mathematica can be said
the same thing. And, prob more so for functional langs.
The langs that this cannot be done, is C, Java, where the lang is
inflexible, low level, or requires big structure that's hard to
change.
if you want software engineering books, i suggest try some books that
are based on statistical survey, as opposed to some dignitary's
“opinion” or current fashion & trends that comes with a jargon. These
type of books are a dime a dozen, every year, they come and go. The
stastical survey approach takes major understaking and cost. The
opinion type any motherfucking “guru” can write. e.g. Paul Graham has
you buy into certain concept of “hackers” fucker and claim they are
like “painters”. Certain Gabriel wants you to believe in poetry and C
is the last language. (see Book Review: Patterns of
Softwarehttp://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
) et al. Certain Gosling wants you to believe Java is the last lang on
earth that'll wipe out Microsoft (circa 1998).
Pascal Constanza wrote:
> Yes. There are actually complete software development methodologies
> built around these ideas. Google for "extreme programming" and "agile
> software methodologies".
Pascal Constanza is a Common Lisp fanatic. Note here, that eXtreme
Programing is one of the snake oil, that ran like rampant wild fire in
the industry around 2002, with many books published on it on the
supposed motherfucking hip Software Engineering practices, but today
you don't hear much of it. I haven't looked at “Agile programing”
agile my ass, but it is probably a waste of time.
... what society overwhelmingly asks for is snake oil. Of course, the
snake oil has the most impressive names —otherwise you would be
selling nothing— like “Structured Analysis and Design”, “Software
Engineering”, “Maturity Models”, “Management Information Systems”,
“Integrated Project Support Environments” “Object Orientation” and
“Business Process Re-engineering” (the latter three being known as
IPSE, OO and BPR, respectively).” — Edsger W Dijkstra (1930-2002), in
EWD 1175: The strengths of the academic enterprise.
you want to be a good programer? Study math, the math of programing,
and master the langs and protocols and tools you use. You want to
climb the tech industry ladder? get better at people, learn politics.
You want to be rich? Study business. Chances are, you are a coding
geek, and at heart you dna is not geared to be interested in politics
or business, and you'll never be rich or big ceo just because of that.
See also:
• Why Software Suck
http://xahlee.org/UnixResource_dir/writ/why_software_suck.html
Xah
∑ http://xahlee.org/
☄
Xah Lee wrote:
> Pascal Constanza is a Common Lisp fanatic.
It's Costanza, not Constanza.
Thank you,
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Xah Lee wrote:
> ...
> if you want software engineering books, i suggest try some books that
> are based on statistical survey, as opposed to some dignitary's
> “opinion” or current fashion & trends that comes with a jargon. These
> type of books are a dime a dozen, every year, they come and go. The
> stastical survey approach takes major understaking and cost. The
> opinion type any motherfucking “guru” can write. e.g. Paul Graham has
> you buy into certain concept of “hackers” fucker and claim they are
> like “painters”. Certain Gabriel wants you to believe in poetry and C
> is the last language. (see Book Review: Patterns of
> Software
> http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
> ) et al. Certain Gosling wants you to believe Java is the last lang on
> earth that'll wipe out Microsoft (circa 1998).
>
> ...
>
> ... what society overwhelmingly asks for is snake oil. Of course, the
> snake oil has the most impressive names —otherwise you would be
> selling nothing— like “Structured Analysis and Design”, “Software
> Engineering”, “Maturity Models”, “Management Information Systems”,
> “Integrated Project Support Environments” “Object Orientation” and
> “Business Process Re-engineering” (the latter three being known as
> IPSE, OO and BPR, respectively).” — Edsger W Dijkstra (1930-2002), in
> EWD 1175: The strengths of the academic enterprise.
>
> you want to be a good programer? Study math, the math of programing,
> and master the langs and protocols and tools you use. You want to
> climb the tech industry ladder? get better at people, learn politics.
> You want to be rich? Study business. Chances are, you are a coding
> geek, and at heart you dna is not geared to be interested in politics
> or business, and you'll never be rich or big ceo just because of that.
>
> See also:
> • Why Software Suck
> http://xahlee.org/UnixResource_dir/writ/why_software_suck.html
>
> looking at the eXtreme Programing fuckheads's traffic history:
> http://groups.google.com/group/comp.software.extreme-programming/about
>
> 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-programming-explained.html
Great article!
Xah
∑ http://xahlee.org/
☄
In article <····································@w39g2000prb.googlegroups.com>,
Xah Lee <······@gmail.com> wrote:
<SNIP>
>
>Pascal Constanza wrote:
>> Yes. There are actually complete software development methodologies
>> built around these ideas. Google for "extreme programming" and "agile
>> software methodologies".
>
>Pascal Constanza is a Common Lisp fanatic. Note here, that eXtreme
>Programing is one of the snake oil, that ran like rampant wild fire in
>the industry around 2002, with many books published on it on the
>supposed motherfucking hip Software Engineering practices, but today
>you don't hear much of it. I haven't looked at =E2=80=9CAgile programing=E2=
>=80=9D
>agile my ass, but it is probably a waste of time.
>
>... what society overwhelmingly asks for is snake oil. Of course, the
>snake oil has the most impressive names =E2=80=94otherwise you would be
>selling nothing=E2=80=94 like =E2=80=9CStructured Analysis and Design=E2=80=
>=9D, =E2=80=9CSoftware
>Engineering=E2=80=9D, =E2=80=9CMaturity Models=E2=80=9D, =E2=80=9CManagemen=
>t Information Systems=E2=80=9D,
>=E2=80=9CIntegrated Project Support Environments=E2=80=9D =E2=80=9CObject O=
>rientation=E2=80=9D and
>=E2=80=9CBusiness Process Re-engineering=E2=80=9D (the latter three being k=
>nown as
>IPSE, OO and BPR, respectively).=E2=80=9D =E2=80=94 Edsger W Dijkstra (1930=
>-2002), in
>EWD 1175: The strengths of the academic enterprise.
>
A couple of weeks ago, a collegue of mine held a lecture about
a company where he is hired,
building paper-folding and envelope-handling machines.
(We are hired hands).
Real time, and real time simulators. Full regression tests
after each change. Agile scrum all the way down.
It looks impressive especially from where I stand. ( Formal procedures that
take 6 months, and bad fixes because approved changes were no
good after all.)
So not dead by a margin, and less snake oil than most methodologies
I know of.
> Xah
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
······@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
On 19 Feb 2009 18:56:42 GMT, Albert van der Horst
<······@spenarnc.xs4all.nl> wrote, quoted or indirectly quoted someone
who said :
>Note here, that eXtreme
>>Programing is one of the snake oil,
Extreme programming is a variant on Deming's idea of constant
incremental improvement that revolutionised quality in manufacturing.
It is also based on the obvious idea that you will be smarter after
you have used some version of a program than you are today. There are
so many computer programs perfectly compliant with specs that looked
good on paper but nobody ever tested with actual use to refine them
until the project was "complete" and it was too expensive to fix them.
--
Roedy Green Canadian Mind Products
http://mindprod.com
One path leads to despair and utter hopelessness. The other,
to total extinction. Let us pray we have the wisdom to choose correctly.
~ Woody Allen .
On Feb 23, 4:56 am, Roedy Green <···········@mindprod.com.invalid>
wrote:
> On 19 Feb 2009 18:56:42 GMT, Albert van der Horst
> <······@spenarnc.xs4all.nl> wrote, quoted or indirectly quoted someone
> who said :
>
> >Note here, that eXtreme
> >>Programing is one of the snake oil,
>
> Extreme programming is a variant on Deming's idea of constant
> incremental improvement that revolutionised quality in manufacturing.
>
> It is also based on the obvious idea that you will be smarter after
> you have used some version of a program than you are today. There are
> so many computer programs perfectly compliant with specs that looked
> good on paper but nobody ever tested with actual use to refine them
> until the project was "complete" and it was too expensive to fix them.
2009-02-09
Today, i happened to run across a blog on the eXtreme Programing
FUCK.
http://www.yosefk.com/blog/extreme-programming-explained.html
Great article!
Xah
$B-t(B http://xahlee.org/
Xah Lee escreveu:
> On Feb 4, 12:29 pm, Pascal Costanza <····@p-cos.net> wrote:
>> Jason wrote:
>>> I just started reading OnLisp and hit this quote:
>>> Why wait for hindsight? As Montaigne found, nothing clarifies your
>>> ideas like trying to write them down. Once you’re freed from the worry
>>> that you’ll paint yourself into a corner, you can take full advantage
>>> of this possibility. The ability
>>> to plan programs as you write them has two momentous consequences:
>>> programs take less time to write, because when you plan and write at
>>> the same time, you have a real program to focus your attention; and
>>> they turn out better, because the final design is always a product of
>>> evolution. So long as you maintain a certain discipline while
>>> searching for your program’s destiny—so long as you always rewrite
>>> mistaken parts as soon as it becomes clear that they’re mistaken—the
>>> final product will be a program more elegant than if you had spent
>>> 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?
>
> yes and no. The problem is that such opinion is not a scientific
> opinion. It can't be verified or denied.
>
> Any dynamic lang, such as Python, PHP, Ruby, Mathematica can be said
> the same thing. And, prob more so for functional langs.
>
> The langs that this cannot be done, is C, Java, where the lang is
> inflexible, low level, or requires big structure that's hard to
> change.
>
> if you want software engineering books, i suggest try some books that
> are based on statistical survey, as opposed to some dignitary's
> “opinion” or current fashion & trends that comes with a jargon. These
> type of books are a dime a dozen, every year, they come and go. The
> stastical survey approach takes major understaking and cost. The
> opinion type any motherfucking “guru” can write. e.g. Paul Graham has
> you buy into certain concept of “hackers” fucker and claim they are
> like “painters”. Certain Gabriel wants you to believe in poetry and C
> is the last language. (see Book Review: Patterns of Software
> http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
> ) et al. Certain Gosling wants you to believe Java is the last lang on
> earth that'll wipe out Microsoft (circa 1998).
>
> Pascal Constanza wrote:
>> Yes. There are actually complete software development methodologies
>> built around these ideas. Google for "extreme programming" and "agile
>> software methodologies".
>
> Pascal Constanza is a Common Lisp fanatic. Note here, that eXtreme
> Programing is one of the snake oil, that ran like rampant wild fire in
> the industry around 2002, with many books published on it on the
> supposed motherfucking hip Software Engineering practices, but today
> you don't hear much of it. I haven't looked at “Agile programing”
> agile my ass, but it is probably a waste of time.
>
> ... what society overwhelmingly asks for is snake oil. Of course, the
> snake oil has the most impressive names —otherwise you would be
> selling nothing— like “Structured Analysis and Design”, “Software
> Engineering”, “Maturity Models”, “Management Information Systems”,
> “Integrated Project Support Environments” “Object Orientation” and
> “Business Process Re-engineering” (the latter three being known as
> IPSE, OO and BPR, respectively).” — Edsger W Dijkstra (1930-2002), in
> EWD 1175: The strengths of the academic enterprise.
>
> you want to be a good programer? Study math, the math of programing,
> and master the langs and protocols and tools you use. You want to
> climb the tech industry ladder? get better at people, learn politics.
> You want to be rich? Study business. Chances are, you are a coding
> geek, and at heart you dna is not geared to be interested in politics
> or business, and you'll never be rich or big ceo just because of that.
>
> See also:
> • Why Software Suck
> http://xahlee.org/UnixResource_dir/writ/why_software_suck.html
>
> Plain text version follows:
> --------------------------------------------
> Why Software Suck
>
> Xah Lee, 2001-12-02
>
> I like to make a coherent summary of my views on the Design Patterns
> and eXtreme Programing stuff.
>
> In my previous articles and other posts posted here recently, their
> contents are summarized and expanded as follows:
>
> (1) Patterns and XP are wishy-washy, unscientific, unproven, and
> without any mathematical basis.
>
> (2) there are enough applied mathematics in computer science for a
> life-time of study.
>
> (3) The programers in computing industry lack sufficient training.
> They lack sufficient discrete math background, lack mastery of their
> tools (languages, protocols etc.), and their knowledge of their domain/
> field are often poor.
>
> (4) It is extremely easy and common for laymen to become a software
> professional, who's codes are a significant percentage of codes in the
> industry. (This is in contrast with other engineering disciplines. A
> desk-top computer is sufficient to send a interested laymen into
> software industry.)
>
> (5) Software engineering is ten thousand times easier than physical
> engineering such as the building of bridges, airplanes, tunnels,
> buildings etc.
>
> (6) Computers do not make mistakes, people do, and sloppiness is a
> common attitude in software industry.
>
> (7) software licenses are irresponsible. The vast majority of software
> license agreements contains clauses that do not guarantee it works.
> Software Quality And Programer Quality
>
> The quality of software depends on primarily of two aspects:
>
> • Programer's mastery of the craft. (Mathematics, programing
> languages, protocols, operating systems and programing applications.)
>
> • Programer's expertise/knowledge of his field/domain. (Example: a
> programer writing software for Chemistry Industry should know
> Chemistry. A programer writing software for Ecommerce should known
> business transactions. A programer in aerospace industry should know
> the basics and specifics of physics... etc. Not only in terms of pure
> academics knowledge, but inside out knowledge of the field's dealings,
> cultures, practices etc.)
>
> Programers should master their tools. Know every detail of their
> languages, protocols, libraries, specifications, standard bodies,
> alternatives, real world discrepancies. Then, programers should strive
> to accumulate knowledge of their respective domain. The academic
> knowledge, and all associated actual practices and experiences.
>
> When a programer masters his tools and domain expertise, he obtains
> the expertise any Design Pattern tries to describe. Design Patterns is
> a snake oil. Icing on the cake. Fluff. Wishful thinking. Slouch's
> drug. Idiot's placebo. And that's not all.
>
> Design Patterns is the opium of computing industry. From a addicted
> individual or company, it may have improved a code or helped a team
> thru psychology. But on the whole, it hinders the propagation of
> quality languages. It stops advancements of language design. It
> reduces the awareness of real education needs like mastering
> mathematics and domain expertise. It is a fucking spoon-feeding
> formula designed to retard the mundane and drug the smart. It curbs
> creation ability. It is a plague, a bad-ass fashion phenomenon; a
> jargon-riding dimwit-pleasing epidemic.
>
> For the record, the “Gang of Four” mentioned in this thread who wrote
> the Design Patterns book are:
>
> Erich Gamma ← fucking ass one
> Richard Helm ← fucking ass two
> Ralph Johnson ← fucking ass too
> John Vlissides ← fucking ass also
>
> These people will be remembered as criminals in the computing history,
> along with Larry Wall and those fucking jackasses who distributed
> their home work now known as Unix. [criminals here is defined as those
> who bring damages to society, including hampering progress in a
> massive scale.]
beautiful, Xah. Continue like this.
Jason <················@gmail.com> writes:
> I just started reading OnLisp and hit this quote:
>
> Why wait for hindsight? As Montaigne found, nothing clarifies your
> ideas like trying to write them down. Once you’re freed from the worry
> that you’ll paint yourself into a corner, you can take full advantage
> of this possibility. The ability
> to plan programs as you write them has two momentous consequences:
> programs take less time to write, because when you plan and write at
> the same time, you have a real program to focus your attention; and
> they turn out better, because the final design is always a product of
> evolution. So long as you maintain a certain discipline while
> searching for your program’s destiny—so long as you always rewrite
> mistaken parts as soon as it becomes clear that they’re mistaken—the
> final product will be a program more elegant than if you had spent
> 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 is true. But what people don't often realize, is that programs
(sources) are not end-products: they are the design themselves!
Program sources are the blueprints used to build the actual software,
the executables and set up systems.
> 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?
Yes.
--
__Pascal Bourguignon__
On 5 Feb, 02:05, ····@informatimago.com (Pascal J. Bourguignon) wrote:
> Jason <················@gmail.com> writes:
> > I just started reading OnLisp and hit this quote:
>
> > Why wait for hindsight? As Montaigne found, nothing clarifies your
> > ideas like trying to write them down. Once you’re freed from the worry
> > that you’ll paint yourself into a corner, you can take full advantage
> > of this possibility. The ability
> > to plan programs as you write them has two momentous consequences:
> > programs take less time to write, because when you plan and write at
> > the same time, you have a real program to focus your attention; and
> > they turn out better, because the final design is always a product of
> > evolution. So long as you maintain a certain discipline while
> > searching for your program’s destiny—so long as you always rewrite
> > mistaken parts as soon as it becomes clear that they’re mistaken—the
> > final product will be a program more elegant than if you had spent
> > 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 is true. But what people don't often realize, is that programs
> (sources) are not end-products: they are the design themselves!
>
> Program sources are the blueprints used to build the actual software,
> the executables and set up systems.
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
> > 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?
>
> Yes.
On 5 Feb, 03:05, ····@informatimago.com (Pascal J. Bourguignon) wrote:
> Jason <················@gmail.com> writes:
> > I just started reading OnLisp and hit this quote:
>
> > Why wait for hindsight? As Montaigne found, nothing clarifies your
> > ideas like trying to write them down. Once you’re freed from the worry
> > that you’ll paint yourself into a corner, you can take full advantage
> > of this possibility. The ability
> > to plan programs as you write them has two momentous consequences:
> > programs take less time to write, because when you plan and write at
> > the same time, you have a real program to focus your attention; and
> > they turn out better, because the final design is always a product of
> > evolution. So long as you maintain a certain discipline while
> > searching for your program’s destiny—so long as you always rewrite
> > mistaken parts as soon as it becomes clear that they’re mistaken—the
> > final product will be a program more elegant than if you had spent
> > 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 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.
> Program sources are the blueprints used to build the actual software,
> the executables and set up systems.
>
> > 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?
>
> Yes.
>
> --
> __Pascal Bourguignon__
On 4 Feb, 21:20, Jason <················@gmail.com> wrote:
> I just started reading OnLisp and hit this quote:
>
> Why wait for hindsight? As Montaigne found, nothing clarifies your
> ideas like trying to write them down. Once you’re freed from the worry
> that you’ll paint yourself into a corner, you can take full advantage
> of this possibility. The ability
> to plan programs as you write them has two momentous consequences:
> programs take less time to write, because when you plan and write at
> the same time, you have a real program to focus your attention; and
> they turn out better, because the final design is always a product of
> evolution. So long as you maintain a certain discipline while
> searching for your program’s destiny—so long as you always rewrite
> mistaken parts as soon as it becomes clear that they’re mistaken—the
> final product will be a program more elegant than if you had spent
> 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.
On Feb 6, 10:19 am, Vend <······@virgilio.it> wrote:
> On 4 Feb, 21:20, Jason <················@gmail.com> wrote:
>
>
>
> > I just started reading OnLisp and hit this quote:
>
> > Why wait for hindsight? As Montaigne found, nothing clarifies your
> > ideas like trying to write them down. Once you’re freed from the worry
> > that you’ll paint yourself into a corner, you can take full advantage
> > of this possibility. The ability
> > to plan programs as you write them has two momentous consequences:
> > programs take less time to write, because when you plan and write at
> > the same time, you have a real program to focus your attention; and
> > they turn out better, because the final design is always a product of
> > evolution. So long as you maintain a certain discipline while
> > searching for your program’s destiny—so long as you always rewrite
> > mistaken parts as soon as it becomes clear that they’re mistaken—the
> > final product will be a program more elegant than if you had spent
> > 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".
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.
Vend <······@virgilio.it> 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.
--
__Pascal Bourguignon__
On 6 Feb, 20:03, ····@informatimago.com (Pascal J. Bourguignon) wrote:
> Vend <······@virgilio.it> 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, 8:41 pm, Vend <······@virgilio.it> wrote:
> On 6 Feb, 20:03, ····@informatimago.com (Pascal J. Bourguignon) wrote:
>
> > Vend <······@virgilio.it> 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?
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).
On 2009-02-06 14:41:24 -0500, Vend <······@virgilio.it> 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.
--
Raffael Cavallaro, Ph.D.
Vend wrote:
> On 6 Feb, 20:03, ····@informatimago.com (Pascal J. Bourguignon) wrote:
>> Vend <······@virgilio.it> 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).
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 <······@virgilio.it> writes:
> On 6 Feb, 20:03, ····@informatimago.com (Pascal J. Bourguignon) wrote:
>> Vend <······@virgilio.it> 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?
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.
--
__Pascal Bourguignon__
On Feb 4, 3:20 pm, Jason <················@gmail.com> 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.