When the need arises

A side note: since “shared libraries” was quite long to type each time, I abbreviated it to “SL”.

A plug-in is needed when you wish to alter the implementation of a specific part of an already compiled program. A script, as well as a SL, is simply a module which you can fit inside an already compiled program to work with that program, so they are excellent for use as a plug-in. Changing from one version of the plug-in to another would be like changing the tire of a bike: you don’t need to take the whole bike apart to replace a part of it. The same goes for programs: you don’t want to compile the whole program to alter a small part. Most IDE’s take care of this pretty nicely, take my C++ IDE Code::Blocks for instance. The IDE automatically generates a makefile and can recompile in such a way that whenever I change a implementation file, but not the header, the only steps it needs to do again are compiling that small source file and re-linking it to main. Here’s an example of the output Code::Blocks shows me when first compiling the main program with a header and an implementation for that header, and then changing the header.

Compiling: main.cpp
Compiling: foo.cpp
Linking console executable: bin\Release\TMP.exe

And after changing foo.cpp:

Compiling: foo.cpp
Linking console executable: bin\Release\TMP.exe

As you can see the most basic option is to simply get the source, compile it once (from scratch) and after that you can alter whatever you want at basically the same cost as scripts/SLs, even slightly less since the program does not have any glue-code for loading (and interpreting) SLs (and scripts). So why doesn’t everyone do this?

Well, most people don’t have a fast computer, compiling a big program can take a lot of time, but that’s a one-time investment so shouldn’t be a biggie.

What could be a biggie is not being able to compile the thing! Closed-source, yeah that won’t work. Some weird compiler costing a bunch and the program only compiles on that one? That neither.

To circumvent these problems, you can build your code that calls something from outside the program, such as a script or a SL!

Differences

So what’s the big difference between a script and a SL? Most differences come with a downside or a benefit (or both, as it depends on what you’re striving for).

Interpreted vs. Compiled

Scripts are interpreted at runtime, this gives them a bit of overhead at first, but this overhead should be negligible on the next passes due to the script being compiled once and thereafter being retrieved from the cache (most of the time). Further discussion about the speed and memory usage of interpreted code versus compiled code will be kept to a minimum.

Deployment time

SLs would take a bit longer to deploy. Change a script in any editor, save it and you’re done. To recompile a SL, I open up my project file, change the code, compile, and then I’m done. Compiling can take a few seconds and is largely dependent on the size and complexity of the code (for C(++) at least).

Code Access

A big advantage of SLs (in the same language, or closely related such as C and C++) is the ease of merging the module with the main program. Give the code the right headers, and you can do anything you could do in the main program. This is pretty hard to do in most scripting languages, often consisting of macros and other code that only exists to glue the script and the program together.

Languages

Scripts are obviously in a different language, but SLs don’t need to be. However, if SLs are in a different language, you need to learn how to compile it in such a way that the compiled code can be called from your main program’s compiled code, make sure it matches the calling convention, variable types, etc. When you want to change or add a scripting language (so that your program can use it) you need to add that functionality in your main program… It doesn’t really differ a lot in difficulty I think. However, most scripting languages are more oriented on ease-of-writing than on speed, as opposed to compiled languages. Therefore, it depends on what you want with this specific plug-in.

Portability

With more and more people “fighting the good fight” everyday, more people are going Linux. Therefore in general people give a bit more if their program runs on more platforms. When writing a script, most of the time you’re done for each platform: the APIs you used belong to the script, not to the platform, as is the case with compiled languages. Making compiled languages portable is a bit harder, since you are then dependent on another library such as Boost, or on some other kind of construct in your source. Preprocessor directive #ifdef works well for small algorithms in my opinion.

List-it

Lets whip up a quick list of benefits and downsides of the options

• Scripts
• Benefits
• Low deployment time
• Potentially faster due to JIT compiling can take advantage of variables known at runtime.
• More portable in general.
• Downsides
• Needs a library that ships along with your app (separate or statically linked, doesn’t matter), given that the library (in the right version) isn’t already available on the system.
• Needs some “glue”-code for exposing the program’s data to the script, so you can access the program’s variable from the script.
• Needs to be recompiled each time the program is launched, given that the interpreter doesn’t store a cache of course.
• Shared Libraries
• Benefits
• Can really act like a part of the program, or at least easier then mixing compiled code with interpreted code.
• Potentially faster due to compiler can make expensive optimizations. It’s okay for a compiler to take a bit longer to compile a SL than for a script interpreter.
• SLs can be closed source whereas scripts obviously cannot be as easily (need to be obfuscated/repacked in some way). Some people may not find this a benefit, but I do, the choice to go open or closed shouldn’t depend on whether the code is easy to hide or not.
• Downsides
• Longer deployment time, but shouldn’t be really different.
• User can’t really check what the library is doing, it could be “bad” code, such as a virus.

So there you have it! A neat list, if I say it myself, with benefits and downsides of the options. I tried to make it as complete as possible but feel free to leave a comment if you think you can add something. For large programs, I think I’ll go for SLs at first, then for scripts to end up with a hybrid solution. For example: if you want to use a lot of internal classes of your C++ program, it’s way easier to go for a SL. On the other hand, if you want to be able to quickly see what different code has for effect, go for a script. If you want both you’re fsked and still have to make a choice. A good and well known example of a hybrid program is Blender: compiled in C, C++ and Python, it uses quite a lot SLs and also has support for Python scripts.

I hope you enjoyed reading the article, I sure did writing it. Thanks go to Maurice Bos of BosByte and Michael of this great site for correcting and in general improving this article. Stay tuned for more articles, there’s a small abstraction tutorial coming up!

Recently I had a discussion with Nick about open source handhelds. Reason for this discussion was the upcoming release of the GP2X Wiz. As with many other things it looks like we disagreed with each other about the GP2X.

Nick argued that these kind of handhelds are slowly becoming obsolete as small notebooks such as the Asus Eee PC are becoming increasingly more affordable. Considering this fact he called devices such as GP2X pure luxury. I understand why he feels this way. After all, why wouldn’t one buy an Eee PC for a little bit more money? Although, I don’t think you can compare the GP2X with an Eee PC. The GP2X is in a completely different market than the Eee PC. The GP2X is just a simple game/media handheld.  It doesn’t claim to be more than that.

If you consider that the GP2X is a game/media handheld, it becomes a lot more interesting. Especially the fact that the GP2X is open source is interesting. This makes it a lot easier for developers, especially unproven developers, to develop applications for this handheld. I think this is a great way for hobbyist developers to get into handheld game development. This would be a lot harder if only the Nintendo DS and PSP were around; those platforms are very closed. So, it’s very good that there is an open alternative.

But the GP2X isn’t the only open source handheld out there. Besides the GP2X there is also the Pandora. Ironcally, Nick’s argument seems to apply completely to this device. Unlike the GP2X the Pandora isn’t only a gaming handheld. In fact, it offers a complete OS. It’s also a whole lot stronger than the GP2X. Unfortunately, the Pandora doesn’t really attract me. I’m not looking for a handheld that has the same functionality as a simple notebook. If I wanted something like that I would buy an Eee PC. No, I want something simple. Besides that I don’t really like the control scheme of the Pandora.

Nick says:

Just look at the thing! It’s so small… Okay, so maybe it isn’t really obsolete, at least it’s not my cup of tea. The eee would be a way cooler handheld, but it won’t really be an handheld. You can just put in your controller and play any game for example. Combine that with the huge offer of games that are already available through Ubuntu’s apt-get and you have a wicked gaming console. Kinda like that mini PS1 there used to be, but with a long batterylife and a high resolution screen too.  I don’t see people in the train playing on their handheld, I see people in the train with their laptops. So yeah, in that way, it’s quite obsolete. When will you play this and actually have a better experience then you would with an eee and a nice controller? Maybe in the back of the car/bus/public transport, but I am more of a music listener when traveling and if I really want to play a game, my handheld is my phone.

I think Michael and I actually agree over that the Pandora is rather useless. Just buy an eee.

Picture to the right is a GP2X by the way, not the GP2X Wiz which admittedly looks more comfy. Maybe just as comfy as the PSP or DS, but those aren’t exactly comfy now are they?

I fired up my gameboy (the first, big, gray one) recently and played Castle Chess. Wicked soundtrack. Don’t tell anyone.

—

Does that mean it’s not neat… No. It has XML-RPC, which is without a doubt really cool. Amongst that, the admin panel isn’t bad, it has a lot of nice functions, etc. etc.

I just don’t think it belongs within the “Simple” software. So if we use it, please be advised. WordPress code is NOT simple. It is very user friendly and neat.

Now, one last thing: fatal logic error on previous post: Michael thinks we can’t deside about what engine to use, which is probably correct, but then he (and only he) decides the users can vote for it. Well I’ll just be an ass and say I won’t let the users choose, so we can’t decide on that either. Done.

But fine whatever, we’ll stick with the 6MB gigantic monsterosity called WordPress for putting TEXT on a webpage. And the “Add New Category” is convienent. And we’ll be busy with other stuff anyway. Like visiting girlfriends. And punishing unwilling colleagues for not working on the all important coilgun project.

Unfortunately, Nick doesn’t really like WordPress. While I prefer WordPress, he prefers SimpleLog. He told me that SimpleLog’s admin panel was a lot better than WordPress. And the few features he did like he wanted to write for SimpleLog. Interesting he didn’t like WordPress widgets. That while he asked for modularity when we started .simplicity.

But it looks like we won’t be able to make a decision on the blogging engine together. So I’ll leave the decision up to the readers of .simplicity.

– Michael

—