Tao of the Machine

Tegenstrijd, again

On, off

Let's say we have an object, call it Enabler, that takes a function and a list of components. The function returns a boolean, indicating whether the components should be enabled or disabled. Every N seconds the object calls the function, checks the result, and enables or disables the components.

How is this useful? In Firedrop (and it would apply to Kaa as well), I have a bunch of menu items that only make sense if a database ("site") is opened or created. If not, then they just won't work. Currently they raise all kinds of errors. One way to solve this is to add code at the top of the functions/methods associated with the menu items: if no database opened, show message and bail out. That gets tiresome though. It would be more elegant if all those menu items (and buttons, etc) would be automagically disabled if there is no database active, and enabled when soon as you open or create one.

Of course there are other examples. Think buttons that are only enabled if certain conditions are met. Etc.

I actually set out and wrote a first version of this object, but that implementation didn't work with wxPython (it used the sched module). Writing a portable version will not be easy.

Language wars

"You've got to be kidding. Forth is just a sequence of words. As such, that is easy, but to understand the structure, you have to know how the evaluation of each word transforms the stack. Given the words A B C D, if you don't know what they do, you are in the dark. A B and C could each deposit something on the stack that D consumes, so that it's like the Lisp expression (D A B C). Or maybe C operates on the results of A B, which is then fed to D, so that it's like (D (C A B)). Or maybe the sequence causes a stack underflow. Effectively, the second level of parsing, beyond just ``sequence of words'', is conflated into evaluation. The calling conventions---how much mut be put on a stack to satisfy a function---are under the program's control."

"The structure of Haskell is probably readable once you study the grammar. I've spent only several hours studying Haskell, but got nowhere. To me, even small examples in that language look like the garbage characters that appear on the terminal when you have a noisy serial cable. It's an ill-designed, ad-hoc monstrosity designed by someone who thought that every programming language design problem can be solved by slapping on more syntax."

"Python is basically a terrible syntactic interface to a subset of the semantics of a language resembling Lisp. It has no ANSI standard, and only one poorly optimized implementation.

Python syntax is fractured in a Fortran like way: some things are expressions, some are statements. This leads to bizarre restrictions, like not being able to write a statement where an expression is expected."

People who voice opinions like these are hopefully not representative for the majority of Lisp users, but they are certainly the loudest. They seem to lack some kind of self-deprecating mechanism. I like Python; it's the best language I know (at the moment -- it's an ongoing search); I am ready to defend it against more conservative forces, if necessary; but I won't go into other newsgroups and ridicule people for the languages *they* think are best, much less go into ad hominem attacks and insult the language designers in the process. This kind of "advocacy" has the reverse effect, it makes Lisp terribly unattractive, no matter the merits of the language per se. (What if I don't understand something and go into the newsgroup to ask a question? That reminds me of my physics classes in high school, where the teacher would make fun of you when you asked something.)

I think I will stay in comp.lang.python for a while. Much friendlier.

Even-if-Guido-writes-ten-PEP-308s-ly y'rs,

Heh

In other news, I actually got a refund from the Ebay seller that sold me fake Zoids. Very nice.

Firedrop milestone 1

Hmm, it may be a good idea to give a short clarification of "Firedrop-speak":

node: aka "entry" or "post" in other systems. I use the more general "node" now, because the other two are not always appropriate. Maybe for weblogs, but Firedrop does more than just weblogs.

section: A Firedrop site is (or can be, this isn't mandatory) divided into sections. When you create a section, you must associate it with a section type. The section types that are currently under development are ArticleCollection, Weblog and FAQ. Nodes in an ArticleCollection are used differently than those in a Weblog or FAQ, etc.

Think of it this way. On my site, I want to put some articles I wrote about Python, so I create a section of type ArticleCollection for that. I also wrote an important app, which should get some pages of its own, in a different section. The FAQ for that app will get type FAQ, of course. A development weblog will get type Weblog, etc.

Firedrop will not be as easy as Kaa, but it still shouldn't be difficult to use (especially since I want to add some newbie-friendly stuff, eventually). In fact, it should fix some problems Kaa has, and generally be more user-friendly. And it should be much more versatile and powerful...

Development isn't going fast though. Sometimes it feels like wading through tar, or something. :-) Partially that's because I use wxPython; I have been wrestling it a lot, and still it doesn't always do what I want. Partially it's also because of the design. I want -- no, need! -- a clean, well-thought-out design, and that takes time to set up (especially when your ideas are vague), but pays off in the long run. An "unclean" design allows for fast development at first, and then it gets slower and slower because your code is a big old mess.

Oh well. I should probably talk less about Firedrop and write more code. :-)

Firedrop fixes Kaa problems, part 1

<#
    print this
    print that
#>

<# print this
   print that
#>

All this will be in Firedrop, but there's nothing really that stops me from sticking the improved module (and test suite) back into Kaa, I guess. Maybe for 0.9...

Fake

• The colors are way off. (Roughly, blue and light grey are reversed.)
• The cockpit cap, normally a see-through "glass", is an opaque light grey.
• The wings cannot fold and don't move when the Zoid walks.
• The plastic is cheap. Some parts were already loose when I opened the plastic.
• The manual looks like a carbon copy, not what you normally get with Zoids. Also, some numbers in the instructions are not correct.
• The stickers aren't see-through; rather, they have a white background.