a good book it is too) or F#:
I have created 7 questions, in different programming languages such as C#, F#, Ironpython, C++, Java and of course the well known and liked true or false. The questions are designed to give a number of points, where the maximum number of points given can be read in the text of the assignment. The rules are simple, the one with the highest score on points, will win. Points will be given for correctness and effort. An assignment might give 6 point, but if not entirely correct, it will be given some points for effort.
The winner gets Office 2007 Student version and gets to choose between two books ? Foundations of F# or IronPython in Action - and the runner-up gets the one that the winner did not choose.
This article will compare the latest incarnations of Ruby, with the latest in Python, Groovy, PHP, Lua, Perl and Java too, to have a comparison with a pre-compiled language. We will see, how scripting languages behave if applied to fractal geometry, more precisely an family Mandelbrot algorithm.As you can see, for this type of calculation IronPython comes out faster than Ruby, IronRuby and CPython.
Browsing on the net, I found a comparison very interesting but a bit dated, dates back more than two years ago. Since then things have changed and I took advantage to make an update, not including all of those languages but only for more known. This is an opportunity to compare Ruby and Python versions even in their Java and. NET, an intention that I had since long time.
These are the performance results obtained from an average of five runs, took after have executed some void attempts (I have not trusted the VM startup):
Language Time (in seconds) slower than java
Java 6 update 15 0,153
Lua 5.1.4 0,815 5x
Php 5.3.0 2,083 14x
Python 2.6.2 2,269 15x
Python 3.1.1 1,566 10x
Jython 2.5.0 2,850 19x
Jruby 1.3.1 2,466 16x
Groovy 1.6.3 6,491 42x
Ruby 1.9.1 p129 2,688 18x
Ruby 1.8.6 p368 6,863 45x
Ruby 1.8.6 p111 9,709 63x
IronRuby 0.9.0 6,038 39x
IronPython 2.0.2 0,978 6x
Perl 5.10.0 2,722 18x
I have recently been wondering about how to build a generic system for parsing and processing lots of EDI messages in such a way that a minimum of work is needed when a new message type is to be processed by the system. The syntactic format of EDI messages is fairly consistent, but the semantics of particular fields are open for interpretation. Thus, I thought it should be possibly to write a general parser for turning a message into a tree structure (much like an abstract syntax tree for “the EDI language”) which would be appropriate as input to the processing phase of the system.main project page has more details - but in Japanese.
Having recently picked up “IronPython in Action” I decided to apply IronPython to the task. Since this was only an experiment, I decided to somewhat give up the idea of a tree structure and instead leverage the dynamic programming capabilities of IronPython. Given an EDI message at runtime I wanted to generate an object with properties corresponding to the segments, subsegments and elements of the message.
Silverlight rather oddly lacks a double click event. You can detect single click, but for double clicking you're on your own. I found some examples for C#, but none for IronPython and had, a few months ago, ported some code I found for IronPython.
I've been using it in application development and user testing for about 6 months and it works fairly well in both Silverlight 2 and 3, although YMMV.