Displaying feedback after each block in E-Prime

If you don’t use E-Prime for psychological experiments, skip this post.
It’s written for the benefit of psychologists who have the misfortune of using E-Prime without a programmer husband to help them out.

Sin, punishment and the Halting Problem

^*This possibility is not available in Buddhism.

Was FogBugz really released ahead of schedule?

On July 20, FogCreek released FogBugz 7. Joel Spolsky bragged about being a week or two ahead of schedule thanks to using EBS 2.0. However, the release had some pretty annoying bugs. Those bugs were fixed in the next release, on July 28.

With all due respect to EBS, I think that instead of releasing ahead of time, FogCreek should have started eating their own dog food. They would have discovered most bugs themselves, fixed them and released approximately on schedule, but without the bugs.

The way I see it, the real release was on July 28, and the date of the buggy release is irrelevant.

Science and free will

On one hand, since I believe in the scientific approach, I don’t accept free will. Instead, I believe that human behavior is determined by the laws of nature, and where those laws are non-deterministic, our behavior is truly random.

However, I find I must assume free will or my world will be overturned. For example, without free will, ethics loses its significance. Of course, people will still behave ethically most of the time because of law enforcement, selfish genes and upbringing, but in the phrase “thou shalt not steal” the word shalt becomes meaningless.

Political freedom, too, becomes pointless. In the absence of free will freedom turns into recognized necessity. What difference does it make then if the state makes its citizens recognize a different necessity?

But science itself, paradoxically, needs free will, too. In experiments, independent variables are used to test causality. But how can a variable be independent in the absence of free will?

All of this is not to say that free will exists; rather, it’s a simplified model we have to contend ourselves with until we have a better one, in the same way that physics freshmen are implicitly taught that Consciousness causes collapse because we don’t yet have an established “correct” interpretation of quantum physics.

AshkEnte

The Rite of AshkEnte, quite simply, summons and binds Death. Students of the occult will be aware that it can be performed with a simple incantation, three small bits of wood and 4cc of mouse blood, but no wizard worth his pointy hat would dream of doing anything so unimpressive; they knew in their hearts that if a spell didn’t involve big yellow candles, lots of rare incense, circles drawn on the floor with eight different colours of chalk and a few cauldrons around the place then it simply wasn’t worth contemplating.

This quote from Terry Pratchett reminds me of programming.

Adding C code to Perl on PC

I tried adding an external C library to Perl, more specifically, ActivePerl on PC. Here are my findings:

The recommended way is using something called xsub, a utility that has its own language, XS. The process is documented in two long manpages, perlxs and perlxstut. It’s long and complicated, involving a makefile generated by a local script, makefile.pl, in turn generated by xsub. The makefile doesn’t work because the backslashes there aren’t escaped. I tried replacing each backslash that wasn’t at the end of a line by two backslashes, but it didn’t work for some other reason. The conclusion is that MakeMake is broken on PC, and therefore so is xsub.

Then there is C::DynaLoad. It allows calling functions from shared libraries. In its doc the author says that xsub is much cooler, but doesn’t explain why. The only reason I can think of is that it can work with Perl variables, but then why not allow passing those variables directly to C functions? Anyway, guess what. C::DynaLoad is written using xsub. So I still had to build it using the makefile and everything, and the makefile was still broken. I tried to find it compiled for PC, but failed.

Now on PC there is Win32::API. Actually it allows calling any function from a DLL. It’s like C::DynaLoad, only it doesn’t require compilation. It actually can receive the C prototype of a function, and you can pass structs that on the Perl side look like hashes. I compiled the library I needed into a DLL, and it works just fine.

On PC, calling C functions in DLLs is standard. This isn’t surprising, since it’s a very simple interface. Why does Linux require jumping through all those hoops? I suppose because it’s more interesting in a geekish way. And that’s symptomatic of the general reason why Linux isn’t popular.

As an aside, I used MinGW, a port of gcc, to compile the DLL. You have to make the functions __declspec(dllexport) and WINAPI (because that’s what Win32::API expects). Now gcc understands the former, but the latter is defined in "winnt.h", on which gcc chokes. It turns out that WINAPI is defined to mean __stdcall (not __pascal any more), and gcc understands that. Then the function names are decorated with @4. I suppose it’s possible to turn off this decoration, but it’s simpler to pass the decorated function names to Win32::API. It works. The flag for making DLLs is -shared.

The wise men of Chelm strike again

Recently I’ve mentioned that there are many Wise Men of Chelm in governmental agencies. Well, there are especially many in armies. Here’s a recent example from The Daily WTF.

Its logic runs like this: On one hand, we want to be able to deal with unexpected moves, so let’s add a random factor to the simulation. On the other hand, we want the random moves to be the same every time!

Framework as an anti-pattern

Framework is certainly a pattern, but it often becomes an anti-pattern. I’ve heard someone say that this antipattern is inevitable in large systems, but I believe that avoiding it is a matter of keeping two simple rules in mind all the time:

Make interfaces as unrestricted as possible.

Create utilities for working in a certain way rather than requiring the user to work in that way.

As an example, consider an application like Photoshop. How do you design filters, keeping in mind that an image doesn’t necessarily fit in memory? An obvious solution would be this:

class IFilter
{
public:
  ImageBuffer Transform(const ImageBuffer& buf) = 0;
};

(Actually, the output buffer is smaller than the input buffer, and you have to express that somehow, but that’s not the point.) So now you have either a class or a function that uses IFilter to convert a complete image, and all is well.

This works for some time, and then you want to create a geometric morphing filter, and the IFilter design doesn’t suit it. So you create IGeometricTransformation, that converts a Point2d to another Point2d. But then you need to create some new filter that doesn’t work in any of these two ways, and you start twisting the design to accommodate for it. Gradually you get a mess.

The corrected design would be this:

class IFilter
{
public:
  ImageDocument* Transform(const ImageDocument& doc) = 0;
};

class LocalizedFilter : public IFilter
{
public:
  ImageDocument* Transform(const ImageDocument& doc);
private:
  ImageBuffer Transform(const ImageBuffer& buf) = 0;
};

class MorphingFilter : public IFilter
{
public:
  ImageDocument* Transform(const ImageDocument& doc);
private:
  Point2d Transform(const Point2d& pt) = 0;
};

That is, specific partial filter implementations are given as utilities rather than rigid rules, and IFilter is the least restrictive possible interface for a filter.

In the next post I’ll take this simplification one step further.

Leave the campsite cleaner than you found it

In Clean Code: A Handbook of Agile Software Craftsmanship I’ve read this very useful rule:

If we all checked-in our code a little cleaner than when we checked it out, the code
simply could not rot. The cleanup doesn’t have to be something big. Change one variable
name for the better, break up one function that’s a little too large, eliminate one small bit of
duplication, clean up one composite if statement.

Or delete some unused or commented-out code.

Don’t modify your language privately

When I was 16, I worked at a company that very soon went bankrupt (but that wasn’t my fault). We used PowerBuilder, an environment similar to Delphi, but with a language of its own.

In that language we were allowed to use minus in identifiers. Which means that we had to surround the subtraction operator with spaces (a-b would be considered a single identifier). At that time I wasn’t in the habit of surrounding operators with spaces. In the options I found a checkbox, that disabled using minuses in variable names, checked it and continued coding happily the way I was used to. Until at the next weekly code merge (which deserves its own post) my code didn’t compile.