Erlang - Why so many (seemingly identical) tools?

Ever wondered why many of the erlang modules provide seemingly similar functionality ("functionality". ho ho ho) using different functions? Why there are so many tools that seemingly do pretty much the same thing?
Consider that you could just use lists:map/2 instead of lists:foreach/2, and ignore the result if all you cared about were side-effects.  e.g.

lists:foreach(fun(X) -> do_something_to_a_file_named_(X) end, [a,b,c])
could just as easily be done as
 _Ignore = lists:map(fun(X) -> do_something_to_a_file_named_(X) end, [a,b,c])

Yeah, yeah. I know. Its stupid.  But you could do it, no?  Come to think of it, I'd bet that any number of people are actually doing it even as we speak - given that its not actually wrong, y'know?

 It doesn't stop there - consider the following in the lists module
    ⁃    lists:sum/1 could just as easily be done using just a wee bit more code using lists:foldl/3
    ⁃    you use lists:reverse(lists:foldl(...)) instead lists:foldr/3 (ok, to be fair, you're probably already doing that because you're paranoid and, O…M…G…., it isn't tail recursive!)

How about these from the dict module (which, to be frank, is where this whole thing started when I was reading Joe Armstrong's thesis)
case dict:find(foo, SomeDict) of
    {ok, Value} -> some_thing();
    false -> other_thing()
end
vs
case dict:is_key(foo, SomeDict) of
    true -> some_thing();
    false -> other_thing()
end

These could basically be the same thing no?

Anyhow, to cut to the chase, the reason that all these nearly identical methods exist is what Joe Armstrong termed Intentional Programming in his thesis.  To quote
Intentional programming is a name I give to a style of programming where the reader of a program can easily see what the programmer intended by their code. The intention of the code should be obvious from the names of the functions involved and not be inferred by analysing the structure of the code. (Reading the code shoudd) precisely expresses the intention of the programmer—here no guesswork or program analysis is involved, we clearly read what was in- tended.
The point behind all of this is that when you have to look at someone else's code (don't argue about this. If you haven't already, someday you will…) or god forbid, you have to go back to your own code years later and look at it (and this one is actually far more frightening than someone else's code), wait, what was my point again?

Oh yeah, thats it.  Sorry for the tangential quasi-rant. Won't happen again...

If you have to look at someone else's code and figure out what it is doing, you're much, much better off if the code pretty clearly indicates what it does.  Whats even better is if all the modules and functions which are referenced clearly indicate what they do.
I mean, seriously, the days of FORTRAN are long gone - punch-card limitations no longer exist, you don't have to name your variables i1, i2, i3 .. i67 (and rest happy in the knowledge that it was automagically typed as an integer).  Today, you can have wonderful wonderful names like FirstTimeInTheLoop and position_in_the_array_that_needs_to_be_filled_first, and all sorts of other similar fun goodness.

The bottom line - when using modules, check to see if there is something that does exactly what you want - odds are that there are (and doubly so if you are using lists). 
Much more importantly, think carefully about code-reuse when writing your own stuff.  You usually find something that you wrote a few months (years?) ago that does about 80% of what you need - and you end up slamming it into your existing code with a few slapdash hacks to get it to do what you need.
Don't do that!.  
Refactor your old code so that it is the correct fit for what you are doing now, or even better, refactor it so that it - as a more general solution - works better for the previous project, the current one and the next one.
Trust me, if you do it properly, you will so thank yourself down the road, the next time you need to use it!

I know, I know, you'll always have the idiots who camouflage their code in the name of job security.  Or even worse, who do it 'cos they don't have the faintest idea what they are doing.  Deal with it - this way at least some of the code is going to be vaguely understandable...


Note: Yeah, there is also Intentional Programming ref: Simonyi which only serves to confuse the point being made here.  Ignore it.

Comments

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

Its time to call Bullshit on "Technical Debt"

Visualizing Prime Numbers