EclipseFP: first timid step towards live programming

The title is sensationalist. All I've done is tweak a bit how we interface between GHCi and the Eclipse debugging framework. What that allows now (in the development version of EclipseFP) is to have expressions (in the Debug Expressions View) evaluated even if you're not stopped at a breakpoint.
So when you work directly in GHCi, you type in expressions to check the results. But when you change some code and hit :reload, your bindings are lost, you need to retype the expressions. EclipseFP does all that for you.

I've posted a video of a simple session in action on YouTube. It's my first video ever! It just shows a trivial arithmetic function being changed and how the result refreshes as soon as you select back the running program in the Debug view. Best viewed large...

EclipseFP 2.3.2 released

I decided to release a new version of EclipseFP, 2.3.2. There also new versions of buildwrapper (0.6.2) and scion-browser (0.2.11) on hackage, even though they are not strictly required (but they compile under GHC 7.6).
This new minor releases offers some bug fixes and performance improvements. Hopefully the installation has been made easier (it is possible to install all helper executables from one place). The debugging mode has also been enhanced, with GHCi history support and the possibility to select expressions in the source code and add them to the Expressions view or see their current value in a popup (when stopped at a breakpoint).

As usual, just point your Eclipse to http://eclipsefp.sf.net/updates. The full release notes can be found here.

Thanks to all the users, bug reporters and contributors!

Happy Haskell Hacking!!

OpenAlchemist: the start of an AI in Haskell

Lately I've been quite addicted to OpenAlchemist, a Tetris-like game developed by I think a couple of French developers (cocorico!). The code is in C++, there doesn't seem to be a clear API to integrate with the engine, the forums are closed, but I still wanted to write an AI for the game..

So I've written a little something in Haskell and posted it on Github just in case it's of interest to somebody. I basically use the Win32 API to capture the game window and save it as a BMP, then I use the bmp library to open the BMP, and some home grown image recognition to see which shapes are displayed on the screen. Then comes the "easy" part, checking the possible combinations and seeing which one yields the higher score. So far the AI hasn't beaten my own high score, so there's still work to do!

I'm still struggling with shape recognition sometimes, so this is an area that needs an improvement. I probably need to read up a bit on the proper algorithms that people have found to do this kind of things instead of just writing my own, but hey, one needs to have fun!

Using GHCi History in the EclipseFP Debugger

I've been asked if the EclipseFP debugger could provide stack traces. Links to great presentations about the subject were even presented! Simon Marlow's explanation of what can be done now regarding stack traces was great, but doesn't solve my problem: the debugging session in EclipseFP uses the GHCi debugger, basically sending GHCi commands and parsing the ouput, and Simon's new solutions require -prof flags, and hence don't work with GHCi.
For the time being I've done something that is not stack traces, but can provide some context when debugging, using the GHCi history. If when invoking a function in GHCi function, you start with :trace, then the :hist command gives you the last 50 evaluation steps. EclipseFP now calls :hist automatically on reaching a breakpoint and parses its output. It represents them as stack frames in the debug view, even that's not what they are. This way, clicking on them opens and select the relevant code, so hopefully you can get an idea of where you are and what you code is doing.
A screenshot showing the history on the program given as an example in the debugging article of the Monad Reader (PDF warning!):

This will be part of the EclipseFP 2.3.2 release, hopefully this will be helpful to some.

Making working from home an attractive option for developers (and their employers)

Warning! This is not a technical post about EclipseFP or Haskell in particular, but rather some ramblings...

I’m a software programmer. I work mainly from home. I love it. But I’m aware that very few job postings offer the possibility to work remotely, and that if ever I have or want to change jobs, I will need to move somewhere else, where there’s a decent job market, to be able to work.

Now, I suppose it’s easy for me to work from home, for a variety of reasons:

•           I have been working on the same project for a few years with success, so my management can trust me to do the work well;
•           I manage a small team of people I’ve known for a long time and that have worked, like me, for years on the project, so instant messaging, emails, a few phone calls and the occasional meeting in person is sufficient interaction: they know what I expect from them, and for better or worse work mainly in their comfort zone;
•           I work in a company that has grown mainly by acquisitions so has development centers all over the globe, in which taking time zones into account for meetings is natural, for example;
•           I like to think of myself as self-motivated, organized and committed, so I don’t need somebody behind my back telling me to work harder ;
•           I enjoy the technical work so I don’t want to be promoted to a management only role, where office politics and being physically close to the movers and shakers of the company matter.

A few of these reasons are specific to me and my situation, but it seems that generally speaking, a few factors could be seen as promoting working from home:

•           The technology is here. At least in the western world, most houses have fast internet access. We have email, instant messaging, phone and video over the internet. We have distributed source control management. We have web interfaces for most tools we may use. We have cloud computing and virtualization so you can log into a remote machine and work on it as if it were local.
•           With the wave of outsourcing, managers should be used to have remote workers, even in different time zones. Of course there was a backlash against outsourcing, but I think the bad experiences with it were more down to the unreasonable expectations (pay less money, get more work done) than to the actual distance between managers and workers.
•           Companies may want to be seen as environment friendly. Encouraging people to commute and/or move to big cities is not a good thing in that regard. I barely use the car during the week now that I can work in my slippers.

Of course I’m well aware of all the objections a company can raise.

•           How could I pay a good salary to somebody I don’t see? But are you only judging the value of an employee by the number of hours she puts in? The end result, working code in a shipping product, can be evaluated the same.
•           How can I build a team spirit if nobody is in the same room? Well, we’re talking computer programmers here. Of course social interactions are good (and I get plenty of that in my personal life, thank you), but I strive on writing good code, making a successful product, and feeling I can satisfy customers and win new ones. I don’t need to be in the same office as the sales people to have that motivation. Meeting the people in the office from time to time is of course OK, the cost of travel and some hotel nights is nothing compared to the office lease and fuel savings.
•           How safe is my code going to be if programmers log on from any kind of location? Well, it happens that I have to travel (to a customer, to another office) so the problem is there even if your employees are not traveling remotely most of the time. Use efficient security procedures (the ones that don’t get in the way of getting work done so that people don’t get so fed up with them that they try to bypass them at all costs) and encrypted connections, I suppose…
•           How do I train my new or junior staff? That is a real issue. If somebody needs to be hand-held to get started, it won’t be doable remotely. So you may want to organize a few face to face sessions between new recruits and senior employees at the beginning. But when hiring experienced developers, this should not be an issue. Your code and your processes are well documented, right?

What more can we do to encourage companies to offer home working? Do we just need higher fuel prices to that employees cannot afford commuting? I hope we can be a bit more proactive. Can more technology help? Do we need more tools?

•           Integrating IDEs with communication tools so that communicating over live code is easier
•           Helping distributed design sessions using things like touch screens and motion capture sensors to better communicate the hand gestures that sometimes help conveying ideas better than word (but on the contrary, I sometimes feel that having to put down an idea in word helps it make clearer, and a trace of that thought can be kept)

Or do we have the tools and just need to get used to them?  Or is it just a shift in employee-employer relationship that may happen slowly and can’t be rushed? In this case, we need to push more stories like 37Signals, about how successful software companies are hiring remote employees and loving it!