I've been struggling for the last few weeks to find a way to explain why I'm leaving Python. I could give the technical nitty-gritty (rejects functional programming, lacks lazy evaluation, grows syntactical features like cancer to overcome the first two design decisions), but at the end of the day, even with this intentional crippling of the language, it's still quite possible to write almost anything you want and actually be quite productive in Python.

So, in the face of this, what's my reason for leaving? Well, while it's possible to accomplish nearly any end result you like, you are constrained in how you get there. The language imposes an imperative style through its distinction between statements and expressions. The only way to achieve lazy evaluation is by using lambda and lambda is crippled by the presence of statements (which can't be used inside of a lambda).

Most Python fans claim (arguably with some validity) that these restrictions are in place to enforce code-readability.

Even if I grant that these restrictions do, in fact, help enforce a type of readability, I don't think anyone would disagree that it limits what a programmer is able to express. To me this argument is akin to demanding that authors limit themselves to 10th grade English so as to not confuse readers. While arguably effective, it also places a hard restriction on how concisely, elegantly, and accurately the writer can convey a concept. Worse, eventually the author will be crippled by this restriction as he or she will lose fluency in more esoteric corners of the language. His vocabulary will shrink from disuse.

In short, I think that such restrictions cater to the average (and below average) programmer. This is quite pragmatic, but hardly attractive if you want to advance your art. Poetry may be quite difficult to read at first, but is vastly rewarding once you've learned to appreciate it.

Jeez. I feel like I've been living in a hole for the last decade. Apparently there is no shortage of fascinating programming languages.

Here's the new one for today: Reia

Enjoy.

I've got a vague notion about web development that I'm jotting down here mostly to help me clarify some thoughts and as something to revisit sometime down the road. The question mark in the title reflects my uncertainty about some of what I'm positing below.

First of all, I don't think that MVC as it's applied to the web is the same MVC first described in Smalltalk. Mark Ramm gives a nice summary of what MVC meant in the Smalltalk environment and it's clear that it isn't very close to what we're doing today. A notable difference is what the Controller meant to Smalltalk apps vs what it means (or doesn't mean) to web applications.

Here's a short list of things I see wrong with MVC as it's currently applied to the web:

1. "Designer-friendly" template engines are counter-productive. Designers ought to be writing CSS, not HTML. Programmers ought to be generating HTML and designers styling it. HTML is the output of the program and should have as little to do as possible with how it's presented.
2. The Model, as it is commonly used, is a merely a language-specific repetition of what is already defined elsewhere (the database).
3. The Controller, having lost its purpose as a place to control flow, has been relegated to an ill-defined (but required!) place to shove anything that isn't strictly Model or View.
4. The View exists solely to insulate designers from code and the programmers from markup.

To be clear, I'm not suggesting that MVC is bad, just that it's misapplied to the web. The goal of separation of concerns is a good one, but I think the lines between concerns are poorly drawn for most web applications.

Django redefined MVC into what they term Model-Template-View (MTV), which at one level is just shuffling terms around, but I think it reflects a goal of eliminating the Controller. I originally didn't really get the point of this, but now I'm thinking they didn't go quite far enough (although had they gone the whole distance, it might have hurt Django's acceptance).

So here's some general thoughts about what should be done in place of MVC.

1. Make HTML generation programmer-friendly, not designer-friendly. This means making HTML look like code and HTML generation natural in the context of regular code. I'm thinking in terms of the Lisp philosophy of growing the language toward the program, in other words, by using an embedded language/internal DSL for generating markup.
2. Code that previously got lumped into the Controller becomes part of the Model or is expressed directly in the View. This revives an older paradigm where work was done "in the database" (i.e. in stored procedures). Stored procedures have a lot of advantages (they function outside of the framework, can take advantage of transactions, etc). The main downside to stored procedures is that most databases don't provide nice tools for dealing with them and they often require a separate programming language than what is used in the main application. This can be addressed by building those tools and by using databases that support programming stored procedures in multiple languages (e.g. PostgreSQL). Alternatively, an ORM layer could be used, although this approach has drawbacks as well (poor performance, added complexity, increasing distance between programmer request and actual function).
3. Designers write CSS only. This means the framework should help programmers generate markup with minimal fuss.
4. The application is the Controller. In Smalltalk, the Controller is where things like input loops occurred and program flow was defined. On the web this task falls to the web server event loop and the framework's dispatch mechanism.

At the end of it all, we're left with what seems to amount to Model-View-Style. To summarize:

• Model: the database and related procedures, the sum of which equates to business logic
• View: presentation logic, including markup generation. The Model is directly accessible from here in the form of objects and methods.
• Style: CSS

To rephrase this in terms of a familiar framework, consider that Django is the Controller, the Model is the same, and the View subsumes the Template in their MTV model. If we acknowledge that there's little reason to create a line between the View and the Template in this model, then we simply merge the two and are very close to what I'm talking about (with the notable exception that Django template code isn't appropriate to the solution).

I'm still a bit doubtful about using stored procedures in spite of their obvious advantages. It's a very limiting decision in some ways (reduces choices of databases and languages, raises deployment concerns), but I think it's worth considering. It would be more appealing if things like ORMs (which are slow and complicated) could be rendered moot by having stored procedures return native objects, but that brings it's own concerns and complications. At the end of the day, a more traditional (non-DRY) Model could be used without affecting the overall architecture significantly.

He's right.

From an article about Microsoft's new D language:

"Today’s developer world is insanely object-oriented,” Lucco said. “Every last piece of data is encapsulated in an object that is a Turing machine, so you have no way to analyze what’s going on with it. Then that’s in stark contrast with the SQL world, where there’s a ton of things you can do with your data, and, over time, different programs can hit the same data and get something out of it. So we were like, ‘Well, how can we make mainstream programming more like SQL programming, without making it harder, like SQL programming is often considered to be?

This is a pretty interesting observation. I still wonder if the issue couldn't be resolved neatly within the OO paradigm by defining "query" interfaces on objects, perhaps not unlike the interface ORMs present. Of course, in another part of the article, he also mentions that D borrows Lisp's "code as data" paradigm, so there may be more to it than meets the eye, assuming he's using the word "data" to mean the same thing in both contexts.

Of course, at some level, it sounds sort of like this might all add up to introspection/reflection, something that's already been pioneered elsewhere.

I read this in the intro to the Revised Report on the Kernel Programming Language:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

It seems obvious, but so few languages in common use today give more than lip service to this philosophy.

As a corollary, I'd add that if you feel especially clever about some twisting of data structures to solve a programming problem, chances are good that you've uncovered a weakness in your programming language.

This is the gut feeling I left Python with. The Python object model has become disproportionately powerful (with many complex subtleties and subtle complexities) to help overcome weaknesses elsewhere in the language. Interesting problems invariably end up being solved via class magic as there are few other powerful constructs in the language.