Spyced

I attended Paul Graham's Startup School this past Saturday. (Thanks to Drew Houston for letting me crash at his place!) I took fairly detailed notes on the speakers; I think this is the most comprehensive overview available, actually. (Note that these are in the order they actually spoke, which isn't quite the same as the plan .) Langley Steinert , entrepreneur. Short "entrepreneurship 101" talk. Lots of interesting Q&A. Marc Hedlund , Entrepreneur in Residence, O'Reilly Media. Talks about over a dozen startups he's seen in the last couple years -- most of which you'll recognize -- and why they succeeded. Qi Lu , VC at Yahoo. One subject: Why yahoo rocks. Total advertorial; skip this one unless you're a yahoo fanboy. Hutch Fishman , part-time CFO for startups. Talks about VC founds, directors, liquidity. Pretty basic stuff if you've read up on this at all, but his Q&A is worth reading. Paul Graham , author of entrepreneurship e...

Like many programmers (I suspect) who hear enough Lisp afficionados talk about how great their language is, I've given Lisp a try. Twice. I didn't make much headway on either occasion. For various reasons I was poking around python/lisp in google tonight and I came across this thread from a couple years ago. This crystalized it for me: now compare if x > y or a == 0: a1 = m * x + b else: a2 = m / x - b with (if (or (> x y ) (zerop a)) (setq a1 (+ (* m x ) b ) (setq a2 (- (/ m x ) b )). In this case, Lisp requires about 33% more typing, almost all parentheses. And, oh yeah, I forgot, aside from the parentheses, the pervasive prefix notation can be a drag. Syntax does matter. Everyone who has run screaming from a steaming pile of Perl understands this. Lisp's syntax isn't the train wreck that Perl's is; at the very least it's consistent. I could get used to it if there we...

As a (mostly ex-) Java programmer myself who prefers Python to Ruby, I'm puzzled by what seems like a rush of Java programmers to embrace Ruby as though it were the only dynamic language on the planet. I understand that it's mostly because of the success of Rails, which definitely came at the right time with the right marketing. But Ruby really doesn't seem like a good philosophical match with Java to me. Java, to a large degree, tried to be "C++ done right." That is, C++ without all the misfeatures that seemed good at the time but whose benefit turned out to not be worth the cost in complexity for developers. Java is a very orthogonally designed language; there is usually one obvious way to accomplish something. Python shares this. Ruby, OTOH, takes the C++ and Perl philosophy of "there's more than one way to do it," with predictible effects on maintainability. ("Perl," said a former co-worker to me yesterday, "is the drunken...

Brace you must Written it is, the Console. “Hello World” YODA the programming language

John, of course, writes the OS X reviews for ars technica. (If you haven't read these, you need to. His level of detail should make lesser reviewers think hard about finding another career.) In his blog, he's been talking about what Apple needs to do to avoid another Copland scenario , i.e., avoid resting on their OS X achievments only to wake up in 2010 and realize, "Oh crap! It's WAY easier to write apps for Windows than for OS X!" Which is a rather long introduction to the quote I liked so much: My instincts tell me that both C# and Java are too low-level. Yes, they both have fully automatic memory management, and both eschew C-style pointers for the sake of safety and security, which is more than can be said for Objective-C. But the runtime that Objective-C uses to do its "object stuff" is arguably higher-level than either C# or Java, both of which still seem to cling to charmingly retro notions of compile-time optimizations and "efficien...

Victor Moholy : A bad API, like a bad novel, feels like a trick: key information is withheld and simple relationships are hard to deduce. I had one of those "a-ha" moments reading this. ("A-ha," I thought. "I feel a rant coming on.") This is exactly why, after building probably one of the largest web applications done with OpenACS 3.2, I never managed to like the 4.x (and now 5.x) series of that toolkit. OpenACS 4.x and later suffer from Second-system syndrome . The effect is rather Zope-like: instead of a learning curve, you have a vertical cliff to scale before you can accomplish anything interesting. Add in bizarre and arbitrary api changes , it's no wonder nobody except the core team really got on board with the later OpenACS versions. (I suspect that the "everything must be a named parameter" had its genesis in the proliferation of functions taking over a dozen parameters. Deprecating all functions that don't require nam...