The C++ trap

I came across this wonderful piece of historical retelling by David Beazley, one of my favorite Pythonistas and the author of Python Essential Reference. Here is a man who conquered C++ in just about every way, but ultimately found himself trapped in its byzantine complexity, only to escape by way of Python.

Swig grew a fully compatible C++ preprocessor that fully supported macros. A complete C++ type system was implemented including support for namespaces, templates, and even such things as template partial specialization. Swig evolved into a multi-pass compiler that was doing all sorts of global analysis of the interface. Just to give you an idea, Swig would do things such as automatically detect/wrap C++ smart pointers.It could wrap overloaded C++ methods/function. Also, if you had a C++ class with virtual methods, it would only make one Python wrapper function and then reuse across all wrapped subclasses.

Under the covers of all of this, the implementation basically evolved into a sophisticated macro preprocessor coupled with a pattern matching engine built on top of the C++ type system […] This whole pattern matching approach had a huge power if you knew what you were doing […]

In hindsight however, I think the complexity of Swig has exceeded anyone’s ability to fully understand it (including my own). For example, to even make sense of what’s happening, you have to have a pretty solid grasp of the C/C++ type system (easier said than done). Couple that with all sorts of crazy pattern matching, low-level code fragments, and a ton of macro definitions, your head will literally explode if you try to figure out what’s happening. So far as I know, recent versions of Swig have even combined all of this type-pattern matching with regular expressions. I can’t even fathom it.

Sadly, my involvement was Swig was an unfortunate casualty of my academic career biting the dust. By 2005, I was so burned out of working on it and so sick of what I was doing, I quite literally put all of my computer stuff aside to go play in a band for a few years. After a few years, I came back to programming (obviously), but not to keep working on the same stuff. In particularly, I will die quite happy if I never have to look at another line of C++ code ever again. No, I would much rather fling my toddlers, ride my bike, play piano, or do just about anything than ever do that again.

From this Swig mailing list entry.

import this: learning the Zen of Python with code and slides

It’s hard to find me gushing more unapologetically than when I talk about the virtues of my favorite programming language, Python.

Indeed, my life for the last 3 years has been dominated by the language. In many ways, pursuing a startup and enduring the associated financial hardship was partially because I had become frustrated with using Java in my full-time work and wanted to convert hobby projects I was building outside of work hours into full-fledged projects.

Continue reading import this: learning the Zen of Python with code and slides

Upcoming: standing desk setup, Python training, Groovy/JavaScript articles

I’ve been quite busy with work lately, so haven’t had time to send a few posts toward my blog. However, I have been working on some spare time and work-related projects that I’d love to share with everyone here.

Among them:

  • Lifehacking through standing desks. I have created a standing desk setup for my home office, and my investors in Parse.ly have created a healthy startup office in NYC. I have some thoughts about this as it applies engineering and hacking to the thing many of us do most: sit in a desk chair all day.
  • 2-day Python Training Course. I have created a 2-day Python training course that helps existing programmers learn Python by comparing it very directly to languages they may already know, like C and Java. I gave this course to a group of government employees a few months ago. It has some interesting characteristics: I designed the whole course using ReStructured Text (ReST) and compiled it into a web-based presentation. This means that the entire course has the potential to be “open source” — exercises, slides, and all. I plan to release this to the public. For now, I am just clearing a few of the images I used in the course to make sure I don’t inadvertently infringe copyright. After that, I will open to the public.
  • Groovy/JavaScript articles go public domain. Some articles I wrote for GroovyMag and JSMag last year are now able to be published in the public domain. These include one about RESTful services with Groovy, one that talks about functional programming with JavaScript, and finally one that discusses a design for “metagrids” in ExtJS 3.x. I will put all three articles up on this blog once they are reformatted.

Stay tuned!

Groovy, the Python of Java

I was a bona fide Java programmer for 5 years before I started working on Aleph Point and Parse.ly. I truly believe that Python and JavaScript are fundamentally better languages than Java for a variety of reasons born out of experience with each of them. (Note: Before this gets marked as flamebait, please notice that not only was I Java programmer for more than 5 years, but I was also a Java open source contributor!) I have enormous respect for the Java open source community, which has produced some of the highest quality modules available anywhere.

Now, don’t get me wrong — Python also has batteries included, and usually, when I think that I’m missing a great module I used to use in Java, it already exists in a much more powerful form in Python’s Standard Library or the wealth of modules on PyPI, GitHub, and Bitbucket. However, I believe in not reinventing the wheel, and so if a great open source tool exists in Java, I will want to interact with it.

One of these modules which we use extensively at Parse.ly is Apache Solr, and its surrounding Lucene project modules. Lucene is an extremely mature framework for document indexing, and Solr is a powerful server-ization of that technology that fits well into complex, mixed language distributed systems. I know there are efforts — like Whoosh — to build fast search engines atop the Python language. And I applaud these efforts — more projects means more competition, and more competition means better products. However, I still believe that you go with the best of breed tools available for production software, and you try not to let religious arguments about programming language get in the way.

Lately, I have come across more and more Java open source projects that have no equivalent in Python, and which I would like to access. Knowing that I wanted to feel comfortable incorporating Java open source projects — beyond Solr, which was already nicely wrapped as a web service — I, at first, thought that I’d be forced to still live among the weeds of complex class and interface definitions, cumbersome Java IDEs, XML configuration files, and (IMO) time-wasting rabbit holes like dependency injection, configuration management, and classpath hell. And then I found Groovy.

Continue reading Groovy, the Python of Java

Pythonic means idiomatic and tasteful

Pythonic isn’t just idiomatic Python — it’s tasteful Python. It’s less an objective property of code, more a compliment bestowed onto especially nice Python code. The reason Pythonistas have their own word for this is because Python is a language that encourages good taste; Python programmers with poor taste tend to write un-Pythonic code.

This is highly subjective, but can be easily understood by Pythonistas who have been with the language for awhile.

Here’s some un-Pythonic code:

def xform(item):
    data = {}
    data["title"] = item["title"].encode("utf-8", "ignore")
    data["summary"] = item["summary"].encode("utf-8", "ignore")
    return data

This code is both un-Pythonic and unidiomatic. There’s some code duplication which can very easily be factored out. The programmer hasn’t used concise, readability-enhancing facilities that are available to him by the language. Even lazy programmers will recognize this code’s clear downsides.

Continue reading Pythonic means idiomatic and tasteful

What One Does

One of America’s greatest strengths is social mobility. There are several cases of an individual starting with nothing and persevering to become rich, powerful, and influential. Success stories of this kind have become an important part of American business mythology, especially in the world of entrepreneurship. They are strong motivators for individuals embarking on companies of their own.

For those of us who start companies, we see the company as a vehicle to creating something valuable and lasting for society, while also advancing our personal goals. This isn’t usually hubris or ego, though sometimes it may be. Instead, it’s usually an attempt to make your time worthwhile: to yourself, to those close to you, and — if you’re lucky and persistent enough — to the entire world.

The problem with social mobility is that not every individual begins at the same starting line. In fact, the range is huge. Those who start with an influential family or significant capital resources have a much easier time getting to the top. For those who don’t have this head start, things are a lot harder.

Though America is not entirely merit-based, it can reward individuals for hard work. I’ve experienced the benefit both of an advantageous starting point and hard work in my 26 years on this earth. I also believe that with each step and milestone in my life, my potential to create enduring value for society has increased significantly.

Beginnings

The inspiration for this essay was a comment I read online about a successful young businessman who was the son of a successful businessman. “I’d [like to] read a story about a 25-yo [who] made good on the same scale[,] who went to a state college, had screwed up parents who were too busy fighting with each other or gettiing drunk to even have a clue what he was doing, isn’t childhood friends with a celebrity… Just happened to be smart and hardworking and optimistic even despite all those factors. That would actually be an interesting story.”

My parents weren’t screwed up, but they did fight a lot — my Mom and Dad separated when I was in elementary school and divorced shortly after that. I’ve not been childhood friends with a celebrity and I don’t have a trust fund.

I’m not saying I came from a disadvantaged upbringing — in fact, quite the opposite. I went to public high school in New York. To a New Yorker, that may not sound like a huge step up in the world, but I recognize that public school in New York represents one of the top educations you can get.

I grew up in a nice house in a quiet suburban neighborhood. I had good, encouraging teachers. My parents were liberal and a positive influence. I didn’t have a silver spoon in my mouth, but I also didn’t have any serious handicap in my upbringing. Probably my biggest step up in the world, given my current trajectory, was that when I was 10 or 11 years old, my Dad noticed an interest I had in computers. And so, he bought me a PC (running DOS / Windows 3.1) and set it up for me on Christmas Day. From that point forward, I was enchanted by the machine. And once I got a 28K modem and dial-up access to the web (on one of the first ISPs, The Pipeline), I became a citizen of the world before I had even hit puberty.

This I do know — though I had a head start, I also worked hard. I was a geek — as I got older, I built my own servers in my basement, taught myself to program, and discovered Linux and Free Software. But I also kept ahead in “the real world”. I did feel a little disconnected from my peers in my private pursuits; reflecting on my childhood, I realize I “grew up” a little more quickly than my peers.

Continue reading What One Does

Flavors.me emerges from beta: lifestreaming for the masses

My good friends at HiiDef just launched a new app that has been in beta for awhile, Flavors.me. This is an excellent tool that has a great, simple, and usable design.

What’s the value preposition of Flavors.me? It’s to unify your various “online identities” into a single, dynamic, automatically-updated, and elegant website.

What do I mean by that? OK — so, like most people on the web, you spread public information about yourself in multiple places. You might run one or two blogs (personal and work?). You might have a Facebook account, a Twitter account. You may share your favorite books at GoodReads, your favorite movies at Netflix, and your favorite music on Last.fm.

Flavors.me lets you take all that information and put it together in a single website to serve as your “online identity”. All your publicly shared information, aggregated in one place, and displayed beautifully.

I’ve been running a Flavors.me site for some time that you can see here: http://flavors.me/pixelmonkey

pixelmonkey-flavorsme

Now, that’s the end product. All the content gets pulled dynamically from your various online feeds. The real magic with Flavors.me is how easy it is to get there. You can drastically change the look and feel of this site using a dynamic, “WYSIWYG” interface. You can do one or two clicks to add a service, reorder it, rename it. Another couple of clicks and you change font sizes, colors, and even the overall layout.

Continue reading Flavors.me emerges from beta: lifestreaming for the masses

The danger of feature-driven design

I recently re-read Douglas Crockford’s JavaScript: The Good Parts. I have been writing more and more JavaScript lately, especially object-oriented JavaScript plugging into existing frameworks. Re-reading the book has definitely been a useful exercise — I think when I first read it approximately 6 months ago, I didn’t fully understand it. But now, I do.

I also found it very interesting to hear Crockford wax poetic about the virtue of simplicity in all forms of software design. The following passage concludes the book.

When I started thinking about this[…], I wanted to take the subset idea further, to show how to take an existing [product] and make significant improvements to it by making no changes except to exclude the low-value features.

We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to consumers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.

Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile applications is becoming significant again. There are ascending performance costs because Moore’s Law doesn’t apply to batteries.

Features have a documentation cost. Every feature adds pages to the manual, increasing training costs. Features that offer value to a minority of users impose a cost on all users. So, in designing products[…], we want to get the core features—the good parts—right because that is where we create most of the value.

We all find the good parts in the products that we use. We value simplicity, and when simplicity isn’t offered to us, we make it ourselves. My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.

It would be nice if products[…] were designed to have only good parts.

I removed direct references to the main subject of Crockford’s discussion — namely, the JavaScript language itself. The truth is, this advice is much more valuable for the design of all software products. Perhaps one day someone will write the much needed book, Startups: The Good Parts.

Persistent Folders: Or, why ideas don’t matter, and execution does

I’ll start off this post with a somewhat controversial claim: I invented Dropbox.

I’ll show why this claim doesn’t matter later, but for now, I’ll assure you that it’s true.

How many of you out there use Dropbox? If you don’t, you should — it’s an excellent tool. In its free version, it provides you with 2GB of storage “in the cloud”, using a new kind of folder called a “Dropbox”. What distinguishes a Dropbox from other folders on your computer? The following:

  • Every file put in your Dropbox is automatically (and securely) uploaded to Dropbox’s servers, ensuring you have an offsite backup of all data therein.
  • Multiple computers can gain access to a Dropbox, ensuring files are automatically synchronized across computers without having to use complication version control systems.
  • All files in your Dropbox are versioned, ensuring you can always recover an older version of a file in case you accidentally overwrite a good version.

Dropbox is supported on Windows, Mac OS X, and Linux, and now even has mobile applications, as well. Further, I have a special place in my heart for this service because I started using it almost 2 years ago, and it has acted as a file sharing and project management tool for my own startup’s internal operations at Parse.ly. I was therefore more than ecstatic to discover that this excellent tool and its smart founders had also made it through all of the hurdles necessary to get an early-stage company the financing it needs: they’ve raised over $7 million in financing and have over 3 million users.

But there is another reason I absolutely love Dropbox: because it was my idea. I invented it.

Continue reading Persistent Folders: Or, why ideas don’t matter, and execution does

Simplifying CSS with 960.gs

I recently did some web design work in collaboration with a graphic designer. She introduced me to what has become my latest favorite piece of CSS code: 960.gs.

960.gs is a CSS grid framework, similar in spirit to Blueprint CSS and YUI Grid. However, 960.gs is at once more minimalist than these approaches, and more thorough.

The author has a detailed blog post explaining his motivations for working on 960.gs, so I won’t rehash each of those. Instead, I’ll just dive into what I liked about it.

Continue reading Simplifying CSS with 960.gs