One of the recent internal discussions kicked off by Russ Blake at Readify has been on what part to play IronPython should have in commercial software development.

Is it ready for the cubicle dwelling masses?

Here's my take on it:

Python (Iron or otherwise):

I think the advantages of Python verses any other language is more a question of commercial environment and fashion than anything else. This isn’t good or bad. It just lumps it in with every other Turing complete language.

Personally I find Python an acceptable language as:

- It’s a good successor to Perl in terms of being a pragmatic scripting “glue” to bind other bits together.

- The syntax, while having slightly different coloured goo than its more “commercial” peers, is readable.

- It scales better than Perl in terms of being to construct medium to large sized applications.

- It also has the advantage of being one of the current “cool kids” of application development (as the attendance of a recent programming comp clearly demonstrated. The only thing sexier than Google in young developers eyes at the moment seems to be Python.)

My only small grumble with it, due to its Perl’esque pragmatic approach to being able to glue bits together, is that it very quickly exposes it ugly underscore ridden underbelly of working gears and levers in the pursuit of decent sized application development.

So my overall response to Python in general is: Meh.

Looking down from a greater altitude:

What I find more interesting is that Python tends to get used quite a lot as a hosted scripting language in other applications.

Everything from games to GIMP to Chumbies seem to be ticking along with Python, LUA or some other scripting language lodged near their heart.

And, hopefully without sounding too much like the crazy guy talking about how poultry controls the CIA, I think scripting languages are where is it’s at.

Crazy Talk:

My dream business application, as I’ve bored many with on previous occasions, is one built in much the fashion as a modern game.

Content designers (aka Business Analysts and Devs) world in their own little self contained bubble world of scripted language goodness.

Framework  developers work around this bubble, wiring up the ‘content’ to the graphics, storage and network bits.

Content designers never attempt to write the binding code for an Infragristics grid and Framework developers never try and write the formula for calculating the rounding on the GST of a baked bread item purchased with a gift voucher.

Now you there’s nothing stopping this from happening purely in the familiar world of C# or VB.NET but it presents a few issues.

CLR without DLR is no fun:

The first is the nitty gritty technical pain of dealing with the shear tedium of attempting to host non-DLR languages in .Net.

It’s just too much work to get a plug-in system working that doesn’t ending up stepping on the toes of memory (Yay App Domain unloading! ), exception handling (Yay App Domains!) or communication (Yay App Domains!).

Secondly, there’s slightly non-intuitive ‘social’ side effects of picking of the same language for both framework and content construction.

Content developers really need to focus on producing the content... not ‘peaking under the hood’ at what the Framework guys are doing and attempting to ‘patch’ into or around any random bits of framework that take their fancy.

Thirdly, making a scripting language (or DSL if need be) your language of choice for how to articulate the solution to your problem is a very powerful idea indeed. In addition to being able to craft the syntax so that more elegantly describes the problem domain, executing your content via a scripting language means you gain a whole more context and control over what’s going on.

Writing interfaces and APIs give you some control... but it’s practically impossible to have any sort of compile time confidence that the content developer hasn’t done something to (un)intentionally thwart the design of the underlying layers. (“So I noticed that if I used reflection and kicked off this on another thread then it all seemed to work... I hope that was okay?... Bob?... Bob?...”)

Expressing the solution to a problem via scripting language or DSL is a higher level of abstraction as well.

Want to add in a funky auto parallel’ising  multithreaded network capable piece of code everywhere the content designer has decided to add some numbers together?

No problems. The language host can specifically keep a look out for when such occasions occur and make a call your new code as required. Zero change the neat elegant highly readable content description of the business process and no need for the content developers to have to refactor their code with weird and wonderful attributes or other languages constructs that have nothing to do with the business problem at hand.

So....

Crazy half-baked conclusion:

My summation is: Hosting scripting languages / DSLs is cool.

Python is okay as a possible scripting language choice... but may not be my first.

Random side thought:

I’m thinking the long forgotten hero of scripting languages is Logo.

· It’s relatively easy to implement

· It has clean simple syntax

· Arguments over punctuation and its placement rarely break out

No joke.