Tuesday, June 06, 2006
A couple of weeks ago I suggested a way of dynamic programming with IronPython.  Essentially it is a combination of using a Smalltalk like System Browser to browse types using .NET reflection and embedding an IronPython interactive interpreter into the System Browser to manipulate the reflected types.
 
Why would I want to do this?  While I really like Visual Studio, which I use for my day job, sometimes it takes forever to build a simple prototype or experiment with a new class library.  For me, I want to see an app up and running as soon as possible, but at the same time leveraging class libraries and third party components.  And I want to do this dynamically.
 
I am also one of those people that learn best by doing.  While I can read the framework class library documentation till I fall asleep, (.NET 2.0 has 29,000 types in it!), I like to play with the types live and through some experimentation, find out how they work.  Sure I can use Visual Studios Object Browser or Lutzs Reflector (even as an add-in to VS), but it is not suited for how I work.
 
Maybe I am old school, but I like the Smalltalk System Browser approach to software development.  In .NET it is a little harder because the Smalltalk world was really simple, you had classes, instances and methods.  Thats it.  In .NET it is more complicated, but still what I am interested is inspecting an assembly for its types and for each type, what are its public properties, methods and events in other words I am using the System Browser as a way to work with the types, not just browse them.  Having an IronPython console window embedded in the System Browser lets me play with those types dynamically.  To me it is the best of both worlds, leveraging pre-built types to dynamically build my prototype or application.
 
As a side note, this blogs focus is on software industrialization.  I have explained what that means in other posts, but one aspect of software industrialization I would like to point out is simplicity.  The ability to browse libraries using the Smalltalk System Browser paradigm and then use those libraries interactively in the same window is simple.
 
The System Browser is initially built as a C# application, just to get parts of the code design down of what I want and in a language I already know.  I am also mirroring the development of the application as a Python Windows application, which is what the final product will be.  While I have run into a few problems, mostly my own, I have had excellent support from the folks at the IronPython forum.  Of course, I have already made a fool of myself on the forum by repeatedly submitting a chunk of Python code that had a (read: my) mistake in it, which I missed on a couple of occasions.  Maybe if I slow down a bit, I will see it before I submit it :-)  Thanks to Dino, Vagmi and J. M. for being patient.
 
I should also point out that for Windows Forms programmers looking to get a tutorial on creating Windows Forms dynamically using IronPython, should look at Michael Foords excellent tutorials

Back to the System Browser - maybe I will have something implemented in a couple of weeks or months.  Stay tuned.
Tuesday, June 06, 2006 7:23:52 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0]
 Saturday, May 27, 2006
As I mentioned in a previous post, I am really excited about IronPython on the .NET platform.  The main reason is being able to program dynamically.  What I mean is that I can import .NET classes and start using them interactively with the interpreter.
 
For example, I can interactively build a simple WPF (formerly Avalon) application in just a half dozen lines of code.  I dont mean running a script either; I mean entering in one line at a time and immediately seeing the results on the screen.
 
For example, the following code imports the WPF library (and a small script to allow interactivity between the interpreter and application being constructed), creates a new window instance, displays the window, sets the title and some text in the form, sizes the text and finally sizes the form to the text.
 
from avalon import *
w = Window()
w.Show()
w.Title = Simple WPF App
w.Content = TextBlock()
w.Content.Text = Aloha IronPython!
w.Content.FontSize = 50
w.SizeToContent = SizeToContent.WidthAndHeight
 
Alright you say, no big deal.  Well, on one hand you are right on the other, I think the point is that it satisfies a major requirement that I have as a programmer which is to interact with building my application in real time.  This goes beyond just the compile, link, deploy cycle of compiled languages.  This allows me to see what I am doing as I am doing it.  Some would say this is hacking with no design documentation and just winging it.  Others would use the analogy of a painter and the canvas where you are seeing tangible results in real-time as you are painting just like in the real world and not in our make belief software world.  Or even if I had a design document and was following Agile methods, this to me gives immediate verifiable results as you are seeing it on the screen, again in real-time.  This whole notion of dynamic programming and the semantic meaning I have for it will be a future topic.
 
I could take the sample above much further and in fact, if you download IronPython you can follow the tutorial which this snippet is from, plus load up XAML, build event handlers and hook them all up to produce a real working live application with a handful more lines of code.  As tutorial states, IronPython provides a very easy way to develop live application in a dynamic and exploratory way.  That is what has me very excited about this dynamic programming language on the .NET platform.
 
.NET 2.0 Framework Class Library has roughly 29,000 types in it.  Plus, as I have written elsewhere in this site on software industrialization, there are tens of thousands more COM dlls and other .NET dlls that have been written.  My point is that though IronPython any of these types can be imported and used dynamically in any application you may be building, particularly if you are predisposed to performing programming in a dynamic and exploratory way.
 
How to so this?  In my post on Software Industrialization using .NET Reflector and IronPython, I suggested building a Smalltalk like System Browser with and IronPython interpreter built into it.  While Lutz Roeders .NET Reflector product is excellent and highly recommended, for me, it is difficult to use from a tree view perspective.  I much prefer Smalltalks System Browser approach plus I can work with types in fewer mouse clicks.  Finally, I can embed the IronPython interpreter in the code window so I can work with the types that I am exploring and later as we will see, add my own types on the fly that are subclasses or extensions or glue code to all of the other types that I have loaded.
 
First things first.  How do I get type information?  There are several excellent articles on .NET Reflection and the best one summarizes it here.  The first thing is to write a wee bit of IronPython code to find the types in any given assembly.  Here we are going to get the types out of mapack.dll
 
IronPython 1.0.2280
Copyright (c) Microsoft Corporation. All rights reserved.
>>> from System.Reflection import *
>>> a = Assembly.LoadFrom("mapack.dll")
>>> Types = a.GetTypes()
>>> for Type in Types:
...       print Type
...
Mapack.CholeskyDecomposition
Mapack.EigenvalueDecomposition
Mapack.LuDecomposition
Mapack.Matrix
Mapack.QrDecomposition
Mapack.SingularValueDecomposition
>>>
 
Easy enough.  Next post in this series is to build a Windows App (in IronPython of course) that starts to take on the shape of a Smalltalk System Browser so we can start reflecting types for possible inclusion for the apps we are building.
Saturday, May 27, 2006 8:16:22 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]
 Friday, May 26, 2006