dhouston

which, even for people like me who drink the interpreted-languages-are-fast-enough koolaid, seems like a lot of levels of indirection :) i think the CLR approach seems a little more straightforward: "native" interpreters that compile e.g. python->the CLR IL (instead of python->interpreter c source->llvm->actionscript).

and i doubt you could just take e.g. the python interpreter and throw it into a SWF -- certainly pieces of the interpreter along with C modules that interact with the filesystem, etc. would need to be tweaked to deal with the AIR runtime.

cool idea though, and they even got quake 1 (!) running in a SWF (see the video below in this thread... wild stuff)

things have, um, changed significantly -- nowadays libraries like directx abstract away the details of direct hardware access and handle graphics, sound, input, timers, etc.

if you're just looking to play around with games, pygame is perfect for you -- http://www.pygame.org .

if you're really looking to learn the details, you should probably grab a couple books on amazon (hard to recommend one in particular without knowing what you wanna do.)

2) my negotiation class (although practice is more useful :P)

3) getting used to busting my ass/grinding through problems

having "batteries included"/mature web frameworks often trumps the innate benefits of the language, i.e. other people who have spent thousands of hours on mostly boring glue -- ORMs, unicode support, templating engines, caching, getting around browser quirks -- to enable you to focus on your app.

furthermore, you're generally going to be bounded by IO/the database or RAM or some other factor in which case the speed of the language is mostly irrelevant.

it's certainly possible to do web development in any language, but why bother swimming upstream when python/php/ruby do a lot of the hard work for you? it's hard enough just to write your application without having to write the infrastructure beneath it too.

i've followed both models, but one of the best things you get from outside investors is forced accountability; it's a good kick in the ass to regularly take hard looks at your plan and have to meet deadlines and ship stuff.

if you're bootstrapping or part time, it's easy to kind of fart along and spend years on an idea that would have either succeeded or failed quickly if you had been forced to execute to a plan.

- activestate komodo for python/perl/php

- visual studio for c++

congrats, anson, lux and sachin!

- working on interesting technical problems that don't correspond to problems that people need solved

- making something that's only slightly better than what's out there (e.g. a slightly better news site or social network) and expecting everyone will magically switch or improves in areas that no one cares about

we'll be kicking out news.yc beta invites soon :)

survivorship bias strikes again: for every CL or POF there are thousands of ugly sites which are dead; and the vast majority of popular sites have pleasing designs.

second, i think it's common for developers to get the equivalent of writers' block when the upcoming task is large and/or poorly defined. some things that have helped with this:

- tricking yourself to take on little pieces of the bigger project (google 'structured procrastination' and hamming's article on productivity); carving out explicit "next steps" (without dependencies) that you can start on now

- writing down a plan or specs to at least get things on paper/into your editor to bring clarity to a jumble of random thoughts

- reducing distractions; putting on headphones (esp. noise cancelling); stopping multitasking http://www.joelonsoftware.com/articles/fog0000000022.html ; also, turning off AIM (or putting up an away message plus hide windows) and your mail client's new-email popup/toaster massively cuts down interruptions

- using rescuetime (to assess the damage and/or feel guilty about screwing around :)), noprocrast on news.yc or just making a commitment to yourself to wean yourself off of news/blog sugar

lots of people have written about productivity; http://blog.pmarca.com/2007/06/the_pmarca_guid.html and http://www.paulgraham.com/hamming.html are good starting points.

but ironically it's tempting to waste a lot of time "preparing" yourself to be really productive or trying to come up with the perfect system. i think there are natural ebbs and flows in levels of productivity; a lot of the battle is detecting when you're slumping and instead of beating yourself up, try to trick yourself into making that period as short as possible.

1. picked a list of 50-60 words/prefixes/suffixes we liked

2. wrote a python script to generate permutations, and then

3. ran dig -f on the text file to see which weren't taken

4. scraped buydomains search results to see which ones were easily for sale.

absolutely everything else was a waste of time, although we're also working with a naming agency and that might be promising (but expensive).

amusingly, domains that were occupied by squatters or companies like buydomains were easier to deal with -- at least they're rational and the conversation, though annoying, is straightforward (arrive at a #.)

domains that are occupied but unused (and don't have a 'for sale' sign hanging up) are generally hopeless. if you get a response, you'll generally get some whacko who either won't sell it, or who will only sell for millions of dollars or something. you'll probably not believe me, and will learn this the hard way (just as pg told us months ago :))

ok enough bad news -- some links that might help:

http://blog.guykawasaki.com/2006/02/the_name_game.html

http://onstartups.com/home/tabid/3339/bid/223/The-Startup-Na...

http://foundread.com/2007/08/20/3-rules-for-naming-your-star...

and last and best (a 100+ page guide)

http://www.igorinternational.com/process/igor-naming-guide.p...

hope this helps -- it's a struggle :)

otherwise, you will lose the traffic that assumes xyz.com is your domain.

and not just from random visitors but important contacts like investors, who assumed we were at dropbox.com. even people who knew well that we were at getdropbox.com would routinely fire off emails to dropbox.com by accident.

the process sucks, but we're changing our name after wasting a lot of time hoping we could secure dropbox.com and going back and forth with the owner.

there are a bunch of useful "top N questions" blog posts from VCs and entrepreneurs that should give you a good start.

i'd also say spend a lot of time coming up with a story and framing your opportunity in the biggest possible way. this was something i really underestimated -- initially we'd just show a list of features and expect everyone to arrive at the vision we had in our heads, but really it's the other way around -- the features drive a more important story and vision.

a story is also a lot easier for an investor to retell and get other people excited about than a laundry list of "um, it does this, and this, and this..." remember, VCs have to then turn around and sell their own general partnership on the idea, so give them the ammo they need to do this effectively.

also -- practice your pitch until it becomes mechanical. not so much by standing in front of a mirror (though that helps too) but rather by debugging it with individual angels or mentors, so that by the time you pitch the investors you really want you've already seen most of the universe of possible objections and surprises and can handle them effectively.

(young entrepreneurs... popular companies... what in particular?)

1) look at http://venturehacks.com to get a better understanding of how the fundraising process works and tactically how to raise interest. investors also generally want a team in place, not one person plus some part timers.

2) if you can talk more about your company, the audience here has some rich individual investors here who wouldn't put you through the bullshit that angel groups would, and even more people who, if not rich themselves, are one degree of separation away from potential investors.