Prioritisation of Panic

Let me start off by asking the folk on this platform one question. Imagine a scenario that you had lost something important with multiple potential negative consequences. For instance losing a bunch of keys including your car keys, your house keys, your changing room locker keys and a USB stick. What would be the greatest cause for alarm? I suspect that while there may be many possible answers aligned with each individual’s life priorities, the real men in this group know that the most feared is the reaction following the revelation to the wife. For while any calamitous occurrence may be approached objectively, with rationality, reflection and hopefully recovery, this particularly troublesome phase involves heightened emotions, reactivating Mrs Saif’s indelible memories of my many past failings. Objectivity, while desirable in principle, has to deal with such a tainted history.

I won’t elaborate further on my survival. I have survived. Barely. Indeed, over the years I must have acquired as poor an ability to remember traumas, as Mrs Saif is good at recollecting them. I haven’t figured out whether it is a natural self defence mechanism shielding me from PTSD, or whether it is a blessing that with age comes a little deafness, poorer eyesight, slower reactions and a reduced residual capacity of my intra-cranial hard-drive. But either way my poor wife’s vain attempts at reforming me, making me a better me, is met with the resistance caused by my irritatingly chilled attitude, constantly in perpetual denial of any need to change, and being so easily distracted.

This experience may help understand the general antipathy or indeed apathy towards any radical change from that which had been established over years. Objectively, a modern object orientated infrastructure within the core appears desirable. But such a goal is not a well defined endpoint. While there are a number of excellent bolted-on frameworks in CPAN, there are differences in priorities and performances. Entry of this form of modernisation into the core without upsetting core values is always going to difficult.

But this work is even more difficult for the poor core developer working on this task. He relies on feedback, without which he finds himself providing a valuable community service without any indication of what the value of his efforts is to that community.

So I decided, while watching a rubbish, inane but ludicrously popular game show, that for once I will make an effort. Not a personal resolution to be more responsible (apologies to Mrs Saif). I am too old for that malarkey. I will use Object::Pad. I will try and replicate this game in an attempt to learn this new way of programming. I will try two things…Firstly by emulating this game using easily identifiable objects, secondly converting a module I have been using into one using Object::Pad. Then I will report back my personal experience of this style of coding. As a disclaimer, I have only ever used classical packages in Perl so am unable to compare with Moose, Moo, Venus etc. I am also as messy at coding as I am in my head.

Deal or No Deal

A simple game where the player has to only answer one question to win money, while captivating one half of the audience, and mystifying the other half at how this could possibly be called entertainment. It seems simple enough to code. We have a “Game Board” object, containing a series of “Box” objects. The boxes each contain a random “Money” Object. A “Banker” object and the game board interact with the player via Objects representing the “Display” and the keyboard “UI” derived from old packages I have lying around. These objects may each have methods for drawing or undrawing themselves, or sending a message to the player, and responding to the players choices.

My effort has been so far remarkably smooth. Using signatures, auto-magically generated setters and getters has made this a remarkably straight forward and efficient process. The game is not yet complete…the biggest attraction of this game is not the challenges it poses but the “banter” and the suggestion that there is any skill or strategy involved. A reasonable algorithm for identifying what the banker should offer would also be interesting. My next post, once this game is completed, is a little review of how the whole experience has been for me, the visible benefits and drawbacks if any.

“`

As a bystander in the evolution of Object-Oriented Programming in Perl, and someone who is really only just starting to get the hang of Perl modules and packages (still not any good at it), I get really quite overwhelmed by ideologies. There is considerable debate about the right way to program things, the right style, the right direction that Perl should go. It is Vim vs Emacs, Atari ST vs Amiga, Mods vs Punks. Really one needs a language to do what one needs it to do, simply, quickly and consistently. For an amateur, Perl has been able to do exactly that for me. I code rubbishly, but hey, who's looking?

But when you look at the clever people in the Perl community, you wonder. You wonder whether you are missing out by not being engaged in the evolutionary process. It is bewildering. I confess I understand a mere fraction of the terms, the rationale, the higher order coding discussions. I have read about Corinna, marvelled at Moose's capabilities, gazed admiringly at Leonerd's prowess, but do not dip my coding toes into the water. You see, I cant swim.

But every body is like, "the water is warm and safe", and "c'mon, Saif, there are no trolls here!".

Ok, ok, let's start in the shallow end. I once had a plan for a collection of "PerlayStation Console Games" (you see what I did there?). Arcade Games for the terminal written in Perl. I could resurrect that while learning "proper" OOP...POOP! But I still have to figure out Slots, Roles, lvalue, (*gasps for air*).

Let's have a plan. Breathe. The way one might develop Perl modules, is first write code without modules that works, sort of like a feasibility test. Then, perhaps separate parts that can go into a module. That module is reused in other projects, and in doing so is tweaked to allow the extended capability. A successful module can be used portably across projects. Then the same program is developed using classes in other OOP paradigms, say Corinna, then perhaps Moo,etc.

Pong was developed, a game with Sprites. The sprites contained position and motion data and the info required to draw the sprite, all contained in a hashRef, which could be passed to subroutines for processing. e.g my $sprite={x=>10....};. This was a deliberate precursor for later conversion into a blessed object e.g. my $sprite=Sprite->new(x=>10,...);, all in all a seemingly painless transformation. The sprite modules that were created from that were initially classic Packages, then eventually as classes using Object::Pad. If I can figure it out I will also use Moo. For the moment the code versions remain monolithic until we have tested it/extended it enough.

Then we measure. Ease of use, readability, code length, performance and other parameters, trying to OBJECTIVELY determine whether to dive in and enjoy the waters, or just stick to shore where it is safe.