Professional IronPython

308
❘
CHAPTER 15
Using ironPython from other .net LangUages 
Before you can use IronPython in another language, you need to create a module that works with 
that other language. This chapter demonstrates a relatively simple IronPython module that offers 
enough functionality to do something useful. Of course, a major part of this task is discovering how 
to use the script engine to access IronPython functionality. The IronPython module you create will 
work fine with either C# or Visual Basic.NET.
The next task is to create an application that can consume the IronPython module. Using IronPython 
from C# or Visual Basic.NET isn’t nearly as easy as using .NET from IronPython — the dynamic 
nature of IronPython makes consuming it in the static languages much harder. The examples in this 
chapter show all the steps you need to take to use the sample IronPython module.
Once you get the IronPython module working from within C# or Visual Basic.NET, you need to test 
it. The testing process will likely reveal bugs in both the IronPython and the C# or Visual Basic.NET 
code, so you also need to perform debugging. This chapter considers both issues and offers insights on 
how to make the task easier.
UNdERSTANdINg THE RElATIoNSHIP BETWEEN
dyNAmIC ANd STATIC lANgUAgES
Something that most developers fail to consider is that, at some point, all languages generate the 
same thing — machine code. Without machine code, the software doesn’t execute. Your computer 
cares nothing at all about the idiosyncrasies of human language and it doesn’t care about communi-
cating with you at all. Computers are quite selfish when you think about it. The circuitry that makes 
up your computer relies on software to change the position of switches — trillions of them in some 
cases. So computers use machine code and only machine code; languages are for humans.
When it comes to dynamic and static languages, it’s the way that humans view the languages that 
make them useful. A dynamic language offers the developer freedom of choice, call it the creative solu-
tion. A static language offers a reliable and stable paradigm — call it the comfort solution, the one that 
everyone’s used. How you feel about the languages partly affects your use of them. In the end, both 
dynamic and static language output ends up as machine code. Dynamic and static languages end up 
being tools that help you create applications faster and with fewer errors. If you really wanted to do 
so, you could write any application today using assembler (a low-level language just above machine 
code, see 
http://www.bing.com/reference/semhtml/Assembly_language
for more information), 
but assembler is hardly the correct tool any longer — humans need a better tool to put applications 
together. The point is that you should use the tool that works best for a particular development pro-
cess and not think that the tool is doing anything for your computer.
Anytime you use multiple languages, you must consider issues that have nothing to do with the dynamic 
or static nature of that language. For example, you must consider the data types that the languages 
support and provide a method for marshaling data from one language to the other. In fact, marshaling 
data is an important element in many areas of coding. If you want to communicate with the Win32 API 
from a .NET-managed language such as C# or Visual Basic.NET, you must marshal the data between 
the two environments. It’s important not to confuse communication and infrastructure requirements 
with differences between dynamic and static languages. Many resources you find do confuse these 
issues, which makes it hard for anyone to truly understand how dynamic and static languages differ.
548592c15.indd 308
2/25/10 9:45:53 AM
www.finebook.ir

---