A Blog of Very Little Brain

'What does Crustimoney Proseedcake mean?' said Pooh. 'For I am a Bear of Very Little Brain, and long words Bother me.'

Archive for the ‘Programming’ Category

Test-Driven Development, cyberpunk version

leave a comment »

From the OneTrueWiki:

add a test, get it to fail, and write code to pass the test

From Blade Runner:

Tyrell: Is this to be an empathy test?
Tyrell: Demonstrate it. I want to see it work.
Deckard: Where’s the subject?
Tyrell: I want to see it work on a person. I want to see a negative
before I provide you with a positive.


Written by Erez

Monday, August 25, 2008 at 20:37

A Quick One while He’s Gone

leave a comment »

The Real Dan Lyons in his blog lays down the word about Microsoft hiring Jerry Sienfeld:

This is Ballmer in full-blown Detroit mode trying to make the latest clunker seem cool by paying Dean Martin to drive one.

How do you encourage Perl programmers to read a dry summary of ways to better use the do or die state of defensive programming? You title it with a Star Trek reference, in this case, “autodie – The art of Klingon Programming“.

If you haven’t done so yet, pick up a free afternoon, and read FreakAngels‘ book one. It’s Warren Ellis’ latest, with excellent art by Paul Duffield. it’s free, and it’s that good. Then go and order the book, so we’ll get more of this.

Written by Erez

Friday, August 22, 2008 at 16:28

Posted in Comics, Programming

Tagged with ,

I am community, hear me roar.

leave a comment »

Only last week I pointed that Trying to build Moose-depending modules was problematic since there isn’t a Perl 5.10 ppm package for it. I also commented thus on the Monastery.

Less than a week later, lo and behold, Moose has been built on ActiveState Perl and can be downloaded from here: http://cpan.uwinnipeg.ca/dist/Moose

Written by Erez

Sunday, August 17, 2008 at 16:28

Posted in Internet, Programming

Tagged with , ,

I agree to disagree with you

with 6 comments

Having advocacy spoken in your cause is good, until you realise that the advocate may express similar opinions, but use different arguments, some of them contradicting your own, to a point of dispute.

Jonathan Rockway, of Catalyst andblog, made such an argument (emphasis mine):

So finally to the conclusion. If you are like me, most programming you do is about gluing things together with libraries. Perl may not be the prettiest language, but we have so many libraries that you won’t have much time to see the ugliness. This is the reason why people stick with Perl, even though other languages have prettier syntax. It is so easy to get stuff done, and contribute your “stuff” back to the community, that we never even worry about the ugly syntax. It just goes away, and all we think about are solving our problems

I mean, thanks. “Yes, Perl is ugly, and Yes, I would’ve dumped it if I only could, and Yes, I feel like gorging my eyes out every time I use it but, those damn Perl Hackers just filled CPAN with so much stuff, that I can’t.” This isn’t “Perl is good”, but “Perl is bad, but CPAN makes it worth your while”. I’ve only skimmed the comments, but the names “Java” and “python” have already been spotted a couple of times.

try searching for your favorite programming topic on search.cpan. You will probably find that your problem has been solved in an easily-digestible library form. Clicking a few links just saved you from a week of coding

For some, the huge monolith that is CPAN is more a curse than a bless. Suppose you want to work with XML, how do you know whether you want XML::Parser, XML::Twig, XML::LibXML, or any of their derivatives? Suppose you finally settle on XML::Simple, and after a while, encounter some issues, you’ll then hit some newsgroup/forum/mailing list only to find out that you should “not use XML::Simple”. The rule of thumb when it comes to using CPAN is “familiarity through usage”. The user is expected to leaf through the dozens of seemingly similar modules and select that which looks the most fitting to his problem. If said module comes short, and with the knowledge of which features he really need, the user is then returning to CPAN for a more focused search, until the golden pot is struck.

Not that there’s anything wrong here, mind you. This process is essential to good software development. Learning about your problem is crucial to finding the best solution to it, pin-pointing the important features you need from a module is another good step. After all, if you only need something to test for whether the XML is well-formed, it means that a: any basic module will suffice and b: XML parsing isn’t one of the major problems of your program.

However, this attitude can also deter people from using CPAN, and coupled with the “Perl is ugly” stereotype, one get the feeling that maybe its better not using Perl altogether. The point I’m trying to push forth is that CPAN is a blessed occurrence, and once used, can’t be underestimated, but Perl true power and, dare I say, beauty is in the syntax.

In a nutshell, Perl was designed to be a programming language that is constructed as a spoken language.

Everything about it, all the “ugliness” that you might find: the “sigils”, context-based interpolation, the integration of functions as keywords in the core language, you name it. It’s all ideas that come from spoken language, and implemented in Perl.

This way, when you speak fluent Perl, you can express yourself better, make better use of the language, and truly fit it to your way of thinking, in a way no other language can. And it got an amazing modules library.

Written by Erez

Thursday, August 14, 2008 at 8:40

Posted in Programming

Tagged with ,

Code and back again

leave a comment »

A recent discussion over at the Open-Cobol mailing list have brought up some nice gems.

My generation learned COBOL not from textbooks but from vendor manuals
and also a set of tutorials in the form of programmed texts called the “IBM green books”
(they had green covers). Programming was an apprenticeship business back then.
We learned from each other.

Comparing the world of today’s corporate programming, of which I am a part, to the world of yesterday’s, from my memories of visiting my mother’s workplace, I can really relate to this description. I would compare this to any person studying a profession and practice, but not being actually familiar with any of the tools and application they’ll actually use. These days, of course, basic to advanced courses are required in any computer-based tool, from OS and Office suites, to the tools-of-trade and assisting applications.

> > I would state that a simple Hello World Program in COBOL has become MUCH simpler
> > than his example. We no long are required to have all those sections or even the
> > preceding line numbers.
> Yeah, on the opencobol.org forum (and in the soon to be unveiled FAQ), hello world is as
> short as:
> program-id.hello.procedure division.display "Hello World!".

There was a language in my youth called APL whose fan base revelled in creating one line
programs. I hope COBOL and its fan base has not been reduced to that level.
An important and unique feature of COBOL is that it was designed to be read as well as written.
It is intended to be a self-documenting language. While recent versions have strayed far from that
original concept the thought of reducing a sample program to one line is a violation of one of the key
features that makes COBOL different from other languages. Just because you can do it doesn’t mean
you should do it.

COBOL was conceived as a language that will have a syntax that will allow non-programmers to be able to read it, and for the programmers to easily translate the non-programmers pseudo-code’s logic to a program. This resulted with PERFORM READ-FROM-FILE UNTIL END-OF-FILE and EVALUATE USER-INPUT

But it also caused the language to become encumbered with the actual semantics, where any action requires a long description, maintained in several parts of the code simultaneously. Over the years, attempts were made to include more advanced features, while, on the other hand, reduce the amount of text needed to be used. It would seem that Open-COBOL have dropped everything but the actual commands, giving a slim version of COBOL, which might do it the justice it needs (if only it was compiled to byte-code rather than to C).

Another interesting element here, is the writer’s reference to one-liners and APL. This is a well known argument against Perl’s supposed unreadability, based on its one-liners, obfuscation and “programming golf” challenges. I, however believe that these, and other traits of the language are a virtue. A programming language with an English-like verbosity, that has an ability to use the shortest programming form, the “one-liner” as an expression method. Apart from the constrains of style and practice, this, is the true strength of Perl, the ultimate freedom of expression in computer programming form.

Written by Erez

Tuesday, August 12, 2008 at 16:12

Posted in History, Programming

Tagged with ,

Strawberry Perl forever

with one comment

…maybe not “forever”, though, but it did (Eventually) did good.

I moved the installation to “c:\strawberry” as dictated by the manpage, and made sure to set the path variables to the correct places. (Also, I’ve added a path variable to MinGW’s bin folder, just to be on the safe side). Then, I tried installing the modules that were acting up originally, which was mostly successful, apart from Tk. Installing it turned out to be a bit of an issue.

A quick search later, and I got some general complains, and even more general solutions, until I hit pay dirt (http://rt.cpan.org/Public/Bug/Display.html?id=13923):

I built Tk via the strawberry perl distribution today. I also had the
“missing file”. The file was not missing, but rather there appears to
be a relative path in Xlib.h at line 1206

#include "../pTk/tkIntXlibDecls.h"

but xlib.h is at C:\Tk-804.027\pTk\mTk\xlib\X11
and there is not pTk dir up one directory.
if you create a pTk dir at C:\Tk-804.027\pTk\mTk\xlib\pTk
and put tkIntXlibDecls.h and lang.h there the build will complete just

Really weird stuff, but it actually worked. After performing the movement, and re-running Makefile.PL, I managed to build, test, and install Tk, which means I now have, hopefully, all I need.

Written by Erez

Monday, August 11, 2008 at 16:26

Posted in Programming

Tagged with ,

We’ll call it a draw

leave a comment »

Previously on “why I no longer think Windows users complaints about Perl are unjustified” I found that installing anything not in ActiveState‘s PPM repos is altogether broken, and, while preliminary tactics worked, at least initially, it turned out that, in the long run, the house always wins. What I thought was a successful installation turned out to be a successful botch-up, with lower level dependencies, such as Moose, not being installed. Attempting to perform the same operation on Moose was apparently the last straw on the side of ActiveState Perl, and that failed miserably. In accordance, I gave up on them and removed the distribution from my machine.

Fortunately, there are other alternatives. Strawberry Perl is one of them. Unfortunately, many of those aren’t mature enough. Strawberry Perl is one of them. For starters, the installer file asks you for a Start Menu path, then begins installation in C:\Strawberry\. While I’m aware that Windows users are accustomed to their computer being treated like the local dump (i.e. everyone throws their garbage wherever they feel like), but I would like at least a minimal control over where I place (some) of the files. Extracting from the .zip file is no better, as all the paths have been hard-coded to the same “C:\strawberry” path.

It is often said that, when it comes to user-awareness, F/OSS projects show the same care and attention of a Soviet tank. Concepts like “Here’s the mailing list, the IRC Channel, the USENET group and the Bug-Tracker, good luck” tend to shirk away non-technical users. On the other hand, Windows users tend to fall on the less-savvy side, and, in accordance, Strawberry’s support page directs to the IRC page, the community site and the mailing list. Oh well.
Of course, users of Perl are, probably by definitions, tech-savvy, so this might not be a correct criticism. OTOH, even a bare-bones hardcore Perl programmer would appreciate some manner in which to reconfigure the distribution’s hard-coded paths, rather than search for every appearance of c:\strawberry (or c:\\strawberry, or c:/strawberry, etc), and replace them.

I’ve rummaged for a while in the files and folders in the distribution, and then checked the site. In the distribution’s CPAN page, I found these comforting words:

At present, Strawberry Perl must be installed in C:\strawberry.
Users installing Strawberry Perl without the installer will need to change the environment manually.

Oh dear.

(…to be continued)

Written by Erez

Monday, August 11, 2008 at 13:15

Posted in Programming

Tagged with