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:
[..]
> 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

Thank you.

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
[url down]
for example. There are many of such examples.


Pascal

> 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

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:
[url down]

Here are some of their customers (in German):
[url down]

[This doesn't mean, of course, that Lisp is used in all these projects.]

You can probably find some more stories at
[url down]


Pascal

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,

Jason <jason.lillywhite> 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.

On Feb 4, 12:29 pm, Pascal Costanza <p> wrote:
> Jason 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 Software
[url down]
) 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
[url down]

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 threadwho 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
∑ [url down]

☄

looking at the eXtreme Programing fuckheads's traffic history:
[url down]

for those who are not aware, it was one of the snake oil wildly
popular in around 2001.

Xah
∑ [url down]

☄


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 <xah> 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
[url down]

Xah
∑ [url down]

☄

Xah Lee escreveu:
[..]
> 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.

On 5 Feb, 02: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!
>
> Program sources are the blueprints used to build the actual software,
> the executables and set up systems.  

[url down]
[..]

On 5 Feb, 07:36, Xah Lee <xah> wrote:
> ................................................

Where is gavino when we need him?

Wouldn't be gavino-ized Xah Lee essays be the best of the 2 worlds?

!! G A V I N O !!

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:

[url down]

hth,kth