Programming

“If you don’t make experiments before starting a project, then your whole project will be an experiment.” - Mike Williams (Creator of Erlang)

Testing XPath in Firefox:

1. Press F12 to open the developer tools
2. Got to 'Console'
3. Type in something like: $x("//div[@class='switcher_bar']//button")

It is very hard to change the data structures in functional languages because of the ripple effect.

I.e.

def a(data):
  b(data)
  c(data)

Change data would mean changing three functions.

Taken from: http://stackoverflow.com/questions/4565325/too-many-arguments-for-function

Ways to address too many arguments:

• Group things (ParameterObject, NamedTuple, ...) - Though that just moves the complexity but it might make things more readable (i.e. rectangle instead of x, y, w, h)
• Use default values for optional values
• Split into multiple functions

Benefits of using pure functions:

• Portable (because it has a clear interface and boundaries)
• Testable (just need to test what goes in and what comes out)
• Easier to reason about (because of clear boundaries)
• Thread safe
• Easy to cache (https://en.wikipedia.org/wiki/Memoization)

When trying to incorporate some ideas of functional programming into my Python code, I tend to end up with lots of parameters in my functions.

Some questions to myself:

• When to use classes vs. functions
• When (or at all) to use parameter objects (http://c2.com/cgi/wiki?ParameterObject)
• What to do about lots of parameters

Some resources:

• http://programmers.stackexchange.com/questions/109179/long-parameter-list-versus-long-state-variable-list
• http://c2.com/cgi/wiki?LongParameterList
• https://web.archive.org/web/20130819160454/http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

Don't have a 'common' library!

I've seen this in a lot of bigger code bases. There are multiple projects that share functionality. For example a solution with web and cli interface. Typically this shared functionality gets shoved into a library called 'common'. It does sound like a good idea at first but it can get very messy after a while.

Here is the problem: Programmers are lazy and creating a new library is painful. So everything that is or just seems to be shared functionality will end up in the 'common' library. After a while this library will be big and bloated and probably will have lots of dependencies on its own.

Let's imagine you need to implement a new client, say for Android. This new client needs only some of the functionality of 'common'. This means including 'common' and all of it's dependencies. More code means more bugs and more things that can go wrong.

A better approach is to have multiple smaller libraries with a defined very specific scope. That way it is easier to reuse only small parts of the overall functionality. As for the pain of creating new libraries: This can be automated to a degree.

Bottom line: Keep things small and simple for best re-usability!