In praise of the polyglot

2007/04/24

If you’ve ever envied the ability of multilingual friends to bridge language gaps wherever they travel or gained new appreciation for your native language by learning a new one, then you can probably see the advantage of being a programming language polyglot. Developer polyglots travel the IT world more freely than do monolinguists (sure that they can apply their skills in any environment), and they also tend to better appreciate the programming language called home, because among other things they know the roots from which that home is sprung. Isn’t it time you became a polyglot?

From http://www-128.ibm.com/developerworks/library/j-ruby/?ca=dgr-jw22RubyOffRails

I certainly feel like it which explains the recent ruby-esque and rail-ish diversions :-). To compensate the high level coding in Ruby, Objective C as next will bring me back down to the metal, I mean Core 🙂

Advertisements

Managing knowledge portfolio

2007/03/25

There are few technical books which you enjoy first time you read them, remember the experience and keep coming back. One of such classic books is The Pragmatic Programmer – from journeyman to master – by David Thomas and Andrew Hunt. If you have not read it, get it, it is worth every cent. Since the book was written – ages ago, back in 2000 – it did not loose anything of its freshness and value – which one cannot say about most of technical books written earlier than 2-3 years ago. Inspired by the success of their initial creation, Dave and Andrew started the website and continued writing whole Pragmatic Programmer series of books.

Book contains 46 tips and explanations and the tip #5 deals with knowledge portfolio – one of developer’s main assets. Unfortunately it is expiring asset so you have to work hard to keep it recent and in good shape. Dave and Andy recommend using the same strategy as successful investors in finance markets:

  • invest regularly – even if small amounts, but create habit investing
  • diversify to embrace change and to widen the reach
  • manage risk – combine high-reward high-risk with low-reward low risk
  • buy low, sell high – try to identify future hits before they become popular
  • review and rebalance – what was true last year, can be different now

They also recommend few practical steps and goals how to achieve the healthy and well balanced portfolio, such as:

– learn new language every year
– read a technical book every quarter
– read nontechnical books too
– participate in local user groups
– experiment with different environments

Which got me thinking about how am doing wrt these suggestions. I guess I have no problem with “read a book” part, either technical or non-technical 🙂 – thanks to Safari I consume 1-2 technical books a month and thanks to e-books even more non-technical ones :-). What I have not done in about 3-4 years was learning a new language. I think I have not learned really new language since C# in 2002. One could argue that for Java programmer, C# is not really such a new language – in that case I have not really updated my language toolset since I started with Python back in 2000. That is terrible ! Obviously, some action is required – I am overdue at least with 4 new languages. Because it is highly impractical to tackle 4 problem at the same time, for this year I will be adding two.

But which programming languages ? Key here is the word pragmatic and the investment strategies above – more specifically, combining high and low risk, buying low and diversifying. I want to explore new territories, but stay away from esoteric and pure-research areas (e.g languages like Janus, Limbo or Concurrent Haskell :-)). After some research I picked two candidates: Ruby and Objective-C for the year 2007.

There are few reasons why exactly these two: they are both similar (with Smalltalk and functional programming/OO heritage) and opposite – one is multiplatform, interpreted, very high level, the other is (practically) single platform – OS-X language of choice, compiled and up to version 2.0 not even garbage-collector enabled. One has pretty clean and nice syntax, other is – well – simple, but quite ugly. And so on.

I have started with Ruby yesterday – found a good book on Safari and started to read and play with the code. I will get back to it when my head stops spinning – and after I get some non-trivial programs done to get some real life feeling of the language. From the book reading point of view, it is pretty amazing what I have found in few hours :-).

Btw, the version 1 of the Ruby boom by the same two authors is available online.


Avalon – reloaded …

2007/03/20

Now this is something really interesting: as found on Adobe Labs site, their technology codenamed Apollo is approaching Alpha status. What Apollo is – in a nutshell – is another virtual machine, similar to Java runtime or .Net framework, with few minor twists: it is multiplatform (as Java) as well as multi-language (as .Net) at the same time. Before flame wars start – I am aware that JVM is capable (more or less) to support multiple languages beyond Java and also that .Net is (more or less) capable running on  non-Windows platforms (e.g. Mono project), but that is not the point. The point is what is different about the Apollo compared to JVM or CLR.

First thing that is different is developers skill-set. Adobe is trying to leverage the experience of Web application developers and allow to use traditionally Web oriented technologies to create desktop applications: HTML, Flash, Javascript and PDF in context of desktop applications. The other is that Apollo is designed with notion of being “occasionally connected”, or in other words online/offline applications. It does support well the regime when you can work offline with local copy of the data and reconnect / synchronize with master copy on-line, providing both access to local resources (as traditional desktop application) as well as rich asynchronous XML capable communication library (as Web 2.0 application running in browser on the client).

Using Javascript/HTML for desktop-ish apps is not really an innovation. If you look on how the Firefox extensions are created, or on Widgets/Gadgets in Vista or OS-X you will see something very similar. The same idea was also implemented in Avalon – renamed to Windows Presentation Foundation – which uses XML to define the user interface and “scripting” that determines the logic. In WPF, you use the .Net languages to do “scripting” (Javascript being one of them) and you need a .Net 3.0 capable platform to run it (currently Windows XP SP2, Windows 2003 and Vista, unless I am mistaken). Even with similar language (Javascript), programming WPF is quite different and requires different skills from Web application programming. Allowing the use the Web app development skills and adding variety of Flash/Html/Javascript/Pdf combinations may be very appealing for somebody who needs to create desktop-like application without learning WPF. Plus the ability being platform-independent is added bonus and could be finaly a solution for a problem that Java did not really addressed well. It has been possible to create rich client Web-startable applications  for several years and yet, it has not become the mainstream. Possibly because of the complexity of creating Swing-UI applications in a first place ?

Compared to Firefox important point is that Apollo departs from browser while keeping the Web capabilities – such as rendering Web pages or creating mixed apps. Eliminating browser is important from security point of view. Installed runtime can give the Apollo application access to local machine resources such as local files without compromising security – as it would be in case of browser based applications. Access to local resources together with modern approach to remote connectivity is very interesting. The browsers are very much Web 1.0 with the request/response shaped vision of the world and adding the asynchronous capability in AJAX was one grandious hack … Another good reason why getting  rid of browser is simplicity of supporting one version of runtime versus making sure that you new great Web2 app works with wildly different Javascript/DOM capabilities of Internet Explorer 5, 6 and 7, Firefox 1.0, Safari, Opera, and so on …

The demonstration videos on Lynda.com show few interesting capabilities of new application types – follow the ‘Sample Apollo applications’ link and also here.

It is still Alpha so it is too early to get excited, we have no data about performance, resource requirements or real world application development experience. Positive is that both runtime as well as SDK should be free. And it is always good to have more options available 🙂


Scripting, repeatability and GUI

2007/02/26

Most programmers love GUI. It is so easy, so convenient, just point and click here, click there, drag and drop, repeat few times and problem solved. Who in sanemind would bother typing and writing code when can GUI do it all. The convenience rules. If you need to add or change something, it takes just few more clicks. Not a big deal, just add a few more easy steps. No problem – right ? Wrong !

What is wrong with this approach is that with few clicks after few clicks, the whole process becomes more and more complicated. It may need to be done differently, based on conditions. It may get different results if the order of clicking changes. If it needs to be done on more than single system, it start to be more like chore, than a shortcut. Something that needs to be done over and over is always very sensitive to human errors. And because the clicks do not leave audit trail, only the guy with the mouse in hand actually has any knowledge on what is going on. It is also very hard to keep the sequence of mouse clicks in CVS :-). And it is close to impossible to tell what was the difference between two series of clicks after they are done – one of which worked and one not.

To get repeatability, you need a process that starts and runs unattended, based on input parameters performs the task at hand. It can be either compiled program or script – but script is faster to create and easier to maintain. Therefore “scripting”. The script allows to be version controlled, contains explicit decisions and it is the minimal documentation of the task. Without script that starts from well-defined state at the beginning and properly handles all tasks / transformations, you will never know in which state you have ended.

Not all script were created equal. Many GUI tools allow you to perform tasks required and then generate scripts that (in theory) perform the same thing. This sounds like an ideal combination of both: you can keep using the GUI and by generating scripts, you keep trail of the changes for version control. Right ? Not quite, unfortunately.

The problem with generated scripts is, well, that they are generated and not written. They contain lots of repetitive information, many function arguments that are not really relevant to the task and no parameters. They are bad documentation because of the verbosity and can lead to problems with version control – small change in GUI setting may lead to very different script rendering.

Generated scripts *can* be used as started point to accelerate the initial steps, though. It is time consuming to start with empty file – but it is very often very educational and sobering experience. Generate first version of the script by tool, then developer takes over, changes the script structure, extracts parameters, re-factors repetitive steps to functions/procedures, adds comments. After this, the GUI should not be used as primary tool again, from that point on running the script should be the only way how to perform the task. If change is needed, edit the script and re-run it. This type of script is actually very useful: it is both documentation as well as tool, it can grow, evolve as the problem evolves and helps understand what is being done.

Typical area where this is extremely visible is database development. In Microsoft world, the Management Studio (former QA) is tool that allows do most of the configuration tasks via GUI. If also will generate the SQL for the task – but the SQL will not be as flexible as it should be: it may contain hardcoded references to database, it may not be complete (e.g. script will generate ALTER PROCEDURE which will fail if procedure does not exist, rather than test existence and drop if exist, then re-create). Formatting will depend on settings – e.g. you may or may not get the brackets around identifiers – which will make version control of such script an interesting exercise.

The GUI tools can be great help if they are used by skilled person who understand their power as well as their limitation and use the GUI to speed up development, but does not depend/rely on the GUI tool exclusively. It usually takes some experience to realize the GUI trap and develop skills/habits outside of the GUI tool. Therefore when looking for e.g. senior database developer, try to test him/her with simple repeatable task that requires working without or outside of the GUI. If he/she has problems writing scripts by hand, using command line tools and scripting in general, it is not a senior developer, regardless how many years of experience has on the resume.