Slashdot Mirror

Psychology is a constantly changing field, but there have been some very good studies that suggest that being rewarded for an action can reduce intrinsic motivation to perform it. The GNU project has a short but good page on this, as it relates to open source. There's also an old (but good) article introducing this effect here.

This, of course, could be found out to be wrong, but it seems like a very dangerous thing if it is right, and it might partially explain why people who are paid to program often no longer want to do it as a hobby - even if what they are paid to do is boring and radically different from what their hobby programming might be.

A time enthusiast :-)

Check this one out as well, very nice overview and analysis. http://naggum.no/lugm-time.html

Worse is better

although the original essay talks about Unix and the LISP machines, it just keeps being true. Linus talks about the "charming oddities", well there you go: worse is better. Try for perfection, and the real world will eat you alive.

I also think he's right about the masses being what matter; I think Intel is still thinking about the data centre, not Joe Sixpack, with Itanium.

Somehow, I doubt it. Surely, no software ever gets "finished" (even TeX, which is, at least by my standards, anything but "perfect").

But Hurd was doomed to failure from the start. It was exactly the diamond-like jewel type of system that was predestined to be obsolete by the time it finally arrived.

What you are effectively advocating is the waterfall model, a software methodology that hardly anyone considers a good idea anymore (it's only kept alive by stupid companies, I've yet to find a developer who prefer it).

If you have no idea what I'm talking about, the waterfall model is the old method of producing software: analyze, design, write, test, deliver. You will have no idea of whether your product actually works before you are in the test phase, and then it's too late to back out, so your company will have to spend a lot to pay for the delayed product (because problems will occur). By the time you actually deliver the product, the requirements will have changed, and it can no longer be used.

Modern software development methodologies advocate an iterative approach. You analyse, design and write a small part of the whole system, preferably the part that's most critical (thus you find out early if the product is feasible), test it, revise your plan, and then do the next part. This way, you will always have a working tested system, and you can focus on stability long before you have all the features in place. And, just as important, when requirements change, you can change the direction you are going in, without scrapping everything you've done so far.

Another epitome of good software engineering practice was best said by Edsger Dijkstra: "Premature optimization is the root of all evil". While C will give you better performance if you have the time for it, and assembler even better, it's much better to first write something that works, and then optimize the bottlenecks. This way, you will only have unmaintainable code in the few critical parts that needs it (90% of the time is spent in 10% of the code).

You should also read Richard P. Gabriels classic paper "Worse is Better for a better explanation of why this approach is sensible. After having done that, you can then consider rereading the part that says "if it was written in C we'd still be core dumping and our company would have probably gone out of business", and see if it makes more sense to you now.

PS: I've just made some dumb waterfall-like mistakes myself, so I know what I'm speaking of :-)

• Structure and Interpretation of Computer Programs
• Common Lisp HyperSpec
• Common Lisp the Language, 2. ed
• Common Lisp - A gentle Introduction to symbolic computation
• The Scheme Programming language, 2. ed
• Reflections on trusting trust
• Lisp: Good News, Bad News. How to Win Big
• John McCarthy's homepage
• Dennis Ritchie's homepage
• Various classic papers it's a shame ACM never bothered to continue adding to
• Another list of classic papers (this time related mostly to programming language design)
• GTK-Gnome Application Development (not a classic, though, as the field is too young)
• KDE 2.0 Development (not a classic though, as the field is too young)
• Eric Weissteins Mathworld
• Compilers and compiler generators - an introduction with C++ (although I'm not too sure if it deserves being called a classic...)
• Parsing techniques - A practical guide
• Art of assembly language programming (never was a dead tree, but good anyway)
• Paul Carters 386 assembly book (same comment as above)
• An Introduction to Scheme and its Implementation (see comment above)
• How to design programs - An introduction to programming and computing (not a classic, yet!)
• The Gutenberg archives contains much non-copyrighted classic fiction in ASCII format
• Sacred texts has copies of or links to many religious text for various major (or minor) religions

I don't see how M$ could make things worse .

Programming is a form of art. Not only is elegance and beauty possible in programming computers, these are at the core of a good programmer's value system. Computers present to mankind the first opportunity to do what religions all over the world have failed to present: the ability to receive unambiguous answers to incantations and prayers -- computers are the man-made gods who listen. I am, of course, talking metaphorically about instructing computers to create what we want to exist.

Like other information should be available to those who want to learn and understand, program source code is the only means for programmers to learn the art from their predecessors. It would be unthinkable for playwrights not to allow other playwrights to read their plays, only be present at theater performances where they would be barred even from taking notes. Likewise, any good author is well read, as every child who learns to write will read hundreds of times more than it writes. Programmers, however, are expected to invent the alphabet and learn to write long novels all on their own. Programming cannot grow and learn unless the next generation of programmers have access to the knowledge and information gathered by other programmers before them.

This triumph is discussed in detail in Richard Gabriel's famous "Worse is Better" (part of "Lisp: Good News, Bad News, How to Win Big"). It's not necessarily always a bad thing.
--

> By that logic, the PPC or the Alpha or even the 68000 should of displaced the x86 along time ago.
I agree that sure, they were better tech, but we're dealing with the New Jersey principle w/ regards to the x86: "It is good enough"

> Intel tried 3 other times to replace the x86 but each time they failed due to lack of compatibility.

What 3 times?

Intel could just be bull-headed and say "After 2002, NO MORE x86". But they won't. They are too busy milking the industry for all it is worth. (Can't blaim them, since they created it.)

At some point you just have to make a clean break AND start pushing it. Does Intel even have a 64-bit cpu out on the market? After how many years of waiting?

No flames. Just honest questions.

You should read Richard Gabriel's article Lisp: Good News, Bad News, and How to Win Big. The gist of the article (paraphrased or cut-n-pasted from the article) is that:

• "The worse-is-better philosophy means that implementation simplicity has highest priority, which means [such systems] are easy to port on machines that are worse than median (smaller or slower)."
• "A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using [this] approach will work well both in small machines and large ones."
• "There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up."

These points apply well to Objective-C in comparison to C/C++, and you would do well to at least read section 2.1 ("The Rise of Worse is Better") to see Gabriel's point.

Wisdom:

Worse is better.

Commentary:

It has been said that Lisp programmers know the value of everything, but the cost of nothing.

Anyone who doubts the efficacy of Lisp systems needs look no further than GNU Emacs for true insight.

Richard Gabriel wrote a paper (in 1991) called Lisp: Good News, Bad News, How to Win Big that tries to explain why lisp didn't take over the world. The "Worse is Better" section is particularly relevant.

On a slightly different topic, to understand why lisp is so interesting I highly recommend On Lisp by Paul Graham. A quick summary of cool lisp features are:

• Very powerful macros. The full power of lisp is available when a macro is expanded.
• An object system with mulitmethods and a metaobject protocall.

Disclaimer: I'm a C++ programmer. I've spent much more time reading about lisp than witting lisp programs.

Dude, get your Richard Gabriel quotes straight before you start putting Scheme and UNIX in the same category.

UNIX goes with C in "Worse is Better" (not "Small is Better")

Scheme belongs with LISP in "The Right Thing"

And for people who have no idea what I'm talking about, check out the following link.

(yes, there was once a time when UNIX was looked down upon as a hack. truly we did not know how low things could get...)

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny the historical fact that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

This resonates with me. I wish the world worked this way. However, it doesn't seem to.

The way the world really works is described by Richard Gabriel in his paper usually called Worse is Better but which is really called "Lisp: Good News, Bad News, How to Win Big". If you want to make the world a better place then you need to know how it works. Otherwise, your attempts to change it will be futile. Most software development methods ignore the lessons of "Worse is Better". One method that pays close attention, and still manages to deliver quality software, is Extreme Programming. Extreme Programming does not work in every situation (for example, it requires small teams) but it handles market pressures well and pays very close attention to users.