In case you hadn’t noticed, I’ve not worked on Harlie for a while. This is because (as I rediscovered when I returned to attempting to work on it) it’s driving me insane trying to work out how to do what I want without reverting to horrible, horrible (and possibly incredibly pessimal) hacks; or even being unable to do things at all.
For example, the commands side of the bot… I intended for this to be easily extendible, so that plugins (inconsistently referred to as ‘modules’ in some places.) can add their own commands. This turned out to be more complicated than I first thought (What wasn’t, on this project?). And the result was that, especially with the re-arranging of the commands into “command subcommand”, it turned into a mess of if/elsif/else trees. This was incredibly non-optimal, to the point it arrived at pessimal.
The second most frustrating point of this project I have not even attempted, it’s still stuck on the drawing board because I can’t think of a way of doing it without driving myself insane (Well, moreso.). I want to be able to let plugins register for events, so that an event gets sent to multiple plugins (For adding triggers, etc.). The only way I could think of doing this (And I think it says a lot about my method of working…) was having an array of handlers and iterating through it, calling each one and passing the contents of the event.
I then promptly slapped myself for thinking up something so awful. This is, quite frankly, a hideously stupid way of doing what I want. One, as perl is single-threaded (See the next paragraph for complaints about this, too…), and I’d be iterating through the array; if one handler sat there and did nothing, the entire bot would grind to a halt. Two, it’s a fairly clumsy-feeling solution, and possibly quite fragile.
And now, for the lack of multi-threading… Yes, I know Perl has ithreads, but I’d have to recompile perl on this PC, and it causes things to break. This is a Bad Thing™. Also, as it’s a compile-time option, it’s not guaranteed to be enabled on every user’s install. Which means it would only work on a few installs, and as I’m not going to enable that feature because of the aforementioned breakage, not on mine. What this lack of multi-threading means is that if a function runs on too long (I don’t have a specific example, but imagine a plugin that attempts to process a large amount of information (or inadvertently enters an infinite loop.)), the bot will not receive events and eventually ping out. This is a Very Bad Thing™.
So now, the programming language I chose because of its suitability for programming an IRC bot (The fact that perl handles text very well.) is becoming a big limiting factor in what I can do. The problem is, what language do I move to now, and how much work is it going to take me to get even half-way to where I am with the perl version? (My vote is on: A lot.) (I’m currently looking at using C/C++ with Boost and libircclient.)