The Adventures of Emacs the Viking

This is another article in my attempts to find new ways of looking at PHP and making it less of a chore to type in all that code. As much as I love PHP I hate wasting keystrokes. More typing is more errors is more grief. Being an off and on user of Lisp, although not as much as I used to, one of the things that I always liked in Lisp was the ability to be able to return multiple values from a function at once using (values) and then marry that with (multiple-value-bind) to create convenient named bindings for whatever you were about to do. I recently found myself wanting to return a couple of values from a helper function and I just didn't want to go to the trouble of having to type all those character required to create an array with keys for the two values and then I remembered MVB and a little light went on in my head! If somebody else has already done this then I apologise up front but it was new to me and I haven't seen it anywhere else so this could be a first! ...

I decided recently, while starting a new project, that it would be interesting to try and take some of my new found paradigms from Haskell back into the relative slums of PHP. As much as I like the fact that PHP just works, the more I get into Haskell the more I resent having to type reams and reams of code in PHP just to get things done. That's just me and I won't change! One of the things that I am really starting to miss now that I understand Monads (at least enough to write them and use them, my own and the libraries) is the ability to be able to have "Maybe". It is such a lovely way of handling data when there really isn't anything and it sure as hell kicks ass over using "NULL" as a return type. PHP is riddled with functions that return FALSE to mean they didn't actually work or some other value if they did which makes a whole mockery of its so called "types". Case in point, when using PDO for example (I could be w...

I recently had the task of learning how to implement our internal company PHP coding standards documents which exist only as a set of JIRA pages into something that could be integrated into the subversion pre-commit checking phase so that not only does code have to be syntax error free, it now also has to adhere to the coding standards. I remembered reading about PHP_CodeSniffer (PCS) and volunteered to "have a look" and see if I could implement one of the more simpler standards, our variable naming convention, as a starter exercise. Well, after the mandatory head-banging and spike in coffee consumption that accompanies learning new stuff, I became very impressed by the way that PCS actually does what it does. It builds upon the token_get_all()   function and creates not just an array of tokens and there positions but it also figures out (I read the source for half an hour!) which bits of code are contained within other bits of code; in other words the context within which...

Having now released my own programming language, FELT , and learned a lot about this and that in the process I have of late, in the evenings, been struggling to reconcile my love of LISP and how simple FELT makes some PHP coding task leaner and meaner with the fact that I still have to use PHP for my day job. In my language, FELT , I have used the square brackets to define a "normal" array and curly braces to define a "key-value" array, mainly because this is identical to JSON format and anybody familiar with Javascript coding just won't have any issues getting to grips with that now will they! Let's take some simple examples of FELT code: (defvar simple-array [1 2 3 4]) (defvar simple-map {:name "Eric" :age 42 :occupation "Viking Hacker"}) When FELT has done its thing, we get the following PHP code, $simple_array = array(1, 2, 3, 4); $simple_map = array('name' => "Eric", 'age' => 42, ...

Some days it's hard to really appreciate what a software developer is or does. And I have "been one" for over a quarter of a century and I still don't know what I do. I can translate management speak into meaningful English and then understand what "they need" as opposed to "what they think they need." I can translate "business requirements" into an internal mental model composed of data stores and processes and subsequently translate that model into "working code" in any language you care to mention to produce a "deliverable". But... I still don't truly understand what happened along the way. I think it is more to do with the underlying nature of the universe rather than the mechanical processes. Codds rules and normalisation for instance, one can learn, understand and apply these rules to great effect but what does "de-normalisation to 2NF" mean to a bunch of atoms and molecules which don't...

The compiler dutifully informed me that: case error_logger:logfile({open, ?IMP_LOGFILE} ) of was giving out: /imp_scan.erl:137: syntax error before: '}' ...and boy did I end up scratching my head until finally, applying Rule #1 (you spelled it wrong) coupled with the Holmes conjecture I realised that (a) I was indeed wrong again and (b) the compiler was correct and here was the problem: -define(IMP_LOGFILE,"/tmp/impscan.log"}). Yes, having decided that the string was best made a constant I refactored the code and accidentally left the trailing closing brace in the macro, hence my confusion! The error message was referring to that brace but because the parameter was itself a tuple I had become confused. Just another day on the job. PS: As I like to call it, the "Holmes conjecture", How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth? .

Some days this job is so hard. No amount of soothing music, coffee, snacks, socks off etc. manages to bring your head back into that "special place", some call it the "zone". Today is one of those days. Perhaps it stems from the fact that I find myself having to work on something that is just looking pretty pointless right now. Not even the fact that it's Erlang seems to be lifting my spirits today, not even the fact that I don't have to touch PHP with a barge pole is even raising a smile. So what is the difference between a "good day" and a "bad day" as a developer? You'd think that after twenty-six years doing it I'd have some idea. I think it relates to a sense of purpose and corresponding sense of achievement. When you perceive that your efforts are actually not going to be in vain; when you perceive that you are being "useful", "effective" and ultimately that you as a person are being "valued...