Great news!  Mono has made it to .NET 3.0 support and this includes some of the latest stuff like LINQ expressions.

I am pleased to announce that Mono C# compiler (gmcs) has now full C# 3.0 support. Most of the features has been available since Mono 1.2.6 release. However, with the upcoming Mono 2.0 release we will also support complex LINQ expressions and mainly expression trees which is fairly overlooked new feature with a lot of potential.

For anyone interested in compiling and running this LukeH’s slightly extreme LINQ example I have good news. It compiles on Mono and it runs as fast as on .NET.

Sun has been on a rampage lately. They recently purchased MySQL (which has some questions with InnoDB) but they also are supporting Python and integrating it into the VM offerings with Jython.

So now we have Google (They employ Guido), Microsoft (IronPython) and Sun (Jython) all turning into Python-istas. Does this mean Python is destined for greatness in the near future? Well I recommend learning it. It is a great language and it has a high productivity rate. Time will tell if it has the ability to be in extremely large code bases. I think it is just a matter of the architecture and organization as with any project.

Jonathan Schwartz at Sun mentioned also taking the “J” out of “JVM” to just make a VM much like a .NET framework. So Microsoft copied Java with C# the JVM and added multiple languages. Then Sun comes back and added multiple byte code compiled languages. And then they both focus on dynamic engines to implement versions of Python, Microsoft doing this within their DLR.

Many times the larger market languages that end up running business or “enterprisey” are heavily influenced by companies, in addition to the other demands from consumers, which here is programmers. So when the big three are all banking on Python as a draw there is a definite market draw there and a tell on the future. But I think it is apparent that Python is becoming a standard market baseplane language.

It is great to be able to use other libraries from .net with IronPython and java libraries with Jython. It has found a way to integrate with the current infrastructure and the language has low bar entry but deep benefits. Python is snaking its way into the market.

Python is so non verbose…

import sys
import clr
from System.IO import Path, Directory, FileInfodir = Path.Combine(sys.prefix, 'DLLs')

if Directory.Exists(dir):
    sys.path.append(dir)
    files = Directory.GetFiles(dir)
    for file in files:
        if file.lower().endswith('.dll'):
            try:
                clr.AddReference(FileInfo(file).Name)
            except:
                pass

This sample is from IronPython showing adding dynamic references to all dlls loaded.

Check out this HTML/XHTML parser in pure Python.

from HTMLParser import HTMLParserclass MyHTMLParser(HTMLParser):
def handle_starttag(self, tag, attrs):
print "Encountered the beginning of a %s tag" % tag
def handle_endtag(self, tag):
print "Encountered the end of a %s tag" % tag


Code generation is not ORM (Object Relational Mapping). ORM is not code generation.

These are two separate ideas. ORM is part-of code generation but code generation is super to ORM.

I get in discussions with people that are strongly against ORM mostly due in part to Jeff Atwood’s post that ORM is vietnam. Yes it can be, and ORM is only for highly tailored teams and projects and creates bulk and uncontrollable code bases. BUT, code generation is valuable and here to stay.

Code generation can be a templating system that outputs code that exactly is the way you would write it and generate unit tests, db field mappings, basic skeletal architecture, maybe a data layer that accesses tables and views or any one of those things from a custom, open source, standard or commercial templating system.

Code generation can also be macros, db migration processes (SSPI or DTS or PL-SQL or n), adding a new file in yoru IDE (VS.NET/Eclipse/FD templates), configuration files, refactoring tools, and many other things. Code generation is a part of life for a programmer or engineer. In fact if you dont’ start getting a handle on the code generation systems that are evolving then you will be that much more without a solution when platforms advance.

Code generation can also be team building because many times people against code generation are hand coders. This is fine and this works great for one programmer. When you add programmer++ to any single team all of a sudden “styles” come into play. Code generation and basic framework or API code structures should be similar in a team environment so that others have a base layer of knowledge they can get up to speed on. Code generation brings the style battles and architecture to the forefront on how code should look in an organization. As you can imagine when you give 50 architects or developers the lead, you will get 50 different was of doing things, some good, some bad. Code generation ensures at least a basic structure of code and apis that can be used. Team integration is hard, code generation usually goes hand in hand with this if it is as small as new file templates in an IDE or a macro all the way to entire api framework generators.

It is important that code within the same project look and act the same. Same styles, same conventions, same architecture. One way of settling this is having code generation that everyone agree upon that can help at least structure projects the same, even if implementation and behind the API layer things are like the wild wild west.

Code Generation > ORM

Code Generation is usually guilty by association. We are hoping to change the perception, but again code generation is really only needed when you get beyond the single programmer mindset, or when you start to make a product family or open source.

Code Generation != ORM, Code Generation IS for the Code Generation