koolmoe

From the article:

"But Lisp is directly executable, so you could simply make the tag names functions that automatically transform themselves."

I don't think we're talking about taking raw strings and doing evals. You control the function implementations so you have control over any danger. Writing the data as a Lisp program saves you the overhead of writing a parser and lexer and all the other tedium associated with building a compiler.

Anyway, languages that can be interpreted really illustrate that it's a blurry line between code and data. Consider Actionscript. It's a scripting language interpreted by Flash, but it's nothing but XML. You could consider it marked up data describing a specific Flash application rather than code. When the interpreter sees the code, it knows how to use the description to generate the app on the fly.

The thing that's really nice about Lisp in this respect is that it makes defining your own domain-specific language (and Actionscript is really a DSL for flash apps) about as easy as it can be. The only downside - if it is a downside at all - is that you will start creating DSL's for every app you build. Maybe that's as it should be. I think so.

>What're your predictions?

How can one make any predictions without knowing the teams?

Nicely done.

What's with the SQL, though? Doesn't NetBeans support migrations?

I think he missed the biggest differentiator between C++ and Lisp - it's fun to program in Lisp!

I agree with this. I also think that the REPL of Lisp, Ruby's irb, and Python's IDLE are very valuable for the new programmer. I knew a few languages when I hit graduate school, but I ended up doing most of my "programming" in Matlab because of the interactive shell. When I first picked up Python and later Ruby and Lisp, I was delighted by the interactivity. The instant feedback, even when it's negative, just feels more forgiving than compiler errors, and the whole process of trying things out at a prompt feels more like learning than code/compile/run.

Upvoted for this mathematician's-gauntlet-throwing snippet near the end:

"I sent an e-mail on 21 October 1999 and again on 2 December 1999 to my department's most comprehensive e-mail alias, which includes faculty, staff, and graduate students, requesting information on pet dogs. The responses were compiled and checked for accuracy on 6 December; a notarized list of the 24 dogs, including each dog's name, date of birth, and breed, and the caretaker's name, was deposited in my departmental personnel file on 21 December 1999. Gott's rule predicts that each dog will survive to twice its present age with probability 1/2. For each of the 6 dogs above 10 years old on the list, I am offering to bet Gott $1,000 US, at odds of 2:1 in his favor, that the dog will not survive to twice its age on 3 December 1999. The reason for weighting the odds in Gott's favor is to test his belief in his own predictions: given the odds, his rule says that his expected gain, at $1,000 per bet, is $6,000; moreover, the probability that he will be a net loser (by losing five or more of the six bets) is 7/64=0.109."

Putting together comments from Matt's blog and the Demo day article from Fred Wilson (?), I think they must be the ones doing fantasy sports betting. Also fits with Matt's background.

"I prefer clearly separating my work life and my fun life instead of living for my job"

That's likely because your job is not fun. If you were more invested in it (e.g., it fulfilled your dreams), you might feel differently.

Thinking that work doesn't have to be fun is what leads most people to dissatisfaction, IMO. I think the idea that your job should be a vehicle for fulfillment is a very important one. Time is scarce resource, and it is a shame that many people are willing to trade the bulk of their lives away helping someone else achieve his dreams rather than trying to achieve their own.

It occurs to me that the most liberating and frightening aspect of entrepreneurship is its lack of definition compared to traditional employment. Consider that a traditional employment relationship leaves the average employee little time for introspection, and it's easy to see that he's been trained to dream small and settle for the scraps of time he hasn't traded to his employer for a relatively small amount of money.

I like to think of programming like building a house of cards. A great card house builder would necessarily have ot take care building the foundation of his card house. In fact, he may require more time early on than an inferior builder.

However, once the house of cards gets large enough, the great builder can build much faster than the inferior builder, not because the great builder is building any less carefully, but because the inferior builder must take more and more time to place each new card, perhaps even being forced to rebuild portions of the structure.

At some point, the inferior builder can no longer extend his structure for fear of breaking large portions of his creation.

As a result, the superior builder not only builds the higher levels faster, but he is able to reach levels that inferior builders can only aspire to reach.

"At 100 million visitors, $25M translates to $4 a month per user in ad funds. $4, per user, per month, sustained for 24 months."

Unless I'm misunderstanding what you are trying to say, you're off by an order of magnitude:

$25M/100M = $0.25

Maybe it's not so insane after all.

"The article mistakes more ideas for better ideas."

Most often, the immediate goal of brainstorming is to come up with as many ideas as possible. Leaders of brainstorming sessions often start by encouraging wild ideas and discouraging the "pruning" that you speak of. In that sense, the number of ideas generated is a logical measuring stick.

The goal is usually to hit an outlier, not come out with the best solution on average. If that is the case, it's better to have more ideas, even if the median idea is worse than the median idea generated by a group.

I don't think the problem with single founders is about generating ideas. It's about not having someone to pick you up when you're discouraged, multiply your enthusiasm, and turn you back around when you've fallen in love with a bad idea.

Either that, or it's just that misery loves company. ;-)

Maybe the point is that you tend to overlook the total cost because of the small cost per event and because you are conditioned to accept the cost as a necessary evil.

IDK, but I do know that managers love those kinds of justifications.

While I agree with your point, it's not the point of the blog entry:

"...if it doesn't work when you've got one, it's extremely unlikely to work when you have dozens."

Also, there is no mention of the difficulty of gaining users, merely that your idea won't be any better when you've got them.

That's clearly not true in several cases.

When a site begins as one incarnation with a small user base and later transforms into something else when the user base has grown, it suggests that critical mass is necessary to make the transformation happen. If HotOrNot started out trying to build a dating site, they'd have been foolish not to consider scaling early on.

A small base of contributors to a wiki may be OK for a very specific domain, but as the subject area broadens, you will certainly need more contributors or you risk having very superficial contributions on some of the subjects.

Anyway, if you don't like the wiki example, what about Digg or Reddit? How about a dating site? Something like epinions?

The notion that a product that isn't useful to a handful of users won't be useful to many users clearly is not one-size-fits-all.

There are many counterexamples to Godin's point, such as wikis. Wikis are useless with few contributors but extremely useful with many.

A secondary advantage (mentioned in pg's essays) is that you can more effectively take a "constant beta" mentality. Rolling a web app out to many users can certainly speed up the process of detecting bugs versus rolling it out to a few.

I remember that.

I also remember buying my first PC around that time - probably in 1992 or 1993. It included an OEM copy of MS Encarta, which seemed like a pretty useful app at the time...

I would think that the average user in the target market for this app knows a little something about filesystems.

None of these "assets" that are supposedly lost after 30 are a function of age. Yes, there is likely a correlation.

However, even if there is a trend to be observed, the information is only useful to someone trying to select from a group of candidates, and then only if the selector is unable to distinguish between candidates on the basis of the desired characteristics. The trend is of no use to the candidates.

Thinking that you have an advantage simply because you are young is foolhardy. Lamenting that you are at a disadvantage because you are over 30 most likely reveals your lack of fortitude. You either are (and intelligent curious dedicated &rest important-attributes) or you are not.

Winer is not using the example of Jobs to refute the idea that younger people are good at startups. In fact, he acknowledges that younger people often have the willingness to accept risk and enthusiasm that their older counterparts may not have.

He's trying to refute Wilson's idea that younger people are developing the design patterns of the web while older people are used to reading the newspaper, watching TV and generally out of touch with what's going on with technology. Steve Jobs seems to be a pretty good example of a person whose ideas about technology have improved with age.

In any case, the idea that the average twentysomething is more plugged in than the average fortysomething may be valid, but it should be obvious that the situation changes when you are comparing individuals who are interested in and devoted to technology development.

I think the lack of a physical keyboard will have minimal impact on the success or failure of the iPhone.

Consider that millions of users adapted to the clunky text message interfaces of their cell phones. They aren't going to balk at a virtual keyboard, especially when the tradeoff is that you get a much larger screen for viewing video. A consumer that wouldn't buy the phone for lack of a physical keyboard probably isn't in the target market anyway.