Tools for Reading, wRiting and aRithmetic

The 3 Rs are the basis of education. So fundamental are these skills I inevitably use, improve and enjoy them daily. The tools needed to perform them vary, but I currently favour the following:

3rskit

Reading: Amazon Kindle

Like the Portable MP3 Player's effect on music collections, portability has changed the way I consume writing. I often have three books on the go (programming for work, something educational and a novel), I read as I walk to work and have the kindle within reach pretty much the entire day. I still have plenty of physical material, but having my entire library at hand is a real luxury. I'd be very surprised if the momentum of e-reading doesn't equal that of portable audio soon. The kindle is simple, light and lacks the distractions offered by more complex devices. Mix in some Slow-Media philosophy: using long-form reading tools like Instapaper and custom Hpricot scraping scripts, you can read web-content away from the distractions of a PC.

wRiting: Squared Whitelines Notepads (1 A4 Wire Bound, 1 Pocket), Pencils and a Kum Automatic Longpoint Sharpener

Notepad and pencil are a simple, effective, low-tech, way to record ideas. Electronics are fragile (Kindle included), transient and, comparably, hamstrung by their inputs. Tablets may be improving, but drawing and writing are elegantly straight forward and tactile the old way.

I like to have a slim, pocket, notebook to hand at all times for quick use. Moleskin's Cahire and Field Notes are great, but, to me, Whitelines are the best match with an HB pencil for readability. An A4 pad is essential for prolonged note making. I prefer squared paper as it suites diagrams, notes, equations and can be used in any direction.

I'm still experimenting with pencils (recommendations welcome), although most HBs will satisfy (I know many readers will have favourite pens, but there is a unique charm to the humble wood and graphite pencil). It is the sharpener that I think makes the largest difference, thanks to Brendan Dawes, I've discovered that Kum's Automatic Longpoint Sharpener is a cut above any other I've used. Seriously, you may scoff but it's properly cool.

aRithmetic: HP-12c Finance Calculator

My wife rolled her eyes at discovery of my HP-12c finance calculator. It looks dated, for the uninitiated, the reverse-polish input is hard to operate and it's expensive (compared with bog-standard models). But this calculator is a classic, a design that has barely evolved in the last 30 years. It hasn't changed because it doesn't need to. Scott Locklin gives a better account than I, and the mechanical Curta could be a worth contender, if I could get my hand on one.

These tools all have a certain low-tech appeal, even the kindle. They feel like a gentle antidote to the hectic computing environment in which I spend most of each day. Although the HP-12c and Kindle are digital, and require power, they do not flicker, beep or emit light - and are, largely, dependency free (provided the Kindle is amply stocked). In combination, I feel that they could provide a life-time's worth of insight and enjoyment. Throw in a reliable solar charger and these tools could make a desert island a very enjoyable place to be marooned.

Tagged learning reading tools

Functional, TDD JavaScript (influenced by Haskell, Lisp, Erlang...)

Having developed a taste for Functional Programming (FP), I've found that there are many aspects that make building software in a TDD style easier. Functions are the basis of FP, a function that takes arguments and returns values is easy to test. If this function is side effect free (i.e. doesn't effect the program from outside its internal scope; has no infulence on, or effect from, state), you can be confident that that function will always work the way your tests expect.

// SIDE EFFECT FREE
fAddOne = function (num) {
    return (num + 1);
};

test("fAddOne", function () {
    eq(fAddOne(0), 1);
    eq(fAddOne(1), 2);
});

// SIDE EFFECT DEPENDENT
obj = {
    num: 0,
    pAddOne: function () {
        this.num += 1
    }
};

test("pAddOne", function () {
    obj.num = 1;
    obj.pAddOne();
    eq(1, obj.num);
});

In the above examples, fAddOne will work anywhere within the app, pAddOne is side-effect based and needs to be called within the scope of an object with a num property. If a refactor in needed, fAddOne, and its tests, can move arround or change applications. pAddOne has some requirements that unit tests don't describe as easily, refactoring will be a little trickier. In effect pAddOne's tests are testing side effects not functionality.

However, the example oversimplifies the problem. In reality side effects are essential, I/O can't be avoided. In (browser based) JavaScript this is usualy in the from of DOM API interaction. In GB.js I attempt to keep a CYOA/GameBook engine independent of side effects, in the demo, DOM building and events are kept to a minimum and try not to overlap. This is fine for individuals working to their own requirements. Teams have different problems; in JS, side effects are easy and the syntax encourages them, in most cases it's easier to just cave in. It may even get work done faster (at first). But, from a Unit Testing perspective quality drops or, at least, refactoring become trickier.

FP is a tool industry could gain more of value from, as does by adopting its features and principals (closures, currying, recursion etc...). The problem for me is blending Object Oriented (OO) and FP styles with TDD. Refactoring and reuse are important, and when a shortcut is made with OO then quality can suffer.

Another gain with FP can be shorter code, but when using TDD with loosely typed languages (JS, Erlang, Lisp etc...) type checking causes length to creep up. While rewriting some of excersises from "The Little Schemer" (with TDD JS) it became apparent that if you want high confidence in the Unit Tests then a lot of type checking happens. This is why I have a set of type checking functions that I use constantly. So, if I'm typechecking a lot am I just re-inserting the type safty of a strongly typed language?

Looking at other FP languages, Haskell currently satisfys me the most. Sepparating  side effects into Monads (I'm still in the process of learning this concept) and using strong typing (and a compiler) feels like it provides real confidence in quality. In fact, by having to decide types in the function definitions there is no need to have tests to cover type safety. So the extra "boiler plate" (that isn't even required by the compiler) can reduce the overall lines of code typed.

I'm hoping that by delving deeper into Haskell's approach I can get a clearer steer on how to construct functional JavaScript applications.

Tagged Haskell JavaScript TDD functional-programming learning

Pocket Programming: Learning New Skills Anywhere

Summer is here, and in a few days I'm off on holiday. Aside from the eating, drinking, sleeping, sight-seeing and reading: it may be a good chance to hone my problem solving and Python skills.

I'll be travelling light, taking in the east coast of Spain. So, any coding has to be done in the most portable/light-weight fashion.

Media_httpwwwjoelhugh_geikz

Here is my pocket sized kit list for an ultra-portable programming environment:

This list is weighted towards to those of you with Symbian phones, but most smart phones have some sort of access to a programming language.

The one of the most appealing aspects of this kit: it is super cheap. The phone was "free" on a 1 year £25 p/m contract, the O'Reilly Book is about £6, pen and notebook another three quid: that's a cheap way to learn some valuable skills.

I'm sure there are a ton of alternative setups (Android, Windows Mobile, Palm, I-Phone?). A bare minimum set of requirements could be: a text editor and a web browser capable of parsing JavaScript (this may be possible on not so "smart phones").

If you're using an alternative setup, or have another way to program on the move, please add it to the comments.

Tagged katas learning mobile python

Which Language Combination?

I'm trying to be a better programmer. I have been writing and learning as much code as I can, the benefits are a threefold positive feedback loop:

  • Learning is, in itself, very pleasurable (it makes you feel clever, which is nice)
  • New knowledge transfers to, and enhances, existing skills
  • New tools and skills provide a greater resource for providing solutions

But, how does a developer know which skills to learn and which languages are best to learn with? (Assuming that you're learning for fun rather than as a work requirement.)

If Google is a good bench mark (assuming that they can take their pick of the best developers), one requirement (taken from an ad for a Software Engineer) asks for:

Fluency in two or more of C, C++, Java, Shell, PHP, Perl or Python.

If you are specifically aiming for a career at Google then making sure you are fluent in two major languages is probably the way to go, and there is certainly no downside to a developer broadening their skill set. In my experience, each foray into new languages has improved my PHP, and in turn, I feel pretty comfortable in Ruby and Python.

When deciding to learn something new: you could argue that PHP, Ruby, Python, Perl etc... are pretty much different brands of the same tool (procedural, interpreted languages). It's great to have the option to use each, but these languages are not necessarily complimentary. It is unlikely that you would write a system with a combination of PHP, Python and Ruby. But, it is conceivable that you could have a project requiring C, PHP and Erlang skills.

Rather than learning interchangable skills, complementary languages might offer the opportunity to become a more rounded developer:

  • Interpreted, procedural (PHP, Ruby, Python, JS)
  • Compiled, procedural (C/C++, Java)
  • Functional, concurrent (Erlang, Scala, F#)

Assuming that side stepping between similar languages is easier than picking up a completely new concept: it would seem learning these varied skills opens up more possibilities.

Sometimes I worry that by learning a particular, none mainstream, language (like Erlang) I could be backing the "wrong horse". However, bearing in mind my earlier ramblings, there's little downside to picking up a new way of doing things, for example Elang may not prove popular, but the functional approach will give me a head start learning F# or Scala.

This slide from Painless Payment Processing by Erik Stenman points out other benefits of learning more "unusual" languages:

Nice paradox:

The lack of Erlang programmers makes it easier for us to find great programmers.

  • There are many great C and Java programmers, I'm sure, but they are hidden by hordes of mediocre programmers.
  • Programmers who know a functional programming language are often passionate about programming.
  • Passionate programmers makes Great Programmers

Or am I talking nonsense?

Tagged erlang functional-programming learning php python ruby tools

What I've been reading/learning this week

I've been too busy this week to form a proper blog post, so instead I thought I'd mention some good content I've consumed.

Functions + Messages + Concurrency = Erlang : Joe Armstrong

This talk from Joe Armstrong (author of Programming Erlang) gives a really clear breakdown of the reasons concurrent languages (like Erlang) are becoming more important as processors gain more cores. The following quite gives good flavour:

Due to hardware changes:

  • Each year your sequential programs will go slower
  • Each year your concurrent programs will go faster

Although Joe focuses on Erlang, this applies to all languages tackling concurrency (Scala, F# etc...), thoroughly recommended to developers wanting to know more.

McMafia, Seriously Organised Crime : Misha Glenny

This book has nothing to do with programming (directly), and it may appear at first glance to be some sort of "aren't gangsters cool" book for macho teenagers. Far from it.

Misha Glenny has been a BBC correspondent covering eastern Europe's wars, politics and then crime (if you've ever heard or read his reports and articles you'll know he's a very clued up chap). This interest lead him to investigate organised crime around the world. The resulting book is unbelievable (in the literal sense), it reveals how deeply organised crime is intertwined with our day-to-day lives.

The entire book is fascinating, and highlights they way organised crime can eventually gain so much power it becomes a part of the establishment and has influence over global politics (not just as an issue but as an instigator). It literally effects the lives of everyone on the planet.

Perhaps one of the areas that gets the least coverage is "digital crime". This is not due to it's insignificance, quite the reverse. It is huge and vastly profitable, the problem seems to be that researching it is almost impossible. Police forces simply don't have the funding and resources to gain enough understanding of the way the cyber criminals operate. It's a subject I'd love to know more about, and one that I'm sure will become more and more important over the coming years.

I can't recomend it highly enough.

Code Complete 2 : Steve McConnell

People have been banging on about this book for ages, so I caved in and started reading it (especially as I found it in the work bookshelf, saving me 30 quid).

I'm only 1/3 in but it already lives up to the hype. Clear, humorous and very well written. One misconception I had was that it is a straight manual to writing code. In many ways it is, but it goes much further into the thinking processes developers use. It highlights familiar problems and explains the solutions in a way that "just works".

Basically, if you heard about it and thought it might be worth a read: it is. Read it sooner rather than later, two chapters in I felt like I understood my trade better and that I was on the right track.

Tagged books crime erlang learning

Erlang FizzBuzz Showdown (pt2)

In my last post I documented some of the steps involved in building a simple FizzBuzz script in Erlang and compared the code to its equivalents in Python, Ruby and PHP. So far we've simply covered using a tail-recursive function to creat a list of numbers 1-100.

The next problem to tackle is checking whether a number is: just a number, a Fizz (divisible by 3), a Buzz (divisible by 5) or a FizzBuzz (divisible by 3 and 5). As I'm in the habit of using if statements to perform checks (I'm primarily a PHP developer) my first attempt looked like this:

fizzbuzz(I) ->
    if
        ((I rem 3 =:= 0 ) and (I rem 5 =:= 0 )) ->
            fizzbuzz;
        I rem 3 =:= 0 ->
            fizz;
        I rem 5 =:= 0 ->
            buzz;
        true ->
            I
    end.

This works just fine, but isn't a good example of writing Erlang in a functional manner, this is more like imperative programming in style. For example, it is not dissimilar to this python function:

# python

def fizzbuzz(i):
  if i % 3 == 0 and i % 5 == 0:
    return 'Fizzbuzz'
        
  elif i % 3 == 0:
    return 'Fizz'
        
  elif i % 5 == 0:
    return 'Buzz'
        
  else:
    return i

In Erlang (and I assume functional programming in general) Guards rather than if statements are far more appropriate. So, using the multiple entry points for a function and combining them with a guard I ended up with this:

fizzbuzz(N) when N rem 3 == 0, N rem 5 == 0 -> "FizzBuzz";
fizzbuzz(N) when N rem 3 == 0 -> "Fizz";
fizzbuzz(N) when N rem 5 == 0 -> "Buzz";
fizzbuzz(N) -> N.

Once I'd taken on board the functional approach the FizzBuzz function has not lost any readability (if anything this is easier to follow) and has become more compact and efficient. From what I've seen so far: Erlang programs rarely need if statements.

The next stage in the FizzBuzz program is to combine this with my earlier range function and loop through the numbers 1-100. Attempt 1 worked like so:

combine(To) ->
  F = (fun(I) ->  fizzbuzz(I) end),
  lists:map(F,range(1,To,[])).

Again, this works: the function combine takes in the number to be counted up to (e.g. 100), then a Fun is created (basically a mini function that can be passed into other functions as an argument) that is a copy of fizzbuzz, and then uses the inbuilt module/function lists/map to apply it to each number in the list returning a new list with the appropriate changes. But again this can be condensed to make better use of Elang's functional syntax.

combine(To) ->
  [fizzbuzz(X) || X 

The end result is the same but the function now uses a pattern matching/balancing style syntax to produce the new list. The process breaks down like this:
  • [] is the list notation, and using the pipes to separate the two haves of the process ([X || X ) means that the result of the right hand site is passed into the left (as X, formed by breaking the list down X ), forming a new list one element at a time.
  • The input list is formed using the range function on the right.
  • Then the fizzbuzz function processes the incoming elements of the new list on the left.

And that almost concludes my Erlang FizzBuzz program. However, it is returning a list rather than printing one line at a time. This is the module so far:

-module(fizzbuzz).
-export([fizzbuzz/1,range/3,combine/1]).

fizzbuzz(N) when N rem 3 == 0, N rem 5 == 0 -> "FizzBuzz";
fizzbuzz(N) when N rem 3 == 0 -> "Fizz";
fizzbuzz(N) when N rem 5 == 0 -> "Buzz";
fizzbuzz(N) -> N.

range(To,To,List) -> [To|List];
range(From,To,List) when From  range(From, To -1, [To|List]);
range(From,To,List) when From > To -> List.

combine(To) ->
  [fizzbuzz(X) || X 

And being used in the console:


Eshell V5.6.5  (abort with ^G)
1> c(fizzbuzz).
{ok,fizzbuzz}
2> fizzbuzz:combine(100).
[1,2,"Fizz",4,"Buzz","Fizz",7,8,"Fizz","Buzz",11,"Fizz",13,
 14,"FizzBuzz",16,17,"Fizz",19,"Buzz","Fizz",22,23,"Fizz",
 "Buzz",26,"Fizz",28,29|...]


Finally, this can be condensed one last time by turning the range function into a tool for applying the fizzbuzz function to each number recursively, printing the results to the console as it goes:


-module(fb_final).
-export([fizzbuzz/1,fbr/2]).

fizzbuzz(N) when N rem 3 == 0, N rem 5 == 0 ->
  io:format("FizzBuzz\n");

fizzbuzz(N) when N rem 3 == 0 ->
  io:format("Fizz\n");

fizzbuzz(N) when N rem 5 == 0 ->
  io:format("Buzz\n");

fizzbuzz(N) ->
  io:format([integer_to_list(N) | "\n"]).

fbr(To,To) -> fizzbuzz(To);
fbr(From,To) when From  fizzbuzz(From), fbr(From + 1, To).



And with that I'm pretty pleased. The fb_final module makes good use of the functional approach, is concise but still fairly easy to read. In conclusion I'm enjoying Erlang a great deal.

P.S:
There is one last small modification that makes fbr/range reusable allowing higher order functions to be passed into it:


range(To,To,F) -> F(To);
range(From,To,F) when From  F(From), range(From + 1, To,F).


This executes using the following console script (inserting fizzbuzz into range as a higher order function):


Eshell V5.6.5  (abort with ^G)
1> c(fb_final).
{ok,fb_final}
2> fb_final:range(1,15,fun(N) -> fb_final:fizzbuzz(N) end).
1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
ok



Done and dusted! And here are some other ways of getting FizzBuzz done in a functional style.
Tagged erlang learning php python

Erlang FizzBuzz Showdown (Pt 1)

As I've become a little more familiar with Erlang I decided to leave the set text and test myself with a basic (often seen) programming challenge (FizzBuzz) and compare the solution with the languages I'm more familiar with.

FizzBuzz is a pretty simple set of rules (also known as Bizz Buzz) and is used for children's maths, drinking games and as a rather basic test given to programmers during job interviews (although it is so well known that it probably lost its value for this purpose a while back).

The rules (for programmers) are simple:

  • Print a list of numbers 1 - 100
  • If the number is exactly divisible by 3 print "Fizz"
  • If the number is exactly divisible by 5 print "Buzz"
  • If the number is exactly divisible by both 3 and 5 print "FizzBuzz"
  • Otherwise just print the number

Solving the problem breaks down to:

  • Create a range of numbers 1-100
  • Loop through each number and check it against the conditions
  • Print out the result
  • Repeat until 100

So far so simple, it is a pretty straight forward task that can be solved in a broad variety of ways.

Here's how I could achieve this in Python:

for i in range(1,101):
  
  if i % 3 == 0 and i % 5 == 0:
    print 'Fizzbuzz'
        
  elif i % 3 == 0:
    print 'Fizz'
        
  elif i % 5 == 0:
    print 'Buzz'
        
  else:
    print i

And PHP:

foreach (range(1,100) as $i)
{
    if (($i % 5 == 0) && ($i % 3 == 0))
    {
        echo "FizzBuzz\n";
    }
    elseif ($i % 3 == 0)
    {
        echo "Fizz\n";
    }
    elseif ($i % 5 == 0)
    {
        echo "Buzz\n";
    }
    else
    {
        echo "$i\n";
    }
}

Of course there are many variations depending on how short and/or "readable" you'd like it to be.

So, when it came to tackling this problem with Erlang I was a little surprised that I couldn't just launch into it. Approaching this problem functionally is a different kettle of fish. While there are built in functions that can help I chose to ignore them in favour of gaining a little more understanding.

In other languages creating a range of numbers was pretty straight forward and barley registered as a task, in Erlang I needed to think a little harder. There is no for or while loop easily to hand, the solution was a tail-recursive function. It might seem bloated to add this function, but if you compare the same function in Ruby, the Erlang function appears better suited to the task (also using tail recursion in none functional languages causes performance/stack issues so this is more for illustration):

% ERLANG

range(To,To,List) -> List ++ [To];
range(From,To,List) when From  range(From + 1, To, List ++ [From]).
#RUBY

def jRange(from,to,list)
  if from == to
    return list 

Erlang functions can have multiple entry points, so in this case the range function has two entry points:
  • One that accepts two identical values, a list and returns a list with the value added.
  • Another that accepts two different values, a list and adds the first value to the list, then calls the same function (itself) adding one to the first value.

As it matches the incoming conditions there is no need for if or else.

The problem with this loop is that it will go on infinitely if From is greater than To, to cover this we need a guard. This is a simple check that From is less than To:

range(To,To,List) -> [To|List];
range(From,To,List) when From  range(From, To -1, [To|List]).

And now we have an operational "range" function similar to those seen in Python, Ruby and PHP - however, Elang FizzBuzz can use it in various different ways. Another small change was to alter the way the list builds up, using List ++ [From] isn't very efficient and [To|List] does the job more elegantly.

In the next post I'll conclude building a FizzBuzz program (mistakes, solutions and better-practice included), check back tomorrow or subscribe to keep up to date.

Part 2 >>

Tagged erlang learning php python ruby

Learning Erlang: Intro

Learning Erlang: Week One

It's a little over a week since I started working through Programming Erlang and it has been a very pleasurable/rewarding few days.

I like to learn new languages for a number of reasons, including: adding skills to my repertoire and gaining new perspectives on my other programming techniques and languages. Despite only being able to grab a half hour here and there I feel these aims have already been achieved in some measure, and it had certainly given me an appetite to learn a lot more. My advice to any developer looking to experience functional languages for the first time is: pick a language (Haskell, Lisp, Scala etc...) and just give it a try. I'm sure some will end up being the more widely adopted than others, but as a learning experience all will be rewarding.

So, as a PHP developer with experience of other Object Oriented and Scripting Languages (Ruby, Python, ECMA etc...) the transition has been interesting to say the least. The key differences when programming in a functional language are the similarities to writing algebra (something I haven't thought seriously about since maths lessons aged 16).

These differences are down to:

  • variables can be set only once
  • the equals symbol is used for pattern matching rather than setting
1> X = 10.
10
2> X = 5.
** exception error: no match of right hand side value 5
3> 5+5 = X.
10
4> X = 2*5.
10

As you can see from the Erlang Console (above periods/full-stops terminate an instruction), as long as both sides of the equals equate to the same result, the program succeeds, I suppose = is used to set X in the first place but from there onwards it's matching/balancing the two sides – as it would in maths.

Combining balancing/pattern-matching with unchangeable variables (variables that don't vary if you like) is a method of preventing/reducing the opportunity for broken code. For example:

1> X = 100.
100
2> Y = X * 2.
200

The statement Y = X * 2. means that Y always equates to 200 as long as X is 100, if you could change X that statement would break. However, you can't change X so in this case Y = X * 2. will always be 200!

This is a very basic observation and one of the smallest hurdles in making the transition from OOP to functional programming, but if you have never seen it before it represents a fairly significant change to the norm.

There are plenty of other changes to adjust to such as: code isn't separated into Classes and Methods, but instead Erlang uses Modules and Functions (Modules are essentially containers for function groups) but these don't produce objects. Something I'm yet to get used to. I'm not yet far enough along to see how complex chunks of information/functionality are handled. A more thorough introduction can be found in the first couple of chapters of Getting Started With Erlang.

This post is just about giving the briefest taste of what Erlang and Functional Programming are like to use, and hopefully encourage others to investigate a little further. In my next post I'm going to run through a simple task I set myself and completed last week: FizzBuzz (as noted by Jeff Atwood as a simple test of programming competence), and give some comparisons to PHP, Python and Ruby.

Tagged erlang introducing learning

Erlang White Paper

This is just a short post to point potential Erlang-ers to the Erlang –White Paper.

It acts as a really concise overview of the language, its purposes and illustrates how to use it. I'm thinking that it will act as a quick reference while learning as it covers most of the basics principals (on first glance it may be enough to get most programs underway).

A roundup of my first week of Erlang is on its way soon, this taster shows how to create a list containing a range of numbers (there is a built in equivalent and it isn't particularly impressive - but it's neat and pleases me).

range(To,To,List) -> List ++ [To];
range(From,To,List) -> range(From + 1, To, List ++ [From]).
Tagged erlang learning
​