Functional-style programming in JavaScript with Ramda

Screenshot from the Mandelbrot web app.

Introduction

The Mandelbrot set is a computer geek’s dream.  It has everything you want for a coding demo.  It’s a simple idea but it produces beautiful images.  And it’s computationally intensive so it can be used to evaluate optimizations.

Let’s use it to practise my current curiosity: functional JavaScript using Ramda.  The source code is on GitHub; you can see it running on Plunker. This article is aimed at people who are familiar with JavaScript and who are curious about functional programming.

Advertisements

Commands and Queries

I’m not sure whether I’m using the accepted terminology here.  People nowadays mean something else by “Command/Query separation.”  But I swear that I first heard the term used (years and years ago) to describe what I consider to be one of the most important principles of method design, and it’s the name I stick with.  What I’m talking about is the idea of classifying methods into two broad categories:

• Commands are methods that change the state of the world.  To put it another way, they leave visible side effects.
• Queries are functions that figure out a result and give it to you.

Mistake #1: Abuse of methods

Before we talk about this problem, I have a bit of a theory about how it arises. Your typical developer reads a bunch of books in school about this cool thing called Object Oriented Programming, and how it has these awesome features called inheritance and polymorphism and stuff like that. Then they go on to higher education and they do the mandatory first year programming course. The lecturer starts at the beginning and slowly explains about methods and how they enable the scaling up of design. And the developer-to-be is thinking “Yeah, I know this already… can we just skip to the good stuff about classes and vtables and overrides? Methods are easy and boring.”

Thoughts on naming things

I’m sure you’ve heard the saying: “There are only two hard things in software – cache invalidation, and naming things.”  I’ve thought about this quote for years and I still can’t decide whether I agree that there are indeed only two hard things.  But I definitely agree that Naming Things is hard.

Naming is hard because it gets right to the heart of what we’re doing: building a model in order to solve a real world problem. To be useful, that model must be a clever description of reality that captures the essence of the problem while ignoring what’s irrelevant. And the way we describe things is with words.

Angular 2 directive – square

This article is part of a series – the contents page is here.

In the last article we looked at the component that displays a piece.  It was pretty simple, not least because it didn’t support any kind of user input.  This time we’ll deal with the display of an individual board square.  We’ll make the square respond to mouse clicks so that the user can select it.

Angular 2 components – piece

This article is part of a series – the contents page is here.

So far we’ve talked a lot about chess and not much about Angular.  It’s time to change tack and look at some components.  We’ll start with the simplest component: ‘piece’, which represents a single chess piece on the playing board UI.  This article might be of interest to developers who are just starting to explore Angular 2.

Chess engine code – the evaluation function

This article is part of a series – the contents page is here.

Throughout this series we’ve referred to the evaluation function and in the last article we saw how the minimax algorithm calls it.  Now, at last, we can reveal it.

You might be surprised by how simple it is.  Or maybe not.  It probably depends on how good you are at chess, and whether you’re a glass-half-empty or glass-half-full person.  Personally, I’m quite intrigued by how such a naïve function can sometimes pull off moves that aren’t half bad.  But yes, I have to concede that sometimes it does some pretty dumb things (although it can be very hard to tell how much of that is due to the over-simplification of the evaluation versus the horizon effect).