Most of the comparations and shootouts of lisp are done on a small
programs
where lisp is compared on speed, terseness and time develop, while on
short
projects some languages might be faster, terser and took less time to
develop
Take something big , a living organism that "evolved" through time ,
changing
programmers , goals and focus. And you'll get this :
http://www.laputan.org/mud/mud.html#BigBallOfMud
A BIG BALL OF MUD is haphazardly structured, sprawling,
sloppy, duct-tape and bailing wire, spaghetti code jungle.
And next time when you'll add something to a 5 screen long
imperative written spagthetti procedure , in c/c++/java/c#/delphi
you'll get the idea why functional programming is a good thing.
assignment is bad, global variables suck, and destructively
modifying arguments should be avoided .
I understanded this today. I'm enlightened amen
I wish you a pleasent reading.
bobi
p.s.
It is possible to write cruppy code in lisp
but in many languages is very hard to write a good one.
Remember that warm soft mud last summer?
On Mar 29, 3:32 pm, "fireblade" <·················@gmail.com> wrote:
> And next time when you'll add something to a 5 screen long
> imperative written spagthetti procedure , in c/c++/java/c#/delphi
> you'll get the idea why functional programming is a good thing.
> assignment is bad, global variables suck, and destructively
> modifying arguments should be avoided .
> I understanded this today. I'm enlightened amen
>
> I wish you a pleasent reading.
> bobi
>
Lucky bastard, i spend 35 years debugging them, and you start
whining the first time you see one?
Do you want to see the biggest c++ constructor in the world?
Haven't you heard about the kitchen sink class?
Pet
On Mar 30, 9:46 am, ·················@gmail.com wrote:
> On Mar 29, 3:32 pm, "fireblade" <·················@gmail.com> wrote:
>
> > And next time when you'll add something to a 5 screen long
> > imperative written spagthetti procedure , in c/c++/java/c#/delphi
> > you'll get the idea why functional programming is a good thing.
> > assignment is bad, global variables suck, and destructively
> > modifying arguments should be avoided .
> > I understanded this today. I'm enlightened amen
>
> > I wish you a pleasent reading.
> > bobi
>
> Lucky bastard, i spend 35 years debugging them, and you start
> whining the first time you see one?
> Do you want to see the biggest c++ constructor in the world?
> Haven't you heard about the kitchen sink class?
>
> Pet
I really had a best laugh in a month , literally lol:
A BIG BALL OF MUD is the most frequently deployed of software
architectures: the BIG BALL OF MUD.
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-
tape
and bailing wire, spaghetti code jungle.
A BIG BALL OF MUD show unmistakable signs of unregulated growth, and
repeated, expedient repair
THROWAWAY CODE is quick-and-dirty code that was intended to be used
only once and then discarded. However, such code often takes on a life
of its own, despite casual structure and poor or non-existent
documentation. It works, so why fix it? When a related problem arises,
the quickest way to address it might be to expediently modify this
working code, rather than design a proper, general program from the
ground up. Over time, a simple throwaway program begets a BIG BALL OF
MUD.
>>>>The real problem with THROWAWAY CODE comes when it isn't thrown away.<<<<
As with a decaying neighborhood, a downward spiral ensues. Since the
system becomes harder and harder to understand, maintenance becomes
more expensive, and more difficult. Good programmers refuse to work
there. Investors withdraw their capital
SWEEPING IT UNDER THE RUG strategy
A simple way to begin to control decline is to cordon off the blighted
areas, and put an attractive façade around them.
"on average, average organizations will have average people".
Ralph Johnson
What does this muddy code look like to the programmers in the trenches
who must confront it? Data structures may be haphazardly constructed,
or even next to non-existent. Everything talks to everything else.
Every shred of important state data may be global
Variable and function names might be uninformative, or even
misleading. Functions themselves may make extensive use of global
variables, as well as long lists of poorly defined parameters. The
function themselves are lengthy and convoluted, and perform several
unrelated tasks. Code is duplicated. The flow of control is hard to
understand, and difficult to follow. The programmer's intent is next
to impossible to discern. The code is simply unreadable, and borders
on indecipherable. The code exhibits the unmistakable signs of patch
after patch at the hands of multiple maintainers, each of whom barely
understood the consequences of what he or she was doing. Did we
mention documentation? What documentation
Just as it is easier to be verbose than concise, it is easier to build
complex systems than it is to build simple ones.
Skilled programmers may be able to create complexity more quickly than
their peers, and more quickly than they can document and explain it.
Like an army outrunning its logistics train, complexity increases
until it reaches the point where such
programmers can no longer reliably cope with it.
The PeterPrinciple,
"In a Hierarchy Every Employee Tends to Rise to His Level of
Incompetence."
We built the most complicated system that can possible work
[Cunningham 1999b].
Such code can become a personal fiefdom, since the author care barely
understand it anymore, and no one else can come close.
Once simple repairs become all day affairs, as the code turns to mud.
It becomes increasingly difficult for management to tell how long such
repairs ought to take. Simple objectives turn into trench warfare.
Everyone becomes resigned to a turgid pace. Some even come to prefer
it, hiding in their cozy foxholes, and making their two line-per-day
repairs