When we ran our app in FF3 for the first time, we were dismayed to find that, after all the talk about browser performance improvements, it had actually gotten a lot slower (especially when scrolling) [~]. As far as I can tell, they're optimizing the wrong stuff. It's possible that our app is unique, but I doubt it. To judge by Google, many people appear to be experiencing the same thing.

[~] Safari 3, on the other hand, sped up our app considerably.

Edit: The only person I know of who's raised this issue is John Resig: http://ejohn.org/blog/javascript-performance-stack/

This may be the study that the author is discussing, although it was released in 2007.

http://www.unicef-irc.org/publications/pdf/rc7_eng.pdf

Hopefully, anyone on this board isn't afraid of real data. The picture seems kind of mixed and even the authors find it difficult to pin down the exact sources of well-being.

I find if something is important enough, it will get to me one way or another. Or I'll see it passing by on HN.

I remember everyone hating google talk when it first came out. No one liked Google news when it first came out either.

There is no guarantees but give it six months to a year before you're 100% sure it's dead.

To nitpick, I think Agarwal's wording about the liquidation preference gives the impression the term sheet implements what's called 'fully participating' preference, where even after collecting the preference amount, they also share in the remaining money.

IANAL, but I think the wording actually implies a 'non-participating' preference: series AA can take the preference amount, or convert to common and share pro-ratably with commons, but not both.

To picture the difference: take Agarwal's example of selling 10% for $10K. But then imagine the company is sold for only $110K. With fully-participating preferred, I believe the investor gets their $10K liquidation preference, then also 10% of the remaining money, for a total of $20K. With non-participating, they could take the $10K liquidation preference, but then they would share none of the rest with the common. Instead they will choose to convert to common and get 10% of the total, $11K. (Someone please correct me if I'm wrong.)

Yeah, but this is an area where both languages are just a mess. If python's lambda is castrated, ruby's notion of an anonymous function is tumorous. We've got blocks, procs, lambdas and methods? What's the difference?

Ruby mixes up the syntactic requirements of "passing" some code to a loop to iterate with with the data requirements of binding a function to a scope. It's just a huge mess.

LISP and Scheme figured all this out decades ago, and yet only Javascript (and, almost, perl) among common scripting languages has managed to absorb the lesson.

Felix Dennis is one of those rare racehorses that not only can run fast, but can also tell you exactly how to run fast.

One of the best books I've read. Very frank and upfront. I re-evaluated many of my beliefs and assumptions after reading it.

It also makes this pointless but interesting piece of code possible:

  class foo(object):
     def subclassme(self):
          class subclass(type(self)):
              def __init__(self2):
                  self2.parentobj=self
          return subclass()

We did that for about two months and then took the invite barrier down. Worked for us.

edit: I forgot the second half of this story. A few months after we took the invite barrier down, we decided to do a "Hollywood" launch - really all we were doing was changing the "alpha" to "beta" and releasing some new features (earning cards by playing games). It worked, we got lots of press. Fox News even called and asked if I could go on their afternoon cable show. I did (here's the video - http://tinyurl.com/2gpz7x). Our site immediately cratered - it was a much, much bigger surge than Digg. We got it back up in about 20 minutes and the follow on traffic was good as well.

So I guess we did a hybrid Gmail/Hollywood.

Instead, Python finds another way, like powerful list comprehensions that can be used wherever Ruby would use blocks and maps.

So I would say you can learn some very interesting things from either language, and there's a good chance they will be different interesting things.

I realize most members here are founders of startups that deal with webapps, but there are some startups that deal with traditional desktop applications - true "software," who share similar interests.

That said - I wonder which of these two approaches is better for desktop software development. I'd imagine the fact that a user has installed your software is a "hook" of sorts - they're easier to reel in than website visitors which can escape rather more easily.

But, y'know, you could try quantifying it if you like, by looking at the libraries available for each language, and looking at how many jobs are "Ruby" as their main skill and how many are "10 years of whatever + Python".

    a=1+2

    a = 1      + 2

I also look at the recruiting efforts my current company (startup in early 200x, now decidedly not-startupy, public, and $500+K in annual revenue): we bias heavily towards "top" CS schools when doing college recruiting. We've gotten some absolutely fabulous candidates from "second tier" schools and we naturally recruit there every year, but if you come from MIT, you get a full 25% (estimated) better chance right from the start of the interview.

For my own account (plural of anecdote not being data notwithstanding), despite being a pretty strong candidate, I strongly suspect that my current lot in life is based more than 50% on my attending (and not even spectacular results at) MIT, and as a result, I give heartily every time they call for alumni donations.

Employers and founders: MIT isn't all that special. So called "second tier" schools also have some extremely capable potential employees, and individual talent, motivation and drive is FAR more important.

High-school students: If you have the choice between MIT and $200K in debt and a state school with a full ride, and you're pretty sure you're going to work in engineering for 20 years, definitely go to MIT. Right or wrong, that name opens doors, and I believe I've done a lot more interesting and lucrative work than I'd have been able to do from the full ride I had offered to me at UMCP.

As an MIT grad, I'm a lot less impressed with the brass rat than most people who are in a position to help shape your lot in life. If you're going to found 5 startups in the hopes that one will be a solid success, save the $200K and invest it in your startups. If you're going to go work for someone else, even just for a while, you'll have no problem paying off your student loans from MIT, or any other top school, IME.

Don't worry about ads and early adopters. Most of them have adblock or some variant turned on, the rest probably don't click on the ads anyway.

A language is not just the syntax of the language itself, it's also the code style, the convention, the best practise, the language specific stuff, the API of the libraries available, the best way of doing things with libraries.

If you use python to write simple number crunching console applications, then switch to ruby, that is an easy switch.

But if you're writing a Web application using Python and Django and you switch to writing DirectSound using C++, and you tell me you can do this in a week, then you are a genius.

The syntax of languages are trivial, but that's like saying you can discover the colors used in a painting. That's the easy part. The difficult part is knowing how it works. Let me list a few examples of technologies that I think differ strongly from each other that make it difficult to switch

- MFC with C++

- Django with Python

- DirectShow with C++

- VHDL

- ASM

- Javascript with JQuery

- CSS with HTML

- Helix Framework with C++

- Quicktime API with C++

- OpenGL with .NET

- LISP

Have you ever had to switch between things on that level? Or are you talking more of a python to ruby switch?

Your Ruby problem with blocks and Proc objects is a nit about elegance and semantics. How often does the difference between an actual Proc object and a block actually affect you? More importantly, if the cost of fixing that nit is that we wind up with Lisp's or Javascript's lambda notation, who would accept that? Javascript has relatively consistent semantics for anonymous functions, but extremely clumsy syntax.

Python simply doesn't have real lambdas. It has the ability to pass something called a lambda in place of a function, and that something forces you to think about things like the difference between a statement and an expression. It then tells you that you don't in fact want anonymous functions, but instead you want to define tens of itty bitty named functions and use them instead. You also "want" that "self" argument to all your methods, and you "want" to tack two underscores to the front of your method names to make them private.

So, I half agree with you. Yes, it would be nice if there was a (zero-cost) way of fixing Ruby's block semantics. Yes, I can rely on Lisp's lambda semantics slightly more than I can on Ruby's, which does start to matter when you start writing domain-specific language code. But I don't agree that this has any bearing on the Python vs. Ruby argument. Python lambdas suck.

I'd mod this up more if I could, because this is the best answer to the original question.

The important thing is the community, not the language. Decide what your problem is, find the people who are working on that problem, and use whatever they use.

The importance of community is the reason why the number of people who praise Lisp as a language is so much larger than the number who use Lisp every day: The Lisp community is small, unfocused, and arguably broken. Meanwhile, I work as a professional Drupal developer and am (god help me) gradually becoming an expert on PHP, but that has nothing to do with my nigh-nonexistent respect for PHP as a language. I do it because the Drupal community is large and growing larger, it includes as many noncoders as coders, and it's focused on building websites rather than obsessing over tools. The result seems to be that customers like using Drupal for their sites. Rails and the like are focused on making programmers feel empowered, but Drupal is focused on making site admins feel empowered.