As far as I can tell people still prefer using python for scripting in their Delphi projects. This is probably because python scripting in Delphi has a long history and it is a proven method with easy integration. What if I would tell you that there is a free solution which enables you to write also your scripts in pascal? A few years ago I discovered an alternative that makes this possible. This highly influenced my vision about the importance of scripting. Since that I accompanied all my hobby projects with full scripting support.

The first question of the reader might be that why I would need a script language in my program? It is, however, very easy to answer this question. The presence of some sort of scripting support in a software product has many benefits both from developer and customer point of view:

• Less wasted time on software building by customizing application without the need for recompilation.
• Unusually flexible reflection capabilities by creating script code on-the-fly with string manipulation.
• Very flexible debugging possibilities by modifying executed code during the debug session.
• Easy separation of often changing high level logic and rarely changing internal framework.
• Powerful tool for the user to customize application for own needs.

These are just a few examples what additions a scripting engine can give. Personally my favorite one is the second mentioned example in the list above. As a result that I’ve worked as a PHP developer for over a year I really got used to the ability to compose code on-the-fly by just putting some strings together. It is a built-in feature of PHP and most other interpreted languages, however it is fairly uncommon that such functionality exists in native programming languages. I knew that to emulate the presence of this facility I have to use some scripting language but I never thought it will be so easy to find one which suits my needs.

First, I was looking around to find out what other Delphi developers use in their projects. That’s how I first met with python. The language itself has a very powerful OOP tool-set but the syntax was too extraneous for me. After checking tons of other scripting languages out there which had mostly no easy integration possibilities with Delphi, finally I found RemObjects Pascal Script.

Pascal Script for Delphi

First, I just said “Wow! This is exactly what I was looking for”. It not just enables you to write your scripts using the language what you also use to develop the application itself but it also provides incredibly easy integration with Delphi. Just to mention a few features of Pascal Script:

• Calling Pascal Script code from Delphi code or vice versa.
• Using external DLLs from within the script without requiring any type of function header.
• Sharing any kind of data between the script and the Delphi code in both direction.

For a full list of features please refer to the official site of RemObjects Pascal Script.

One thing that most Delphi developers got used to is that most of the third-party components and tools available for Delphi are with a commercial licensing. Well, this is not the case with Pascal Script. It is not just freely available but also comes with full source code. This further increases the potentials of it as you can add new features to it if you wish. However, it is already powerful enough for most use cases.

How it works?

In a nutshell, using Pascal Script is piece of cake. You just have to put together your source code string, compile it and then execute. Yes, Pascal Script needs a compilation phase which produces a byte code as an intermediate format. By telling this, you’ve probably already figured out that Pascal Script is not just very flexible but also provides adequate performance by not having to interpret directly the source code. Let’s start with a very simple script:

{ some very simple pascal script }
begin
  PrintString('Hello World!');
end.

This will call the procedure PrintString with the string parameter “Hello World!” . But where this procedure comes from? Well, actually you have to bind it using the run-time library that comes with Pascal Script. To execute this script having an actual Delphi procedure bound to the procedure name used in the script you’ll need some code similar to the following:

program HelloWorldScript; { host application that executes the script }

uses
  uPSCompiler, uPSRuntime;

procedure PrintString(message: String);
begin
  writeln('Message from script: ', message);
end;

function LoadScript: String;
begin
  { load the script from some file and return it }
end;

var
  Compiler: TPSPascalCompiler;
  Exec: TPSExec;
  ByteCode: tbtString;
begin
  Compiler := TPSPascalCompiler.Create;  // create an instance of the compiler
  // register user procedure to compiler
  Compiler.AddDelphiFunction('procedure PrintString(message: String)');
  if Compiler.Compile(LoadScript) then  // compile the script to byte code
  begin
    Compiler.GetOutput(ByteCode);
    Exec := TPSExec.Create;  // create an instance of the executer
    // register user procedure to executer
    Exec.RegisterDelphiFunction(@PrintString, 'PRINTSTRING', cdRegister);
    if Exec.LoadData(ByteCode) then  // load byte code to executer
      Exec.RunScript;  // run the script
  end;
  Compiler.Free;
  Exec.Free;
end.

If a newbie looks at this code, probably thinks that it’s overcomplicated. Well, actually this is true. Pascal Script needs some basic setup stuff but if you take the time to learn it, you will figure out that it does not involve too much code to use it. One thing that may still need some clarification is the registration of the user procedure provided to the script…

Connecting the script to the Delphi code

Pascal Script needs that all the procedures, functions, variables, types and classes that we would like to provide to the executing script needs to be registered both to the compiler and the executer. The compiler needs this information for syntax validation and to produce the byte code, that’s why it’s enough to provide the signature of the particular language element to it. The registration to the executer is which actually binds the concrete object to the script.

All these manual registrations looks like a pain in the a** at first sight, however, they are unavoidable. Fortunately, Pascal Script provides a very handy tool for us to automate this process, namely the UnitImporter. This tool can create an import unit based on an actual production code unit that will provide one parameterless procedure that registers all the classes, methods, etc. to the script compiler and run-time.

Beside this, Pascal Script provides ready baked units for the registration of the standard units of Delphi and a component set that integrates into the IDE, although I haven’t used them so far. Anyway, even if the framework seems to be a bit too complex and needs too much auxiliary code, in practice it is very easy to use it and most of the support code for scripting can be generated with the UnitImporter. If you don’t believe me, try using it for a while and you will see.

Portability and usage limitations

Maybe Pascal Script is not the Holy Grail of Delphi programmers but it is a very powerful scripting engine. The first question in those who are not developing on/for Windows platform can be that “Is it portable?”. This is another advantage of Pascal Script as it is as portable as Delphi can be. This means that it will work fine also with the Free Pascal compiler and it comes with the same component set for the Lazarus IDE as well.

So if not the portability and the ease of use then has it any disadvantages by the way? Unfortunately, yes. We’ve already seen that it has both-way interworking capability with Delphi, it has tools for automating the integration process and it can be used also for cross-platform projects, but it has small problem: it supports only a subset of the Delphi language so you cannot define classes in the scripts. You can still use classes and objects inside the script, but only those which were defined in the host Delphi application.

Anyway, this does not necessarily mean that Pascal Script is not flexible enough. I used it in my project mainly for the following purposes:

• Using the services provided to the script (classes, objects, etc.) to manipulate application behavior at run-time.
• Handling Delphi events with procedures/functions implemented in scripts.
• Baking a console that makes debugging tasks much easier by correcting errors while the program is running.

Personally I don’t understand how Embarcadero Technologies (the current supplier of Delphi) haven’t integrated it into the core Delphi distribution as they did with many other popular frameworks like DUnit.

Conclusion

Pascal Script is probably not a script language that can have a future on it’s own but it is still a great addition to the feature set of Delphi as it provides a way to push the flexibility of the language above it’s limits with minimal effort. It is fast, robust and stable, and it offers most of the facilities that usual developers expect from a scripting language. Maybe I’m quite biased as I really enjoyed working with Pascal Script, but I think you Delphi programmers out there should definitely take a look at it and give it a try.

Those who know me know it well that I am not a big fan of languages which produce managed code. In this article I would like to cover the reasons behind my skepticism. Also I would like to dispel the myths around such languages and try to prove them with facts (we will see how well I manage to achieve this). If you disagree with me, you’ll most probably hate me because of making this post but please, respect my personal point of view.

As I’ll mostly talk in this post in general about managed code I would like to emphasize that I have worthwhile experience only with Java and have barely used C# and other managed languages so my primary arguments maybe apply directly only to Java but still would like to present my arguments in general as they still apply in some way to all such languages.

Without the intension to insult anybody, I would like to start with a citation from one of my friends, who often says that “Java is just a pseudo-language”. Mostly I agree with him and it’s not just because I have my not so delightful experiences with the language but also because it introduced a brand new way of coding style that is a complete nightmare for an old-school coder like me. As I don’t want to start another religious war, I’ll stop my preposterous arguments here as I would like to prove my concerns with facts that nobody can disclaim.

“… nowadays Java is almost as fast as native code…”

This used to be a common myth in the last few years. For those who are still arguing by shouting this loud on forums and blogs, I would like to draw their attention to the fact that Java is still an interpreted language no matter if the latest JVM versions do some on-the-fly compilation of the code and as such it is inherently slower than any language that generates native code.

As my hobby is computer graphics I have to talk a bit about the case of PC games. Have anybody seen a game fully written in Java or any other interpreter based language that produces state-of-the-art graphics which competes with the best professional games and it also provides the same performance? I think not, and this is not a coincidence.

GPUs are getting more horsepower in a much faster pace than CPUs. That is what resulted in the batch crisis lately. It’s already happening for several years that the CPU is simply not powerful enough to feed the GPU with enough data in complex real-time rendering situations. There have been already tons of different software and hardware technologies which already targeted this issue a long time ago but as a perfect example that is the reason which resulted in the appearance of the completely redesigned DirectX 10 API and which emerged the need for a cleaner architecture for OpenGL as well. That’s why there are no advanced games written in interpreted languages as they waste those very valuable CPU cycles which would have great benefits otherwise.

“… Java has a much greater expression power…”

I tend to agree with this one. As these languages are interpreted by a virtual machine they provide great room for such features that would be impossible or simply very inefficient in a native language. That’s why one of my favorite programming language is PHP as an example. It is even more flexible then Java, for example, but never forget that PHP never meant to try to replace native languages as instead it is used in a totally different domain.

There are many language features that are not available in native languages but they weren’t left out unintentionally. Their lack is primarily justified by the fact that most of these features are rather inefficient and they simply not fit in the philosophy of a performance oriented language like C++. However, the most important ones like reflection, delegates and most OOP related facilities are present for example in Delphi, which is one if not the best OOP language that doesn’t make too much trade of between flexibility and run-time performance. Also, even if most of these features are not present in C++, Objective-C and other popular native languages, they can be made available with a little programming knowledge in the particular language (maybe not just little).

“… you don’t have to care about resource deallocation as there is the garbage collector…”

This is one of the most annoying “features” of managed code based languages. I understand that the prevention of memory leaks can have a great impact on development effort, however the unpredictable behavior of garbage collectors is simply unacceptable in certain situations. The issue of lost references has been already addressed in almost all native languages with the use of reference counted objects so I simply don’t get it why is this still an important feature. For efficient resource management you need much finer control over the time and way how resources are released.

“… you just have to care about the basics and Java will make you the rest…”

While I strongly support the idea of COTS, the way how Java and friends interprets this concept is simply unacceptable for me. Sometimes you need to know what is going on under-the-hood. This is basically the same issue like that of the garbage collector. Beside that, according to my personal taste, I don’t like if the compiler tells me how to do a particular thing. I rather do it in my way and even if I tend to agree that the compile time static analysis what the Java compiler does can be very valuable in some situations, simply denying code generation even in the case of a very minor semantic problem is simply makes me angry.

“… Java eliminated almost all unsafe features inherited from C++…”

This is one of the things that hurts me most. While Java really managed to achieve this, it sacrificed flexibility, ease of use and the fun of programming to make this possible. One such removed feature is operator overloading. I love them! As an example a linear algebraic library, which is often used in graphics programming, or the string library is not just makes the coding more natural, it eases the reading of code which is written with these in mind and that greatly effects the maintenance cost of a particular software as the code is read ten times more than modified. Java in this domain seems too verbose for me and it is much harder to read the long method invocation chains, that is not just used to be used by the developers, but is the recommended way how to code in Java.

This post already ran wildly long so I will close the topic for now. As a conclusion, I have to point it out that this article presented the subject from a rather subjective perspective at the end. Sorry for that, I will recap on the topic in a later post where I will try to be more detached and I’ll present actual use case examples but for now, this is all that came from my heart so please, don’t be very harsh with me if I was very biased. I hope you enjoyed the article anyway.