Andrew Montalenti

In 2009, Jack & Russ hacked on an early prototype of SeatGeek for the Dreamit Ventures summer class in Philadelphia. The initial prototype came together in the last two weeks before demo day. I remember that Russ hadn’t shaved in weeks because they were spending every night hacking.

You see, before that, the founding pair knew they wanted to start a company, but they weren’t sure about the idea. They had brainstormed ideas ranging from “WebMD for pets” to “amateur art marketplaces”, finally landing at “Yelp for Bloggers”, an idea they called Scribnia. This got them into Dreamit Ventures.

Continue reading What entrepreneurship really looks like

From a poster at Hacker News commenting on The New Yorker article, Inside the Collapse of The New Republic:

I think I’m exactly the audience that TNR wants. I’m well-educated, make a good living, largely agree with them politically, enjoy long-form journalism, and am familiar with the brand and its history.

Yet I don’t think I would ever subscribe to TNR. I just see a magazine as something that’s going to pile up in my house. I can read more than enough great content online for free. If I was going to subscribe to a magazine, I think that The New Yorker is a lot more interesting than The New Republic.

Take note, journalistas. This is how your readers view your stuff — not as a “public trust”, “a voice”, or “a cause”, as TNR was described by the exiting editors in their resignation letter.

For better or worse, readers view your stuff as a product. And a product, to be bought, let alone used, needs to be useful.

Continue reading The New Republic as a product

Interesting insider Q&A with Paul Sutter, co-founder of Quantcast. Via Hacker News:

Q: What methodical process did you follow for your startup? Did you first test the market using tactics similar to the lean startup approach?

A: Basically, make a list of known problems that you’re well suited to solving, rank them by criteria, fail a lot, bang your head against the wall, and eventually things start to stick.

Continue reading Solving problems with startups

Apache Storm, Kafka, and Spark are gaining a lot of momentum in the data analysis and processing communities. I was curious whether the interest in using these technologies with Python, in particular, is growing. Based on these Google Trends reports, it seems like it is.

Continue reading Web interest in Apache Storm, Kafka, Spark in the Python community

In June 2012, I promised myself that I’d learn Clojure “as a mind expander”. As a long-time Python programmer who has been using Python full-time in my work at Parse.ly, I wanted to explore. I wrote then:

I don’t know whether Clojure programs will be better or worse than equivalent Python programs. But I know they will be different.

It took me awhile, but in January of this year, I started teaching myself the language.

Rich Hickey, and the “Cult of Personality”

My approach was to first learn the underpinnings of the language from books and online videos. If you embark on this for Clojure, you will inevitably run into the copious publicly-available material from the language’s creator, Rich Hickey.
In stark contrast to Guido van Rossum in the Python community, Rich Hickey is undeniably not just the Clojure language’s creator, but also a kind of spokesperson for a functional programming renaissance. Guido van Rossum generally lays low and lets the Python language and community speak for itself, and tries to avoid controversy. To him, Python is just a popular tool he happened to create, and it doesn’t represent any major paradigm shift in programming. It’s a positive evolutionary improvement supported by a great open source ecosystem and community. To Hickey, however, “traditional” programming languages — but especially popular ones with an object-oriented focus, such as Java and C++ — are just plain wrong. He proposes Clojure as an antidote of sorts.

You can get the gist of this from his motivating videos, such as Hammock-Driven Development, Are We There Yet?, and Simple Made Easy. For a thorough overview of Clojure as a language, you can also get a walkthrough by Hickey, given to a room full of Java developers, in Clojure for Java Programmers Part I and Part II.

Here is a summary of the viewpoint. Most languages are missing some important attributes that can help us tackle the most complex issues in programming projects:

Continue reading Clojonic: Pythonic Clojure

For many years, IT as a field was dominated by people who could not write code.

This is because computer technology was mystifying and befuddling to most people that anyone who knew merely how to use computers with any level of comfort could demand a tax from those who didn’t.

During that same period (late 90s and early 2000’s), programming itself was being commoditized by offshore outsourcing, so the same IT people were positioning themselves for management positions. This is how MIS (Management of Information Systems) became a popular career path among the IT elite, and why when I was in college in 2002-2006, Comp Sci enrollment was at a major low.

Continue reading “So, you work in IT?”

In 2010, the Python core team wrote PEP 3107, which introduced function annotations for Python 3.x.

Nearly 4 years ago, I wrote this response to the PEP, but I published it to a discussion site that ended up becoming defunct (Clusterify). I saw that recently, interest in function annotations for type-checking was revived by GvR, and thought I might resurrect this discussion.

Background

There is a huge flaw with the creation of Python annotations, IMO. Lack of composability.

The problem only arises when you consider that at some point in the future, there may be more than one use case for function annotations (as the PEP suggests). For example, let’s say that in my code, I use function annotations both for documentation and for optional run-time type checking. If I have a framework that expects all the annotations on my function definition to be docstrings, and another framework that expects all the annotations to be classes, how do I annotate my function with both documentation and type checks?

This amounts to lack of a standard for layering function annotations. Is this really a problem?

It’s true that some standard for this could organically form in the community. For example, one could imagine tuples being used for this. If an annotation expression is a tuple, then every framework should iterate through the items of the tuple until they find an item of the matching type. However, this won’t always work: what if two frameworks are both expecting strings, or two frameworks are both expecting classes, with different semantics?

Continue reading Python annotations and type-checking