Slashdot Mirror

Are you freakin' kidding? PowerPoint rocks! I mean, WTF would Lincoln's Gettysburg Address have been like if he didn't have PowerPoint? Boring, that's what. Really, his "New Nations" graph is just the best! And the "Review of Critical Objectives" bullet-points? Sweeeeet!

Are you freakin' kidding? PowerPoint rocks! I mean, WTF would Lincoln's Gettysburg Address have been like if he didn't have PowerPoint? Boring, that's what. Really, his "New Nations" graph is just the best! And the "Review of Critical Objectives" bullet-points? Sweeeeet!

Are you freakin' kidding? PowerPoint rocks! I mean, WTF would Lincoln's Gettysburg Address have been like if he didn't have PowerPoint? Boring, that's what. Really, his "New Nations" graph is just the best! And the "Review of Critical Objectives" bullet-points? Sweeeeet!

Gettysburg address in powerpoint: http://www.norvig.com/Gettysburg/

For what it's worth, Peter Norvig has already pointed this out (he cites research from John Hayes and Benjamin Bloom).

Check out his short essay on how to learn to program in 10 years.

I see. Well, then let me rephrase that: I'd rather do it efficiently in C/C++ right now than wait for an efficient Python compiler that may never come.

However, it seems that Lisp compilers are becoming too fast for some people today, because some of the old Lisp gurus are migrating to Python. A better proof of this "Wirth's law" couldn't exist.
 

I have no idea where you got those numbers, but I can only assume you didn't understand what the parent is talking about. That is in no way what this means.

http://www.norvig.com/oreskes.html

Page with details about Oreskes' original claim, Peiser's attempt at replication, and some Googler's attempt at replication:

http://www.norvig.com/oreskes.html

Judge for yourself.

This is a fake dilemma.

Languages compiled into bytecode can be JIT-compiled into native code, or they can be pre-compiled into native code using a utility like Microsoft's NGEN. And when you are pre-compiling you have all the time in the world to optimize.

In a small but non-trivial program you can usually get C++ to beat Java and C# by throwing away all the high-level features and programming in what can be called "C with templates". But as soon as you start relying on, say, std::basic_string you may get surprised to see that C# and Java are winning. Java and C#'s GC-heap allocated strings are faster than C++'s basic_string if you use them in data structures because in Java and C# you only allocate the string once and pass it around by reference, where in C++ the each copy of basic_string is either going to allocate separate copies of its contents or do thread-safe reference counting which is unfriendly to the processor's cache.

I can also provide examples where real-world C++ will provide significantly better performance than Java or C#.

On a real-world program the performance of C# or Managed C++ is going to be roughly the same as the performance of C++, while depending on the problem Java may trail a little bit because it lacks structures so some data cannot be packed as tightly thus leading to more cache misses.

To see an example of C++ and C# being pitted against each other on a real-world problem take a look at the follow thread:

http://blogs.msdn.com/ricom/archive/2005/05/10/416 151.aspx

As I said, this is a fake dilemma. A more interesting question is how does the performance of mostly dynamically typed languages (Python, Ruby, Lisp) compare to the performance of statically typed languages (ML, Java, C#, C++)?

Peter Norvig has some numbers from four years ago:

http://www.norvig.com/Lisp-retro.html

On a real-world problem without external bottlenecks (database, network) dynamically typed languages can expect to be between two and five times slower than statically typed languages, though the trend is expected to worsen somewhat due to the expanding gap between the speed of the processor and main memory.

Also note that Lisp has by far the best performance among the dynamically typed languages. Companies that write Lisp compilers have been working on the problem far longer than the authors of Python and Ruby, and have significantly better type inference engines and compiler back-ends.

Dejan

Exactly. The main problem is that incompetent programmers are producing horrible code.

I have a shocking revelation for you: not everybody cares as much about programming as you do. Some people have other things to do with their day, and programming is not what they want to do with their lives.

To say that people for whom programming is not job #1 are "incompetent" may be true if you squint just right, just pretty much everybody are incompetent drivers, incompetent chefs, incompetent runners, incompetent artists, and so forth. But does that mean we should all stop driving, cooking, running, and drawing unless we're Mario Andretti, Emeril Lagasse, Frank Shorter, Boticelli? Of course not.

A programming language (a real one, not a theoretical one like Dijkstra's) exists to write programs. And there are gobs of people who have some need to write programs, but simply don't have 10 years to devote to study right now.

As the saying goes, when somebody goes to the hardware store for a 1/2" drill bit, he doesn't want a 1/2" drill bit, he wants a 1/2" hole. People writing programs in languages us geeks call "wimpy" don't want programs: they want results. I'm not the best cook or driver, but I haven't killed anybody with my food or my car, and I doubt any of these bad PHP programmers have killed anybody with a webpage -- a webpage that probably served its purpose, might I add.

Easy. Pick something you are interested in and can hold you attention for a few minutes. Then figure out whether you are in it for the short-term or long-run. The start reading up on the classics like http://www.norvig.com/21-days.html, the Mythical-Man Month, and Peopleware.

Cheers.

Up until that bit, what you were saying seemed quite reasonable. Perhaps your Lisp programming stint was rather cursory or you weren't using a Lisp aware editor?

The examples you give could be described as expert systems, of a sort, relying partly on socially-produced data. I think there's little doubt that such systems will proliferate, and at some point it could start making sense to tie them together. In a way, the "semantic web" is working towards supporting that sort of thing. But this approach is at odds with almost everything that's succeeded on the commercial Internet so far: it's all been about, essentially, exploiting simple business models (Amazon) or clever tricks (Google), and leveraging them to the hilt. That's what the short-term VC-funded approach to product- and company-building is good at.

I think your idea is the sort of thing which could evolve over time, but is unlikely to be built by any one team unless they start with a whole bunch of existing systems that are ripe for integrating. Of course, if I'm wrong and you end up founding a billion-dollar dotcom, please post a Slashdot article about it so I can kick myself!

BTW, if you're working on AI-like applications, I hope you've read PAIP. And of course, Norvig's at Google now...

I'm a largely self-taught programmer (I have a pure mathematics background - no programming required!) currently working at a top software company. I got here largely because of the initiative I showed working on personal projects. So I think the best thing to do for you would be to pick a project you find interesting, and implement it at home. Having something solid you can point to and say, "I did that," can be pretty persuasive.

A few links you might be interested in:

How To Become A Hacker

Teach Yourself Programming in Ten Years

Hope this helps!

Quite a few Google employees read slashdot regularly (and even post too!). Especially the "techguys".

It's really not an insidious cabal. Really. Quite a few quite prolific people would bail if the company started doing any thing "evil". There are too many principled idealists that work there that could get a new high-profile job in minutes if the evil factor was kicked up a notch.

I was talking about the Java syntax. Obviously porting the libraries would be a gargantuan task (so maybe I exaggerated there a bit). As far as speed, take a look at this before you start calling me an ignorant fanboy. The CMUCL LISP compiler produces code that is between 1.3 times slower and 90 times faster than Java, with LISP being about 3x faster than Java on average (although obviously your mileage may vary). Who's ignorant now, punk?

1. The resulting framework is quite often nearly impenetrable to an outsider, so when it's wrong, it's really, really wrong; even an open source framework might be of only dubious value since you're unlikely to be able to unravel all of the pieces in any useful amount of time.
2. As you add pieces together, the complexity of the whole increases geometrically. (Not "exponentially" as the term is commonly abused.) This can be mitigated by maturity, both of framework or core developer, but that's more rare than you might think. But the thing is, you are very unlikely to need all of the pieces. If the framework does 40 things, at a complexity of 1600, but you only need to use it for 12 things, at a complexity of 144, you're gaining an awful lot of complexity. (The numbers are of course made up, but the idea holds; don't try to over-rationalize the figures.) What's worse, as mentioned in the previous point, you might want to do 3 things that the framework fights you on, and now you're either going to have to give up on those 3 things, make unbelievably ugly hacks to get each of them half-sort-of working, or scale a huge learning curve to fix the framework that you are now significantly invested in, but know effectively nothing about the insides.

Especially in this age of using more dynamic languages, I'm finding I'm a lot happier taking smaller libraries and tying them together with my own frameworks, which I understand and can make sing and dance in exactly the ways I need them to with only the minimal complexity.

One important point here is the scale of development. If I'm going to do a three-week project, I'm going to probably go ahead and use a framework. But the larger the project, the larger the team, the more time that geometric price has to come up and bite you in the ass, where you Absolutely, Positively Need this thing the framework can't do, and it has to be done by tomorrow.

Also depends on your skill level, of course. And one of the cardinal Laws of Programming is that there are no Laws of Programming, only tradeoffs. I don't expect everyone to agree, I'm not pitching this so much as throwing it out as food for thought. Caveat, caveat, caveat.

I don't do Java, but my guess is that Hibernate, to the extent that it is a framework, is probably a win because it's so mature. But then again, you can also look at it as a really big library, because it sure does seem to play well with a lot of things. I think one of the distinguishing charateristics of a "framework" as I mean it in this post is that it is well-nigh impossible to glue two "frameworks" together, and sometimes even adding the capabilities of an additional library is an exercise in frustration. But the upshot is, I'm finding in practice that I'm a lot happier and more effective in the medium and long term, even on my own projects, with libraries that I tie together myself and not "frameworks".

While I'm not dogmatic about any particular one of them, the Agile-style development really help with this, and I might not feel this way without their influence. Automated Test (unit tests, usu

I'll bite.

There are things pretty hard to do the functional way in Python. As an example if you wanted to get a sorted list of the foo for all bars you'd do:

    (sort (mapcar #'foo bar) :test #'>)

but in python you have to use a temporary variable here and there which breaks an otherwise nice functional pipeline:

    foos = map(foo, bar)
    foos.sort()
    foos.reverse()
    return foos

The lambda in Python is not quite right. You can't close over a writable var in it (in fact its really awkward to close over a writable in Python) and you can't use ifs and other statements in lambdas. Well we have a point here, why are there statements at all? In Common Lisp if is an expression and it has a value, that is the value of the branch that gets executed.

You are right though, Common Lisp is not purely functional, and thats a strength. In CL you can use functional programming when the problem calls for it and OO when that makes you feel better. Yes you can express all loops as a tail recursion but there is nothing as good as while loop instead of pulling mental contorsions out of a hat.

But there is more than just better functional programming that CL has (some implementations as least) and that Python lacks. There are macros, tail recursion, symbols, type inference, rationals, multi-methods and a syntax the easy programming a lot. Its really convenient to grab a branch of an if and to move it up in place of the if in only two key strokes. The indentation trick with python produce clean code but what a pain it is to play with blocks... and to grab that piece of code that happend to use two space per level instead of four.

Yes, there is a problem with deployment in CL and Python wins there. The packaging system in Python is pretty neet too. And Python doesn't look too scary so you can start to do functional code even if you boss is an OO zealot. Norvig as a nice summary of the pros and cons of each language:

    http://www.norvig.com/python-lisp.html/

". . . have made sure the user is very knowledgeable about what Mono is, what .NET is, what C# is, and how all of them relate to each other."

In the same manner that the first 5 chapters of The Feynman Lectures on Physics makes one very knowledgeable about physics.

Teach Yourself Programming in Ten Years

KFG

A Slashdotter Can Dream

Stuff You Already Know (but is likely wrong now)

Hey, This one actually has a computer reference

You Have Them All Memorized, Right?

Yes, The Creators of This Website Are Morons

Peter Norvig wrote an interesting article a while back (well, the title's interesting anyway) about how long it REALLY takes to learn programming. http://www.norvig.com/21-days.html. I'm up to 6 years right now, and still learning. I think you learn the most when you're first starting, as well as when you start to learn best practices. I didn't start learning the best ways to do things until a couple years after I started programming, and instead developed spaghetti code instead of decent OO code. I suggest the read--it's good.

Basically, when you first start coding, you learn syntax and "do this, do that" situational programming. After a while, you start to develop methodologies for programming, and then up to design patterns and other higher-level programming tactics.

Sounds like another '.NET for idiots' book.

Honestly, you can build smart applications with the emacs editor and 5 years experience 'fooling around' with code. Why does everyone want to become a brilliant programmer from day 1? Takes time you know.

Here's a free guide, shorter, more enlightening and language agnostic: Teach yourself programming in 10 years.

> If you don't understand C++, you are only liable to reinvent it. Badly.

Isn't the saying that you will reinvent Lisp, badly? Greenspun's Rule/Law? ;-)

This example is of an accumulator generator snagged from Paul Graham's website: http://www.paulgraham.com/accgen.html. Tailored to a problem that functional languages can solve more easily, but it is still interesting.

I would also recommend: For a Java/C++vs. Lisp comparison.

And for another programmers take on it where he tries the same thing: C++ hackers take

Also see another PG article: Succinctness is Power If you google for succinctness PGs article is the first result amusingly enough.

And here is a pretty famous study done on Erlang: Erlang Study

I hope we can at least agree that not all languages are created equal. I am honestly not interested in cloning or working in a langauge like C++. I am much more interested in languages like Lisp. I also freely admit that my OO experience leans heavily on Java, Lisp, and Ruby coding. And that I have little real C++ experience. I have done *basic* OO in my C++ programs. I used the STL for a couple of REALLY simple things in one of my later C++ programs but that is really about it. I try to use C++ in its more modern and usable context when I use it, but it is quite a time investment and I am really only after performance if I am using C++ so I keep it as lean and mean as possible and end up with C using objects with new and delete and a smattering of STL when it saves me time and I can easily do it without adversely affect the outcome of my program. So I base a lot of these assumptions on: a lot of C programming, a lot of OO programming, and a little C++ programming.

You might be onto something about the semantics of OO programming compared to the syntax of the language. It is relatively unimportant as long as the Syntax does not get in the way.

As for specific types of programs: Web development, simple and relatively complicated desktop applications. Pretty much anything that is not processor bound. I am being vague because I really do believe it in a very general sense. I do a lot of web development.. so in my world I am a little IO bound by network latency. You have to work around big warts like HTTP being stateless and generally you really want to maintain state. I also develop the occasional desktop application (Windows stuff ...Sigh). For Windows programs you really do need to use as little memory as you want, but you can still get away with using .NET which runs in a VM and is GCd. I really do focus on web development and network programming, though. I have written all sorts of programs such as search and data indexing stuff. It is still fast enough with hundreds of megabytes of data and it isn't C++.

So in my IO bound world I use the most productive and powerful languages I can convince my team to use without secretly wanting to murder me. There is a bigger learning curve for C++. And to be honest I am not concerned about average programmers. I only want people working for/with me that can wrap their head around any programming language even assembly. So ideally I only want to work with people that can use C++ and be good at it. Only I don't want to use C++ because I think the learning curve is not needed. That said is there REALLY a reason for every programmer to understand pointers? Is it really required. We are coming to an age where entire generations of programmers are raised on Java and GCd languages. I wasn't, but I know quite a few programmers who were/are. Do you really have to know assembly on up? Is that important for every programmer to know? You can't even talk to modern x86 processors directly these

From "Teach Yourself Programming in Ten Years"
"I did the following power search at Amazon.com:

          pubdate: after 1992 and title: days and
            (title: learn or title: teach yourself) ...
The conclusion is that either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days."

When people talk about books titled "ten yourself something in NN hours/days" it always reminds me about this webpage.

And in fact that's the truth - you can't learn that something in few days. Progamming? unix administration? sailing? playing chess? Man... that takes years to master.

Peter Norvig has a nice comparison of Python and Lisp.

I believe if you ignore books with "Quickstart Guide to...", "Idiots Guide to...", "Dummies Guide to...", or any book that promises to teach you something about computers in less than two years, you'll have very few books left to read.

Interesting related link to follow: http://norvig.com/21-days.html

It does not even have to be "broken" for people to switch. Did people switch to Excel because 1-2-3 was "broken"? No, it simply served people's needs better, and enough barriers to entry fell that it was worthwhile to switch.

Why has Firefox adoption slowed? Because about as many people have switched for whom it is worthwhile to switch to Firefox 1.0. When Firefox 1.5 is out, expect a few more to switch, because it's a little better. Firefox 2.0 will bring another level of people. If (when?) HP or Dell or Apple start preloading Firefox, it'll grow by even more.

Don't forget that it's the primary browser for lots of Linux users. Linux usage is still growing, and every Linux user has a good chance of being a Firefox user -- and a 0% chance of being an IE user.

And remember, Any technology that surpasses 50% penetration will never double again (in any number of months).

Loathing Microsoft, their products, and what they're doing to our culture is most certainly not a "Slashdot-only" perspective. Whenever I get someone who says to me "Powerpoint is a good thing", I like to forward them to The Gettysburg Powerpoint Presentation. (Trust me, you will laugh, but you may also cry.)

This was not written by a Microsoft-hater, but rather by someone who fears the ill-effects of what software like Powerpoint is doing to human communication, and how it's shaping our thoughts. I strongly suggest reading his why did I do this? article, too.

Loathing Microsoft, their products, and what they're doing to our culture is most certainly not a "Slashdot-only" perspective. Whenever I get someone who says to me "Powerpoint is a good thing", I like to forward them to The Gettysburg Powerpoint Presentation. (Trust me, you will laugh, but you may also cry.)

This was not written by a Microsoft-hater, but rather by someone who fears the ill-effects of what software like Powerpoint is doing to human communication, and how it's shaping our thoughts. I strongly suggest reading his why did I do this? article, too.

In Lisp, source filters never break.
Never.

Norvig was one of the technical reviewers for HOP, and asked in one of his reports why I spent so little space in the book discussing source code generation. I think only a Lisp expert would have asked that. Source code generation is unreliable and inadvisable in every language except Lisp.

And if you're even vaguely interested in Lisp, get a copy of his classic book. Easily the best book on programming I have ever read for any language. Norvig is The Man.

By Peter Norvig.

Don't miss the rest of his site while you're there.

By Peter Norvig.

Don't miss the rest of his site while you're there.

I've so far failed to get any of the GUI toolkits to work with SBCL or CLISP under Gentoo.

Me neither. CLX, CLIM, cl-gtk, Lambda-gtk, cl-sdl - none of them worked properly for me. They installed perfectly because the Gentoo maintainer for dev-lisp really knows what he's doing, but I couldn't get any compiled or working.

It's been very disappointing because I'm really enjoying Lisp the language, having worked my way through Practical Common Lisp and now reading the classic PAIP which must be the finest book on programming I have ever read anywhere for any language. Lisp the language has unbelievable power but all the free implementations suffer from immature interfaces to the rest of the world. That's fine if you want to use Lisp as a "glorified Logo" as yet another frustrated person on the Web put it, but for writing GUI apps with SDL, I've now chosen Lush which is a Common Lisp-based variant with a plethora of add-on libraries that actually work out of the box.

I'll keep holding thumbs that CL attracts enough people to make it as trivial to extend as Python and Ruby are now. I just remembered, cl-ltk did work for me - check it out. Peter has also added support for the new Tile widgets which have themes and advanced widgets.

Even mainstream Python won't have macros any time soon. Check out the section "Gotchas for Lisp Programmers in Python" number 12 on the Python for Lisp Programmers guide by Peter Norvig.

What's funny is that the guide is supposed to be an introduction for Lisp programmers to learn Python. But to me, it is damming evidence of why Python is so much less powerful than Common Lisp. Instead of making me want to learn Python, I wanted to learn CL even more!

Perl has been gradually tacking on closures, declarative programming, metaprogramming and other lisp-like features to the language, in a piecemeal fashion. But Perl will NEVER have a powerful, simple macro system like Lisp, since Perl's fractal syntax makes that totally impractical.

-Don

Interview with Mark Jason Dominus

The Perl Review: Why did you write Higher Order Perl?

Mark Jason Dominus: My main reasons were as I explained in the preface of the book: It had become increasingly clear to me that most Perl programmers seemed to be writing C programs in Perl, and that it was possible to do a lot better than that. We have a really good tool, and it's a shame that we're using it the same way that we have to use the old crappy tool.

[...]

TPR: At the start, you compare Perl, Lisp, and C and say that Perl is more like Lisp than C. Do you think Perl would be as powerful if it was closer to C? Could it be more powerful if it was closer to Lisp?

MJD: I don't think anyone thinks that Perl would be more powerful if it were closer to C. In the 1980s, Unix sysadmins wrote in C and in Bourne Shell, and Perl has largely replaced both of those for those sorts of tasks, leaving C a fairly small niche.

In the preface of Higher-Order Perl, I said that Perl shares six of Norvig's "seven features that make Lisp Different". The seventh one is the one that Norvig calls "uniform syntax". That's the one that led Larry to say that Lisp looks like oatmeal with fingernail clippings mixed in. But it enables language features that are so powerful that they're almost unimaginable to people who haven't studied Lisp. It's really hard to do justice to the huge benefit that Lisp gets from its simple and uniform syntax, which Perl just doesn't have at all. Any attempt to construct Perl code dynamically is fraught with error, and we take it for granted that it won't work. For example, in the documentation of the Perl6::Subs module that was recently released, Chip Salzenberg says "This module is a source filter. Source filters always break." And I think that's true. But source filters in Lisp are easy to write, and they never break. Lisp's main assignment operator, "setf", is implemented with a source filter. So if Perl were more like Lisp in that sense, I think it might be more powerful. On the other hand, I don't think it would be very Perl-like.

Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup of the issue. Paul Graham also has an interesting take on this subject.

As mentioned by Paul Graham, in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.

Powerpoint was previously explored on Slashdot.

Of particular interest was this link to a Powerpoint presentation of the Gettyburg address.

Paul Graham said it best:

For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

If you are spending a lot of code writing stuff that fits nicely into design patterns, you'd be far better off switching to a platform (any lisp platform; any python platform; ruby/rails) that frees you from this redundancy automatically.

blakespot

This is news? Sounds like a relative of Norvig's Law.

If Linux in the workplace reached 100%, would slashdot use the headline "Linux Growth in the Workplace Comes to Grinding Halt"?

Always mangled? Oh, I dunno, some prefer 'simplified', i.e. -- I always get a chuckle out of the classic "Gettysburg Address Reduced to Powerpoint".

http://www.norvig.com/Gettysburg/

[Note - you really must refer back to the original plain old 'dull' text version as you view this in order to refresh your memory of the terse, amazingly lucid text, and extract maximum value.]

NonXMLdude

You seem to imply that Powerpoint is some sort of advancement. I find it to be an impediment to information transfer, actually. I can always arrange the information using some other method which produces superior results (unless you like the car zooming audio effects and screen wipes...)

Take a look at this and then let me know if you think that powerpoint is really all that....

Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.

They did, actually. I told them (as did lots of other people) even back when Lisp was more hyped up than Java has ever been and people were dropping $100k for a single Lisp-based workstation. They just weren't listening. The result of their lack of good engineering sense and arrogance was the demise of Lisp and the predictable (and predicted) 20 years of dark ages of C/C++ programming. It just boggles the mind that 20 years later, people like you still don't get it. I guess hindsight isn't 20/20 after all.

I won't even say anything more about Java, since I don't like the language, other than that you seem to know very little about its actual capabilities. For Python vs. Lisp, read Norvig's article.

1: Learning lisp will make you a better programmer and thinker.

2: Lisp tends to be much more productive than other languages, so you can get more done with it than with most other languages, in general.

3: Lisp represents a pretty good approximation to the vanishing point toward which languages seem to be evolving, and being in the future before everyone else is cool and good for you.

1: Learning things that are meaning-heavy, as opposed to fact-heavy, tends to stretch your brain and make you think different (and better) in the future. Learning C#, C++, java, etc., is mostly minutia: getting all sorts of syntax down, remembering which class does what, and fitting all manner of facts into your head. Learning lisp tends to be a process of learning whole new methods of thinking, which tend to be enormously powerful.

2: http://www.norvig.com/java-lisp.html

3: Graham says this much better than I can.

Looking at the before and after designs, I don't see anything spectacular. It simply looks more designed. I don't have anything against highly designed documents - after all, as I mentioned, I am a member of the American Institute of Graphic Arts - but equating more designed with more usable is a mistake.

I wonder what the designer in question (Greg Storey) thinks of that most linear of documents, the novel. How might his tremendous design skills be brought to bear on the problem of more effectively presenting the information in A Tale of Two Cities than Dickens did?

At some point this obsession with presentation begins to look like the problem it's trying to solve. Compare Storey's modified presidential daily briefing to Peter Norvig's PowerPoint version of the Gettysburg Address. Not quite as bad, but moving in the same direction.

Now if IE could manage a 237% increase in marketshare that'd be impressive. It would disprove Norvig's 's Law.

Feels like this new Google feature is just an expanded version of Norvig's ELIZA recreation from his (great) book Paradigms of Artificial Intelligence Programming.