Compiling expression trees with Roslyn… without memory leaks

Introduction

My story starts, as many good stories do, with the awesomeness of Entity Framework.  Anyone who has used it knows that you can replace those ugly SQL WHERE clauses with beautiful lambda predicates:

var adultCustomers = db.Customers
                          .Where(c => c.DateOfBirth < DateTime.Now.AddYears(-18));

Advertisement

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.

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).

Chess engine code – minimax

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

In this article we cut to the chase and present the function that implements the minimax algorithm.  I’m going to cut out some miscellaneous stuff so that we can focus on the core, which is walking the tree and comparing the lines.  You can get the full version in the code base.

Chess engine code – running in the background

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

In earlier articles we’ve seen the code for generating moves.  Before we use it to build a playing engine, let’s take a detour and consider how we’re going to run that engine.

We’ve already identified that, thanks to the vastness of chess’s move tree, our engine could be slow to run.  Sophisticated modern engines can generate strong moves in just a few milliseconds, but unfortunately such speed and strength is beyond the scope of this project.  We’re going to have to wait a few seconds for Shallow Thought to calculate its moves.  (Incidentally, is this a good time to mention that Shallow Thought runs a lot faster on Chrome than on Edge?  Hmmm).