Design patterns are probably one of the most misused and misunderstood programming techniques out there, and I argue this is because they’re studied out of the context in which they were conceived, or worse, because is assumed that this context never changes. This ultimately causes some particular set of patterns to be considered as a somewhat general tool whose use is a good programming practice.

This is not a critic to the Gang Of Four book[1], which I believe is one of the best books addressing object oriented software programming. The authors of that book were very aware of the consequences of the wrong use of the techniques they were introducing, and so they stated in its first pages[2].

The context of a design pattern

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design[3]; a set of descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context[1]. Much of the misuse of design patterns comes from ignoring the context part.

If you change the problem domain or the programming paradigm or the language applied, then the set of appropriate patterns also changes. Indeed, since patterns are reusable, proved solutions to common programming problems, if a problem goes away by changing one of those variables, then the pattern is no more. Similarly, as some problems disappear, new ones arise when the context is changed[4]. A detailed study of this argument is made by Peter Norvig in his slides Design patterns in dynamic languages[5]. There he reaches the conclusion that most of GoF’s patterns are simpler or invisible in Lisp or Dylan.

Some argue that while the implementation gets simpler in some languages, the patterns are still there, so they’re still useful in the sense that they provide a vocabulary for programmers to describe the design. This might be true in some cases, but not in most. Usually, the higher the level of the language features, the higher the design abstractions and the lesser the need to refer to patterns that usually are foreign to the domain of those abstractions.

For example, in a statically typed language such as Java one might need to introduce interfaces or class hierarchies to achieve polymorphism, whereas in a dynamically typed one everything is polymorphic, the feature is taken for granted by the programmers and since it’s built-in, it’s not needed anymore to describe the design. Another example, more related to what’s commonly accepted as a design pattern, are iterators. In C++, when not using STL, one might find the need to introduce iterators as a part of the program design. In Java, where every standard data structure comes with its own iterator, one might use them a lot, but they stop being a part of the design worth discussing. Lastly, in Python, where the iterator implementation is completely hidden by the control and data structures, one might never even see an iterator-related piece of code.

Choosing a programming language

This is part of a broader problem, but is directly related to the one I’m addressing here. Commonly in the software industry (but unfortunately in the academic community too) the people in charge of the design and architectural decisions on a software project don’t consider the language as a parameter of the solution. Sometimes they just pick the one they’re more comfortable with, but often this decision is made by management people based on non technical factors, such as programmer availability. Paul Graham puts it very clearly in one of his essays[6]:

The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.

Suppose, for example, you need to write a piece of software. The pointy-haired boss has no idea how this software has to work, and can’t tell one programming language from another, and yet he knows what language you should write it in. Exactly. He thinks you should write it in Java.

Why does he think this? Let’s take a look inside the brain of the pointy-haired boss. What he’s thinking is something like this. Java is a standard. I know it must be, because I read about it in the press all the time. Since it is a standard, I won’t get in trouble for using it. And that also means there will always be lots of Java programmers, so if the programmers working for me now quit, as programmers working for me mysteriously always do, I can easily replace them.

Well, this doesn’t sound that unreasonable. But it’s all based on one unspoken assumption, and that assumption turns out to be false. The pointy-haired boss believes that all programming languages are pretty much equivalent.

I won’t get into how viable it is for the employee to disobey the manager’s bad decisions or how valid the manager’s point of view is. But as a programmer I too think that you can’t let the suits make technical decisions for you.

When professors are closer to the the industry than to science, this too has an effect in their approach on teaching. They will tend to select as teaching languages those more widely used and (at least where I study) impose that choice thus creating a vicious cycle where the student never develops the need to compare and choose the language better suited for each job.

Be it by choice or by obligation, the  lack of the habit of choosing the programming language for each project causes the context to be considered as invariable. If the context is assumed static then the patterns for that context are the only patterns ever applied (ever taught for that matter), and so they end up looking universal or more relevant than others. The fact that most GoF patterns are never needed when programming in languages such as Python is seen by the naive as a shortcoming of the language rather than the opposite.

Patterns smell funny

Some programmers (specially those recently introduced to the technique) think that the more patterns it has, the better a design is. Or maybe a less extreme position is that given two ways of solving a problem, if one uses a known pattern, it’s better. This, I suppose, is based on the mentioned idea that patterns introduce a common vocabulary that lets them speak at a higher level. Also on the widespread belief that they are some sort advanced programming technique.

On the contrary, I think that a design that introduces much patterns smells funny, using the parlance of Refactoring (and Frank Zappa). Fowler and Beck argue that certain structures in code suggest the possibility of refactoring, and call those bad smells[7]; they don’t necessarily imply that the code is wrong, but it probably is.

In one hand, a pattern introduces foreign abstractions into the problem domain, increasing the design’s complexity. On the other, often making the design more flexible in one specific direction, it does so by sacrificing flexibility in the others. This tends to be a recipe for disaster when programmers believe they can predict how a system may evolve in the long run. Graham holds a similar position[6]:

When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough– often that I’m generating by hand the expansions of some macro that I need to write.

He is off course, speaking from the standpoint of a Lisp programmer. Indeed, if we accept the idea that patterns  come to overcome the lack of  a certain language feature, most patterns are presumably needed because of the absence of macros. Still, there are many contexts in which using Lisp might not be the best technical decision, so we should apply a more general principle.

First we should abandon the idea that patterns improve the design of software, and use them only when they are really needed, this is, when there’s no simple solution to a problem with the current abstractions of our domain. Second, we should be aware of the proliferation of patterns, since it might be a sign that the language (or architecture) we are using is not the right tool for the job. And be prepared to leave the tool when necessary.

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented software.
[2] Design patterns should not be applied indiscriminately. Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost you some performance. A design pattern should only be applied when the flexibility it affords is actually needed.
[3] Software design pattern.
[4] Despite the book’s size, the design patterns in it capture only a fraction of what an expert might know. It doesn’t have any patterns dealing with concurrency or distributed programming or real-time programming. It doesn’t have any application domain-specific patterns. It doesn’t tell you how to build user interfaces, how to write device drivers, or how to use an object-oriented database. Each of these areas has its own patterns, and it would be worthwhile for someone to catalog those too.
(…)
The choice of programming language is important because it influences one’s point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called “Inheritance,” “Encapsulation,” and “Polymorphism.” Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor. In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other.
[5] Peter Norvig, Design Patterns in Dynamic Languages.
[6] Paul Graham, Revenge of the Nerds.
[7] Martin Fowler, Refactoring: Improving the Design of Existing Code.

Since I had sincere hopes of end up using it on professional projects, after looking around I leaned towards Common Lisp, and particularly the book Practical Common Lisp by Peter Seibel. After the first 9 chapters, I’m somewhat disappointed. I’m guessing this is partly because of my high expectations and partly because most of lisp’s “cool” features are getting less and less uncommon as languages advance[2]. These are my first impressions.

It’s not readable. Strangely enough I don’t mind all the parentheses nor the prefix notation; I get that they’re part of what makes Lisp so powerful and actually got used to it pretty quickly. Still, the language is overall pretty cryptic, even for things that could with no effort be a lot clearer (t/nil instead of true/false?). It might not be for experienced Lisp programmers, but, well, if it’s readable only for the experienced, then it’s not readable.

Some examples from the first chapters of the book:

(format t "~{~{~a:~10t~a~%~}~%~}" *db*)

and:

(defmacro where (&rest clauses)
  `#'(lambda (cd) (and ,@(make-comparisons-list clauses))))

Suddenly Perl isn’t looking that bad.

The operators set is huge. That’s not good news for me. I like languages that have a small, orthogonal, easy-to-remember set of built-in operators, and good libraries built on top of them. This is the case of C and Python, and not of Lisp, which seems to have loads of built-in operators, between special operators, functions and macros. In the first chapters of the book, every bit of code introduces a couple of new ones. This not only makes it hard to keep track of them, but without seeing a thorough reference, I have no idea on what to expect to be available as a built-in and what I’m supposed to write myself.

From what I read, that small core is there somewhere, but at least this books makes it look like it’s too low level to get anything done with it, and instead uses the macros built on top of it.

…and it’s not orthogonal. There seems to be way too many operators for the same purposes but with slightly different behaviors. The most evident case of this is the equality: =, CHAR=, EQ, EQL, EQUAL, and EQUALP. Seriously?

…and some names are really, really bad. MACROEXPAND-1, LET and LET* (a common pattern for slightly different operators), Y-OR-N-P, etc.

It’s not intuitive. As a consequence of the previous points, it gets really hard to guess my way through a piece of code; instead I have to look up most operators. Anytime a new operator was introduced in the book, it worked different from what I expected.

Macros look promising. They certainly do; after catching just a glimpse of what can be done with them, macros look like a powerful tool that one can get quickly used to, and will miss in other languages. I particularly enjoy the way they’re used in the book as the driving technique to constantly refactor code, built bottom-up.

I’m aware that most of this issues would go away after some time using the language, but taking in account the downside of being not so widely used as other languages (meaning less documentation, less libraries, less users, etc.) so far it’s not looking like one I’d use for more than one or two projects. It might make sense for me to check out some other Lisp dialects, like Scheme or Clojure.

[1] Eric Raymond, How To Become A Hacker.
[2] Paul Graham, Revenge Of The Nerds.

'''
Wrapper for the ifile.it API. Uses the poster api.
'''
import urllib2
import json
from poster.encode import multipart_encode
from poster.streaminghttp import register_openers
import urllib

class Ifileit(object):
    """ Wrapper class for the ifile.it API. """
    
    UPOLOADED_FILE_URL = 'http://ifile.it/{ukey}'
    GET_UPLOAD_URL = 'http://ifile.it/api-fetch_upload_url.api'
    FETCH_API_KEY_URL = 'https://secure.ifile.it/api-fetch_apikey.api'
    PING_URL = 'http://ifile.it/api-ping.api'
    
    USER = ''
    PASSWORD = ''
    API_KEY = ''
    
    @classmethod
    def ping(cls):
        """ Returns True if the ifile.it server is up. """
        
        response = cls._open_and_check(cls.PING_URL)
        return response.get('message', '') == 'pong'
    
    @classmethod
    def upload(cls, the_file):
        """ 
        Uploads the_file to the ifile.it server. It should be a file-like 
        object as required by poster. 
        """
        
        #Needed by poster
        register_openers()
    
        post_data = {'Filedata' : the_file}
        post_data.update(cls._get_akey())
        datagen, headers = multipart_encode(post_data)
        
        request = urllib2.Request(cls._determine_upload_url(), 
                                                    datagen, headers)
        response = cls._open_and_check(request) 
        
        return cls.UPOLOADED_FILE_URL.format(ukey=response['ukey'])
    
    @classmethod
    def _determine_upload_url(cls):
        """ Gets the upload url from ifile.it API. """
        
        return cls._open_and_check(cls.GET_UPLOAD_URL)['upload_url']
    
    @classmethod
    def _open_and_check(cls, url, data=None):
        """ 
        Opens the given url string or Request object and checks for the status
        parameter in the response.  If it's 'ok' returns a dict with the 
        response. otherwise raises IfileitApiError.
        
        Data should be a dictionary of POST arguments or None for a GET request.
        """
        
        if data:
            data = urllib.urlencode(data)
        
        response = json.loads(urllib2.urlopen(url, data).read())
    
        if response['status'] != 'ok':
            raise IfileitApiError()
        
        return response
    
    @classmethod
    def _get_akey(cls):
        """ 
        If the user info is set, return the akey parameter for the POST API 
        calls. Otherwise returns an empty dict.
        """
        
        if cls.USER and cls.PASSWORD:
            if not cls.API_KEY:
                response = cls._open_and_check(cls.FETCH_API_KEY_URL, 
                                               {'username' : cls.USER,
                                                'password' : cls.PASSWORD})
                cls.API_KEY = response['akey']
            
            return {'akey' : cls.API_KEY }
        
        return {}

class IfileitApiError(Exception):
    pass

There’s a fact that I think makes this situation worse, and is that Java is a pretty dated language. What I mean is there are too different problems;  The first one is that programmers don’t bother to study other languages, so they use one tool to solve all problems. This is indeed a big issue, but more related to engineering and science than to programming. The second one is that there clearly are better languages to do what Java is supposed to do best: general purpose object oriented programming, and if you may, web applications back-end programming (which is what most programmers end up doing here). And those better languages are not obscure novelties as some like to suggest, but languages that have been around as long as Java has. Ruby and Python are the examples I’m most familiar with, but there are others, notably lisp.

I don’t know about any Java programmer that having tried a higher level language such as Python, wanted to go back to using Java. Bruce Eckel —who wrote the books that are used for reference on Java and C++ in the programming courses that teach object-oriented programming at my college—  noticed almost 10 years ago that sticking to Java was a huge waste of programmer’s time. A lot has been written about the advantages of Python over Java; a specially concise example are Eckel’s slides Why I love Python[2]. I also like a couple of screencasts by Sean Kelly, that focus more on web development (where Java is specially useless)[3].

I’m not interested in repeating all those points; most of them are related to language features like dynamic typing or native types. Some of them can be overcome by enhancing the language with new features, and this is what Java designers have been doing: they have been patching bad language design decisions ever since it first came out.

But there’s one particular aspect that I think defines on principle why Python is a better language than Java, and it won’t change no matter what features are added or removed. And it is the philosophy behind the language, the way they think about the programmer. Quoting Eckel: Java treats programmers like they are stupid, Python doesn’t.

Java design and libraries consistently make a huge effort making it difficult for a programmer to do bad things. If a feature was a potential means for a dumb programmer to make bad code, they would take away the feature altogether. And what’s worse, at times they even used it in the language implementation but prohibited the programmer to do so[4]. Paul Graham remarkably pointed this[5] as a potential flaw of Java before actually trying the language:

Like the creators of sitcoms or junk food or package tours, Java’s designers were consciously designing a product for people not as smart as them.

But this approach is an illusion; no matter how hard you try, you can’t always keep  bad programmers from writing bad programs. Java is a lousy replacement to the learning of algorithms and good programming practices.

The implications of this way of thinking are not limited to language features. The design decisions of the underlying language have a great effect on the programmer’s idiosyncrasy. It’s common to see Java designs and patterns that make an unnecessary effort in prohibiting potential bad uses of the resulting code, again not trusting the programmer’s judgment, wasting time and putting together very rigid structures.

The bottom line is that by making it hard for stupid programmers to do bad stuff, Java really gets in the way of smart programmers trying to make good programs. Python on the other hand, is focused on making it extremely easy to program well[6]. It gives you the choice; If you want to do crappy code is your responsibility.

[1] Paul Graham, Revenge of the Nerds.
[2] Bruce Eckel, Why I love Python. The points are extended in these interviews.
[3] Sean Kelly, Recovery from addiction, Better web app development.
[4] Bruce Eckel, The Zen of Python.
[5] Paul Graham, Java’s Cover.
[6] Tim Peters, The Zen of Python.

Using just request.is_secure wouldn’t work, since my project is served by gunicorn through a nginx proxy_pass, and by default, django can’t tell if its being served on a secure connection.

I don’t know if it’s the best way to do it, but this is how I managed to solve it. First I added the line:

proxy_set_header X-Forwarded-Protocol https;

In the nginx configuration, on the server that uses ssl. Then, I modified the configuration of gunicorn, as suggested in the website, with the setting:

secure_scheme_headers={'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-SSL': 'on'}

Lastly, from my context processor, I checked the request headers to tell if the connection is http or https:

def is_secure(request):
    return ('HTTP_X_FORWARDED_PROTOCOL' in request.META and 
        request.META['HTTP_X_FORWARDED_PROTOCOL'] == 'https')

And that’s it.

Someday I might take the time to explain more profoundly why I hate (I’m using the word hate here) C++. For now I’ll just make some notes.

I’ve been forced many times to use it, and no one could ever give me a good reason why. I believe such reason does not exist. If you want to do low level, system level or whatever you want to call it programming, C will do. While it lacks the facilities of more recent languages (and lisp), making it a doubtful choice for general purpose programming when efficiency is not the primary concern, I found C to be a really simple and clean language. It’s not at all hard to keep the primary feature set and libraries in your head.

C++ on the other hand is huge. You need to google constantly to do the most simple things, and what’s worse, you should do it, because there are a lot of things that just don’t work in the obvious ways. This is specially true when working with files.

All the advantages of object-orientedness quickly fade away when you see yourself dealing over and over with obscure syntax errors on classes that are a hundred lines long way before they do any real work. The real advantage of object oriented programming is the way it helps to think and structure your programs, and you don’t need classes or inheritance to accomplish that.

C++ is so bad that makes Java look good. I don’t like Java. I think it’s too verbose and lacks several features I expect from a high level language, most of its advanced techniques (design patterns, reflection, xml frameworks) being just patches for those absences. But all in all, Java is a language that makes sense. C++ is not.

It’s backwards compatible with C. Seriously Stroustrup? What on earth were you thinking?

The compiler never helps. The error messages never make sense, and in most cases ignoring them is the healthier choice.

C++ Strings suck. They suck so hard that they’re not a built-in type, they’re not even used in the libraries, so you have to use stuff like c_str().

Streams suck. The syntax is weird, they’re just too many of them, I seem to recall there was some diamond inheritance weirdness going on over here… I’d rather stick to C files.

STL sucks. The iterators are error-prone and tedious to use. You have to write a lot to use most of the methods of the containers, even for basic stuff, ending up with code like:

    for (map<string, string>::iterator it = myMap.begin(); it
            != myMap.end(); it++) {
        string key = it->first;
        string value = it->second;
        //...
    }

Don’t even get me started on templates.

Whether you use them or not, namespaces are a pain in the ass. If you do use them, the code gets confusing and annoying to write (and it’s easier to get compiler errors when you forget to specify the namespace). If you don’t use them in your code you still need to add the using namespace std bit everywhere or you get syntax errors that as usual don’t point the problem.

Why are there references? One can’t consistently use either references or pointers, you are forced to mix them in certain contexts [1].

The language is not consistent. An example: you instantiate classes in the stack like:

    MyClass myObject(arg1, arg2);

But what if your class has a constructor that takes no arguments? You might expect it to work like this:

    MyClass myObject();

But no, the correct way is omitting the parenthesis:

    MyClass myObject;

You might find yourself wondering for half an hour why your program won’t compile for things like this.

Methods are not virtual by default. Premature optimization is the root of all evil.

It’s copy-paste oriented. Code duplication is trouble. In C++, the standard way to code a class is to copy all the method prototypes from the .h to the .cpp file, adding the MyClass:: bit. Even with just a couple of getters and setters, theres a whole lot of typing and copying. This is not only tedious, but one of the places where more errors occur. And remember, the compiler speaks its own language.

You can’t refactor. Unit testing frameworks are awkward to use and setup. Creating a class and making it compile is so hard that most of the time you stick to add an if.

[1] http://www.paploo.net/programming/rant_01.shtml

It’s useful every once in a while to recall how hard it was to accomplish certain things on certain cluttered and rigid languages, and how easy it is when you can use something as powerful as Python¹. Well, I ended up with something like:

import urllib2
import json

URL = 'http://openlibrary.org/api/books?bibkeys=ISBN:{isbn}&format=json&jscmd=data'

def get_olid(isbn):

    response = urllib2.urlopen(URL.format(isbn=isbn))
    js_dict = json.loads(response.read())
    key = 'ISBN:{isbn}'.format(isbn=isbn)
    if js_dict.has_key(key):
        return js_dict[key]['identifiers']['openlibrary'][0]

But the real beauty of Python this time was not the clearness or succinctness of the code, nor how useful the libraries were, but rather how easy it was to figure out how to use those libraries. Just checked the function signatures on the online documentation (I could have used the help function, but I like the docs better), and started to play with them on the shell until I got the result I expected. It even saved me the time to read thoroughly the OL reference, since I could see in the shell the contents of the response they are sending me on each call.

1. Yes, there are no silver bullets, but there are some real good bullets and some real bad bullets for each job, and I find Python to be a great general purpose bullet .

To add a new site on nginx I just touch a new file in the /etc/nginx/sites-enabled, with the contents:

server {
    listen 80;
    server_name myserver.com;

    location / {
        proxy_pass http://127.0.0.1:8888;
    }
}

Now, supposing I want to have acces and error logs, and serve my site’s and the admin site’s media, I would add some lines to the server:

access_log /var/www/django/myproject/access.log;
error_log /var/www/django/myproject/error.log;

location /media {
    root /var/www/django/myproject;
}

location /admin_media {
    alias /usr/local/lib/python2.7/dist-packages/django/contrib/admin/media;
}

Where /media and /admin_media are the MEDIA_URL and ADMIN_MEDIA_PREFIX pointed by my settings.py. That is, I have a media folder in my project root directory and the admin media is served directly from the django installation.

To actually run my django site on http://127.0.0.1:8888 I create a gunicorn configuration file in my project root (where manage.py is located):

bind = "127.0.0.1:8888"
workers = 3

Assuming I named the file gunicorn.conf.py, gunicorn is run from the same directory doing:

gunicorn_django -c gunicorn.conf.py -D

And that’s it.

When the code is updated, there’s no need to restart nginx; instead, gunicorn is restarted (not so prettily) with:

kill -HUP <main gunicorn process id>

To serve multiple sites, just use differents ports (8888 in the example) in each one’s configuration file.

print "Hello blogging world!"