This post was provoked by fears that following
the acquisition of Novell by Attachmate the Mono project faces an uncertain future. I've documented my thoughts on the Java/C# schism and what it might mean for my attempts to get my own Python modules working in these environments.
Mono is an open source project that implements C# and the supporting .Net framework allowing this language to be used on platforms other than Microsoft's Windows operating systems.
The schism between C# and Java is (was?) very harmful in my opinion and represents a huge failure of the technology industry back in the 1990s when the key commercial players were unable or unwilling to reach an agreement over Java and Microsoft redirected their efforts to developing C#. (Just imagine where we would be if the C language had suffered the same fate!)
Since then, Java programmers have smugly assumed that their code would always work on a wider variety of platforms and represented the more "open" choice. I always felt that Mono did just enough to enable the C# community to retain its credibility even though it would be hard to argue that it was a more open choice, especially given the absence of any standard in versions 3 and 4 of the language. However, Oracle's acquisition of Sun has created a sense of uncertainty in the Java community too.
In both cases it seems natural to use the word 'community' because programming languages do tend to foster a community of users who interact and share knowledge. In the case of open source communities they also share code by contributing to the frameworks that support the language's users. This latter point is critical to me, the Java community goes way beyond the core framework. Java without the work of the Apache foundation would be significantly less useful for programming web applications.
That said, there is a new community of Java developers emerging because of its use on the Android mobile platform. This programming community may share the same syntax but could easily become quite distinct. In some ways it is a return to Java's roots. Java was invented as a language for embedded devices where the types of programming errors C/C++ developers were making could be fatal. The sandbox was a key part of this, ensuring a higher level of security for the system and protecting it from rogue applications. These are just the qualities you need on a mobile phone or consumer electronics device where the cost of bricking your customers' favourite toys is an expensive repair and replace programme. C# is also in this space, in this recent article on
The Death of Mono notice that the knight in shining armour is driven by a mobile-based business case.
So if you want to use C# and .Net to develop web applications it seems to me that you are better sticking with Microsoft's technology stack and playing in that community because running your code on other platforms is likely to get harder, not easier. And so the Java/C# schism lives on in the web app world.
Python and the Java/C# Schism
Given that the C# and Java communities seem to be a playing out an
each to their own strategy it got me wondering about the Python community and how IronPython and Jython fit in. Python started out as a scripting language implemented in C/C++. There is typically no virtual machine or sandbox, it is just a pleasant and convenient way to spend a few days writing programs that you would have previously wasted years of your life trying to implement in C++. The Python framework is a blend of modules written purely in Python with some bare-to-the-metal modules that wrap underlying C++ code.
Given that both Java and C# provide C/C++ like environments with the added safety of a sandbox and garbage collection, implementing Python on these platforms was a logical step and Jython (Python on Java) and IronPython (Python on C#) have even caused the word CPython to enter the vocabulary as the original Python interpreter.
In an earlier blog post I described my first steps with IronPython and described how previous attempts to implement PyAssess and my QTI migration tool had failed on Jython. With hindsight, I shouldn't be too surprised to see that the IronPython developers have made the same decisions and that my code fails on IronPython for the same reasons it fails on Jython. The technical issue I'm having is
described in this discussion thread, which raises concerns of a schism in the Python community itself!
Actually, the trajectory of CPython towards Python 3 should solve this problem and Jython, IronPython and CPython should converge again on the unicode vs string issue, though when that will be is anyone's guess because Python 3 is not backwards compatible. Not only will code need to be reviewed and, in some cases, rewritten but the conversion process will effectively fork most projects into separate source trees which will make maintenance tricky.
As with the Java and C# communities, the framework is just as important as the language and probably more so in defining the community. Even if the basic language converges on the three platforms it seems likely that the C#/Java schism will mean that most projects for IronPython will exist as a more pleasant and convenient way of implementing a C#/.Net project rather than as a target platform for cross-platform projects. For example, Python frameworks like wxPython (a GUI toolkit for desktop apps) rely on the commonality of an underlying framework (the C++ wxWindows) so are unlikely to emerge while the Java/C# schism remains.
