Older blog entries for mwh (starting at number 190)

9 Jul 2004 (updated 9 Jul 2004 at 17:06 UTC) »

Hmm, advogato reappears just as I finally set up my own blog. Hmm, what to do. A potential advantage of my own blog is that I can hack on it to support various Emacs/reST-y integration issues, but that's only relavent if I get around to it...

ncm: Well, I'd probably mirror my own blog here in any case, and besides, that's what Planets are for.

We're just putting the finishing touches on the programme for EuroPython 2004.

My, what a lot of talks! Should be good — there's going to be some tough decisions on which track to follow at some points.

The world would be a scarier place if virus writers were less incompetent.

Random Thought For The Day

At the ACCU conference a week or so back, Steve Alexander mentioned that the constituent parts of large Python projects he'd worked on were more loosely coupled than those of similarly sized Java projects.

I wonder if this is in part because of the prominence of unit testing in the Python world.

If you're trying to write a unit test for some object that requires you set up six billion other objects before you can create an instance of the class being tested (a) you don't have a unit test any more and (b) it's just really really annoying. It always helps when doing the wrong thing grates.

I doubt this counts as a particularly profound thought, but I've just now had it strike me. I guess this is also an XP-ish thing: when you come across something that smells bad like the tight coupling I've just been removing, do something about it. Like, now.

Tangent

Another tangent to this is when you're doing test driven development (I don't feel I can capitalize that phrase in the context of what I've been doing for this particular personal hack) you really have to structure your program in a way that supports this methodology. I'm not sure people always realize this.

To pick two methodologies that in some sense are opposite extremes, consider the arguments that crop up from time to time between the static typing crowd and the unit testing crowd. The static typing crowd are used to structuring their programs in a way that maximizes the advantage of their methodology, i.e. crafting types in such a way that if your program compiles it has a damn good chance of doing what you want. The unit testers are experts at separating their problems into components that can be tested individually and writing thorough tests. I suspect that some of the reasons for the flamewars is a failure to appreciate the other "side's" practices.

(Hopefully you'll have noticed an assumption above that "static typing" means ML or Haskell or something like that. C coders just lose. Java I don't know much about but probably loses too. In C++ it's probably possible not to lose, but oh my, it hurts.)

As to which "side" is better, well, I'm not going to attempt an answer to that question :-) One thing to consider, though, is the side benefits of a given methodology such as the unit testing driving loose coupling. There are probably side benefits to the powerful static type system approach, too. I will notice that for sub-genius programmers, the unit test approach is probably just plain easier.

Of course, there no reason static typing and unit testing are mutually exclusive. Though, it seems to me that a unit test framework for ML (say) would have to include tests that 'merely' assert that some piece of code does or does not compile -- unit testing the type system, in other words. Hmm, the advantages of setting things down in prose: that last thought had definitely not occurred to me when I started this post... I wonder if any work has been done in this direction.

The Hack

Oh yes, the hack I've been working on: a PowerPC assembler in pure Python :-)

This has its own special fun in that a failing test is more likely to show up as a core dump than as a traceback...

Talk at EuroPython

You only have a week left to submit a talk at EuroPython 2004.

Or you can still register at the early bird rate for another fortnight or so.

It's going to be good!

Whew! After many nights of sweat and toil, registration for EuroPython 2004 is now open.

I never thought I'd know as much about Zope, Plone, Archetypes, etc as I do now. I still don't know an awful lot, but judicious cutting and pasting and changing in likely looking places got what I wanted doing done. It's all a bit of a big scary uncommunicative ball of mud, but certainly seems quite a powerful ball of mud :-)

The Glastonbury ticket farce would be funny if it wasn't so annoying. Off to the pub, I think.

Went climbing in Spain last week. Much fun was had, although the weather was a bit crappy.

Somehow, finishing this PhD and developing Python and/or PyPy doesn't seem so attractive as finding some crappy job in some convenient location and going sport climbing every weekend. Hmm.

25 Feb 2004 (updated 25 Feb 2004 at 12:50 UTC) »

If you've been programming Python for a couple weeks/months and you think that you can do a better job of designing and implementing the language than those who've actually been doing this for the last 15 or whatever years, you are probably wrong.

And in the unlikely event of you not being wrong, patches are much more welcome than whining.

Who am I trying to kid? Whining is too easy.

follower: I'm glad that someone is actually passing array.array()s to fcntl.ioctl... it was one of those bits of hacking I suspected might never actually be used.

181 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!