Tuesday, June 3, 2014

Easy Familiarity

I was at a software conference a couple weeks ago where I attended some sessions on functional programming.  I, like many imperative programmers, am finding functional a bit foreign and hard to internalize, and I enjoyed listening to some experienced practitioners talk about it.

In one session, the presenter said, "simple is not the same thing as easy."  "Simple" is a characteristic of a thing.  It is simple or it is complex.  A "hello world" program is simple; spaghetti code is complex.  "Easy" relates to an individual.  I find pointer-intensive software to be easy.  Garry Casparov finds chess easy.  The presenter's point was that we should strive to make simple software (complexity is the single greatest enemy to quality).  In his opinion, functional languages can make many programs more simple than in imperative languages.  This, in spite of the fact that many imperative programmers would find the functional program difficult to understand, due to lack of familiarity.

In another session, the presenter said, "readable != familiar".  Same idea, slightly different spin.  When I first learned C, I found conditional expressions to have low readability:
    int max_xy = (x > y) ? x : y;
Almost thirty years later, I don't give it a second thought.  Did it become magically more readable?  No, the construct was always readable.  I became more familiar.  On the other hand, I've had maybe 20 years experience with regular expressions, and they are still virtually a "write-only" language.  Regular expressions fundamentally have low readability.

simple != easy
readable != familiar

Both encourage us to not fear change, to not assume that if X was good enough for my grandfather, then it's good enough for me.  I find it strange that programmers would resist new ways of thinking, new approaches, new language features.  Our profession barely existed 50 years ago, it changes every year.  And yet, in my early years, I knew programmers who resisted C because you couldn't do things that you could do in assembly language.  A few years later, people were doubting that C++ could ever be usable in embedded systems.  (Now Java is being embedded, for goodness sake!)  Personal computer operating systems have progressed from simple program loaders (e.g. MSDOS) to full Unix with virtual memory and symmetric multiprocessor capability.

And still programmers resist the new, the different.  (I'm no better!  I'm still don't consider myself a good OO programmer.  I've done very little C++.)

One guy at the conference went so far as to say (approximately), "If you don't learn functional programming, in 5 years there will be a name for your job: 'maintenance.'"  I'm not sure that's true -- there are still a lot of new non-OO C code being written -- but it gives me pause ... and motivation to learn some more Haskell.

No comments: