Python Programming, news on the Voidspace Python Projects and all things techie.
PyPy and .NET
The big news in the PyPy world of course, is that they have just released version 1.0. This includes a very powerful, only partially working (so far), JIT compiler. What is most incredible, is that the JIT compiler is compiled 'dynamically' for the front-end language spec. That means any interpreter written in RPython!
When trying to understand what PyPy is useful for, I've found this explanation (by Chris Lattner) helpful:
pypy provides infrastructure for building interpreters in [r]python. This infrastructure makes it much easier than starting from scratch, e.g. by providing reusable components for language runtimes (like GC's).
GenCLI takes RPython applications, and turns them into native (IL - CLR bytecode) .NET executables.
The code GenCLI produces is slightly slower than C#, but massively faster than Python or IronPython (tested with Martin Richard's Benchmark) :
|Language||Speed (average time per iteration)|
|pypy-cli richards.py (built-in)||5952.501|
This is interesting to us at Resolver, because we have some C#, and may also be interested in performance optimisations for some of our core classes. The option of writing in RPython rather than C# is an attractive one!
There are a few problems with this (i.e. it can't currently be done):
- GenCLI generates executables rather than class libraries
- The classes it generates have their attributes name mangled
- All attributes and methods are public
- GenCLI expects a single entry point (for applications), for class libraries it would need to support multiple entry points (with a way to express this in RPython, including the types of their arguments)
- No support for custom .NET attributes (the main reason we currently write C# by hand)
- Only limited support for accessing .NET libraries
The main developer of GenCLI is Antonio Cuni, who will be continuing the development as part of his Phd thesis. At least partly because of the interest from us, he will be looking at working on the changes necessary to make RPython a useful (and fast!) .NET development language.
|||You can read more about the CLI backend in their EU report: High Level backends, which is pretty readable as these things go.|
Microsoft Take Security Seriously
It looks like Microsoft are finally taking security seriously. This knowledgebase article explains the new password policy:
Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords. Please type a different password. Type a password that meets these requirements in both text boxes.
Some Interesting Things
A few random oddments:
Jim Stroud (who blogs about the recruiting industry), decides to use my Python specific search engine (Python Search) to hunt for Python programmers.
A new (fun) website values Pythonutils at around $106 000.
They must be crazy, but it is well past time for an updated Pythonutils release. I'll see if I can get round to it this weekend. (Thanks to Nicola Larosa for the link; Nicola is also co-author on two of the modules in the Pythonutils package.)
These are pictures from the student conference in Krakow I spoke at last month.
In two weeks time Andrzej and I speak on IronPython & Windows Forms at the RuPy conference. Jan Szumiec (who worked as an intern at Resolver last summer, and has worked here on and off since) is also doing a talk on DSLs in Ruby.
Armin Rigo will also be doing a talk on PyPy. As it has just gone '1.0', and I missed the PyCon talk, I'm really looking forward to his talk.
Perl 6, Python on Parrot & Virtual Machines
As development of Python 3 started to change from mirage to concrete, Guido declared that Python 3 wasn't going to be 'another Perl 6'. In other words, Python 3 is not a new language, and it isn't a complete rewrite.
Perl 6, is a complete rewrite, and by my understanding is a very different creature from its predecessors. This isn't automatically a bad thing of course, but it is a massive amount of work, and means that the result faces a bigger barrier to adoption amongst the faithful.
It may not surprise you to hear that I don't closely follow news in the world of Perl. I do however keep half an ear out for all news in the programming cosmos. Perl can fairly be described as the language that popularised dynamic languages , and a few years ago was probably the most 'popular' language of discerning hackers. It does surprise me that I don't hear more about Perl 6.
What I do hear about from time to time, is progress on the Parrot virtual machine. Parrot is a general purpose VM, capable of hosting many different languages, but mainly motivated in order to support Perl 6. Alongside Parrot are two other implementations of Perl 6, a 'slow but mainly complete' implementation in Haskell (Pugs), and one built on top of Perl 5.
Parrot development nearly stalled after a (the?) lead developer quit, but progress seems to have ramped up recently. There is a huge number of different languages being built on top of it, but the development of Python on Parrot seemed to have died quite a time ago. What caught my eye was part of the release notes for Parrot 0.4.10 :
- New language: Pynie - a Python compiler for Parrot
Pynie seems to be at a much earlier stage than previous attempts, but at least it is still being developed.
I doubt I will ever need to use it, but still interesting. I am interested in virtual machines, as some day I would like to experiment with language design. A while ago I stumbled across HLVM  which looked very interesting, but after the initial release little seemed to happen.
Whilst writing this entry, I discovered this announcement :
Chris Lattner and I had a recent discussion about merging the HLVM and LLVM projects. We agreed in principle and the merging of the two projects will now commence.
After the merging of the two projects, HLVM will be a sub-project of LLVM (like llvm-gcc, llvm-java, llvm-tv, etc.) with its own SVN repository module. Its purpose is to provide the necessary tool kits (mainly a pluggable Abstract Syntax Tree) to make it easy to create front end languages that target LLVM. It also aims to abstract out common things that all front end language compilers (e.g. a compiler driver, common AST nodes, translation of AST to LLVM IR, etc.). It is our anticipation that HLVM will become the predominant tool kit for building compilers that target the LLVM IR and its optimization and code generation facilities.
|||No, VB doesn't count.|
|||Based on LLVM which is used by PyPy.|
Simplicity or Power? User Interface Design
A recent article on application usability by Sean McGrath struck me as interesting.
I still have in mind a desktop application that I'd like to write, once I've reclaimed my spare time from 'the book'. Sean's article talks about the best applications finding the middle ground between power (configurability) and ease of use.
User interface design is something that I've learned about from Resolver (it's not hard to learn when you start from nothing!). As usual I blame Andrzej for some of the most memorable sound bites about UI design, him and the ever increasing seductive brushes with Apple Macs that I seem to have been subjected to recently.
The old adage about the difference between Windows and Linux goes: Windows makes simple things easy and difficult things impossible, whereas Linux makes everything difficult. Unfortunately there is probably still some truth to this. This is also exemplified in the open source world, where applications that are completely configurable attract a devoted following whilst remaining utterly unusable to the unenlightened masses.
Sean argues that the best applications tread the middle ground between simplicity and power . You ought to be able to start using an application without having to delve into the source code, but they should also be flexible enough to tailor for different needs within the same problem domain.
The touchstone I've learned for UI design, is intuitiveness. This is obvious I guess, but it is easy to forget as you add new features. For every element in the user interface, take a step back and ask 'is it obvious what it is for'. The native GUI elements that users are faced with every day, including the icons used for common tasks, means that you can provide an interface that users intuitively understand; even for new tasks and programs.
If you feel the need to add a tooltip to an icon to explain its purpose, then it isn't obvious enough. User preferences can be a sign that a feature hasn't been thought through carefully enough and a developer decision has been abdicated . These are all simple principles, but designing an interface with intuitiveness as the yardstick for every decision means that your program is much more likely to be used (even without attaining perfection). There is no problem with adding layers of complexity and configurability, but the same principles hold true for every 'layer'. They also apply to designing the API of your scripting interface, and in some ways the questions about 'intuitiveness' when designing an API are analogous to the decisions faced in designing a user interface.
Developers can create good software without needing to be 'designers', and no sane program provides Lisp as a user interface.
All I need now is the opportunity to practise what I preach...
|||Although some of the best just do one job, and do it well. They're often the apps. or utilities that I really appreciate. For obvious reasons they tend to be smaller though.|
|||An idea popularised by Joel Spolsky.|
Categories: General Programming
IronPython in Action: Progress Report
Just a quick post to let you know how the book writing is going. Not too bad, I'm only half sick of it.
Actually so far it has been a great experience, despite being hard work and sapping all my spare time. Having my work professionally edited is definitely improving the quality of my writing. Still, ask me again in six months.
I've just finished chapter four. This is well behind where I should be, but I have a good list of excuses. It took almost a month to get the first chapter reviewed , and I had to cut about a third of the material from the Python tutorial (a subject I tend to be enthusiastic about).
It also took me a long time to get back into gear after the PyCon / Krakow break. Things are moving apace now though. Christian has even started work on his chapters.
Once I've finished chapter five, and revisited the first four of course, then there is a possibility that it will go into the Manning Early Access Program, so you might get to read it earlier than expected.
Whilst we're vaguely on the subject of Manning, they're looking to bring Quick Python up to date. If you have some writing experience and are interested in the task, then let me know and I'll put you in touch.
|||Learning my way round the Manning templates and systems.|
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.