A Good Mix 6: Databases, the DLR and Programming Languages
Another selection of blog entries and articles on IronPython culled from the last few weeks.
I last reported on FBConsole in August 2007, when version 0.7.2 was released. FBConsole is a "Firebird RDBMS Tool Powered by IronPython" (a Python console for the Firebird database). This new release (via) is built with IronPython 2.0.
Another blog entry in Japanese. It is useful though as it shows you the ScriptRuntime configuration (app.config) needed for hosting both IronPython and IronRuby in a single application. Useful if you are using the DLR to provide user scripting and want to give your users a choice of languages to use.
Another update, with accompanying release, for the Cobra Programming Language. Cobra is a .NET programming language with both dynamic and static binding, a Python inspired syntax and first class support for unit tests and contracts. As usual there are language, library and documentation updates - including contributions from the community.
Keelkit describes itself as:
Jon Skeet is a well known .NET developer and author. He is also the Stack Overflow user with the highest reputation. In this blog entry he asks whether the new proliferation of programming languages is a land of polyglots or a tower of babel?
I last reported on FBConsole in August 2007, when version 0.7.2 was released. FBConsole is a "Firebird RDBMS Tool Powered by IronPython" (a Python console for the Firebird database). This new release (via) is built with IronPython 2.0.
Another blog entry in Japanese. It is useful though as it shows you the ScriptRuntime configuration (app.config) needed for hosting both IronPython and IronRuby in a single application. Useful if you are using the DLR to provide user scripting and want to give your users a choice of languages to use.
Another update, with accompanying release, for the Cobra Programming Language. Cobra is a .NET programming language with both dynamic and static binding, a Python inspired syntax and first class support for unit tests and contracts. As usual there are language, library and documentation updates - including contributions from the community.
Keelkit describes itself as:
KeelKit a domestic ORM tools, automatic generation Model, automatic generation of form, automatically generate unit test framework ,for automatic generation of language exchange with other Model, using the T DBHelper, strongly typed query! No language and database boundaries!Through the use of an add-on package Keelkit has IronPython support, including integration with IronPython Studio. The latest blog entry (in Chinese) has some of the details. It is available for download from the codeplex site.
Jon Skeet is a well known .NET developer and author. He is also the Stack Overflow user with the highest reputation. In this blog entry he asks whether the new proliferation of programming languages is a land of polyglots or a tower of babel?
What does this mean for the average developer? Currently, if you're writing a non-web application in .NET, you really only need to know a single language – and any of them will do. (Plus potentially SQL of course…) Compare this with web developers who have to be intimately familiar with HTML, CSS and JavaScript – and the differences between various implementations.
How long will it be before backend developers are expected to know a dynamic language, a static OO language and a functional language? Does the benefit of mixing several languages in a project worth the impedance mismatch and the increased skillset requirements? I'm not going to make any predictions on that front – I can certainly see the benefits of each of these approaches in certain situations. They've been designed to play well together, but there are bound to be limitations and oddities: times when you need to change how you write your F# so that it's easily callable from C#, for example.
Whether or not you learn multiple languages to a professional level is one thing, but becoming familiar with them is a different matter. In the course of co-authoring Functional Programming for the Real World (where "co-author" is a bit of a stretch title - I've played more of an editorial role really, with the added bonus of picking on Tomas whenever I felt he was perhaps a little harsh towards C#) I've learned to appreciate many of F#'s qualities, but I don't really know the language. If someone asked me to write a complete application in it (rather than just a toy experiment) I'd be reaching for books every other minute. I hope I'll learn more over the course of time, but I doubt that I'll ever be sufficiently experienced in it to put it on my CV. The same goes for IronPython, although I'm considerably more likely to need Python at work than I am F#. (Python is one of the three "approved" languages at Google, along with Java and C++.) None of this means that time spent in these languages is wasted: I'll be able to apply a lot of what I've learned about F# to my C# coding, even if it will make me pine for things like pattern matching and asynchronous workflows periodically.
Comments
Post a Comment