Slashdot Mirror

It's an example of Worse Is Better. USB was easy to implement for devices because they basically just need to respond to packets in a ping pong manner. It was also covered by a patent pool so if a company joined the USB Implementers Forum it was issues a vendor ID and joined the patent pool.

Later revisions improved the speed and added a bunch of features but they did so on a carefully back compatible way. You can still plug in a USB 1.0 mouse into a USB 3.0 host, and it'll work.

https://www.dreamsongs.com/Ris...

Grace Hopper did not invent COBOL

COBOL was ultimately designed by a committee, but Grace's early compilers had a lot of influence on the language design.

The military and other organizations found it difficult to build financial, logistics, and administrative software for multiple machines that each speak a different language, and thus formed a joint committee to create a common language. (Science and research institutions had FORTRAN for cross compatibility.)

Basically the COBOL committee grew sour with disagreement. As the deadline for the first specification approached, the committee fractured into a "git'er done" tribe, and a "do it right" tribe. The git-er-done tribe basically cloned Grace's language with some minor changes and additions because they knew they didn't have time to reinvent the wheel from scratch. Grace's language was road-tested.

As the deadline came up, the git-er-done group were the only tribe with something close to ready, and so that's the work the committee heads ultimately submitted. There were a lot of complaints about it, but the heads wanted to submit something rather than outright fail. (The story varies depending on who tells it.)

Later versions of COBOL borrowed ideas from other languages and report-writing tools, but the root still closely mirrored Grace's language. Therefore, it could be said that Grace Hopper's work had a large influence on COBOL.

(It's somewhat similar to the "worse is better" story between Unix/C and a Lisp-based OS: http://dreamsongs.com/WorseIsB... )

- - - - - - -

As far as what orgs should do about existing COBOL apps, it's not realistic to rewrite it all from scratch, at least not all at once. That would be a long and expensive endeavor. It's probably cheaper to pay the higher wages for COBOL experts, but also gradually convert sub-systems as time goes on.

However, whatever you pick as the replacement language could face the same problem. There's no guarantee that Java, C#, Python, etc. will be common in the future. Rewriting COBOL into Java could simply be trading one dead language for another.

I know shops that replaced COBOL "green screen" apps with Java Applets. Now Java Applets are "legacy" also. (And a pain to keep updating Java for.)

Predicting the future in IT is a dead-man's game. At least the COBOL zombie has shown staying power. If you pick a different zombie, you are gambling even more than staying with the COBOL zombie.

If it ain't broke, don't fix it. If it's half-broke, fix it gradually.

Microsoft has apparently invented such a stinker of a product that better is actually worse.

In almost every case, as Gabriel's classic observation holds, it is better to get something out on the market fast rather than try to make it technically superior. The only obvious reason to cancel the second-generation Hololens is that it is fundamentally not ready for prime time, and would make the Microsoft and Hololens brands look worse if people saw them.

I wouldn't say that C in infamous for it.

I would. The mess around pointers, types, and casting, and what is portable and what isn't, along with clever C hacks abounds.

You can certainly do things like that but even the most experienced programmer knows that it is an ugly unportable hack.

Which is why somebody recommended it and it got upmodded.

As for portability, properly written C is actually portable unlike most high level languages out there.

Well, sure, if you believe in the myth that we just need to have more education, hire better C coders, or strive to do better, C is a good choice for a "portable" language. But in reality C has inherent design flaws that make it easy to write non-portable code.

If you want to write programs that have actual portability there aren't that many alternatives to C.

That's because C has inertia and everybody ports it to their platforms. It's the king of worse is better.

This is unix "ethos":

The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

Methinks you're throwing the baby out with the bath water.

"Make everything as simple as possible, but not simpler."
    -- Albert Einstein

Sometimes complexity IS the right solution. Look at ZFS's beautiful design. Instead of having 3 separate API layers, by combining them you can do even more holistically that simply wasn't possible before.

The Unix philosophy is not a religion -- it is a guiding principle. Like all principles there are times to violate the heuristic. Sometimes complexity solves certain problems extremely well.

What we are against is:

* Over-Engineering
* Things are TOO simple which means you need needless complexity to get anything done

This isn't the first time the Unix Philosophy has been discussed:

* Arch Linux to migrate to Systemd
https://news.ycombinator.com/i...

* Linux Future
http://www.pappp.net/?p=969

* "Worse is Better"
http://www.jwz.org/doc/worse-i...
https://www.dreamsongs.com/Wor...

* Follow up -- Back to the Future: Is Worse (Still) Better?
http://www.dreamsongs.com/NewF...

Methinks you're throwing the baby out with the bath water.

"Make everything as simple as possible, but not simpler."
    -- Albert Einstein

Sometimes complexity IS the right solution. Look at ZFS's beautiful design. Instead of having 3 separate API layers, by combining them you can do even more holistically that simply wasn't possible before.

The Unix philosophy is not a religion -- it is a guiding principle. Like all principles there are times to violate the heuristic. Sometimes complexity solves certain problems extremely well.

What we are against is:

* Over-Engineering
* Things are TOO simple which means you need needless complexity to get anything done

This isn't the first time the Unix Philosophy has been discussed:

* Arch Linux to migrate to Systemd
https://news.ycombinator.com/i...

* Linux Future
http://www.pappp.net/?p=969

* "Worse is Better"
http://www.jwz.org/doc/worse-i...
https://www.dreamsongs.com/Wor...

* Follow up -- Back to the Future: Is Worse (Still) Better?
http://www.dreamsongs.com/NewF...

Or to be more succinct... http://www.dreamsongs.com/RiseOfWorseIsBetter.html linux has become worse to become better.

Go re-read why worse is better http://www.dreamsongs.com/RiseOfWorseIsBetter.html and realize any form of micro-architecture has long since been destroyed by the formidable drive of the monolithic design and it's ability to be simultaneously horrible and intractably irremovable from the minds of the vast majority of engineers, along with being faster to get out the door and therefore meeting all requirements of the business people who actually shove all this garbage down our throats.

There are a few problems with functional programming languages that have prevented their true adoption anywhere.

1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.

Common Lisp (and Scheme, even more so, although the community is more oriented toward impure functional style) enforces no fixed paradigm. It can be used functionally (conses happen to be a pretty good data structure for functional algorithms), but is more often used in an object-oriented manner. It was even one of the first OO languages, and AFAIK the first to implement multiple dispatch. It even has a powerful imperative operators.

Thanks to macros and the metaobject protocol you can even add new paradigms to the language. Paternalistic, Lisp is not.

3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead. For a consumer application, that overhead usually doesnt impede adoption (its more like the software is poorly written than the applications environment is too inefficient). But when talking about server programming the costs of running something under Ruby vs C are astronomical, and the same problem arises with functional programming. It might not hurt the consumer that the Python implementation of their music player consuming 30% more clock cycles than the exact same program written in C, but it does cause huge scaling issues with popular resources like Twitter.

4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside. Developer time is important, but when you factor in the massive overhead trying to get 20+ year professional developers in C to try to think functionally you are never justifying the upfront cost of using the languages.

Languages like SML and OCaml are actually more optimizable than C. Thanks to providing more type information &c they can take advantage of fancy whole program optimization and whatnot.

The "way hardware works" is an artifact of C being the dominant language. There's no reason hardware couldn't (and it has before) have GC assistance, type checking, capabilities, etc. It's really not appropriate and scalable to view the computer as something that flips bits around a gigantic linear array... it was reasonable to deal with that when you had 4000 words, but not when you have 400000000 words.

Software is nice because you can abstract! Writing programs to a model of an infinite store that Just Works (tm) is beneficial to everyone -- it frees source code from a particular hardware implementation, is easier to reason with, and separates the concern of hardware resource management.

The GNU Hacker's Meeting page has "GNU Operating System" at the top. The GNU Operating System was intended to be "a complete Unix-compatible software system", with "all improvements that are convenient, based on our experience with other operating systems".

However, that's not what happened:

At the beginning of the GNU Project, I imagined that we would develop the whole GNU system, then release it as a whole. That is not how it happened.

Since each component of the GNU system was implemented on a Unix system, each component could run on Unix systems long before a complete GNU system existed. Some of these programs became popular, and users began extending them and porting them—to the various incompatible versions of Unix, and sometimes to other systems as well.

The process made these programs much more powerful, and attracted both funds and contributors to the GNU Project. But it probably also delayed completion of a minimal working system by several years, as GNU developers' time was put into maintaining these ports and adding features to the existing components, rather than moving on to write one missing component after another.

so one could argue that the real result of the GNU project is not the intended complete operating system but, instead, a collection of pieces of free software that have been adopted by a number of operating systems, including Linux distributions, the *BSDs, Mac OS X, and perhaps other commercial UNIXes.

Those operating systems are, however, not built with a 100% GNU userland. So, at best, Guile might, at some point, be the extension language for all pieces of software from the GNU project, and perhaps even for many pieces of free software not from the GNU project (most of it is licensed under the LGPL, so even non-free software written for environments that provide Guile could use it as an extension language, as long as they avoid GPLed parts such as the readline module), but I wouldn't hold my breath waiting for an operating system where it's the extension language.

Perhaps when Andy Wingo argued that Guile should be the extension language for GNU, he meant "for all pieces of software from the GNU project", but I wouldn't hold my breath waiting for it to be the extension language for an entire operating system - relative technical merits of various languages nonwithstanding, the world will probably have to live with the languages that Wingo asserts "are at the height of [their adoption curves] and beginning [their] descent" or that "will fall out of favor" for quite a while. Perhaps he's right, and Python's fading away and JavaScript will become a legacy language; if so, whether what replaces them is some flavor of LISP is something to be determined by waiting and watching. After all, Worse is Better.

Shared Source, Accessible Source, Viewable Source, mean the source can be viewed. Using Open Source in this fashion is incorrect and is an unethical PR word-play ploy by a proprietary company trying to cash in on what Open Source actually is.

"open source" means that the source is publicly available, and nothing else. anything else you read into it is because you are spending entirely too much time on slashdot.

http://www.dreamsongs.com/IHE/

So you are right about the NoSQL fashion trend. Looks like for some companies it's easier to throw a pile of cheap commodity hardware driven by some NoSQL BigTable-wannabie at the problem instead of carefully optimizing queries and indexes for the best performance.

Companies do whatever is cheapest. Today, it's cheaper to scale with hardware than with optimizing queries and indices. This is just what Richard Gabriel's described in his classic essays, see http://www.dreamsongs.com/WorseIsBetter.html

Do you know the cost (salary or consulting) of a MySQL expert? How about the cost of optimizing for that one database, tying yourself down to it with non-standard SQL? How about MySQL's historical baggage, piles upon piles of backwards compatibility?

It's not as simple as it seems, the business of data.

It is important to remember that the initial virus has to be basically good.

he also said

However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.

MIT approach being another name for better/lisp model of development.
This leads him to say

I think there will be a next Lisp. This Lisp must be carefully designed, using the principles for success we saw in worse-is-better.

I intend (at some point) to learn lisp so this is not an attack on this language, as I believe learning it will make me a better programmer. As for the Alex Payne I choose the great programmers who have worked on TCP/IP etc over the past 40 years, than him.

Have things changed since Gabriel pointed out that Worse is Better?

That's fine, but once you reach maturity you should be trying to do the "right thing" (the exact opposite.) And the Linux kernel has reached maturity for quite a while now.

I think Linus is right on this.

You think most C programs people see are viruses?

Well, I guess that might be true, depending on your point of view -- C itself is a virus.

Is this where I say "Eclipse is almost as nice as my Symbolics machine", or where I say "the internet is almost as nice as when it had no ads"?

(I had started a much better comment but Firefox crashed.)

Because "Worse is Better".

It's 2006 --- no programmer of desktop/workstation/server programs is going to spend time optimizing their code [...]

1) Programs are becoming platform-agnostic. [...]

2) The world is moving towards higher-level languages and higher-level programming constructs. [...]

The C++ code I posted is straight STL, which calls a function in the Xerces-C++ library - it has a major bug in it as posted because Slashdot ate a critical '<'. See this posting for the details.

I object to the C++ STL method of denoting function objects because it's verbose, and it's verbose without being enlightening. In C++, this kind of stuff happens routinely because of having to avoid new syntax and new keywords that might conflict with old C code. Is 'operator()' clear and intuitive to you?

The second line is only cryptic if you don't know Lisp at all. It's short for

(function string<)

and is the standard Common Lisp notation for reference-to-function. In the Scheme dialect, the (function ...) wrapper isn't needed, but the name of the string comparison function is different:

string<?

The last one in normal Lisp source would be indented like this:

(lambda (s1 s2)
        (declare (string s1 s2))
        (string< s1 s2))


It's closer to the C++ because of the (optional in Common Lisp, for speed only) declaration in the second line.

None of this stuff is tricky Lisp - it's just a notation you're unfamiliar with.

On the subject of verbosity, one of the real gurus of Common Lisp, Richard Gabriel, agrees with you. See the "Abstraction Descant" chapter in his book Patterns of Software. Great book if you're at all into software patterns, BTW.

I shouldn't need an entire fucking book (that I have to buy) trying to sell my on something that I really doubt that I need.

(This is not meant as an endorsement of this book, as I haven't read it, but come on, dude. If you don't RTFA at least RTF summary!)

I shouldn't need an entire fucking book (that I have to buy) trying to sell my on something that I really doubt that I need.

(This is not meant as an endorsement of this book, as I haven't read it, but come on, dude. If you don't RTFA at least RTF summary!)

The original claim, that "MySQL is fine for the vast majority of applications out there" is not invalidated by any of the problems you point out.

The objections you raise are valid, but irrelevant. There are far more cases of small-scale applications use out there than Industrial Strength applications. Who cares if some David Hasselhoff fan website's bulletin board isn't robust? Even the owner of the board probably doesn't REALLY care.

See also: http://www.dreamsongs.com/WorseIsBetter.html

I think this is another example of the "worse is better" philosophy in action. Having just reread Richard Gabriel's article, I'll post a link to it: http://www.dreamsongs.com/WorseIsBetter.html. He is originally decrying the shoddiness of Unix software compared to ITS, TOPS-10, or LISP-M, but the point is valid here as well.

The whole point is that good software takes time to write, but that the last 20% of the functionality takes 80% of the time to write. Different end-users also have different ideas about what that 20% should be, compounding the problem. Why do you think that MS Office has so many useless features? They are trying to please everyone, which gets you nowhere. Far better to release something that is only 80% done and get to market first, because then nearly everyone is 80% satisfied. Otherwise you end up with a product years late, and only 20% better!

As for explicitly calling it "beta," hey, at least they're being honest with us!

Check it out.

There is an old saying in the CS industry that applies here. The concept is worse is better and sony is in the position to produce a better product but instead the worse gets accepted. Hopefully this time better will win. See http://www.dreamsongs.com/WorseIsBetter.html .

Open source doesn't have imagination or innovation, yet is likely to put innovators out of business?

Yes. Consider worse is better to be a sort of Gresham's law for software: bad software that is given away for $0 (whether it is open source or not, actually) drives out more-innovative commercial software. People say that they value innovation, but in the end nothing beats the allure of free.

http://www.dreamsongs.com/WorseIsBetter.html

It's tough to watch a system you consider inferior take over the world.

I have recently started to play with PHPDoc to create self-documenting code.

That's not quite self-documenting code. That's source code that contains documentation.

I use tools like WinMerge, Subversion (only a little, not so good at it) and ReplaceEm to maintain large codebases.

Keep practicing... it'll come to you. You might also want to look for a copy of Pragmatic Version Control Using Subversion.

I know OOP, but it isn't natural for me, so I'm still a procedural boy, even when Object-Oriented Programming might help.

OOP is not an overnight thing. It takes quite a while to get the "feel" for it.

I have no idea what vectors and matrixes are.

So, quit making excuses... go and learn them!

I'm self-taught, my schooling is as an English major. So I have absolutely no Computer Science education behind what I do. While I try to do well, my solution to a deep and complicated problem is going to be basic compared to a guy who spent years of his life learning algorithms.

The reason people spend years of their lives learning algorithms is so that THEY can produce basic solutions to deep and complicated problems. One elegant algorhithm can save you a lot of tricky coding.

You're not the first "artsy" to ply the coding waters. Those english skills will pay off down the road. Just ask Richard P. Gabriel.

Resier4 or XFS is what UNIX should have started with...

ACL's make more sense, and UNIX should have had them from the start.

Just to check, you know that Unix started in 1971(ish), right? Expecting filesystems developed in the last ten years targetting modern hardware to have existed thirty years ago on hardware less powerful than the PalmOS device in my pocket seems a little optimistic.

You touch on some things that Unix (and it's children) can definately do better, but you seem out of touch with Unix's history. Unix evolved to where it is today over thirty-five years. Doing everything all at once wasn't an option; indeed Grand Visions generally fail while something Good Enough that continually improves (warts and all) generally wins. Thus Worse is Better (that's just an excerpt from the original article, see it all here.

http://www.dreamsongs.com/WorseIsBetter.html

Worse Is Better
Richard P. Gabriel

The concept known as worse is better holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this piecemeal growth. This is the story of the evolution of that concept.

From 1984 until 1994 I had a Lisp company called Lucid, Inc. In 1989 it was clear that the Lisp business was not going well, partly because the AI companies were floundering and partly because those AI companies were starting to blame Lisp and its implementations for the failures of AI. One day in Spring 1989, I was sitting out on the Lucid porch with some of the hackers, and someone asked me why I thought people believed C and Unix were better than Lisp. I jokingly answered, because, well, worse is better. We laughed over it for a while as I tried to make up an argument for why something clearly lousy could be good.

A few months later, in Summer 1989, a small Lisp conference called EuroPAL (European Conference on the Practical Applications of Lisp) invited me to give a keynote, probably since Lucid was the premier Lisp company. I agreed, and while casting about for what to talk about, I gravitated toward a detailed explanation of the worse-is-better ideas we joked about as applied to Lisp. At Lucid we knew a lot about how we would do Lisp over to survive business realities as we saw them, and so the result was called Lisp: Good News, Bad News, How to Win Big. [html] (slightly abridged version) [pdf] (has more details about the Treeshaker and delivery of Lisp applications).

I gave the talk in March, 1990 at Cambridge University. I had never been to Cambridge (nor to Oxford), and I was quite nervous about speaking at Newtons school. There were about 500-800 people in the auditorium, and before my talk they played the Notting Hillbillies over the sound system - I had never heard the group before, and indeed, the album was not yet released in the US. The music seemed appropriate because I had decided to use a very colloquial American-style of writing in the talk, and the Notting Hillbillies played a style of music heavily influenced by traditional American music, though they were a British band. I gave my talk with some fear since the room was standing room only, and at the end, there was a long silence. The first person to speak up was Gerry Sussman, who largely ridiculed the talk, followed by Carl Hewitt who was similarly none too kind. I spent 30 minutes trying to justify my speech to a crowd in no way inclined to have heard such criticism - perhaps they were hoping for a cheerleader-type speech.

I survived, of course, and made my way home to California. Back then, the Internet was just starting up, so it was reasonable to expect not too many people would hear about the talk and its disastrous reception. However, the press was at the talk and wrote about it extensively in the UK. Headlines in computer rags proclaimed Lisp Dead, Gabriel States. In one, there was a picture of Bruce Springsteen with the caption, New Jersey Style, referring to the humorous name I gave to the worse-is-better approach to design. Nevertheless, I hid the talk away and soon was convinced nothing would come of it.

About a year later we hired a young kid from Pittsburgh named Jamie Zawinski. He was not much more than 20 years old and came highly recommended by Scott Fahlman. We called him The Kid. He was a lot of fun to have around: not a bad hacker and definitely in a demographic we didnt have much of at Lucid. He wanted to find out about the people at the company, particularly me since I had been the one to take a risk on him, including moving him to the West Coast. His way of finding out was to look through my computer directories - none of them were protected. He f

Worse Is Better
Richard P. Gabriel

The concept known as worse is better holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this piecemeal growth. This is the story of the evolution of that concept.

From 1984 until 1994 I had a Lisp company called Lucid, Inc. In 1989 it was clear that the Lisp business was not going well, partly because the AI companies were floundering and partly because those AI companies were starting to blame Lisp and its implementations for the failures of AI. One day in Spring 1989, I was sitting out on the Lucid porch with some of the hackers, and someone asked me why I thought people believed C and Unix were better than Lisp. I jokingly answered, because, well, worse is better. We laughed over it for a while as I tried to make up an argument for why something clearly lousy could be good.

A few months later, in Summer 1989, a small Lisp conference called EuroPAL (European Conference on the Practical Applications of Lisp) invited me to give a keynote, probably since Lucid was the premier Lisp company. I agreed, and while casting about for what to talk about, I gravitated toward a detailed explanation of the worse-is-better ideas we joked about as applied to Lisp. At Lucid we knew a lot about how we would do Lisp over to survive business realities as we saw them, and so the result was called Lisp: Good News, Bad News, How to Win Big. [html] (slightly abridged version) [pdf] (has more details about the Treeshaker and delivery of Lisp applications).

I gave the talk in March, 1990 at Cambridge University. I had never been to Cambridge (nor to Oxford), and I was quite nervous about speaking at Newtons school. There were about 500-800 people in the auditorium, and before my talk they played the Notting Hillbillies over the sound system - I had never heard the group before, and indeed, the album was not yet released in the US. The music seemed appropriate because I had decided to use a very colloquial American-style of writing in the talk, and the Notting Hillbillies played a style of music heavily influenced by traditional American music, though they were a British band. I gave my talk with some fear since the room was standing room only, and at the end, there was a long silence. The first person to speak up was Gerry Sussman, who largely ridiculed the talk, followed by Carl Hewitt who was similarly none too kind. I spent 30 minutes trying to justify my speech to a crowd in no way inclined to have heard such criticism - perhaps they were hoping for a cheerleader-type speech.

I survived, of course, and made my way home to California. Back then, the Internet was just starting up, so it was reasonable to expect not too many people would hear about the talk and its disastrous reception. However, the press was at the talk and wrote about it extensively in the UK. Headlines in computer rags proclaimed Lisp Dead, Gabriel States. In one, there was a picture of Bruce Springsteen with the caption, New Jersey Style, referring to the humorous name I gave to the worse-is-better approach to design. Nevertheless, I hid the talk away and soon was convinced nothing would come of it.

About a year later we hired a young kid from Pittsburgh named Jamie Zawinski. He was not much more than 20 years old and came highly recommended by Scott Fahlman. We called him The Kid. He was a lot of fun to have around: not a bad hacker and definitely in a demographic we didnt have much of at Lucid. He wanted to find out about the people at the company, particularly me since I had been the one to take a risk on him, including moving him to the West Coast. His way of finding out was to look through my computer directories - none of them were protected. He f

"Worse Is Better" I guess.

(unless (equalp
(lisp-implementation-type)
"SBCL") (quit))

I agree that some programs have a quality that is somewhat close to literature, but maybe not poetry. In particular, I agree with Richard Garbiel that there should be a Master of Fine Arts in Software.

I still claim that software is a discipline of its own, and natural languages and its literature are only very loosely related to it.

(unless (equalp
(lisp-implementation-type)
"SBCL") (quit))

I agree that some programs have a quality that is somewhat close to literature, but maybe not poetry. In particular, I agree with Richard Garbiel that there should be a Master of Fine Arts in Software.

I still claim that software is a discipline of its own, and natural languages and its literature are only very loosely related to it.

There's so many things wrong with these proposals I won't even bother going into specifics.* What I will say is, there is a Better Way, and I have seen its genesis. The Master of Fine Arts in Software, and the University of Illinois just recently gave the idea a trial run, which I was thrilled to have been able to participate in.

* OK, I couldn't help myself, I had to mention one specific: Why is writing HTML and CSS in the programming curriculum?

It's called worse is better. Read it and weep.

And to a lisper or a relational database fan, "objects orientation" in the ms/java/c++ sense are limited and limiting.

So how is the Unix shell not?

At least the Unix way allows objects, rdbms, or lisp to be slapped on top - see KDE dcop - Oh look, arbitrary object access from the shell -
dcop konqueror-2492 konqueror-mainwindow#3 'minimize()'

Great - for the DCOP-ebabled applications. How many of those are there outside KDE? As for RDMBSs, an object-based command line would allow you to essentially use something like JDBC or ADO, (since you are a Lisper, CL-SQL or CommonSQL, or any of the 10 other SQL bindings for Lisp (see below for related commments on FFI)) from the command line, and to get results back as a ResultSet object. Try doing that on the command line. Yes, I know you can pipe commands into 'pgsql' or whatever, but that's not a very rich interaction. How do you deal with the results of your querys? Parse it rhough with awk? The fact that you need an entire pattern-matching language to deal with results from an RDBMS shows you how weak the Unix way is. And if you write those scripts to parse the output, what happens when you add another column to the result, and you have to change all your scripts? That is the type of ad-hoc interfaces I was talking about earlier, the ones that programmers should be moving away from, not towards.

A real Lisper would find Unix terribly limiting and awkward - after all, none of the LispM's ran Unix, did they. Cripes, read some of the great writings of the Lisp crowd: Worse Is Better, or even the Unix-Hater's Handbook to get an idea of why Unix sucks, from a Lisp perspective.

Clueless MS Fanboy

Cute. I'm not an "MS Fanboy" - I simply think that Microsoft is updating it's products with new and better ideas much faster than the free Unix people are. Linux *needs * something like .NET - currently cross-language solutions either suck or are non-existent. .NET increases integration in ways you can't do under Unix. Hell, if there was such a thing, Lisp wouldn't be such a niche language. If it could fully interact with all other languages, it would be viewed as much more useful. For an example of how Unix screwed things up, witness the huge number of FFI bindings available for Common Lisp - every commercial implementation has a different one, and each free implementation has several. With .NET, there's no need for that - all languages can work will all others. It's simply a better platform. If you can't agree that MS has produced some superior products, then it is you who are simply biased.

Clayton Christensen's "The Innovator's Dilemma" is a great book. It is very similar to Richard Gabriel's "Worse Is Better". This theory also explains why inferior products like DOS, Windows, C++, and Java succeeded. They sucked in many ways, but they were better in some small, important way.

Well worth the read, even if you aren't familiar with / think you don't like Lisp. There's another page with links to followups too.

Well worth the read, even if you aren't familiar with / think you don't like Lisp. There's another page with links to followups too.

Well that happened. A little late maybe, but it happened. The iPod even exceeded it.

But I'd never have guessed we'd still be using a shitty 1960s era operating system (Unix) as our reference standard. And even worse, that it would still be way better than all the commonly-available alternatives (unless you count BeOS as "commonly-available"). Nor would I have predicted that software would still be developed in death-march sweatshops led by clueless pinhead bosses, to end up being just as buggy and fragile as it ever was. Nor that we'd be rehashing crap like virtual machine interpreters and reference count garbage collectors, dressing them up with new chrome nameplates and trying to pass them off as anything but the old, tired, failed ideas they always were. About the only thing good about software today is that at least nobody uses Ada any more.

Electrical engineering has advanced by leaps and bounds in the last 20 years. Computer science pretty much stopped dead in 1985. It's easy to blame this on Microsoft, but that's overly simplistic. Microsoft, the ubiquity of commodity (lowest-common denominator) computing, and the overarching need for backward compatibility were certainly big factors. But we also need more Feynman-type thinkers to continually remind us when we have our heads up our asses, so new computer scientists won't think the pablum they're taught is as good as it gets. Dijkstra was the best we had at this, but he's dead now. At least we still have Tufte, Gabriel, and these guys.

Mob Software: The Erotic Life of Code
An Essay in First Person by
Richard P. Gabriel & Ron Goldman

It has been previously discussed in Slashdot.

Here is a lengthy discussion on the topic. Basically it comes down to personal and corporate philosophy and what makes the most business sense.

Read some of the famous papers by Richard Gabriel on why "Worse Is Better". This isn't really an answer to your problems, but it may help explain why things are the way they are.

Worse Is Better

Worse Is Better[2]

People in the LISP world often refer to this. Of course Worse Is Better hasn't seem to help FORTH at all, it's the most "worse" solution of them all. (I'm not trolling, I really am a serious FORTH fan. But FORTH is elegent because of it's simplicity in one's ability to write a compiler for it, not because it's easy/easier to use)

While it's rude of BitTorrent to act so stupidly and is clearly a bug (or at least bad design), it's not entirely to blame. Software is going to occasionally act flaky and enter a state where it's not going shut down politely. Because of this the operating system must provide a way for you to terminate rogue processes. If you operating system doesn't let you do this, your operating system has a bug (or at least bad design). So, submit a bug report to Bram, sure, but also submit a bug report to your OS provider. After all, if you're going to pay for a proprietary OS, you at least deserve support to get it to behave reasonably.

As to why Python, I think it's pretty clear: it was a language that he could get BitTorrent shipped quickly with. One could point to the rapid development advantages of scripting languages and ease in handling common cases, but ultimately Bram decided it was the language he could get stuff done quickly in for whatever reason. (Similarly, I get many tasks most quickly done in Perl, even though other people might find Perl much harder to use.) Sure, it has drawbacks, but it's a 90% solution. A 90% solution today is far better than a 100% solution next year. Ultimately worse is better. The biggest advantage is now that we see that it works pretty well and we have a good specification, people care implement Java, C++, C, Ada, or whatever versions. So enjoy what we have now and look forward to the future. If you're really inspired, help write the future!

XP is heavily influenced by TDD -- Test Driven Development. The idea is that you only write code when you have a failing test. You write the test, it fails, you write the code to make the test pass. Then you go back to the requirements, write another test specified by the requirements, run it, it fails, so you write the code to fix it. Repeat until all tests (unit and functional) pass. When all your functional tests pass, you've met the requirements for the app (because the functional tests represent the use cases) and you're done.

Coding in this fashion does two things. It ensures that you've got a safety net at all times, and it forces your code to be loosely coupled and modular. Because you have 100% coverage, you're not afraid to change the code, because if you break something, you'll get a failing test. If you make a change and all your tests pass, you have the confidence that you didn't inadvertently break something in your code.

Additionally, your code needs to be modular and loosely coupled because it's tough to test if it isn't. If you have a God Class with lots of dependencies, you won't be able to unit test it because of all the dependencies. That's to say, you won't be able to test it as a unit. If you have a method that's doing lots of things, you'll have to write lots of tests to verify every path of execution. So instead, you're strongly encouraged to write simple methods that do one thing well for ease of testing.

A real OO guru knows all sorts of things about coupling and cohesion and patterns and when to use composition and when to use inheritance. They always obey the Law of Demeter and consistently separate the implementation from the interface. And to be able to do this, they've got a dog's life of OO experience under their belt. Here's the kicker. The XP evangelists say that using XP and TDD, in particular, gives you the benefits of all this experience as an emergent property of the methodology.

You obey the Law of Demeter because testing a class that breaks it isn't a unit test -- it's a subsystem test. You use interfaces because it allows you to substitute mock objects for the objects that your object under test interacts with. You use composition and inheritance appropriately because your tests will fail if you don't. Oh, and by the way, if you start with inheritance and move to composition, it's not a problem because all your tests will insure you don't leave something broken.

The point is that a programmer really only needs to learn how to write good tests in order to be a good programmer. TDD gives you all the stuff that you would normally have to have gained through experience.

So, that's why I think it's similar to AOP. They both produce higher quality and more maintainable software. However, TDD is a social solution, while AOP is a technical one. And, as long as I'm on my soapbox, I'll just mention that many patterns are compensations for things that more powerful languages do easily. For example, lisp's map procedure is an example of Visitor. Generally, languages that support higher order functions, or that treat functions as first class types, don't require as much pattern silly-walking. Also, AOP is old. Lisp has had it for a long time. In fact, the main architect of AspectJ, Gregor Kiczales, worked on the Common Lisp Object System (CLOS) with Richard Gabriel. Plus ca change, plus ca meme chose, innit. Here's a link to some thoughtful writings on the subject.

One other point -- for those inclined towards genetic programming. I think that the XP TDD way of programming suffers from the same problems as the hill climbing algorithm. It tends to produce quality, but I think it's easy to get stuck at a local minimum.

This is not really at all like "Cathedral/Bazaar" but rather, " Worse is Better. (now updated)

The underlying idea is that the "right" way isn't always the best, but rather, that the "best" way is what is "good enough" for cheap.

This is the same force that makes Linux compete against *nix, and is also responsible for the rise of Microsoft against vastly superior technologies.

Gregor Kiczales, the lead on the AspectJ project, wrote "The Art of the Metaobject Protocol", which was a description of how to do metaobjects in Lisp (metaobjects, and particularly generic functions, are closely related to AOP). A description that Gabriel and Steele put together can be found in The Common Lisp Object System: An Overview