Provided at least a majority of them are satisfied with the language that
  made them rich and do not feel the urge to create their own pet languages.

| Why don't we already have hordes of Lisp millionaires?

  Perhaps because they do not want to credit Lisp with it?

Can you imagine if Bill decided to do a Visual Lisp? There'd go the
neighborhood.

In both cases, the main ingredients for success were:
- being pretty damn smart
- finding a complex domain that doesn't have good tools yet
- understanding that domain thoroughly
- building a solution in Lisp
- selling the solution into the market

[...]

i started to give my views on patterns and XP in this thread, then it
got ramified by someone into a hogwash discussion that revolves around
attacking the word "mathematics".

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 lacks sufficient training.
They lack sufficient computer science 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 non-qualified people to become
a software professional, who will gradually churn out significant
quantity of codes. (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 bridge, airplane, tunnel, train, ship... building.

(6) computer 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 don't guarantee it works.

--

The quality of software depends on primarily of two aspects:

* Programer's mastery of the tools. (programing language, protocols,
operating system ...)

* Programer's expertise/knowledge of his field/domain.

Programers should master their tools. Know every detail of their
language well. Then, programer should strive to accumulate knowledge
of their respective domain.

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 an addicted
individual or company, it may have improved a code or helped a team.
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 languages 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.]

--

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 vs Bridge Building. This would be on easy one. We can also
consider Software Engineering vs Bridge Engineering. This will be a
bit difficult. We'll need to further discuss what does "engineering"
really encompasses 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.

Build bridges 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's essentially
costless.

The essence of computers can be likened to an 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?

--

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 an awareness of this situation, so that the
public (consumer) will start to demand more responsible software
(licenses).

... my time's up. Next time when i have some time, reminds me to write
on WHY software industry is the way it is, and why the solution is to
first raise the awareness of irresponsible licenses. This should be
the last message in this episode.

Goodbye my love, cum all over your face.

 Xah
 x...@xahlee.org
 http://xahlee.org/PageTwo_dir/more.html

Feast your eyes. Note the ominous all-caps.

-----------------------------------
Excerpt of License agreement from 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).

-----------------------------------
GNU General License, excerpt:

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.

-----------------------------------
END-USER LICENSE AGREEMENT FOR MICROSOFT WINDOWS 98, excerpt:

LIMITED WARRANTY

On to the serious stuff though:

Bridges do not need to be made to 100% exact tolerance to fulfill
their function; normally, 99.9% will do the trick.  With software,
you need 100% tolerance; any 1 bit error is liable to bring the
world down.  Forgeting to screw in 1 rivet doesn't normally bring
a bridge down.  This is due to the continuous nature of physical
systems, versus to the discrete nature of digital systems.

Software programs rarely overbuild, instead preferring to underbuild until a
problem surfaces. (Worse is better, XP, etc.), so I agree with Xah on this
point. However, computers need not be a passive abacus, they can also
interact with the world as we perceive it. (To be fair, even non-situated
computers still have physical devices to deal with that are unpredictable,
like disk drives, memory that can fail, when a key press will occur, etc.,
but I'm talking now about computer based artifacts that directly sense and
influence the world around them; solving this problem will make all software
better and more reliable).

The key to better software in the future will be structured overbuilding,
with overlapping responsibilities for modules, etc. Certainly, that's the
tack I've taken with agent based systems, and the artifacts have turned out
to work surprisingly well in the face of unanticipated (by me) phenomena.
[It's a side issue that the phenomena could have been 100% anticipated: I
work with natural language and sensors on the real world. The combinations
and meaning projections are far worse than bridge engineering.]

A fundamental step is to build software to basically "deal with any input it
might get", though not necessarily to always do the best that could have
been done (by some omniscient agent). With an agent, the input is a speech
act, which is far more expressive to begin with than simply an integer or a
symbol. (To be clear, I'm not talking about functions that simply take the
wrong type of argument and generate an error, I'm talking about functions
that are told things they don't think they need to know, and figure out how
to incorporate the data into the desired solution, or decide the information
is spurious, or decide that the sender is broken and needs to be
repaired/replaced/ignored, ...). To make this happen one needs semantic
input to a module, so there is  some chance of figuring out what it actually
*means*. But it also means a different approach to writing the component in
the first place, from something that is purely functional (domains and
ranges, etc.) to something that incorporates inputs into a more holistic
understanding of a situation, and can then provide an appropriate output
contribution.

http://www.civeng.carleton.ca/Exhibits/Tacoma_Narrows/DSmith/photos.html

and

http://www.civeng.carleton.ca/Exhibits/Tacoma_Narrows/TacomaNarrowsBr...

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

Simply put, more code, more errors.

I think what you are finding is that you are thinking more completely about
what inputs a module can get and are thus being more careful about your
coding.  A lot of software is written without being thoughtful of all the
possible inputs and how to handle the extrodinary situations.  Incomplete
thinking translated into incomplete code.

I think more effort should be put into knowing the problem more completely.

I'm not sure what's meant by overbuilt, but if you assign two different
people to do something in two algorithmically divergent ways, or even if
you give them no guidance but you insist they not communicate (better if
they never even knew one another), then a machine that did both of those
tasks in parallel, even at the possible addition of a constant factor
multiplier in the O() notation [which is a no-op, since it reduces out],
is going to be more reliable.   It means dividing the task so that the
operation is either gratuitously repeatable or side-effect free or any
of several other modalities I can think of that don't have names, unless
you have a separate store, as the RAID example does, but even so, it seems
good.

Also, related to this, but not quite the same, I used to follow
computer chess, ages ago, and apologize for not using a more recent
example, since I'm sure there must be one, but Greenblatt had this
chess program for the pdp10 that was really two processors: one did
smart stuff, the other did "blunder control" of brute force multi-ply
lookahead just in case it could rule out stuff the smart part was
considering.  I'd say the blunder control wasn't really a "solver",
just an extra safeguard that statistically improved the reliability of
the overall system.  I'd say the Lisp Machine's hardware typechecking
did the same thing, though RISC architectures have killed this whole
genetic line: hardware type checking didn't take longe than
non-type-checking because the type-check was started in parallel with
doing the add [for example].  By the time the add was done and had a
purported value, different hardware had checked whether the quantity
being added in parallel was wrong, and if so, it kicked the other
processor and said "Hold on, you're getting ahead of yourself".  I
would call this overbuilt, and I would not a priori think it was
introducing extra risk, though I suppose you could disagree.  No
tradeoff comes for free.  I suppose the industry decided there was a
cost to wide instruction architectures, but not whether there was a
cost, but whether the cost was a cost in "risk", and whether, if so,
that risk was of the same kind.  (I'd bet that sometimes all one can
do is shuffle risk around, like a bubble in a carpet, and so it matters
as much where the risk is as how much it is...)

And when you get all done with it, I think the thing that continues to
separate people from computers is not raw compute power or inability
to simulate architectural components, but the willingness to
accomodate "redundancy" and "chance" as key architectural components
of a working system.  The whole left-brain/right-brain issue that
people raise is almost surely just the right half of the brain doing
spontaneous generation of test cases through random (or uncorrelated)
means while the left half is proceeding in the kind of orderly fashion
that we expect of computers.  Sort of like the Greenblatt program, the
right brain can cut off bad ways of going because it's not making an
attempt to be linear or orderly or complete--it's just doing things in
monte carlo style or perhaps following some set of
statistical/associative connections it's made that are unique to the
individual's experience, but in addition to cutting off avenues, it may
chance on solutions or patterns that inspire or direct, or it may suggest
metaplanning activities that it thinks would structure stuff better,
because it's acting redundantly and not constrained to account for its time
as part of the basic problem solving activity.

Note that in yesteryear, transatlantic aircraft once were required to
have 4 engines, due to the significant likelihood of one or more
failing in flight.  (Not good if you're 800 miles from land!)

As the reliability, sophistication, and power of jet turbine engines
has improved, the requirement has changed.

In much the same way, mainframes used to be pretty fragile, but are
now the sorts of computers that are used when you can Never Have
Downtime.  Some of that comes with "parallelism," but some comes from
a touch of "over-engineering" on some single components that are
designed not to be fragile the way PCs are.

On the other hand, it would be pretty insane to have the left engine
on a jet come from Rolls Royce and have the right engine come from GE,
as construction and maintenance would both become a nightmare :-).

-> Fast sorting often involves QuickSort for big lists, but reverting
   to linear insertion for the little sublists.

-> Root finding using Newton's Method can be unstable if it is used by
   itself; it tends to be better to blend it with other search
   schemes, so that when Newton goes off it's nutter due to some sort
   of discontinuity or other such thing, there's _something_ out there
   that can notice "This seems to be going badly; let's try a
   different point."

b) People don't understand heuristics.

   "Heuristics (from the French heure, "hour") limit the amount of
   time spent executing something.  [When using heuristics] it
   shouldn't take longer than an hour to do something."

c) They've spent the money building a system bus that can cope with
   multiple CPUs.  That was expensive.

   And now you propose doing redundant work, thus flushing the money
   down the toilet?  How gauche!

I _don't_ think you're looking in the wrong places, with a bit of
fingers-crossed about the mainframe world, where they _do_ consider
redundancy and auditing [from that list] to be pretty important.

We have some highly unscientific numbers for the bounds checking case
in the Dylan compiler at:

  http://berlin.ccc.de/cgi-bin/cvsweb/gd/examples/sieve-mark/BENCHMARK....

This of course slightly misses the point you were making about
designing reliable systems, but at least it shows that performance is
no excuse to risk system reliability by not doing bounds checks.
Every posting to Bugtraq about Yet Another Buffer Overflow makes me
think: "Why are those people still using C to write mission-critical
software?".

Andreas

  Well, you could do what the other "innovative" guys out there do: Create
  another amazingly idiotic virus for some idiotic Microsoft product used
  by millions if not billions of people who would rather die than think
  about what they are doing, and, to misquote Bertrand Russel, in fact they
  do.  That would certainly satisfy "to do something I wasn't willing to do
  at slower speeds", but the speed was probably not the reason.   :)

  Seriously, software secure from Microsoftitis (the leprosy of software)
  would be something that computers could help us attain.  However, it
  would take an act of Congress to finally turn around and notice that if a
  bank that was repeatedly robbed of all its money because it had the level
  of security for which Microsoft's products are famous, had tried to blame
  "crackers" and had taken _no_ precautions for twenty years to prevent
  these incidents from happening, the government would have shut them down
  and incarcerated the (ir)responsible owners and (mis)managers.

  The fact that the U.S. Government does not stop Microsoft from making and
  distributing software that aids and abets electronic terrorists means
  that they are harboring terrorists, according to the standards set by
  Presiding Dimwit George W. Bush (who has reverted to pre-9/11 blabbering
  with the highest pause-to-speak ratio of all present public figures).
  The only solution is to bomb the shit out of Microsoft's headquarters and
  their offices around the world, and to wage war on electronic terrorist
  trainer and leader William H. Gates III.  If the world has finally had
  enough of terrorism, what will it take to make people tire of the crap
  that Microsoft produces and demand the end of their terrorist reign?