Python Programming, news on the Voidspace Python Projects and all things techie.
What Fujitsu-Siemens Think 'Customer Service' Means
Executive summary: don't buy a Fujitsu-Siemens laptop if you anticipate the possibility of ever having to use the warranty. In January 2007 I bought an Amilo Pa1510 laptop to replace an ageing IBM Thinkpad T30 - a move that was a mistake in any case as the Thinkpad was the better machine...
After about six months the DVD drive started to fall out of the laptop. As it always worked fine when slotted back in I wasn't too worried. Soon after that I switched to a Macbook Pro anyway and the Amilo became my wife's laptop. As she didn't use the CD drive it wasn't a problem - until December when I was away and the drive now doesn't work at all.
Straight after that we moved house, and I finally contacted the Fujitsu help desk on January 22nd, which turned out to be two days after the one year 'limited warranty' expired. The 'customer service' man on the phone told me I would have to write in. Which I duly did. On the 3rd of March I received a reply to my letter of the 24th of January. Here is the salient part of the reply from Sue Young on their 'help' desk:
I do occasionally hear from customers who like yourself are outside the warranty period - be it a day, a week a month or even longer - and have experienced a failure that they would like us to fix free of charge. We would dearly like to assist these customers as we are no unsympathetic (sic) but as a business we have to question the practicality of this.
They may not be unsympathetic, but they are bloody useless. The laptop failed in a serious way inside the warranty period, but I reported it two days late and they refuse to honour the warranty. I wrote another letter surprised that they didn't feel a moral obligation to repair their failed laptop and reminding them of the UK consumer law. It ended:
As I'm sure you can understand, for an item that cost so much I can't let Fujitsu get away without living up to its obligations. I will be eagerly awaiting your response and documenting this conversation on my blog. I have to say that so far I am disappointed with the level of 'customer service' offered and couldn't recommend in good faith anyone purchasing a Fujitsu Siemens laptop if this apparently simple problem can't be resolved.
I will be taking this up with Dabs.com, where I bought the laptop from. In the past I have found their customer service very good but have never had to resolve a problem like this with them.
Report from the ACCU Conference
I've just returned from the ACCU Conference in Oxford. This is an annual occurrence, which started as a C/C++ conference but in recent years has had a thriving dynamic languages track (this year the 'flavour-de-jour' was functional programming). Last year Mark Shuttleworth was one of the keynote speakers, and the year before that the eminent Guido Van Rossum - so after my talk was accepted I was expecting quite an academic and 'high powered' conference (in other words I was very nervous about speaking there and didn't know what to expect).
Of course in reality it turns out that although they do have some very good speakers, it really is a community organised event with some fun and down to earth people. One thing that was a real challenge to my mindset was to spend a bit of time with a genuinely intelligent person (Dirk Griffioen) who chooses to program in C++.
First things first, my talk went very well. I was speaking for an hour and a half on IronPython and Dynamic Languages on .NET. I had a good audience (around fifty people I guesstimate) who were very responsive and asked a lot of questions. About half were .NET programmers and half Python programmers. They seemed to like Resolver One , and were impressed by first class functions and decorators in Python. For those who attended, or are just interested, here are some links:
- ACCU 2008 Talk Slides: IronPython and Dynamic Languages in .NET
- IronPython in Action Homepage
- Embedding IronPython 2 in .NET Applications: Examples with Downloads
- IronPython and Silverlight 2 Articles and Examples
- IronPython Articles
- The IronPython Cookbook
My favourite part of the talk was my deliberately provocative statement on static typing:
In statically typed languages, it turns out that a significant proportion of language 'infrastructure' (boiler-plate) is there for the sake of the compiler rather than the programmer.
In C# this includes delegates, interfaces, generics and type declarations which are all obsoleted by a dynamic type system.
Fortunately this was taken with a smile by most people there.
The Thursday keynote was by Simon Peyton-Jones, the creator of the GHC Haskell Compiler. The keynote was on controlling side effects in programming (Caging the Effects Monster.). He wasn't just advocating pure functional programming languages, but was encouraging developers to change their programming habits. He did a great job of explaining how to do this, but whilst he mentioned parallelism I didn't feel he explained why very clearly.
This was followed by Joe Armstrong talking about Erlang and then Simon doing a three hour tutorial session on Haskell - I spent the whole day learning about functional programming! Simon's examples were using Haskell for shell scripting (!) and the xmonad window manager - he was very much touting Haskell as a general purpose programming language. He demonstrated using Monads for IO and was easy to follow (although by the end of three hours my brain was starting to hurt). I've promoted Haskell higher up the list of languages I would like to learn (and a Resolver developer, Kamil Dworakowski, has just started a new blog on Developing an Application with Haskell).
One of Simon's early examples in his tutorial was writing a Haskell function to traverse a graph of silicon atoms to find neighbours (the 'n-shell'). The function was fantastically simple, but was exponential. Simon commented that this could be solved by using memoize. Inspired by this, in my talk I showed how easy it was to write a memoize decorator in a few lines of Python (here is a better implementation).
Whilst chatting to Dirk, he tried to convince me that memory allocation in C++ is simple these days, and that most people who have had painful experiences of C++'s complexity are remembering an older C++ which is now much improved. Unfortunately the Friday keynote, by Andrei Alexandrescu (a C++ expert and a collaborator in the specification of version 2.0 of the D Programming Language), did much to convince me of the opposite. This was an hour and a half of examining, in detail, the terrible problems of trying to implement general purpose identity (lambda x: x in Python for all cases), min and max functions in both the current standard of C++ and C++ 0x (the forthcoming standard) . This includes dealing with rvalues, lvalues, passing and returning arrays, consts and non const values. What a lot of awful, terrible, unnecessary complexity.
I also got a chance to demonstrate Resolver One to Simon Peyton-Jones, who was particularly impressed with the fact that cell ranges are iterable. This means that you can have formulae like =SUM(val for val in A1:D8 if val > 10), or use the filter function with a lambda predicate and a cell range: =SUM(filter(lambda x -> x > 10, A1:D8)) . He says he has been trying to get features like this into Excel for years.
|||Don't forget it is free to download and try, and free to use for non-commercial purposes.|
|||Even at the end of Andrei's presentation of the identity function - which he said took virtually a day to work out - someone in the audience pointed out a corner case it couldn't handle.|
|||Because the : is used for cell ranges in the Resolver One formula language, lambdas (and dictionaries) use the little arrow instead: ->.|
Resolver One Quant and the Credit Cooperatif
Two pieces of good news for Resolver Systems.
Firstly we have a big corporate customer. This is great news for us. As a small company, even with a fantastic and revolutionary product, some companies are reluctant to invest their IT effort (money is rarely the issue) unless they are confident we aren't going to disappear in a year's time. With some big customers under our belt this becomes less of an issue. Of course it also nice to see Resolver One being used!
Today Resolver Systems announces the signature of its first French corporate client for Resolver One: Credit Cooperatif (Groupe Natixis/Banques Populaires). Resolver One provides Credit Cooperatif with a Rapid Application Development tool for analysing and presenting business data using a familiar spreadsheet interface. Resolver One integrates databases, code and IT-developed components to create powerful and easy-to-use solutions - all using your existing knowledge of spreadsheets.
Louis Jaouan, Director of Financial Risk at Credit Cooperatif commented:
"In the Financial Risk department, in order to rapidly respond to new needs, we have to write a number of tools ourselves, to access different sources of information and manipulate them, all without having to go to our IT department. We use Excel and VBA, but we prefer Python for its combination of simplicity and power. We were looking to better link spreadsheets with Python programming, and Resolver One seemed to be the most elegant solution because it was based on Python but also gave us compatibility with our IT team's architectural choice of Microsoft .NET.
We had been looking at using IronPython for a year but were hesitant to take the first step until we saw the elegant and secure environment provided by Resolver One. I signed up as a beta user as soon as I learned of its existence. Its original conception is intellectually elegant and even though we so far use only a fraction of its capabilities, we have already witnessed a significant increase in the speed at which we deploy new control tools."
The second piece of news is probably more interesting. Resolver Systems has a new partnership with a French firm called Zeliade Systems. Together we have produced a new product called Resolver One Quant. This combines the powerful Zeliade analytics library with Resolver One as a front end for traders:
Resolver One Quant is an advanced tool for calibrating and pricing portfolios of complex derivative products. Its large database of structured products and models allows traders to get started straight away, and quants can easily and quickly add new products with the powerful Python programming language.
Based on the Resolver One spreadsheet engine and Zeliade Systems' outstanding analytics, it works out of the box on computers where the Bloomberg desktop is installed. A flexible mapping system allows Resolver One Quant to connect to in-house reference data or trade databases.
The Zeliade package contains various complicated algorithms used for complex equity and derivative trading. We are also working on hooking up Resolver One to the grid computing libraries they use. The guys at Zeliade really like Resolver One and have really been stretching it as they integrate it with their systems.
Last week I was experimenting with trying to port Resolver One to IronPython 2. IronPython 2 is still in beta, and it doesn't yet support static compilation (which we use to create binary distributions), so we can't yet use it for our 'production version'. The porting experiment is so that we can pick up any potential problems early and give feedback to the IronPython team. As IronPython 2 now supports multiple engines starting the port was pretty straightforward, once I had worked out the basics of the new API anyway. It uncovered a couple of minor bugs in IP 2, which the team are working on fixing, and some mysterious problems that I haven't yet managed to diagnose and could either be problems with Resolver One or IronPython 2.
Switching to IronPython 2 will give us a few advantages. Firstly IronPython 2 is Python 2.5 rather than 2.4, so we get all the Python 2.5 goodness both for user code and our codebase. A lot of bugfixes have gone into IP 2 that haven't (or can't) be backported to IP 1, and Dino is working on some fantastic performance improvements for IP 2 that are either in already or will be available very soon. This includes key areas like dictionary performance.
Perhaps more interestingly, because IronPython 2 is built on the Dynamic Language Runtime (and creating engines for different languages is trivially easy) it would be very little work for us to allow Resolver One user code to be written in Ruby or any DLR language! Currently IronRuby doesn't interoperate well with other DLR languages. Their first priority is to get a good Ruby implementation (which means being able to run Rails well), but interoperability is their next priority.
Oh, we also have a job opening for a PR and Marketing Assistant. I realise that this is unlikely to appeal to my regular readers, but you never know.
Python Fans Take Aim at the Enterprise
Python is already a mature technology -- and ready for its close-up in the enterprise.
Dangoor noted that early on in TurboGears' days, he heard from PHP programmers that were looking for more structure. [...] Python uses namespaces heavily, and PHP is just now getting namespaces.
Python lowers the bar to the point where it's possible for the users to tweak their own software
The source code is easy to understand, the basic tools are all free, and there's no arcane build process to go through.
Python doesn't have a huge marketing machine behind it [...] We use grass-roots methods, word of mouth. Python is not a fad, and there are no gimmicks.
Any competent programmer can easily learn Python and be productive within a few hours or days at most. 
Python has reached a critical mass of adoption within the past few years
The good news for Python programmers is that demand seems to be exceeding supply, but that will correct itself with time
While Python can stand on its own merits, Foord noted that particularly important for Python adoption is the fact that both Jython (Python on the Java VM) and IronPython (Python on .NET) are now both in a good state.
This means that where the standard technologies are built on Java and .NET, Python is still a viable choice of programming language
|||This really has been our experience at Resolver Systems. When we hire, Python experience is never an issue. In fact, I was the fourth developer at Resolver, and the first one with any Python experience.|
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.