Slashdot Mirror


Xooglers - Google Discussed by Ex-Googlers

perler writes to tell us that Xooglers, a relatively new website created so that ex-Google employees could reminisce and share, has been gaining a great deal of popularity recently. The website shares what went wrong, what went right, and all of the funny happenings in between. Quite an interesting piece of Google history.

2 of 211 comments (clear)

  1. WTF are you babbling about? by Some+Random+Username · · Score: 1, Troll

    What does memory corruption have to do with anything? Read the mysql posting. Ron ignorantly (and incorrectly) states that mysql's lack of transations didn't matter because they can easily roll their own. This is nonsense, you cannot roll your own because if your app dies, or the db dies in the middle of one of your pseudo-transactions, then your data is left in an inconsistant state. So your pretend transactions aren't actually giving you the basic guarentee that transactions are for.

    And mods, how can you possibly mod an AC with a nonsense post about who knows what as informative? Give your head a shake, seriously.

  2. Re:If you read the stuff by njyoder · · Score: 0, Troll

    Actually, I was just trying to make an example. I have plenty of experience with C++.

    Which is why you don't know the syntax for declaring a character array?

    Well, in this case, the race condition was between the GC and the other thread.

    It wasn't, since they wouldn't using a garbage collector in this case.

    You could have race conditions, but not between the GC and a thread. In this case, it would have been a cureall.

    I don't think you understand what cureall means. If something only applies to a very select and limited case, it's very much the opposite of a cureall. I'm guessing he was inexperienced with multi-threading, because I'm no expert in it, yet even I can recognize that information you want to be globally accessible should be in a global variable of some kind.

    Well, that's why a C++ programmer gets less work done; he has to do tasks that a LISP programmer doesn't have to deal with

    Well if you repeat that enough times, it must make it true! Or not. LISP will end up taking far more time because of its limited language capabilities. The rest of the world prefers multi-paradigm langauges, and for good reason.

    In this case, the performance penalty of a LISP, over C++ would be negligible -- so overall, the C++ programmer loses.

    No, not really.

    As Ron makes clear, there were multiple programmers.

    Yes, but he apparently was the one responsible for finding this particular problem. His rant reads more like he's bitter than anything else, probably because *he* is the one who introduced the error in the first. Also, sour grapes.

    So using C++ imposes more costs: the programmers have to talk to make sure they don't fuck themselves with little implementation details

    Are you kidding me? The programmers always have to talk to eachother on ANY project, it doesn't matter what the language is. First you suggest that programmers not be cautious, then you suggest that they not talk to eachother. And this "little implementation detail" is something that should have been obvious from the beginning. "Let's use local stack storage to share details between threads" is just plain dumb.

    What's the headache? Also, why do you say "less powerful"? I'm really not getting your point here.

    Have you actually seen how enormously complex and large the C++ language is? Given that you can't even manage a simple declaration, I doubt it.

    LISP is a more powerful language, because it has closures, a GC, arbitrarily complicated macros, runtime compilation, etc.

    C++ supports all of those except runtime compilation (which is rather problematic anyway when dealing with a COMPILED language) and can do it better too. The templating system allows you to do all kinds of things, that's the beauty of C++, it's very extendable.

    Since the 1970's, Common Lisp has been faster than Fortran for problems where performance matters.

    And fortran was superseded by C in perforamance many years ago. Beating Fortran ceased being an accomplishment long ago. Incidentally, that's wrong. Back then Fortran had the best support for mathematical computations.

    Furthermore, if you will argue that "C" or C++ is faster than LISP, because you can do machine-level things, then I'd ask why you just don't use assembly, to get the most "power". Whatver "C" has, assembly has more of it, right?

    No, because the compilers are far superior. The best high level compilers you can get are for C/C++. No amount of equivalent work has gone into the sheer man-hours into their development to make the best optimizing compilers.