Prolog: Just the beginning?

If you’ve been following my recent computer-related posts about learning 7 languages in 7 weeks from a similarly titled book, you may be wondering why several weeks have elapsed since I wrote about my experiences with Io and there has been nothing about the next language on the list, whose tutorial I should have completed at least a fortnight ago.  If you know me reasonably well, you may have guessed that this project has fallen by the wayside as I’ve moved on to other interests.  Ordinarily, that would not be a bad guess but, as it happens, I’ve just been taking a slightly more leisurely pace than the book’s title indicates (and, yes, it’s partly because I have other interests and obligations and can’t spend all my time just concentrating on learning one programming language for a whole week).

The third language covered in the book is Prolog.  This is the oldest language covered in the book, by quite some margin.  It dates back to around 1972, so it’s a bit older than me. It’s also the only language covered, apart from Ruby, that I’d ever really looked at before.  It’s been a few years since my last foray into Prolog and I’d forgotten most of what little I learned about it at the time.

Prolog is an example, perhaps the Ur-example, of logic programming languages, which are based on a programming paradigm called declarative programming.  Thus, the Prolog approach to programming is quite strange to someone used to the more common imperative programming paradigm.  Instead of issuing the computer with a set of commands to solve your problem, you give it a description of the problem and leave the solution to the computer.  It takes a bit of getting used to this idea, but it means that Prolog is very good at solving some problems that would be much more difficult with other languages and, conversely, much less well suited to other problems.

The tutorial in the book builds up to a couple of quite neat programs.  One is designed to find solutions to the classic Eight Queens puzzle in chess, while the other is a Sudoku solver.  The worked example of the latter in the book is only for a 4×4 sudoku, and it leaves the full solution of the standard 9×9 puzzles as an exercise (which is a fairly straightforward generalisation, involving quite a bit more typing but no new concepts that don’t appear in the smaller version).  Unfortunately, the program in the book is designed to work with GNU Prolog and uses some library functions that are not available in other implementations, so I couldn’t just type it in and get it to work on the SWI Prolog system I was using.  However, a bit of Googling turned up a couple of other solutions written for SWI Prolog (making use of some libraries for that version, and hence not directly useful to other Prolog versions – this lack of portability seems to be a particular feature of the language, although it’s by no means unique).  One of these managed to fit the whole program into 13 lines of code and seems very elegant, although a couple of the details are slightly beyond my current grasp of the language.  This is certainly a big improvement on sudoku solvers I’ve looked at in other languages, which are typically much longer and more convoluted.

Due to the very different approach to programming, Prolog represents a quite different tool from any of the other programming languages with which I am acquainted, and it seems especially good at some kinds of problem that especially interest me (including, but not limited to, natural language processing).  For that reason, I’m hoping to keep on developing my Prolog skills and hope to be able to do useful things with the language before too long.  In the meantime, I’m going to carry on with the remaining 4 language tutorials in the book (the next one up, IIRC, being Scala).

The film that Tate associates with Prolog is Rain Man.  This is, by all accounts, a classic film on the subject of autism and generally very well regarded by critics.  Although it dates back to 1988 I have not previously got round to watching it, but I managed to pick up a cheap copy the other day and I thought it was an excellent, thought-provoking and very moving film.  I can certainly see how Prolog resembles the semi-eponymous character, Raymond (an autistic savant), who seems very difficult to interact with in many respects but is outstandingly brilliant at certain things.




Io, by Jove!

I have been continuing the programming project I started the other week of working through the book Seven Languages in Seven Weeks, although it is already in danger of getting swamped by the many other things vying for my attention (especially, at the moment, my resurgent interest in human languages as fuelled by the Bangor Polyglots group I’ve just joined).

The second programming language in the book, and the one I’ve just finished working on, is Io.  Of all the languages covered, this was the only one I’d never even heard of, putting it at the opposite end of the spectrum from Ruby (the only one I’d used much already). The official Io website, which I’ve just linked to, describes it as “prototype-based programming language inspired by Smalltalk, Self, NewtonScript , Act1, LISP  and Lua” (check the original source to see the nature of the inspiration in each case).  While Self, NewtonScript and Act1 are also languages that I’m entirely unfamiliar with (though I’d heard of NewtonScript), I have played a bit with Smalltalk, LISP and (to a lesser extent) Lua, so I could see some resemblance.

Prototype-based languages, such as Io, Lua and Javascript, are object-oriented languages but, unlike most OO languages (such as Ruby, Java and C++) , they are classless.  Instead, each object inherits (via a process known as cloning) and extends or modifies behaviour from another object, which acts as its prototype.  This approach is supposed to encourage a very flexible style of programming.  I have previously done a fair amount of work with Javascript (though mostly via the excellent jQuery library, which hides most of the gory details out of sight) but have not fully grokked the idea of prototype-based programming.  My experiences of Io this week have deepened my understanding somewhat, although I think I’m still a very long way off full mastery of the concept.

The advanced features of Io which are the culmination of Tate’s tutorial are its facility for writing domain-specific languages (essentially by rewriting the syntax of Io itself) and its tools for handling concurrency.  Neither of these are areas of which I have much previous experience, so I’m not in a position to judge how much of an improvement Io offers over other languages for work in these areas.  I think several of the other language tutorials in the book will also be looking at concurrent programming (I’m not sure about DSLs) so hopefully by the time I’ve finished the book I’ll have a better idea which language to turn to if I should ever need to do anything like that.

The film character Tate associates with Io is Ferris Bueller, the protagonist of the 1986 movie Ferris Bueller’s Day Off.  I first saw this film (or at least a large chunk of it) very shortly after it came out, as it was shown to my primary school class on the last day of term.  In hindsight, I find it quite a surprising choice of film to show in this context since (a) it’s all about somebody skiving off school who is clearly depicted as the hero of the film and not seen to suffer any ill-consequences from his truancy (an odd message for a teacher to want to convey, surely!?) and (b) it’s 15 rated in the UK and none of us in the class were older than 11.  Still, I suppose it was the last day of term and the party mood was probably affecting our teachers too (as in, they just wanted something to keep the kids quiet while they went and made a start on their own end-of-term party).  My second viewing of the film took place only a few days ago and I enjoyed it a lot more than I thought I was going to; unlike many films of its era it doesn’t feel painfully dated by now.

Returning to the programming language, the name Io is shared with (and presumably comes from, though I’ve not been able to find anything to confirm or contradict the supposition) one of the moons of Jupiter.  Interestingly, one of the languages listed as an inspiration for Io is Lua, which is the Portuguese word for moon (to find out why, check out the Wikipedia article on Lua).  I don’t know whether that’s a coincidence or whether Lua inspired the name as well as some of the features of Io.

At first, I found Io quite fun to play with.  As I began to try to go deeper, it quickly became quite frustrating as it was so different to other languages I’ve used (although that is, really, the point of the exercise).  After a few days, some of the ideas began to click and I was able to make fairly good progress.  I was heartened to notice that Bruce Tate himself said that it took him several weeks of working with Io to really begin to get a grip on it.  I’m glad to have made its acquaintance but I don’t plan to do any more work with Io for the moment as I think my limited programming time can better be spent in other directions.  I may well return to it for another look in the future though and would certainly recommend it as an interesting language to have a look at.

A great place to chill

Perhaps it’s unsurprising that a band with a name like the Penguin Cafe Orchestra should play some very cool music. 🙂

The PCO (as I’ll shorten them, although I don’t know if this is an officially sanctioned abbreviation) is a band that I was first introduced to way back in about 1990, when I used to go across to my maths teacher’s house for computer programming lessons.  It’s a sad fact that this kind of thing would almost certainly not be allowed to happen now, due to child safeguarding laws and suchlike.  In addition to taking my first steps in programming computers beyond what ZX Spectrum BASIC had to offer (not that I’m knocking that, as it was an excellent introduction to the whole programming thing), these semi-regular Saturday afternoon sessions over the course of several months, or possibly a couple of years, introduced me to the fine art of making guacamole (a skill which I don’t think I’ve ever got round to putting into practice but it’s nice to know it in theory anyway) as well as a whole load of excellent music, of which the PCO is very definitely at the top of my list.

The music of the PCO is often-described as New Age; Wikipedia defines this as “an umbrella term for various downtempo music intended to create artistic inspiration, relaxation, and optimism”, which is actually not too bad a description of the PCO sound in general, although quite a lot of their stuff (including most of my favourite pieces) is fairly up-tempo, energetic music.  There’s a good chance you’ve heard some of their music, perhaps without realising it, as several of their tunes have featured in films and adverts over the years (see the Wikipedia article linked at the start of this post for a list).

For some reason I used to believe that there was an actual Penguin Café (which I thought was in Edinburgh) and that the PCO was the band in residence there.  I now gather that this is not the case (at least the bit about the PCO being a house band for a café – there may well be a Penguin Café in Edinburgh as indeed there is one in Bangor).  Instead it’s the name of a group of musicians led by the English composer/multi-instrumentalist Simon Jeffes who, sadly, died of a brain tumour in 1997.  Incidentally, although the word café is properly written with an acute accent on the ‘e’, this seems to be absent from the official spelling of the band name.

The original PCO produced, I think, 5 studio albums and 2 live albums (as well as a few compilations) during their active years from the early 1970s to the late 1990s.  I have had the first four studio albums for quite some time and enjoyed listening to each of them many times over.  I have only just got my hands on the last studio album (Union Cafe, released in 1993) and one of the live albums (descriptively entitled Concert Program and hailing from 1995) and have so far only had time for one listen through each, but my first impressions are very favourable and I shall look forward to many more listenings of both.

One of the things I love about the PCO, apart from the many fine melodies, is the eclectic range of instruments to be heard in the ensemble.  Looking through the sleeve notes to Union Cafe, for example, I find that alongside violins, cello, piano, trombone, clarinet and cor anglais, there are appearances by a ukulele (that one has been a fairly common feature of pretty much all the PCO albums), electric aeolian harp and “clay pot and twigs”.  There’s also one track which was realized on a computer and another one featuring a guest performance from Kathryn Tickell on the Northumbrian smallpipes (as well as one with Nigel Kennedy – presumably this is back when he was still using his first name – on violin).  The whole PCO sound is very much instrumental music, although there was some use of vocals on their first album (mostly by Emily Young, who also painted the wonderful pictures of people with penguin heads that adorn most of the album covers).

Apparently Simon Jeffes’ son, Arthur, has taken up the mantle of the PCO, now redubbed simply as Penguin Cafe and has produced one album so far (with a completely new set of musicians), while many of the original members of the PCO have continued working together under the name of Anteater.  I’m not sure whether they have released any albums yet, but both of these bands may be well worth a listen whether they are following closely in the footsteps of the PCO or exploring new paths.

Ruby, my dear

I recently acquired a new computer programming book entitled Seven Languages in Seven Weeks (by Bruce A. Tate, published 2010 by the Pragmatic Programmers; ISBN: 978-1-934356-59-3).  As the name suggests, this is an introduction to not one but seven different programming languages and is designed to be worked through (it’s very much a hands-on kind of book) in a fairly short space of time.  Rather than purporting to provide complete coverage of each language (which would be impossible, probably even for a single one of them, in just one book) it aims to give a fairly general introduction to each one and demonstrate some of it’s particular characteristics, leaving the reader to hit Google in search of further documentation etc.  As well as giving you a broad exposure to a range of different programming paradigms, this book is intended to equip you to pick up the elements of a new language quickly and efficiently.

The seven languages covered by the book are (in order of appearance): Ruby, Io, Prolog, Scala, Erlang, Clojure and Haskell.  I’ve just started working on the Io section of the book and, if all goes according to plan, I intend to write a blog post about each of the languages once I’ve finished the relevant section.  For now, I’ll focus on Ruby.

Of all the languages in the book, Ruby is the only one that I already have a reasonable amount of familiarity with (although I’ve played a bit with Prolog and I’m fairly sure I had a quick look at Haskell once too).  I have already written a handful of, admittedly fairly small, real world programs (as opposed to tutorial exercises) in Ruby, which could reasonably be described as a general purpose scripting language.  At the moment, I would probably describe it as my second choice go-to language for general purpose programming; Python would be my first choice, largely because I’ve been using it for somewhat longer, am a lot more familiar with it and have a bit more dead-tree-format reference material for it; they are both excellent languages (each with several definite pros and cons relative to the other) and I’d rather get reasonably proficient at both than concentrate exclusively on either one of them.

The particular (though by no means unique) feature of Ruby that Tate focuses on in his book is metaprogramming, which (he says) “means writing programs that write programs”.  I’ve come across the idea before, mainly in my studies of Lisp (although I didn’t quite get as far as doing any metaprogramming for myself).  I still don’t feel that I entirely grok the concept, but I think it’s definitely something worth exploring further and it appears that Ruby will be a good vehicle for it.

A nice, slightly quirky feature of the book is that Tate likens each programming language to a film (or TV series in one case) character that he feels epitomises similar characteristics.  In the case of Ruby, the chosen film is Mary Poppins.  Tate describes the titular character (and hence also Ruby) as “sometimes quirky, always beautiful, a little mysterious and absolutely magical.” [Actually, to be pedantic, he applies that description to Ruby and then says “Think Mary Poppins.]

I fairly recently started (or rather restarted, as it’s an old project I started and abandoned several years ago) a programming project using Python, so I’ll probably try to get it finished in that language.  However, the next time I have a real-world problem to solve with a script, there’s a good chance I’ll reach for Ruby.

Raspberry Tea

I am writing this on my Raspberry Pi, which is currently hooked up to my monitor at work (it’s now my lunchbreak and I’ve, once again, successfully resisted the temptation to play with my Pi all morning).

As I mentioned the other day, my first attempt at directly hooking up the I/O hardware (rather than going in via SSH or VNC to a headless setup) failed because my HDMI cable and DVI adaptor combo was too big to fit in the space at the back of my monitor.  I suppose the proper geek solution to this problem would have been to dismantle the cable and adaptor and see if I could wire them together directly and make the whole thing short enough to fit.  Instead, I opted for the slightly-less-exciting but also considerably-more-likely-to-work-without-frying-myself-or-my-monitor approach of buying a new cable with a HDMI connector at one end and a DVI connector at the other.  This has now arrived and works fine.

My Pi is beautifully quiet compared to my desktop PC, as it has no fan to make lots of noise (the chip is sufficiently cool-running not to need one) but it’s also noticeably slower (as it has a lot less memory and probably a much slower processor), so I won’t be trying to persuade my boss to let me replace my office computer with a Raspberry Pi, nor ditching my home PC in its favour.  However, it’s certainly an excellent little bit of kit for the price.

I’m still trying to think of actual GPIO based projects that I might want to use in real life, but I’ve now come up with an idea that is at least a step up from just making LEDs flash in pretty patterns.

Several  years ago, I wrote (and then, over the space of a few years, gradually modified) a simple little tea timer script.  As I recall, it started life as a shell script but was soon reworked in Python and has remained in that language to this day.  There are plenty of tea timers in existence but none of the ones I could find did quite what I wanted (which, initially, was mostly to allow me to run it from the command line without a GUI environment to hand, although I later added a GUI option too).

My script works reasonably well and I still use it occasionally, although these days if I want a countdown timer (whether for brewing cups of tea or other purposes) I usually reach either for my mobile phone or my mechanical kitchen timer.  However, one problem I always found with it was that it’s all too easy to miss the alarm bleep and the console message or dialog box that appears when the timer is finished.

It occurred to me the other day (or perhaps it was this morning?) that a nice shiny LED to indicate when the tea is done would be a lot more eyecatching and, with the Raspberry Pi’s GPIO facilities, it wouldn’t be very difficult to set up.  In fact, I’m intending (once I get home to my electronics stuff) to rig up two separate LEDs – one (probably red) to shine while the timer is operating (to show that it’s working) and the other (probably green) to switch on when it finishes.  I may further refine it by making the first LED flash as well if you don’t switch the timer off after a minute or so.

Due to the nature of the hardware and software involved, it’s unlikely to be possible to produce a very accurate timer, but it certainly should work well enough for purposes such as brewing a cup of tea.

Another slice of Pi

I mentioned the other day that I’d got myself a new Raspberry Pi computer and promised to say more about it soon, especially the fun I’ve been having with its GPIO port. This post was slightly delayed due to the pressing need to write about other Pi-related stuff at the end of last week, but here it is now.

GPIO (short for General Purpose Input / Output) is the name for pins on various integrated circuits (or chips) that are available to be programmed by the user. Essentially it’s a convenient way to interface your chip with a wide range of hardware. The Raspberry Pi FAQ defines GPIO as “a pin that can be programmed to do stuff.”

The Broadcom BCM2835 chip at the heart of the Raspberry Pi has 8 GPIO pins (as well as several other pins that are accessible by the user for various purposes that I haven’t yet figured out) and a nice, shiny 26-pin (IIRC) connector to make all of the pins accessible. Unfortunately that includes about half a dozen pins that can fry your chips if you connect stuff to them. Also, it’s not terribly convenient to connect wires directly to these pins. For these reasons, I decided to invest in a cheap, simple and potentially extremely useful accessory called a Slice of Pi (NB I have no connection to Ciseco, the company that sells this product, apart from being a satisfied customer). This is described as a “breakout board” and plugs in to the GPIO port on the PI, providing nicely labelled female connectors (i.e. sockets rather than pins) for the pins you can usefully use while hiding the ones that are liable to destroy the processor.

The Slice of Pi comes as a PCB with a bunch of loose connectors that need to be soldered into place. As well as being, presumably, slightly cheaper for the company to produce, this gives you the flexibility to only include the connectors you actually need. Fortunately it is not a particularly difficult soldering task to assemble the board, as my soldering skills are not the greatest.

Armed with my new Slice of Pi and a bunch of electronics stuff that I’ve had for years (since a previous occasion when I got interested in electronics), I have been able to wire up a few simple circuits to test out the GPIO capabilities of my Pi. So far, this has amounted to a few LEDs and a switch (plus a bunch of resistors and some wires) and all I’ve done with them is to make the LEDs flash in pretty patterns (hopping from one pattern to the next at the press of the switch) but I look forward to being able to move on to bigger and better things soon.

Pi Led #3

On the software side, the GPIO port is controlled by a library for your programming language of choice. At least, I assume there are GPIO libraries available for several languages. So far I’ve only looked at Python, which is the Raspberry Pi’s language of choice (and the reason for the “Pi” bit of the name, although they don’t tie you into using just one language) as well as one of my own favourite programming languages (and probably my strongest, to boot).

Having accomplished my first goal of getting the Pi to flash LEDs in pretty patterns, my next task is to figure out some actually useful things to do with the GPIO port.

A tasty slice of Pi

Last year I was quite excited to hear about the new Raspberry Pi, a computer designed to be small and cheap. Its main aim is, apparently, to provide an accessible and stimulating route into computer programming for young people (rather like the ZX Spectrum and other microcomputers of my youth, although I’m not sure if that was one of their design goals or just a side effect of the fact that you had to type in commands just to get a program to load and the easy accessibility of a programming environment if you wanted to take things further) but it is also a quite capable general purpose computer. The thing that most immediately attracted me to the Pi was the presence of a GPIO port, allowing easy access to hardware control.

As with several other items of new technology, including my Android phone and my Kindle, I waited until I had got my hands on one or two Raspberry Pis (or Pies – I’m not sure if there’s an official plural form) belonging to other people before I purchased one of my own. In many ways this wait served me well, as they doubled the amount of onboard RAM fairly late in 2012 and so, by waiting until the cusp of the new year, I ended up with 512MB instead of 256MB. Mine is a Raspberry Pi Model B, which comes with a built-in ethernet adapter and 2 USB ports so is (IMHO) well worth the extra cost against a Model A (about £10 cheaper but with 1 USB port and no ethernet – actually I don’t recall seeing any of those for sale, so I don’t know if they are still doing them).

The Pi comes with composite video and HDMI outputs for graphics. Unfortunately I don’t have a TV at home (to use the composite video signal) and my monitor is VGA-only (for which HDMI adaptors are expensive). Also I didn’t, until last week, have a USB keyboard. This meant that I couldn’t plug my I/O peripherals directly into the Pi and have had, instead, to resort to running it headless and accessing it via an ssh connection from my PC. This is no great problem except that my PC is in my bedroom, my router is in the kitchen and I therefore have to keep running in and out to get to the Pi (or I could trail an extra-long network cable through the house but I’d rather not). I have now procured a USB keyboard and have an HDMI cable with DVI converter on order, so that I’ll be able to take the Pi into work (I have a DVI-capable monitor in my office) and play with it directly during my lunch breaks, but for now I’ll be sticking to headless / ssh use when I’m playing with it at home.

To start with, I decided to run my Pi with the recommended operating system – a customised version of Linux called Raspbian (which, as the name suggests is based on Debian, one of the most established Linux distributions). I’ve been running Linux, on and off, pretty much since I first got my own PC about 12 years ago and it (in the flavour of Linux Mint 11, aka. Katya) is currently my main OS on my home PC, so Raspbian is pleasantly familiar. At some point, I may try out one or more of the other Pi-based Linuxes (or Linuces or whatever – again, I’m unsure about the plural form). If so, I’ll probably wait to get a new SD card first. One of the attractions of the Pi is the fact that all the software resides on an SD card, so you can effectively have a different machine set up just by swapping out to a different card. One of the ways I can foresee playing around with my Pi is to have several different versions of Linux set up on different cards with a nice stable one (probably Raspbian) I can fall back on and others to be more experimental with.

As I mentioned before, the thing that first drew my attention to the Pi was the GPIO port and, indeed, I have already started to play with that. Since this post is getting a bit long, I’ll postpone further details for a bit.