Django and starting with an empty file

Luke Plant pointed out that Python, in contrast to Java and C#, makes templates unnecessary most of the time. In Java, a minimal program has a class definition and a method definition. In Python, the minimal template is an empty file.

The advantage of this is the ease of diving in and writing code. You don’t have to set up and/or use templates in an IDE, copy and paste, type boilerplate code in manually, or run a command-line script to get started.

As Luke points out, Django is the same way. This is one way it differs from Rails. In Rails you run script/generate.rb to generate a model from the database definition or a boilerplate view or controller. This is the way that is taught in the tutorial.

In the Django tutorial, the reader is instructed to simply type the code in and save it in a text editor. And as Luke points out, Template Inheritance makes it so adding a new page with the theme of the main page involves only three lines of code.

I also like how the models are structured. In Rails, you run script/generate.rb and a model file is generated, along with tests and a “migration file”, and you repeat this for each class (a class corresponds to a database table). In Django, you make a module file in the “models” directory, and each module file can contain however many classes you want it to. Sometimes it makes sense to have multiple models in a file (when there are tightly coupled models) and other times it makes sense to give a model its own file. Django gives the developer the freedom to choose how to structure the model directory.

I feel more in control when I use Django, because once the initial directories are set up, I add things starting with blank files and writing them using my own style. No boilerplate comments or tests are there to distract me. Also, since I don’t have multiple files being generated at a time, in different directories, version control is much simpler.

There are a number of other design decisions in Django that I like, some which differ from how Rails is designed, and some which are the same. The success of Django, I think, comes from being a well-designed and innovative framework, written from the perspective of its creators (the same could be said of Rails). I think this is why it has more mindshare and a bigger community than imitation frameworks.

I think that starting an open source project that imitates another as closely as possible, but on another platform, is a bad idea. Not only does imitating result in copying mistakes, it also results in copying style, which inevitably get mixed with the style of the copier. I think it’s better to figure out which features are needed from the existing project’s platform, and to adapt them, one by one, to fit well into the new project’s platform, and to the style of the developers and users of the new project.

Quirky Buildings; Quirky Java

I love NYC. I visited for a week, and found the experience absolutely amazing. There is so much to see and do.

The best parts of the experience are meeting people and just walking around. Central Park is beautiful, and I like walking down the streets of Manhattan and seeing the interesting mix of new and old buildings, people, shops, and restaurants. I also like the MTA (subway system). For about twenty bucks for a week, you have a pass for a subway network covering all boroughs, except Staten Island, which is not accessible by Subway, but is accessible by a free ferry. There is more to see in those boroughs, at least when it comes to human civilization, than there is in all of Arizona. In Arizona, however, I have to drive for transportation, and it is expensive enough that going to new places is a rare experience for me, even on weekends.

Today I received a random e-mail from a recruiter about a Java web application job in NYC. I said I don’t have Oracle experience, but he was still interested and said I could probably get an interview. The mere thought of moving to NYC gave me butterflies in the stomach. How I would love to return, and visit the zoos and museums, walk around, and go to interesting clubs like LispNYC.

So I set forth to learn more about programming in Java. I am very motivated in this endeavor. One of the requirements for the job that I got the e-mail about is Spring. So I decided to pursue a project that I’d been planning to do in Java Swing (a desktop GUI framework) and do it in Spring, as a web application. I’ve been working my way through a tutorial, figuring out how to get a good setup with Tomcat, Ant, and Spring. Next I’m going to hook a PostgreSQL database to it.

I’ve heard good things about Spring. Some people like it even more than (gasp!) Rails. So far I’ve just entered the first sample code for a controller:

import org.springframework.web.servlet.mvc.Controller;
import org.springframework.web.servlet.ModelAndView;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
public class TileEditorController implements Controller {
  public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException
  {
    return new ModelAndView("");
  }
}

A class named ModelAndView! Interesting. I imagine if Java had support for tuples, Spring probably wouldn’t have that class. I think in absence of tuples, however, it’s a perfectly valid way of doing it. Quirky, but good.

Some things are complicated. Other things are just quirky. I don’t think it’s good for a developer to let quirkiness get in the way. In fact, I think a lot of the time it’s just a fact of life, that can not only be accepted, but enjoyed.

Just as I enjoy the quirkiness of buildings in NYC, which are full of character, and take on a life of their own, I can appreciate a clever solution to a programming problem that reality brings. I think of programming now more as a series of steps. If I have to do something needlessly complicated to complete a simple step, that’s annoying. If I have to do something straightforward but a little quirky, that’s OK by me!

Framework-itis

Today Bruce Eckel posted a blog entry called When Reuse Goes Bad. He tells of a project he was sent in to fix, as a consultant:

The main design and technical problem (ignoring for the moment Weinberg’s maxim that “No matter what they tell you, it’s always a people problem”) was that the contractor had decided that this was an opportunity to develop a reusable software system, and that they could develop this system on the customer’s dime.

This resulted in classic framework-itis. The contractor was no longer just trying to solve the customer’s problem, they were trying to solve all problems that looked like it. So for that reason alone the project would have required 10x the original time and money.

This reminded me of a post by my friend Eliazar, where he proposes a new dictum, Use before you reuse.

As I ponder on these points, I think of Paul Graham‘s essay Taste For Makers, where he states, “Good design solves the right problem.” When I think about getting at the heart of the problem, I think of the chapter about Use Cases in The Pragmatic Programmer. If the goal is to design a non-trivial library for thousands of users with many different usage patterns, how do you get at all the use cases? You can’t. The thing to do is to make something that solves one problem well, and adapt it, one by one, to solve other problems. Eventually, it will solve a lot of problems.

I think the Linux kernel is a good example of this. The first Use Case was Linus Torvalds running it on his own computer. In time it was adapted to run on many different computers and to do many different things. It had fewer growing pains than other things that were built Cathedral-style.

PLT – A community of people working on ambitious projects

Anyone who has poked around in the Scheme or Functional Programming community has no doubt heard about PLT, or at least one of its projects, which include DrScheme and the book How To Design Programs. PLT is a group of people spread across four universities that works on a number of projects, some of which involve making really cool software, and others which involve teaching programming.

They’ve created a complete graphical programming environment called DrScheme, which includes a Scheme interpreter, various Scheme libraries, and an IDE written in Scheme using their libraries. It even has its own HTML renderer that is used to implement the Help Desk feature of DrScheme.

They’ve used PLT Scheme (the umbrella name for the different distributions of their Scheme implementation) to build:

  • A PLT web server, which presumably is used to host their own website, which is well designed.
  • A Slideshow application, which Matthew Flatt uses for in-class presentations
  • PLaneT, a package repository for PLT Scheme

Four of them wrote a great introductory programming book, How To Design Programs, (HtDP) which covers a lot of practical programming concepts that were sadly skipped over in my C. S. program.

Using HtDP, they have a TeachScheme! project, which aims to “turn Computing and Programming into an indispensable part of the liberal arts curriculum” [1]. This is an important goal. Even if most people in other fields don’t program as part of their job, I think it’s a good idea for them to learn enough to understand the process of programming, as it often effects their work. HtDP starts at a level that most high school student ought to be able to understand, while still being interesting to a graduate of a state university’s C. S. program. That is an impressive achievment.

I think that in order to make a really good learning organization, you’ve got to have ambitious projects and invite all members to participate. PLT certainly has more than its share of ambitious projects – a Scheme compiler, language extensions, a portable GUI framework, a web server and application framework, a package repository, and an HTML renderer. The same could be said about MIT, with their wide variety of operating systems, graphics, and compiler projects. It should be possible for any school to work on something along those lines. The first step would be for a member of faculty to start an ambitious project, and invite students to participate (hopefully with pay for anyone who does substantial research).

To start an ambitious project, you need something to work on. Fortunately, there are a lot of ideas already out there, and it’s not that hard to come up with an idea. In the words of John Locke:

The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three: 1. Combining several simple ideas into one compound one, and thus all complex ideas are made. 2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations. 3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made.

John Locke, An Essay Concerning Human Understanding (1690)

A lot of programming projects are started by a programmer noticing problems that take lots of repetetive work to solve, and coming up with useful abstractions. Ruby On Rails was started this way. There’s a very good chance that the next big thing will as well.

[1] http://www.plt-scheme.org/

Common Lisp: First Impressions

I went to my Alma Mater’s library in search of a book on Common Lisp and found Paradigms of Artificial Intelligence: Case Studies in Common Lisp by Peter Norvig. The book is 946 pages long and covers both AI and Common Lisp in depth. I started working through the Common Lisp chapter and found that it is much richer in features than I expected. I’ve always heard that Common Lisp is quite a contrast to Scheme, but hearing isn’t the same as experiencing it.

One thing that I like about Python is the cleverly designed def (define function) syntax, which gives the programmer all kinds of convenience and flexibility in defining functions (for example, having an arbitrary number of arguments, having explicitly named arguments, or having a combination of positional and explicitly named arguments — details here). Common Lisp has clever function-defining syntax too. Here’s an example of declaring a function with three explicitly named parameters, one of which is optional:

> (defun foo (bar &key (baz 30)) (list bar baz)
FOO
> (foo 30)
(30 30)
> (foo 30 :baz 90)
(30 90)

Another thing Common Lisp has in common with Python is doc-strings. I’ve seen them in emacs before. A doc-string is a piece of documentation that can be put in the function declaration and accessed at run time (or from within the REPL). In both Python and Common Lisp the doc-string goes in between the argument list and the function body.

One cool thing about Ruby is the ability to call a method with a minimal number of keystrokes. If bar has a method named baz with 0 parameters, the code to call it is “bar.baz”. There’s no need for empty parenthesis! In Python “bar.baz” would refer to the method itself. In ruby, to refer to the method itself, it’s “bar#baz”.

Common Lisp uses a hash symbol to refer to a function, but it is for a different reason. Common Lisp, like elisp (Emacs’ built-in scripting language), has a separate namespace for functions and variables. It’s possible (but arguably bad style) to have functions and variables with the same name. To refer to the functions, you add a hash and a single quote before them (e. g. #’foo).

It looks as though Python and Ruby both have inherited from Common Lisp. And that shouldn’t be a surprise – the designers of Python and Ruby have been programming long enough to remember a time when Lisp was more popular.

One thing about Common Lisp that’s often cited when someone mentions how big it is compared to Scheme is the format function. The format function practically has its own language for printing out text, and as Norvig notes, it’s not a very Lisp-like language. But there is also the loop macro, which was given its own chapter in Common Lisp the Language, 2nd Edition.

While I might just skip over learning to use the loop macro, I think that there are a lot of really cool functions and macros in Common Lisp that you could do without, but make things more convenient. It has some things that might seem redundant, but that can be used to code more clearly what you are trying to do. For example, there is a when macro, which is like if, but without the else clause. A Common Lisp programmer that comes upon “when” knows not to expect the else clause.

Another neat thing about Common Lisp implementations in general is that there tends to be debugging and optimization support accessible from the REPL (read-eval-print loop).

My first impression is that when I use Common Lisp, it feels like a mature language. I can tell why Norvig chose it to do lots of AI projects. It has a lot of features people want — it “lets hackers have their way with it” [1]. It’s multi-paradigm. Scheme is a little too focused on one paradigm (functional programming) for my tastes.

[1] Paul Graham‘s essay The Dream Language, form Hackers & Painters, which is not available online (yet). In my opinion, it’s one of his best essays.

Django, Wikis

Over the last couple of weeks, I’ve been trying to code up a news aggregator that works the way I want it to. That meant I had to decide what I was going to use to develop it.

I thought about what I like, and read about a few different web application frameworks. A few things I was thinking when I chose to give Django a try:

  • I prefer liberal open source licenses (MIT, BSD) to copyleft ones (GPL).
  • I want Python or Ruby. Of the two, I prefer Python because it has less syntax and more libraries coded for it.
  • I like PostgreSQL. It has some cool extension libraries (for mapping and other domains) and a liberal license.
  • I want something that’s proven
  • I want something that is very actively being worked on
  • Not having to write any SQL at all for simple sites is a plus.

I thought about web.py, Rails, Turbogears, and Django. I also thought about Python servlets or writing my own framework.

Things that impress me about Django, besides meeting my above criteria:

  • The template system. It has its own template system that supports “Template Inheritance”, which is a very neat concept. It also plays well with Dreamweaver, they say. I haven’t used Dreamweaver so I’m unable to confirm that.
  • The admin interface. It’s a bunch of code that comes with Django to provide a nice admin screen. In the program I’m making, if feeds become corrupted I could go into the admin and fix them. Or I could just have a good look at the data
  • The configuration files, including regular expressions for URLs.

I set to work installing it, and decided to document how I did it in a Wiki. For this, I installed Instiki, which is an impressive program. One thing I like about it is the fact that it supports three different wiki languages. I chose Markdown, which is not the default. I expected that since it was not the default, the support would be very rudimentary. I was pleasantly surprised! It’s supported and documented every bit as well as TextPattern, including a quick reference on the side of the editing pages.

After I figured out how to get a kick-ass Django development installation on my iBook, I decided to share my knowledge with others. The best place to post the information, I determined, was on the Django wiki. The wiki, as it turns out, is powered by Trac. It has its own wiki syntax that is similar to wikipedia.

After a search for translation tools, I started manually converting what I’d written to Trac’s wiki format. This was tedious, so I wrote a script to help out. After that I searched around a bit more, and found that Aaron Swartz wrote an html2text that converts from HTML to markdown syntax. What a great idea! First, Markdown looks good in plain text format, since it was designed to use the same idioms that people use when sending plain text e-mails. Second, it can be used to go from any wiki format to Markdown. This is because in order to display pages wikis convert from plain text to html. So all you have to do is go into view source in any wiki, copy the segment of the wiki you want, paste it into a text editor, save it, and run Swartz’s html2text on it, and voila, you have converted from that wiki format to Markdown.

If I get around to writing a serious tool to help me translate from Markdown to Trac, instead of just writing something to go between the formats, I’ll write a script to convert from HTML to the Trac wiki syntax.