Web: Flock

I've been trying out Flock lately as an alternative to Firefox. Although it's based on the same rendering engine, I've heard that Flock is more stable. Flock is interesting in the way it integrates with the many social networking and blogging sites I use, but since I'm a minimalist, it's not really my cup of tea. It's been more stable than Firefox, but it doesn't support the Foxmarks plugin, so I can't synchronize my bookmarks with it. This put me in sort of an awkward position since all my bookmarks are in Firefox, and although I was able to import them, I'm not ready to give Firefox and Foxmarks up yet. I've heard that it at least supports Firebug, which is another must have for me.

Well, I've been using Flock for a week or so now, and I can really see why some people would like it. However, it's just not my thing, and it finally crashed on me. It's probably Mozilla's fault that it crashed, but I'm now tempted to switch back to Firefox.

In summary, Flock is cool, but I sure wish Mozilla were smaller and more stable. Personally, I blame C++ ;)

Updated:

I just ran out of disk space, which could be the reason Flock crashed. That is, perhaps, more forgivable ;)

Python: Walking Recursive Generators

import types

__docformat__ = "restructuredtext"


def walk_recursive_generators(generator):

    """Walk a tree of generators without yielding things recursively.

    Let's suppose you have this:

    >>> def generator0():
    ...     yield 3
    ...     yield 4
    ... 
    >>> def generator1():
    ...     yield 2
    ...     for i in generator0():
    ...         yield i
    ...     yield 5
    ... 
    >>> def generator2():
    ...     yield 1
    ...     for i in generator1():
    ...         yield i
    ...     yield 6
    ... 
    >>> for i in generator2():
    ...     print i
    ... 
    1
    2
    3
    4
    5
    6

    Notice the way the generators are recursively yielding values.  This
    library uses a technique called "bounce" that is usually used to
    implement stackless interpreters.  It lets you write:

    >>> def generator0():
    ...     yield 3
    ...     yield 4
    ... 
    >>> def generator1():
    ...     yield 2
    ...     yield generator0()
    ...     yield 5
    ... 
    >>> def generator2():
    ...     yield 1
    ...     yield generator1()
    ...     yield 6
    ... 
    >>> for i in walk_recursive_generators(generator2()):
    ...     print i
    ... 
    1
    2
    3
    4
    5
    6

    Look Ma!  No recursive yields!

    """

    stack = [generator]
    while stack:
        for x in stack[-1]:
            if isinstance(x, types.GeneratorType):
                stack.append(x)  # Recurse.
                break
            else:
                yield x
        else:
            stack.pop()


def _test():
    import doctest
    doctest.testmod()


if __name__ == "__main__":
    _test()

Updates:

• Don't insert at the beginning of the list. Append to the end.
• Call the generator before passing it. That is more flexible, and safer too since you can check against the GeneratorType.

On Paul Graham and Joel Spolsky

I've often enjoyed reading the works of Paul Graham and Joel Spolsky, but there's always been something that bothered me about them, especially Paul Graham. Paul Graham writes his arguments like a mathematical proof. Each step in the process seems reasonable, and by the time you reach the end, you don't feel like there's any room to disagree. However, I just don't think life is so black and white.

My buddy Alex Jacobson finally explained it to me. They are good "story tellers". Apparently, this is even part of the culture in New York, where Joel is from. Hence, it's enjoyable to listen to their arguments. However, there's a problem with good story tellers. Their tales are often so enjoyable that it's easy to be lulled into a false sense of security and overlook the exaggerations and mis-truths. Like listening to a good talk-show host, it's easy to forget to be objective.

For instance, it's somewhat frustrating to listen to Paul Graham's constant preaching about Lisp in comparison to any other programming language. Now, I like Lisp. I think it's fantastic. However, I think Paul Graham's arguments in favor of Lisp can occasionally be closed minded. For instance, in Beating the Averages, he portrays languages as lying along a single continuum of sophistication:

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to.

That's a seductive argument. It's so seductive, that it's easy to overlook the assumption that a continuum even makes sense. There are tons of features that Lisp doesn't have that are useful for writing applications. In fact, I like to think there's a master set of language features and each programming language simply picks some subset of that master set. Lisp has macros. Cool. However, Haskell has a really neat type system and lazy evaluation. Where does Haskell lie on the continuum in comparison to Lisp? I will remind you that Haskell too has a macro system (template Haskell). Liskell is a programming language that uses Lisp syntax on top of Haskell in order to enjoy all the benefits of both. Does that mean Liskell is the highest on the power continuum? Maybe, but it's far more likely that there simply is no continuum.

Anyway, I'm not advocating that we stop reading Paul Graham, Joel Spolsky, etc. I'm just advocating that we maintain the use of our own brains. Not everything they say is gospel.

Happy Hacking!

Books: Founders at Work

I just finished reading Founders at Work: Stories of Startups' Early Days. I've been nibbling away at it over the last five months or so. It's now one of my favorite books. If you work at a startup or are thinking of starting a startup, this book is a must read!

I like to interview, so when I'm looking for a new job, I tend to interview a lot. The last time I was looking for a job, I felt like this book was my personal guidebook to Silicon Valley (which loosely includes San Francisco). So many of the people and companies I was interviewing for were in the book. I felt like I was getting the inside scoop. Even when they weren't in the book, the book gave me insights on what a good startup looks like.

Now that I've finished building Free or Best Offer, it's time for me to look for my next startup. I wonder where the book will lead me next. Although they aren't mentioned explicitly in the book, I'm currently leaning toward Metaweb.

Free or Best Offer

Today, we launched our Facebook app Free or Best Offer. I wrote most of the code, whereas my co-worker Alex Jacobson designed most of the features. We've been working on it for the last few months.

In other news, I finally finished reading "Agile Web Development with Rails" cover-to-cover. 685 pages! Man, my head hasn't hurt this bad since I decided to read "Design Patterns: Elements of Reusable Object-Oriented Software" cover-to-cover.

Anyway, it's been quite a day. If you get a chance, checkout my app and get a free beer ;)

OOP: Alan Kay

In "Dreaming in Code" on page 289, Alan Kay, the creator of Smalltalk and of the windowing paradigm, said, "I made up the term object-oriented...and I can tell you, I did not have C++ in mind." In fact, he said that the OOP that we see today is a bastardization of his original ideas.

One thing that he had in mind was that objects would be actors. An actor is an object + a thread + a message queue. Just imagine if each object had its own thread and they passed messages to each other asynchronously. This idea is gaining popularity these days in languages like Erlang, Scala, and Groovy. I like to say that what we have today is one employee (i.e. thread) wearing many hats (i.e. running the code for many objects) vs. one employee per hat.

For a while I've been intrigued by Alan Kay's thoughts on OOP. My buddy Mike Cheponis sent me this, Dr. Alan Kay on the Meaning of "Object-Oriented Programming".

Interestingly enough, the two OO-haters I know actually agree with Kay's original thoughts on OOP.

Python: Giving a Talk at Google

I'll be giving a talk on various approaches to concurrency in Python with an emphasis on network servers at the next BayPiggies meeting which is being held at Google this Thursday.

Find out more.