The Things You Can’t Do

Flexible. Dynamic. Feature-rich. These are usually terms to describe programming languages, libraries and frameworks; they sound great, but what are we trading off to get them? And what can we can gain if we run in the other direction and strive for less of these qualities?

In this talk we’ll draw a line straight through ES6, immutability, “functional-style”, Flow, Elm and PureScript in twenty minutes: why they’re useful, what you have to give up to make the best use of them, and why that isn’t a bad thing. It’s a tall order, but it’s a tour that’ll get you thinking, and will leave you with enough jumping-off points to dig into for months to come.

Some constructs are more powerful than is needed. In looping through an array in order to print out a series of items, for may do more than is actually required, and while in is simpler it returns more than is required. The forEach construct hits the sweet spot, doing exactly what is required.

It’s always a case of using the best method for the job. To turn one array into another, forEach can do it but is in this case is also too powerful and too easy to mess up – the map function works better for this purpose.

ES6 brings us functions like let and const that can prevent programs running if the right conditions aren’t met: useful safety methods.

When you are working with a series of arrays, problems can occur when one function changes the array, preventing the next function from doing its job. Immutability can stop those changes and keep the intended functions on track.

Sometimes you write code that is poor but it’s hard to see exactly why it is poor. This is where you look for tools to help you.

If a method doesn’t do exactly what is required, check to see if another method exists that meets your exact needs.

It’s not that some methods are better per se, it’s that they are better suited to specific purposes. Other examples of tidy, purpose-specific functions include reduce and filter.

Having a function like const stop your program is a good thing – better it stops for you in development than for your users in practice.

Using seamless-immutable or the immutable.js library will stop unwanted changes and blow up your programming, which is what you want in development.

Flow is a command line tool that will encode, record and check your programming. TypeScript is also useful for this.

JSON is an example of a light touch, using the least power. It does what it’s meant to do and nothing else.

HTML is similar, in that it’s a markup language intentionally reduced in what you can do with it, just as CSS does what it’s meant to do but can’t read from a file, or loop forever, or generate a random number.

Don’t hesitate to make your programming fail in various circumstances – that’s how you find out what might fail in public use.

Stopping an errant program running at all is the most desired option, but stopping it mid-run is the next best option.

Don’t use more power than you need to achieve your desired outcomes.

Not all tools, methods, functions, operators that are fit for the purpose you have in mind – examine the options and find the best fit.

It’s the things that you can’t do with your chosen tool that makes it harder to misuse, which means fewer bugs and fewer errors.

This isn’t a call to action so much as a call for consideration.