Thursday, 25 August 2016

Programming Language Timestamp, 10 years on

It's been ten years since I wrote my Programming Language Timestamp, a sort of time capsule of how I felt about the various programming languages I used, or used to use, at that moment in time.

Ten years is a long time, and I no longer write code professionally. So while a major theme of my 2006 article was making the transition from university—where I focused on intellectually interesting languages like Lisp and Prolog—to the working world, dominated by Java, the major themes in 2016 can be enumerated as follows:

  • I have a lot less time to program, between a non-technical day job and having kids
  • The languages I use have a lot more to do with what I'm comfortable with, than what I think is ideal.

So, without further ado, here are the languages I use now, in order. The reality is far from my ideals, but this is what life getting in the way looks like.

1. Perl. The Swiss Army Chainsaw is today far from the dominant scripting language it was when I learned it in high school. And rightly so. It's a mess, the primary merit of whose syntax is that there's a perverse pleasure in producing code that, to the non-initiate, looks absolutely incomprehensible. (Like this gem from one of my recent scripts):

while (<>) {
    if (m/^\#(.*)$/) {
        $comment .= "$1\n";
    } else {

The thing is, I learned Perl so well back in the day, and it's so useful for text processing, that I still end up using it all the time. (Another big factor was that I was able to install it without admin privileges, which I don't have at work, so I have access to it whereas I do not have access to a JDK.) The idealist in me would prefer to be using Guile as my scripting language, and I'd recommend others learn Rexx or, most obviously, Python, rather than Perl, but Perl is what I know, so that's what I use.

2. Java. Java, formerly my bread and butter, is still what I turn to for anything requiring libraries (I never really got confortable with Perl modules but I know the Java world inside and out). It also powers all my web-based projects. Thus it holds on to the number two spot fairly easily even though I'd in theory like to be moving away from it, in favour of...

3. Clojure. I've written about Clojure on here a couple of times. I'm still bullish on the language: if I can do Lisp and still have access to all the Java world I know so well, it should be perfect for me. But I just haven't had the time to build up the language knowledge and the workflow for it to become that go-to language. It's definitely my programming skill priority—it's just that I have so little time to consecrate to improving my programming skills these days.

4. VBA. Sadly, it might have been more honest to list VBA ahead of Clojure and maybe even Java, but I just can't stomach the thought of that. Working in an office job with Excel as your tool though means that macros are often the only programming option available (if I need to share the functionality with others; if it's just for me I can and will use Perl instead). But to say that it's not my favourite language or first choice would be an understatement.

5. Python. Wait, didn't I already explain that I don't need Python for anything, since it doesn't bring anything useful to the table of someone who's already mastered Perl and Java? That's true, for me, but if I were starting over from scratch, Python is the most logical choice as an easy programming language to familiarise oneself with, that has huge library support, and can scale to larger projets more elegantly than Perl can. I don't use it because I'm not starting from scratch.

But my son is. I owe a great deal to my father teaching me BASIC on the Commodore 64 back when I was in grade school, so I certainly want to give my own kids the same advantage. And while his first taste of programming came in the form of a game we worked on together in Clojure, that language is probably a bit too dense for a first introduction to writing code. So I've bought him a fun and colourful book aimed at teaching kids to code, and it uses Python, which I agree is an excellent choice. So in guiding him through that I'm starting to get my toes wet with that language as well, although I don't think I'll ever do more with it than help him debug his code.

And that's about it. As in 2006 I don't really consider things like SQL, bash, HTML, or Javascript "programming languages", so although I still regularly use them I won't list them here. And I've dabbled in Lua, Objective C, and newlisp, and thought about learning assembly for real, but those just aren't likely to get much attention going forward if I'm being honest. Hopefully in 2026 when I next do this exercise (don't hold your breath, but I wouldn't have guessed the site would still be here ten years ago either), by then Clojure will have moved up the list, but apart from that, it looks like I'm getting set in my ways. I think I feel middle age creeping up...

Posted by jon at 7:30 PM in Programming 

Sunday, 1 March 2015

Beginner Tips on Game Programming in Clojure

The barrier to entry on game programming in Clojure is surprisingly low, thanks to the ease of use of play-clj and the excellent example programs provided by Zach Oakes. This makes it possible to get cracking on the actual content of a game very quickly.

That is, assuming one is already a fairly competent programmer. In my case, being a longtime Lisper and possessing a very deep knowledge of Java, it only took a couple hours to get up and running on James' game. But I thought it might be useful for some if I spelled out what the steps I followed were, in case it might help out a newer clojure hacker unsure of what to do when confronted with all these unfamiliar parentheses.

After completing the absolute beginner's first steps (installing a JDK, Clojure, and Leiningen, learning the basics of Clojure syntax, knowing how to execute the example games, and knowing to have the language and library documentation open in tabs of your browser), here's how I got rolling on making a platformer of my own.

I began with a bit of time away from the code, scanning in my son's artwork and retooling it a bit in the GIMP. I then downloaded the Tiled Map Editor and began by modifying the existing map of the example, replacing the art assets with tiles made from my son's drawings.

Next, it was time to begin appropriating the code. Super Koalio's actual game code is contained in just three .clj files, each only about a hundred lines long, so the first step was simply to read over each file in detail and understand what it was doing. Along the way I added comments, and made notes of things I wanted to toy with—either to better understand what was happening by testing different behaviour, or to implement different features (such as double jump).

I then moved the files into a new namespace and began hacking on the game in earnest, but I publish here the original clojure Super Koalio files, annotated with my comments but before I began altering the code, in case they might help guide someone else through the same exercise:

  • core.clj—sets up the game, loads the level, and the main screen rendering routine.
  • entities.clj—mostly concerned with the player character, his animation and movement rules (there are no enemies or other moving sprites in the demo game).
  • utils.clj—utility functions, mostly related to handling player input

I know that my comments reflect an imperfect understanding of the code in some places, but I wanted to present a methodology for figuring this stuff out, rather than official documentation (that's why I use comments instead of docstrings, too). This is my process, and it works pretty well for me.

Once one has the game running and has understood what the source code is doing, the only thing left to do is begin playing with changing the code and adding features. There's no substitute for actually getting one's hands dirty with the code, and as a Lisp, Clojure is particularly easy to play around with, since the code can all be inspected—and modified—even when the program is running. Have fun!

Posted by jon at 10:00 AM in Programming 

Saturday, 21 February 2015

A curriculum for learning to code

The other day in a conversation with a friend she mentioned how her teenage son-in-law aspired to become a game developer, and mentioned what his college plans were. Rather than go off on a side-track about the work-life balance issues experienced by game devs, my main reaction was to emphasise that one does not learn to code in school. If one hopes to develop any skill at it, it should be first and foremost a hobby and a passion, which formal education can supplement and refine (by imparting such things as design patterns and best practices, without which the pure hobbyist is likely to produce messy and inelegant code).

A 15 year-old wanting to start down the path to game development, I said, should begin by writing a Snake or Tetris clone, the skills for which can be picked up within a couple years, and would give a solid base for growing as a programmer from that point on, depending on what direction he wanted to go into.

Upon further reflexion, I think that this advice is a bit too blunt, but the basic idea—learning to code by writing progressively more complex games—is a pretty solid concept. But Tetris and Snake are a bit too hard to be considered beginner projects. Below I list a more realistic progression (which I might try with my own kids when they're big enough), which does grow with one's ability as one learns how software works. Of course it's not meant as a rigid path—if the passion is there to explore a given direction further (like writing interactive fiction with Inform, which might well appeal more to some personality types keen on fleshing out a fictional world, as opposed to moving on to Asteroids, which requires learning trigonometry), then that's what one should do. It's better to let one's specialisation (and one must specialise at some point) be determined by passion (for music, graphics formulæ, networking protocols, etc.) than anything else.

Here then is the basic progression I would propose one set out for oneself, as soon as one starts learning a programming language. Each project can be expanded on and have features added for as long as the student feels inspired to do so.

  • Guess a number. Basic algorithms and input/output concepts.
  • Hangman. More interesting / complex algorithms. Can begin life as an interactive console (scrolling up) and then upgrade to using ncurses or an equivalent to function on a fixed ASCII screen (including an ASCII art hanged man).
  • Sokoban. Introduction to graphics. Rudimentary collision detection (synchronous with player input). Beginning level design and storage.
  • Snake and/or Tetris. Introduction to the game loop. First version can be ASCII based, then can branch out into 2D graphics (or 3D, for the determined and impatient). Basic collision detection. These games could be long-term projects, adding in music, high score lists, etc.
  • Asteroids or anything that involves animation (a slot racer or side scrolling-shooter would fit the bill as well). Learning about how geometry, trigonometry, and perhaps even physics models impact animation. More complex collision detection, and asynchronous input.

The last item may be a hard sell, since the programmer has enough knowledge to branch out into different areas (a top-down RPG, Zelda clone, or platformer, for instance), and might not be interested in something like this, which can be quite complicated to code. However I include it as part of the curriculum because I think getting a feel for this maths-heavy part of animation programming is an important thing to be exposed to, if one wants to be a game programmer.

Any programmer who has written the above games has the basic skill set he needs to go forward with whatever kind of project he chooses to set for himself next. Hopefully along the way, along with from-scratch programming, he's naturally been exposed to a few APIs (ncurses, Java2D, etc.), and can, whatever ambitious project he sets up for himself next, figure out on his own which gaming library meets his project's needs, and can go about learning it without too much trouble. (It is not unlikely that porting that old Snake or Asteroids clone over to the new framework will be the first step in learning his way around it.)

Of course it's also necessary to do some outside reading in order to learn how to use programming language features, how memory management works, and how to implement all kinds of different algorithms efficiently. But the idea here is that the needs of the projects are what govern the learning, rather than taking a series of books and tutorials and working through them, as if they were the ends in themselves.

So that's my basic, generalist curriculum. I imagine others have already come upon this same idea independently, but I thought I'd share my take on it, for what it's worth.

It could of course be adapted for someone who only cares about creating fighting games, or RPGs, or what have you, but the course proposed above should, in my opinion, produce a self-confident programmer who can apply his skills to a broad range of things. More importantly, game programming requires a lot more skill and application than plenty of other forms of programming (web, database, utility applications, etc.) which, while not as fun, can also one day pay the bills quite nicely. Of course, knowing the right tools and languages, to introduce to the right person at the right time, in order to keep them engaged and enjoying the programming process, is another part of the puzzle. I look forward as a father to seeing whether I can finesse that for my kids, and transmit to them some of the fun that there is to be had in computer programming.

Posted by jon at 10:03 AM in Programming 

Saturday, 19 April 2014

Full Circle

While I enjoy my post-MBA career as a organisational consultant and project manager (mainly because as a programmer I was never consulted when it came to strategic business decisions, and saw fewer opportunities to move up in the organisation), I miss programming. Programming was my hobby since I was a boy, and doing it for a living was (as I often said), pretty much the equivalent of getting paid to play video games.

Now, even when one is not working full time as a programmer, the ability to program still constantly comes in handy at work, whether it's gritting your teeth and putting up with VBA ugliness to perform some wizardry in Excel, or banging out a perl script to extract data that nobody else seems to be able to find by any other means. But recently the bug has bitten me again to return in earnest to programming for fun, and it's been fascinating getting back into serious programming after three an a half years away from it, to see how things have evolved. What's really exciting is that things seem, to me, to be evolving in an extremely positive direction.


I wrote a sort of programmer's autobiography some years ago, but the gist of it is that, after exploring a number of languages in the nineties, I fell completely in love with Common Lisp (via Scheme), and bemoaned that language's fall from grace in industry (following the AI winter, which wasn't Lisp's fault), even as I adopted it with enthusiasm for my own increasingly larger personal projects. At university, most of my online life was lived in Emacs.

When I unexpectedly found myself needing a new career, and decided to turn my computer skills into something employable, the realities of the market meant setting Common Lisp aside and embracing the world of Java. .NET was never a consideration for me as a Linux enthusiast, and the PHP/Python/Ruby third option did not appeal to me, probably because Common Lisp had instilled in me enough of an industrial approach to make me averse to languages that can easily get messy with large codebases, or which when pushed to handle large scale tasks have to resort to complex workarounds that undermine all their initial elegance. (In fact it was a 10k-line Scheme program collapsing under its own weight that had moved me to CL in the first place, fairly or unfairly I thought the mainstream scripting languages belonged in the same boat.)

Though I fully intended to keep using Common Lisp for personal projects, the constant need to evolve my Java skills meant that it gradually took over, and Lisp fell to the wayside. I also found myself using Emacs less and less, proud that I knew how to use it but also resigned to the fact that it was destined to be a relic of the past.

I always viewed Emacs as the software equivalent of Led Zeppelin or Monty Python: Products of the seventies that are pretty much perfection when it comes to doing what they do. They could still be recognised as the pinnacle of something by the following generation (mine), but the march of time is already starting to make them less intelligible to the following generation, and they seem destined to become so dated as to become inaccessible one day to all but a few.


Given my history it should come as little surprise that, if a guy like me decides he needs to update his skills, he doesn't need to hesitate long, looking at the current lay of the land, before zeroing in on Clojure. Lisp is back in vogue, and I can leverage all of the libraries I'm already familiar with through the Java platform? Yes, please!

My aim is first to master the language through a few practice projects (starting with a dashboard web app showing some of my server stats, since the existing version uses outdated JSF components and is really getting long in the tooth). Along the way I want to work through my O'Reilly Clojure Programming book cover-to-cover, both because it's excellent, and because back in the late 90's O'Reilly was always pushing back about publishing a Lisp book, saying that it wouldn't sell. (In those days, an O'Reilly book would have been serious enough exposure for the language that it actually would have boosted the mindshare significantly. I know that's not really true any more today, but now that O'Reilly finally have published a major Lisp book, I'm sure as heck going to read it!) Then I'll probably look for an open source project to contribute to, or perhaps write a game.

So, recently I upgraded my Eclipse from Galileo to Kepler (that will tell Java devs how long I've been out of the game). I've kept my Emacs current at 24 but I installed CIDER, and have found that to be superior to Eclipse (contrary to my expectations). Emacs seems to have picked up momentum, in fact. I'm sure it's still another world to the uninitiated, but it no longer feels like 'old software' to me.

Some things are still not where I'd like them to be. My first impressions of setting up a project classpath are not good, this could be an area where the tools might need improving (and maybe I could do that), or I just haven't learned the right way to do it yet. DB2 isn't one of the supported clojure jdbc databases, which is surprising, though I think it's likely it will work anyway, and I still know jdbc well enough to fix anything that might be broken.

But sitting there, looking at my Emacs running an inferior lisp just like I would have done fifteen years ago, realising that that inferior lisp also just happens to be the JVM, really felt like the merger of two worlds.

I can't wait to start hacking!

Posted by jon at 10:55 AM in Programming 

Tuesday, 20 September 2011

Potential Side Project

Posted by jon at 7:44 AM in Programming 

Tuesday, 29 August 2006

Adoption d'un nouvel EDI

Le changement d'une préférence d'EDI c'est un grand bouleversement dans la vie d'un programmeur. On y passe tant de temps, et sa performance est tellement liée à notre propre productivité. Je marque donc l'occasion en annonçant ici qu'après plusieurs années d'utilisation d'Eclipse (depuis la version 2.0), mon EDI de préférence s'est changée le week-end dernier en faveur de NetBeans 5.5.

Un peu d'histoire : Mon premier EDI fut Microsoft Visual Studio 1.0, que j'ai eu gratuit avec un livre en 1997. (Jusqu'à là je ne connaissais que BASIC et les éditeurs de texte.)

Vite poussé à l'environnement Linux par la pénurie des compilateurs gratuits en Windows, je reprenais l'habitude des editeurs de texte pendant quelques années. Quand une version est sortie pour Linux, j'ai essayé IBM Visual Age Java—je me souviens que le logiciel m'impressionnait, mais bouffait trop de ressources et n'était pas si pratique que ça, et je n'en ai pas fait un grand usage. Je devins un grand maître de GNU Emacs (ce qui est véritablement un EDI plus qu'un editeur de texte quand on sait s'en servir). Comme mon langage de prédeliction à l'époque était le Lisp, cette combinaison fonctionnait très bien.

Quand Eclipse 2.0 est sorti on en faisait pas mal d'éloges sur Slashdot, mentionnant entr'autres que son mode de compatabilité Emacs était l'un des meilleurs jamais vu. Alors j'ai jeté un coup d'œil, mais ce n'était pas plus impressionant que Visual Age pour moi, et j'ai continué avec le package JDEE sur Emacs pour ma programmation Java.

Mais peu à peu, j'avais des problèmes avec JDEE ou d'autres packages Emacs à chaque mise à jour, et je commençais à ressentir qu'Eclipse dépassait JDEE de plus en plus en fonctionnalité. En plus le temps de démarrage de mon Emacs était presqu'aussi long. Quand je me suis mis à vraiment utiliser Eclipse et bénéficicier de la documentation intégrée (que j'avais en Lisp auparavant) et les autres outils, je l'ai adopté totalement.

L'essor d'Eclipse a sans doute motivé Sun à améliorer leurs propres EDI (le nom même d'Eclipse est une insulte de la part d'IBM après tout), et avec la version 5.5 (toujours en beta), je crois que l'avantage est enfin de leur côté.

Pour les applications Java EE, l'outil de base dans le monde Eclipse s'appelle WTP. WTP fonctionne bien, mais on ne peut pas dire que c'est à la hauteur des attentes créées par l'éditeur eclipse lui-même. Côté NetBeans, l'Enterprise Pack est pour moi plus intuitif, et surtout plus intelligent—il crée les Entity beans et tout ça proprement et correctement, et reduit énormement la quantité de code qu'on doit écrire. C'est peut-être subjectif mais pour que je change d'une plate-forme que je connaissais déjà si bien, je pense qu'il doit y avoir quelque chose derrière.

Le Mobility Pack est génial aussi, c'est même la raison d'origine pourquoi j'avais installé NetBeans. Avant j'utilisais une combinaison d'Eclipse et la ligne de commandes pour programmer mon téléphone, et c'était nettement mieux dans NetBeans, évidemment.

Dernier point pour les francophones, la localisation de NetBeans est nettement meilleure que sur Eclipse. Alors plus besoin de décrypter des messages en anglais à 2 heures du matin !

Posted by jon at 8:23 PM in Programming 

Friday, 8 February 2008

Comment déclencher du JavaScript après n secondes

Dans certains cas, on peut avoir une bonne raison de vouloir déclencher du JavaScript après un délai de 10 secondes, par exemple. On sait, j'espère, qu'il ne faut jamais utiliser un boucle qui ne fait rien pour compter le passage du temps ! Mais alors, comment faire ça correctement? Heureusement il existe en JavaScript un moyen très facile et propre de le faire:

var delai = 10; /* Dix secondes */

var apres = function () {
  alert(delai + 'secondes se sont pass\351es!');

setTimeout(apres, delai * 1000);

Et voila, c'est tout ce qu'il faut pour que notre fonction apres se déclenche après 10 secondes. Pour résumer, la fonction JavaScript setTimeout prend donc une fonction en premier argument, et un délai en second argument, exprimé en millisecondes. Facile! Cliquez ici pour le voir en action.

Voir aussi :

Besoin de vous rappeler des accents comme le \351 dans l'exemple? Trouver un tableau complet ici.

À la recherche d'un bon plugin JavaScript pour Eclipse? Essayez JSEclipse.

Posted by jon at 6:41 PM in Programming 

Thursday, 28 September 2006

Computer language timestamp

My attitude on various computer languages has gone through a lot of evolutions over the decades (I remember as a grade schooler I thought the FOR...NEXT loop was way too complicated), and I wish I'd written out what I thought at the time since it would be interesting (and probably pretty embarrassing) to re-read later ("Perl is AWESOME! Anybody who writes anything using anything else is stupid and wasting their time"—imaginary me, circa 1998). So I've decided to start now and sort of document what the computer languages I actually use (or play with) are these days, and what I think of them. This may only be useful to me since I'm the only guy with a clear idea of how I used to think, but it's my blog and I write what I want.

  • Java—What I use for 100% of my time at work (I'm not counting stuff like SQL, Javascript, XML, or "AJAX" as programming languages in the context of this discussion) and probably 80% at home. Which means that unlike a lot of people this is a language I actually enjoy using. Like everybody else, this is not a language I liked at first. But as I have learned more and more about programming as "software engineering" I have got a lot more respect for Java.

    Another huge evolution has been my new conviction that programming languages are not in and of themselves relevant—except that sometimes knowing a better language can be a shortcut that lets you get somewhere faster than everybody else. Platforms are what matter. Not libraries, platforms, as in the 'official' language of a given computing platform used and supported by whoever puts out that platform. The languages that become important and widespread are the native languages for a platform, period. C is important because of UNIX, C++ because of Microsoft, Objective C for Apple. And Java for the Java platform, the only one that's portable. C# is rapidly becoming important because .NET is becoming Microsoft's platform; it will increase at C++'s expense, as, I think, we are already seeing. If Java's libraries were not so vast and complete as to qualify for 'platform' status Java would be a second-rate Ada for me. (In that Ada is the ultimate "software engineering" language, but it has poor libraries availible to the casual coder—and besides, it is not the "native language" of any platform.)

  • Lisp—My old favourite has been relegated to second place following my realisation regarding platforms trumping languages. Still for the most difficult problems I will turn to Lisp, and I still back the maxim that those who do not know Common Lisp are doomed to reinvent it, poorly. But IDE's like Eclipse make development in Java almost as pleasant. Anyway, Lisp is my language of choice for modelling complexity, but for simple tasks it doesn't have the libraries (and for some reason I find it a lot harder to get used to a third-party library in Lisp than in other languages).

  • Perl—Perl hasn't been one of my favourite languages since high school, and I stopped favouring scripting languages over languages that enforce good software engineering practices the first time I had to rewrite a 10,000 line program of mine that didn't scale (in fairness, that program was written in Scheme, not Perl). But I have recently started using Perl a lot more, since a "right tool for the right job" approach practically dictates that it be used for text processing and glue code. Nowadays though I don't write any larger programs with it, but I am very glad I got back into it.

  • C—I've been brushing up my C a lot this year, partly out of guilt at not contributing to Open Source (another topic in itself) and partly because it's the most important programming language in history. I got K&R for Christmas (I had read it a couple times but never bought it because of the price) and have gone through that, and done a few of the excercises, and also did some stuff with Glib and ncurses, and did a Linux kernel device driver tutorial.

    I have only used it for toys though, since I have yet to come up with a project for which it meets the "best tool for the job" criterion in 2006. But I am hugely glad that I decided to brush up on it, because a thorough understanding of pointers is actually a great help in writing Java code (which, although it doesn't have pointers, does pass objects around by reference; and understanding this clearly is paramount for judging the cost of some things, and eliminating redundant lines of code in others). So I think that getting my C knowledge straight has contributed enormously to making me a better and more knowledgeable programmer, even if I don't actually use C.

  • C++—This was the first PC language I learned, which led to me not touching it again for 8 years. I don't like C++, I still see it as error-prone and unportable, with its defining feature being that every language feature known to man has been crammed into it at some point. Nonetheless, I thought that as a professional programmer it is something I should be competant in, so I have set about relearning it from scratch. The language has changed so much from my Visual C++ 1.0 days that it's almost unrecognisable... I really would like to learn this well enough to have it on my resume and maybe use one day at work (it feels precarious having only Java as a sellable "work language" on my resume), but I do not see myself coding in C++ at home by choice any time soon.

  • Stuff I don't use anymoreScheme, which was once my weapon of choice, now isn't even installed on most of my computers. I'd probably use it (and Dr. Scheme) if I were teaching programming to beginners though since its regularity is very nice. Tcl/Tk used to be very good for portable GUIs, but there are other ways to do this now, and Java is more portable. Prolog was a real eye-opener to learn, but I haven't used it in a long time and my textbook is locked up in storage in Canada, so it's pretty irretreaveably forgotten for the time being. C64 BASIC was once synonomous with programming for me, but I have not used BASIC since high school. Logo however has the sole claim to glory of being the only language that I haven't used since elementary school.

  • Stuff I'd like to use moreAda, Fortran 95, Assembly. Mostly for learning purposes, although the first two, Ada especially, might be useful for something non-trivial if the problem played to the language's strengths. I haven't done much with Python or Ruby either, although despite this they would probably be my recommendations if a non-programmer asked me what programming language to learn since they are so user-friendly and have great libraries.

So there's a good snapshot of my views on various programming languages circa 2006; it will be interesting to put it in the time capsule and see how it stands up to future scrutiny.

Posted by jon at 11:28 PM in Programming 

Wednesday, 24 January 2007

Découvrir le Rexx

Qui dit langage de script de nos jours pense typiquement à Perl, Python, ou Ruby. Eventuellement, il en connaîtra d'autres, comme l'Applescript sur les ordinateurs Mac, shell, si c'est un ancien d'Unix, etc. Un alternatif qui est moins connu qu'il ne devrait l'être, c'est le Rexx. Ici je donne quelques raisons de considérer le Rexx si vous êtes à la recherche d'un langage de script, en mettant l'accent sur ses avantages par rapport aux langages plus connus.

  • Le Rexx est multi-plateforme. Ceci lui donne déjà un avantage par rapport aux langages plus traditionnels tel que l'Applescript ou shell. Comme Perl et Python, des interprètes Rexx existent sur toutes les plateformes majeures, y compris même la machine virtuelle Java. Rexx est même plus multi-plateforme encore, étant le langage de script de référence sur les systèmes IBM moins connus, comme MVS et OS/2. Si vous vous mettez au Rexx, donc, vous serez habile à programmer sur n'importe quel ordinateur, même si un jour vous changez de système.
  • Le Rexx est simple. Perl, Python, et Ruby sont des langages très à la mode. Cela comporte ses propres avantages, notamment au niveau des libraries. Mais ce sont aussi des langages complexes. Pas de problème si vous les utilisez régulièrement. Mais si vous êtes comme moi, et vous n'avez pas besoin d'un langage de script plus souvent qu'une ou deux fois par mois, ça peut être frustrant de devoir aller à la documentation chaque fois pour se rappeler comment faire une opération simple comme lire ou écrire un fichier. Avec Rexx, je trouve ce travail de mémoire plus simple, ce qui me rend plus productif.
  • Le Rexx est puissant. Ce n'est pas parce que j'insiste sur sa simplicité qu'il faut croire qu'il s'agit d'un deuxième Basic! Rexx a tout le dynamisme qu'un programmeur Perl peut vouloir, y compris les comportements utiles par défaut, les variables dynamiques, etc. Les commandes parse et interpret sont particulièrement puissantes avec cette dernière on peut exécuter du code créé dynamiquement, comme en Lisp!
  • Le Rexx est utilisé en industrie. Bonne chance pour trouver une boîte suffisement bien branchée pour employer le Ruby en industrie! Perl et Python sont de plus en plus présents, c'est vrai, mais seul Rexx se trouve dêjà en place avec ce qu'on nomme "les vieilles technologies". Et en plus, il est moins connu par les programmeurs actuels. Une bonne connaissance de Rexx peut donc aider le programmeur professionnel à faire de la programmation dynamique dans un environnement technique où cela est rarement possible, et à faire valoir une connaissance qui n'est pas facile à trouver sur le marché de l'emploi. Les librairies Rexx sont aussi très complètes.
  • Le Rexx fait de l'arithmatique décimale. Beaucoup de gens ne sont pas au courant des inexactitudes mathématiques provoquées par leur code à cause de l'arithmatique binaire de la plupart des langages de programmation. (Par exemple, en C (sur x86) et Java, la condition 1.1 - 1 == 0.1 sera false!) Rexx évite tous ces problèmes en faisant de l'arithmatique décimale à précision arbitraire. Croyez-moi, c'est une bonne chose.

Voilà pour les avantages tels que je les vois. Maintenant je vous présente un peu de code pour vous montrer la facilité de Rexx. Le programme suivant affiche un message à l'êcran:

say "Bonjour tout le monde"

A la différence de Perl et ses amis, qui ont grandi dans le monde Unix, où le C domine, Rexx a grandi au sein d'IBM, et sa syntaxe s'inspire plutôt de PL/I. C'est un point historique, mais sa seule vraie conséquence c'est qu'on remplace { et } par les mots-clefs DO et END. Les structures de contrôle sont donc assez facile à assimiler:

if x = 2 then do
  say 2
else do
  say "pas 2"
/* Compter de 1 à 10 */
do x = 1 to 10 
  say x
do 3
  say "Cette ligne s'écrira trois fois."
do forever
  say "Ce boucle ne termine jamais."

Et ainsi de suite, ce n'est pas mon but ici de donner toute la syntaxe du langage. Regardons plutôt un exemple pratique, pour voir si on peut envisager comment on utiliserait Rexx dans la vraie vie. En voici un script qui prend deux arguments: un fichier d'entrée et un fichier de sortie. Il lit ensuite le fichier d'entrée et remplace tous les tablatures par quatre espaces.

parse arg filein fileout .
do while chars(filein) > 0
  char = charin(filein)
  if c2x(char) == 09 then
    call charout fileout, "    "
    call charout fileout, char

La première ligne met les valeurs du premier et deuxième arguments fournis à la ligne de commandes dans les variables filein et fileout. Après, le programme boucle sur le fichier d'entrée en remplaçant toutes les tablatures par quatre espaces, mais laissant les autres caractères comme ils sont.

Ce n'est qu'un exemple toute bête, mais ça ne prend qu'un coup d'œil pour voir que le langage est beaucoup plus lisible que le Perl sans être verbeux, et sans sacrifier sa puissance dynamique. Le résultat: un langage facile à apprendre, difficile à oublier, et très utile pour toutes sortes de programmation, des PDA jusqu'aux Mainframes!

Liens utiles sur le Rexx (anglais):

Posted by jon at 11:10 PM in Programming 

Tuesday, 29 May 2007

Edition de JavaScript sous Eclipse

Au cas où vous n'étiez pas déjà au courant, je me suis dit que ça valait le peine de signaler JSEclipse, un plugin pour le très populaire EDI Eclipse qui rend beaucoup plus agréable l'édition des fichiers JavaScript. Publié par Adobe Labs, ce plugin gratuit permet d'utiliser les raccourcis f3 pour sauter aux déclarations, d'avoir la complétion automatique, le coloriage du code, et améliore globalement l'édition des fichiers .js par rapport à WTP. Si vous éditez souvent des fichiers .js (ce qui arrive de plus en plus souvent avec la vague AJAX), vous aprécierez beaucoup ce plugin.

Pendant que je suis sur le sujet, voici quelques autres liens qui sont utiles à garder à portée de main quand on fait du JavaScript :

Posted by jon at 10:37 PM in Programming 

Saturday, 30 August 2008

Erlang: The Movie

While I'm on the subject of wacky tech movies, one of the most bizarre, funny, and yet highly educational YouTube movies I've ever viewed has to be Erlang: The Movie.

(Erlang is a hot language these days as multi-core and multi-processor computing becomes the norm, and people worry more and more about how to write good concurrent programs. Erlang is a language that is made for this, which makes it easy and safe to write programs that do more than one thing at once, without having to worry about the things like unreproduceable race conditions or deadlocks that can plague you with C pthreads or Java.)

Posted by jon at 12:01 AM in Programming 

Monday, 10 March 2008

Gestion des trunk, branch, et tags dans Subversion

Subversion est actuellement parmi les solutions de gestion de versions les plus employés de nos jours. Une organisation typique de projet avec Subversion utilise ce qu'on appelle un "trunk", des "branches", et des "tags". Dans cet article j'explique brièvement ces termes.

Le trunk (tronc en français) est, comme son nom l'indique, le projet principal. Si on veut faire du développement en parallèe (ce qui arrive souvent, par exemple, quand on a livré une version, qu'on continue à maintenir pour corriger des éventuels bogues, mais on prépare en parallèle une version 2.0 avec plein de nouvelle fonctionnalités), on met ces "branches" dans, comme on pourrait le deviner, un branch.

Un tag, quant à lui, est une balise, qu'on peut appliquer à une révision pour l'identifier plus facilement—pour dire, «ça, c'est la version 1.2», par exemple. Un tag n'est en réalité qu'un branch qu'on ne modifie jamais, mais on les met à part parce que conceptuellement les deux sont très différents.

Un dossier subversion aura donc typiquement trois dossiers à la racine, branch, tags, et trunk, avec une copie du projet dans trunk, et d'autres copies dans des sous dossiers de branch et/ou tag selon les besoins et l'évolution du projet.

Posted by jon at 6:59 PM in Programming 

Monday, 5 February 2007

Introducing DietTracker

For any who care to check it out, I am releasing as Freeware a little utility I wrote for tracking my diet, which I have creatively named "DietTracker". It runs on Linux, Mac, and Windows and requires only that Java 5 or later be installed on your machine. The link to install is found at the end of this article, but first I'll explain what it is.

There are a million-and-one ways to track your daily calorie intake, from making a spreadsheet to the innumerable web sites that are out there for doing it. What I find to be the difficult/annoying part of tracking what you eat isn't so much taking the time every day to write it down, as it is looking up how many calories are in every given dish. Emilie cooks a delicious dinner every night, which is wonderful, but it means I can't just look on a label to know the calorie count of the meal—I have to add up a whole list of ingredients, which is quite a hassle.

There's no magic way to get around having to count up the calories once, but DietTracker's job is to ensure that you only ever have to do it once for each ingredient. After that, meals are memorised, so I can just say, "yesterday I had cereal and coffee for breakfast, a chicken sandwich for lunch, and chicken fricassé for dinner", and the program will automatically handle the ingredients and calorie counts for those meals, as long as I've entered them beforehand. So the hard work is all moved to the beginning of diet tracking (which is when motivation is highest), and afterwards the program makes things quick and easy to keep up to date.

This version 1.0 has four functions, laid out plainly enough on the main menu:

The first step is entering foods, the individual building blocks of a meal:

I didn't include any functionality to look up calorie content from within the program, (there are already plenty of resources out there to do that, so it didn't seem useful for the work it would involve). The next step is to combine foods into a meal, so that you can easily enter in what you've eaten later:

In our case, over a cycle of two or three weeks there's a pretty standard list of meals we might eat. So although it's a bit of work up front to enter in what you eat, once you've done it, it's done. Then with foods and meals defined, the day-to-day use of the program is simply a matter of putting in what you've eaten, which is pretty painless:

And last but not least, entering in what you've eaten is only useful if you can look back on it afterwards and see how you're doing:

(Those numbers are made up, but you get the idea.)

Anyway, I find this useful, and it was a worthwhile programming exercise since I haven't done a desktop app in ages. (This one still could use a bit more polish, to be honest, but I wanted to get it out there.) I have plenty of ideas for future versions, as well: the most obvious area improvement is doubtless the food and report screens, which could be expanded to include more information than just calories, (although since I only care about calories for the time being, I'm not too motivated). But I do plan to add a moving average line to the bar graph, and perhaps an "export to Excel" button to let you work with the raw data yourself. Another biggie is that there is also currently no way to remove incorrect entries (other than directly modifying the internal database, which is fine for me, but hardly doable by non-programmers). I also plan to add an internet-connected option so that your data is kept in a central repository, even if you use DietTracker on different computers (this is actually already nearly finished). And the French-language version could use some polish.


To install the application on your computer, all you need to do is click on the link here. This will directly launch the installer:

Once downloaded, you will need to authorize DietTracker to run on your computer; it will create and use a directory named "DietTracker" in your home directory.

(More information about how this type of secure web-based installation works can be found here). On any platform, you can also lauch the program directly by saving the "DietTracker.jnlp" file to your computer and double-clicking on it. If and when I get around to releasing updated versions, the program upgrades itself automatically.

Feedback on how useful the basic premise and useability of the "Enter Meal" screen would be appreciated by anyone who gives it a try; as well as suggestions for extra features. And finally (for any who missed the link hidden in the "Installation" section above),

Click here to install DietTracker

Posted by jon at 9:49 PM in Programming 

Thursday, 2 November 2006

Keeping the lights on

Most people I think, when they go away on vacation somewhere, use one of those timers to automatically turn the lights on while they are away, so as not to broadcast one's absence too openly to potential burglers. It won't be long, I imagine, before someone's 'loose lips' on their blog, tracked down by tech-savvy wrongdoers, leads to them getting burgled after unthinkingly broadcasting their upcoming absence to the entire Internet.

We are just getting back from our trip to Italy today, and if all went as planned we had a great time and will be posting about it soon. Also if all went well, my blog continued posting stuff I'd written weeks earlier, making it appear as if we weren't away—and hopefully, we were not burgled, 'proving' that the system works :-) My own little version of a timer to turn the lights on and off.

So, I thought I'd come clean about this right away, just in case I have generated any resentment by 'refusing' to answer questions in the comments or by not cleaning up comment spam with my usual celerity. Non-robot posted posts will be returning soon!

Posted by jon at 8:34 AM in Programming 

Thursday, 2 April 2009

Les trois plugins Firefox les plus incontournables

Lire cet article aussi sur mon site Expertise Java & J2EE 100% en français (lien direct).

Grâce à son architecture extensible et son licence open source, le navigateur Firefox est devenu un des outils les plus utiles pour les développeurs web. Nul autre outil permet tellement facilement de tester des sites web, et de diagnostiquer ce qui ne va pas en cas de mauvais affichage, et tout cela gratuitement. En voici les trois plug-ins qu'il vous faut installer pour transformer votre navigateur Firefox dans un outil puissant de développement.

1. Firebug. La transition de HTML classique vers CSS nous a permis de séparer contenu et présentation. Tout cela est génial, mais comment est-ce qu'on s'en sort quand on a plusieurs feuilles de style avec des centaines de classes, et on doit trouver pourquoi tel <div> ne se trouve pas au bon endroit? Firebug permet de voir, simplement en passant le souris sur la page, toutes les classes css qui s'y appliquent, et lesquelles sont priorisées au-dessous des autres. Débugger le css serait un cauchemar si on n'avait pas Firebug.

2. Selenium. Marre de remplir les formulaires pour tester les différents parcours de votre application? Selenium permet, à la manière de jUnit, de sauvegarder vos parcours et de les rejouer automatiquement. Un outil très mûr et facile à adapter à vos besoins (exportation des tests en java, intégration ant, etc.), Selenium est indispensable pour tester vos applications web.

3. LiveHttpHeaders. Des fois, le serveur ne se comporte pas comme on s'y attend et on a du mal à comprendre pourquoi. Le plugin LiveHttpHeaders permet de voir, pour n'importe laquelle page internet, les en-têtes HTTP que votre navigateur a envoyé avec sa requête, et aussi les en-têtes de la réponse serveur. C'est rare qu'on en a besoin, mais c'est extrêmement utile à avoir lorsque, par exemple, on a des comportements différents en recette et en production et qu'on soupçonne qu'une configuration WebSphere ou Apache est derrière le problème...

Posted by jon at 7:09 AM in Programming 
« August »
Older articles
Non enim id agimus ut exerceatur vox, sed ut exerceat.