Hacker News new | comments | show | ask | jobs | submit login
How Larry Page learned Java (groups.google.com)
78 points by karussell on Apr 17, 2011 | hide | past | web | favorite | 18 comments



It seems to me that this submission (and the other recent Google code quality submission) are an amusing but perhaps misleading sidetrack. Google isn't what it is because of Larry's language choice or his coding chops. It's _much_ more about the idea and execution of page rank.

In one sense, this is the classic path trodden by people who listen to all the good advice available here. The idea of page rank was worth very little. What Larry did was learn enough programming chops to build a prototype, then used then prototype to prove the idea worked, then iterated better and better versions as the requirements became more clear and as the bottlenecks became apparent.

This is exactly the sort of advice I'd give today to anyone with "an idea" - learn enough to code up a quick prototype. If you're starting from scratch, choose a modern fashionable language since it'll probably give you an enthusiastic community of people prepared to give advice and help when you get stuck. (right now, my choice would probably be between Ruby and Haskell). Don't worry too much about code beauty or scaleability or efficiency yet - there's a very high chance your idea will turn out to be not such a great one, and you'll either pivot a few times to find a variation on the idea that is great, or drop it altogether for the next "great idea", so don't fall into the trap of investing more effort than required too early. Have a plan for how you'll do it "properly" if you get traction, but first just get something running quickly to see if anybody is likely to pay you for it...


Woah there. Be careful with that quick dismissal of what you term 'code beauty'.

Sure, constructing quick and dirty prototypes is necessary, especially if you want to assess whether the idea is actually worthwhile, but this 'well, hey, even Larry Page didn't seem to know much early on so obviously code quality is overrated, blah blah' attitude is a bit dangerous and something of a stretch (we're basing this discussion on him not knowing one small aspect of a then-beta language, c'mon).

Sure, write something quick and dirty, and seek to refactor it later, but keep in mind that doesn't justify not having the chops to be able to write reasonable code first time.

I really think this 'none of this stuff matters, it's just aesthetics' idea is really pernicious - what is this 'aesthetic' stuff? To my mind it's writing code which is clear + understandable to you and other human beings - that is all that good code is. I believe that, with discipline, you can learn to do that quickly and efficiently and scale it accordingly from prototype -> critical library without ever just totally letting loose and writing crap (where crap is defined as being difficult to understand). That's before you even begin to consider the quality of the software perf-wise if you make naive algorithm choices.

Note that prototypes very often become core systems way more often than you would expect, so these 'throwaway' systems are often not as throwaway as you first thought.

This stuff isn't aesthetic, irrelevant or subjective nicety (all ideas 'code beauty' brings to mind), this stuff is the very means by which we construct our products and core to everything we do. Can we please stop pretending otherwise?

And, though it's something of an appeal to authority, I do think it's relevant in this particular case - keep in mind when google interview people, they themselves actually seem to think this stuff you're down-playing is important. I doubt an appeal to 'well I'll learn algorithms and so on later once I've got stuff working' would really prove sufficient.


Oh for sure.

To a hacker ( or a progrMmer, or the guy who's going to have to maintain the code, possibly when it's scaled to 40,000 servers), code beauty is critical.

To "an ideas guy", a prototype is _way__ more important.

But I hope the ideas guy partners with or hires someone like you, or like Tom Christiansen - the guy who got the "write it at least twice. always throw the first version away" meme firmly stuck in my head back in comp.Lang.perl.misc in the mid 90s.

Modern startup techniques, particularly the "fail fast" mantra, strongly suggest that quick prototypes, even if they are crappily coded prototypes, are often a great idea - and are often within reach of inexperienced or non technical founders.

(and yeah, I know what you mean by throwaway code ending up as critical production systems, just this morning I got mail from a cron job trying to run a crappy perl script I wrote over 10 years ago - it's monitoring critical infrastructure for a project I did for a company I haven't been in touch with since 08, and from the grapevine I hear they got sold in 09 or 2010 and I've never even met the new owners...)


Cool, I'm glad you see my point :-) - it's just that there seems to be almost a meme going round, not just on hn, that 'hey this stuff just doesn't matter because the customer doesn't care' which seems fallacious to me (see other posts for why :-)

I think the term 'code beauty' is a poor choice though; that seems to me to implies something subjective, when in fact I fundamentally believe code quality dictacts product quality.


> In one sense, this is the classic path trodden by people who listen to all the good advice available here. The idea of page rank was worth very little. What Larry did was learn enough programming chops to build a prototype, then used then prototype to prove the idea worked, then iterated better and better versions as the requirements became more clear and as the bottlenecks became apparent.

Yes, he had to build a prototype, prove the idea worked, and iterate and address bottlenecks. But take the page rank idea away, and Google would not have been anywhere near what they are today. I don't see how the idea can be dismissed as being worth very little.


For sure, "page rank" ended up being a great idea, but Google was built on the idea _and the execution_.

Ideas are really really common. Sme of them are great, some of them are just OK, lots of them are bad ideas. Mostly, you can't reliably tell a truly great idea without a working example. My contention, and the view that I see expressed all the time in here, is that the idea _without_ the execution would have been worthless (and I suspect Larry wasn't the first only person to have the same idea, but much like the Winklevosses, anybody else who thought of it got out executed by Larry, and Larry succeeded I. The execution, not the idea.)

Yeah, you need an idea. But ideas are not that hard to come by. Execution requires some work, and as Einstein said "opportunity is missed by most people because it's dressed in overalls and looks like work."


That seems like a reasonable question to ask on a Java list back in 1996.


Yeah, I'm having trouble seeing any problem with it.

He wanted to do things the right way, made an effort to figure it out by himself, and then asked in the appropriate forum.


I think so to. In 1996, was "Programming for the Internet" (or the equivalent) actually taught in college?


In other words, don't just sit there with your hands in your pockets waiting for your friend to figure out the answer!

"How do I learn to program?" "Pick a language, start building something, ask around (with good, detailed enough questions) when you're stuck." Larry's message could have been written by anyone posting on StackOverflow.


It's amazing what information mailing lists hold about people.


The quality of something working >> any other quality of a project.


Grr I've seen many posts like this recently jumping on the slightest stuff - at the risk of being down-voted, what the hell people? I expected better, pretending like we can just hack together pieces of crap and pretend like it doesn't matter is exactly how we end up with 99% of software out there sucking and the few who bother trying for more cleaning up, in fact that's how google won out in the first place.

The quality of software is not unrelated to how its implemented. The quality of software is defined by how it's implemented.

The user might not care about the details of how you got there but they sure do care about the quality of the software itself only they don't see it in terms of the underlying details, only what the product does for them and how it does it.

Now can we stop denigrating our craft, please.


Very misleading headline.


I love how the email was sent at 4am!


Why didn't he just use Google!?

Oh... that was before the inception of Google.


Ok, sorry. title is indeed missleading. It should have been:

This was Larry Page! 1996 is perfect and then he decides to use Python after the Java mess ;)

Like I said recently http://twitter.com/#!/timetabling/status/59909520436117505


That reminds me of Ask HN/Slashdot/Reddit. Ideally I'd prefer most of them to be non-anonymous, but I know in the real world it isn't possible.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: