Tao of the Machine

Barren wastelands

Judging from the discussions in some newsgroups (like nl.comp.programmeren ), large groups of people still have no clue that there are other programming languages out there besides the well-known commercial ones. I wonder if this is a common problem, or that the Netherlands are a backwards country when it comes to programming. <0.3 wink>

Languages like Java, C++, Delphi, C#/.NET, and Visual Basic are discussed like they are top of the bill, and generally the best choices around. Partially that is because of the “everybody uses language X, so let’s use it too” mentality. Partially it is because there’s a bunch of myths that people like to believe in (commercial languages guarantee better support, non-commercial languages are not maintainable, etc).

I don’t know, but stating that C++ (or Visual Basic, Java, whatever) is the best language because many people use it, is like saying that Britney Spears makes the best music.

But the biggest myth is, that it doesn’t matter which language you use, because inherently they are all the same. “What you can do in Visual Basic, you can do as well in Delphi or C++.” That is sooo wrong. Especially when you throw a language like Python in the mix. (I mention it because I’m obviously a Pythonista, but I could have said Perl as well, or Smalltalk, Lisp…)

Programming languages shape the way you think. If all you do is design forms and make components do stuff, then maybe you won’t need to think so much, and then any language with a GUI builder is just fine. I personally am not content with that anymore. I want to write code that is maintainable, elegant, well-written, reusable, and extendable. I want to whip up a prototype in a few hours. I want to just deal with the problem at hand rather than fight the language. I gladly sacrifice such dubious benefits as support, GUI builders, MSDN subscriptions, or “market value”. (Not to mention, compile times, buggy releases, and static typing…)

That’s why I use Python. Maybe someday you will see the light too. :-)

Programming by contract in Python

Nifty stuff (via Simon Willison ). I see that the PEP uses docstrings, so the author is not proposing a language change, which is a Good Thing.

Another nice thing is that you are free to ignore the pre- and postconditions, and only use them when appropriate. I expect that including some tests in running code can be quite expensive.

Eiffel is a nice language. I used to read Object Oriented Software Design in college (in the library, when I was supposed to go to class :-). I’m not sure I could ever do serious programming in it though… it’s too restrictive for my taste.

( Unrelated: Textile (or maybe its implementation, PyTextile) doesn’t always seem to work well. For example, in the “Simon Willison” URL above, I had to put a space between the URL and the ), to prevent it from being considered part of the URL. Not a deadly sin, but a bit annoying, and it’s not the only problem I’ve encountered. The code is hairy, with lots of regular expressions, so I feel not up to the task to correct the problem myself. :-( I wonder if there’s a better format or implementation out there. )

Hmmm...

In other news, I have a working version of Firedrop2 now, good enough to switch my weblog to it. Observant readers will notice the new layout as well. It's quite possible that certain things don't work 100% yet; I'll get to that later.

The source is currently a mess, mostly the build.py script which is over 200 lines. Refactoring is in order...

Test test...

Progress...

Firedrop2 is coming along nicely as well. Maybe tomorrow I will be blogging in it, rather than in Kaa.

Firedrop “1” and “2” have very different philosophies. Or rather, the first version didn’t really have a clear goal; it promised lots of power and flexibility, yet also tried to be very user-friendly. It’s not easy to blend the two.

Firedrop2 is different. It is minimalistic, but not in a “let’s provide only a few core functions” kind of way. Rather, it sets up a basic frame for weblogging (and HTML publishing in general), and encourages people (programmers) to customize things by writing their own code. So, it’s not for end users anymore. It’s for programmers who like to customize their sites but do not want to reinvent the (whole) wheel. Firedrop2 provides a simple editor, and library functions to be used for (e.g.) archiving, generating HTML, embedded Python, macros (maybe), uploading, RSS, etc.

It tries to make as few presumptions as possible. Where Firedrop1 used a number of predefined attributes (active, visible, categories, text format, etc), Firedrop2 only uses insert_date and modified_date, and leaves the rest to the user. If you want to add categories, active/inactive entries, invisible entries, special tags, or cream and sugar, go ahead. The system will not stop you, and you will have to write your own code to support it (which is easier than it sounds).

I want to create a version that works (to a certain extent), start using it, and then grow it to become more sophisticated. Where Firedrop took a long time to do anything useful, Firedrop2 may replace Kaa in a few days after its first prototype. (keeps fingers crossed)

Put it on Wax... *

Wax is coming along nicely. I whipped up a rudimentary GUI for Firedrop2 in 5 minutes. Here’s what the code looks like:

from wax import *


FONT_COURIER = Font(“Courier New”, 10)

class MainFrame(Frame):

    

    def Body(self):

        self.SetTitle(“Firedrop2 GUI”)

        

        self.splitter = Splitter(self)

        self.listbox = ListBox(self.splitter, [])

        self.notebook = NoteBook(self.splitter)

        self.splitter.Split(self.listbox, self.notebook, 

         direction=‘vertical’)

        

        self.editor = TextBox(self.notebook, multiline=1)

        self.editor.SetFont(FONT_COURIER)

        self.notebook.AddPage(self.editor, “Editor”)

        self.output = TextBox(self.notebook, multiline=1, 

         readonly=1)

        self.output.SetFont(FONT_COURIER)

        self.notebook.AddPage(self.output, “Output”)

        

        self.statusbar = StatusBar(self, numpanels=3)

        self.SetStatusBar(self.statusbar)

app = Application(MainFrame)

app.MainLoop()

The Wax controls are far from complete yet (for example, they don’t have any events at the moment), but they are already usable. And easy to use! Maybe I’m on to something here. It sure feels easy after spending some hours in .NET hell. ;-)

Firedrop2 ideas

Firedrop2 will be much more open than the first version (which is unreleased, in case you haven’t been following this). It will not attempt to control everything or to stop “users” from doing stupid or smart things.

Simplicity counts, so here’s the current plan:

• You have a directory with entries. Entries are in a special (but not complex) format. These files have the extension .fd2, so you can put other files in the directory without them being mistaken for entries. (Actually, you can put files anywhere, but it’s probably cleaner to keep everything in one directory.)

• A script called build.py in that directory takes the entries and generates output files. You can customize the script to make it do whatever you want. There will be some kind of API to help you, but the possibilities won’t be canned, like in the first Firedrop.

• A configuration file (or maybe multiple) in the directory contains info about FTP server, publishing, etc.

• Firedrop2 is a library: there will be a number of modules for certain purposes, e.g. weblog stuff, RSS, uploading, etc. (I think many of these will be borrowed from the original project.)

• Firedrop2 is also a GUI: a simple user interface (probably using Wax) should let you edit entries, run the build script, do a preview, etc.

• It will not be for everyone. If you like to hack Python and customize some code to make your weblog (or site) do what you want, then Firedrop2 should be for you. If you like as little effort as possible, you should probably look for a different tool.

• I’m not going to be anal about categories, attributes, etc. If you want to mess up, you can. The program will not stop you.

Let’s see if I can get this running soon. Shouldn’t take more than a day or so… I’ll probably need to do a little more on Wax though, before it can be used. Watch this space…

Wax/Wane *

So far, Wax is coming along quite well. There was a nasty bug, probably due to the fact that it’s not a good idea to create any windows before the Application has been started and initialized. (Although it worked with some controls… this is a bit of a mystery.) So now you have to create classes for everything, then call Application with the main class (not instance) and a list of parameters. Not perfect, but better than overriding OnInit, IMHO.

I would like to add more dynamism, like creating frames on the fly and then sticking them in a mainloop, but you can’t force wxPython to have the Tkinter nature. :)

To give y’all a taste, here’s a small Wax program that shows off some components…

from wax import *


class MainFrame(Frame):

def Body(self):

        b = Button(self, “a button”)

        self.AddComponent(b, align=‘center’, stretch=1)

        

        l = Label(self, “a label”)

        self.AddComponent(l, align=‘center’)

        

        t = TextBox(self, “some text”)

        self.AddComponent(t, align=‘center’, stretch=1)

        

        cb = ComboBox(self, [“one”, “two”, “three”])

        self.AddComponent(cb, align=‘center’, stretch=1)

        

        lb = ListBox(self, [“hava”, “nagila”, “hava”])

        self.AddComponent(lb, stretch=1, border=1)

        

        self.Pack()

        

app = Application(MainFrame, title=“foo”, direction=‘vertical’)

app.MainLoop()

Wax on the melt

Today’s 1-day project is a thing called Wax. It’s a layer on top of wxPython’s classes, that (hopefully) takes away some of the pain and hassle when working with wxPython.

Some of the goals are:
* getting rid of pesky IDs that wxPython seems to require everywhere
* better event handling, with methods on the appropriate objects, rather than calling functions (with IDs!) on several objects
* making layout easier; this is achieved by building sizers into some container controls (Panel and Frame, for example)
* making wxPython’s classes generally easier to use, e.g. by adding useful high-level methods

(A more ambitious goal is to make it easy and natural to separate “business logic” from the GUI, but that turns out to be surprisingly difficult.)

Those may seem hardly like goals that can be achieved in one day, but we’re getting there. (I’m cheating; I already had some prototypes to play with.) There’s a handful of objects available already. For now, Wax will be for internal use, not in the least because I might change anything at will, so it’s probably not a good idea if others use it, under the assumption that it’s a robust toolkit.

Much of Wax is inspired by Tkinter, by the way. Event-handling and layout, for example. I was also thinking of adding Tkinter-like config objects, but that may not be such a good idea.

If you have ideas that might go into Wax, let me know.

1-day projects

Since I have always had a short attention span for projects of any kind, something needed to be done. (No, I’m not ADHD. “Short” here means a few days, not a few seconds, thank you very much.)

The new idea is 1-day projects. I will spend a day trying to design and implement an idea, and expect to have something concrete and working by the end of the day. If that isn’t the case, then I may or may not choose to continue and spend some more time on it, depending on how much I like the idea. The project doesn’t need to be finished after one day, but I would definitely like to see some results. I think the general idea is: is it useful after one day? Can I do something with it? That is very important; IMHO, development works best when you can actually meaningfully use the program you’re working on.

This functions as some kind of mental razor. I may well conclude that an idea is not worth pursuing (too much trouble, etc), and then I only spent/wasted a day on it. It also forces me to keep things simple and to keep my goals humble. It will hopefully prevent me from making mistakes like with Firedrop, a project that started out promising, but which suddenly grew all kinds of new lofty goals (cross-platform, multiple GUIs, lots of content stuff I wasn’t going to use myself, etc).

Some project ideas would not be suitable for the 1-day approach. Sapphire, for example, would never make it. But a rewrite of Seeker or Tarantulon might. And so might Firedrop2.

I have a 1-day project scheduled for today. More on that in my next post.