Editorial
“If Lisp is not a mainstream language, why are we using
it as the framework for our discussion of programming?
Because the language possesses unique features that
make it an excellent medium for studying important
programming constructs and data structures and for
relating them to the linguistic features that support
them. […] Above and beyond these considerations,
programming in Lisp is great fun.”
Structure and Interpretation of Computer Programs – A. J. Perlis
Some people love to collect stamps, some others prefer empty bottles of beer, some have a soft spot for dolls and some would be dead without their weekly intake of comics. I adore programming languages. Thanks to the internet I can indulge in my passion of finding new programming languages, studying them, possibly even try them and learn as much as I can not so much about the language itself, but about the reasons that justified its creation, its peculiarities, its unique strengths. Most important of all, in fact, it’s the attempt at learning new techniques to solving problems, techniques that may prove useful in other contexts. This hobby of mine is not particularly new. It dates back the days when I first discovered that computers had programming languages that I could learn. It exploded like a disease when in my university days, I first used a terminal with a connection to the Internet. I was really amazed when I found out that there were so many programming languages that one page couldn’t list them all and, more, that new ones were being added all the time and that (oh joy!) of many of them existed completely free implementations. At the time I was about to get my master in Physics so I should have taken a more practical approach to computing, but because of the morbid fascination I had, I just fell in love with any new language, useful or useless. Now that I am a professional developer I have somehow adjusted my aim and my sensitivity: what I look for when I come across a new language is the thrill of the unexpected and the untried but also some sort of applicability. The meaning of “new” is of course “yet unknown to me”, since in the last 3 years, for the first time I’ve come across languages already some 25 years old, and still very interesting. It’s a somewhat late realisation the meaning I give to “applicable”.
When I tried to collect ideas for this editorial, I discovered much to my surprise, that what I am looking for in a language to make me consider it interesting for anything more than academic theories (which I also enjoy a lot) is an extensive set of utility functions to perform what are normally considered trivial tasks or, otherwise, to communicate with the outside world. An example should make this foggy definitions clearer. We have a collections of files and we want, without the aid of archiving utilities, spread them over a set of floppy disks, in such a way that the slack empty space left is minimal. If you think that the problem is somewhat outdated, then let’s substitute the words “floppy disk” with “CD-ROM” to have a problem I have to solve at least once a week. Let’s imagine that we found an amazing programming languages whose engine is based on a really cool optimiser, with a simple and intuitive syntax which makes writing the solution almost trivial. Alas, this dream language doesn’t have in its standard library a function to read directories from storage facilities. True, it can read ASCII files, so we could redirect the output of a dir command to a file and post-process it, but it starts being messy and our (well, my) excitement for the language has decreased and our trust has subconsciously started to fade.
Here’s a suggestion for your next rainy Sunday afternoon. I suspect that if you live in England you won’t have to wait long for it to arrive even if it’s summer… Download the documentation for the standard library set distributed with languages like Perl, Python, Ruby, Java, SmallTalk, Visual Basic, C#, SML, a good implementation of Forth, Delphi or Erlang. Not only you’ll find that they have functions or objects or modules, depending on the paradigm used, to give you complete control over the files on your Hard-Disks, starting of course from the list and their sizes, but that they have XML parsers, SOAP producers and consumers, ODBC bindings, matchers for regular expressions, lexers, parsers, network bindings, advanced GUI building capabilities, CGI extensions. They can interface to mail servers as well as web servers. They can talk to your DNS, they let you interface to 3D graphical libraries, they can play music, they let you write with minimal (OK, this last is a lie, but only just) effort distributed applications. And if the mentioned capabilities are not in the standard library set, then there’s at least one website which collects public extensions to the library where it doesn’t take long to find a working implementation of the exotic protocol that you have to interface to. For some languages it’s possible that the implementation of the funny protocol is a commercial one, but it’s definitely there and not even that expensive.
What about APL?
I could stop here, but it wouldn’t be fair. I am not the first one to lament a serious lack of a library of APL workspaces to accomplish the most trivial tasks as well as the sophisticated ones. Not surprisingly, around the most recently born APL dialects a library is being built, thanks to the support of the vendor itself, but also thanks to many volunteers. It’s almost heart-warming to see a complete regular expression engine in the standard J library, as well as fairly complete OpenGL and ODBC bindings. It’s nice to see a powerful set of functions to produce graphics. It’s cool to have basic bindings to network services. There’s still no trace of SMTP, POP3, FTP, HTTP, LDAP (to mention a few popular internet protocols) support, no XML, no SOAP, no ORBA, no compression, no encryption, but it’s clear that things are moving in the right direction for the J community. I am not blaming Dyadic or Cognos because they don’t invest enough in libraries: they are market-driven and they do what they can with their resources.The blame goes to all those who complain about the poor acceptance level of APL and yet stick to the tradition of leaving things as they are. I am amongst those. In a recent issue of Vector, Adrian and I showed how it was possible to use a free library to do data compression. We could have spent time refining the solution, and packaging it as a ready-to-use set of functions but using as excuse the chronic lack of time of a professional, we left it at the stage of proof of concept. Nobody took it from there to complete it, though, so we are in good company.
Actually, the kind of refinement I am talking about is not something one person can do on his own. First, there need to be versions for at least all the Windows’ interpreters available. Second, the proposed solution must be used by other parties who must send feedback to the original author, possibly even send improved code and documentation. And yet it all must remain freely available for public consumption. Impossible? That’s how the impressive libraries accompanying Perl , Python, Ruby (and so on) grew. People had a problem to solve, did it themselves, did not accept the idea of their work being duplicated over and over, wanted to show-off and donated it. Over the years a brook carves a canyon… And the project in which the original library was used, improved in quality because of the works of the others who took over the component. There’s always somebody more talented than you are in at least one area and it’s a waste not to let him help you if he’s willing to.
We all have our small set of functions to read a directory list. Some of us built interesting operators which are the equivalent of an each on a list of files, recursively generated to span an entire subtree. Why don’t we refine them and submit them to a public forum? I know the answer already: no time to refine anything “I only do stuff I am paid for and my boss wouldn’t let me donate my code”, and lack of a properly moderated forum. I am not the first one to propose something like this, although I have the impression that in the past the focus was more on more basic algorithms, such as clever ways of removing trailing blanks. That’s also very interesting and it matches perfectly the spirit of the project. But it’s no longer enough: to be palatable APL must be presented to the potential new user with a library to perform tasks that, even if not in the spirit of the language, are fundamental to build even the simplest complete application. Careful though: I am not saying that somebody should write an XML parser in APL. We all know that a fully compliant XML parser implemented in APL would perform so badly that nobody would want to use it. It’s OK to cheat in these cases. I’ve already praised the beauty and the power of quadNA and foreign functions (Java, .NET). We could have a simple-minded XML parser implemented in APL to play around (there’s one already implemented in K) and another one based on external bindings for mission critical applications.
Isn’t it a contradiction to wanting to spread APL but not APL code? How are the future APLers supposed to learn? There are hundreds of thousands of lines of good public Perl code, code that can be used to learn Perl as well as learn about the problem whose solution is coded. Once I have understood how to extract simple information about a JPEG encoded bitmap (such as width, height and so on) by reading the source code of a JPEG decoder written in Java, actually, of the JPEG decoder provided with the standard Sun Java SDK.
I cannot do much more than to throw the idea in the arena once again hoping that the times have matured since the last proposer did the same and that the bright success stories of the other programming communities can inspire us. I can even propose myself as a coordinator ad-interim till a better one is found, confiding in the understanding of my boss. You know how to contact me.