
Simplistic programming is underrated - mgdo
https://lemire.me/blog/2017/12/06/simplistic-programming-is-underrated/
======
zamalek
I don't think it's underrated; it's that it's hard to write.

You almost go full-circle. You start off writing highly procedural code (with
too much branching), join the GOF-all-the-things religion and eventually
revert to highly procedural code (more specifically "algorithmic code" or
"functional code").

As an example, many years ago I wrote a dependency resolver. It needed to find
cycles (as we had some rules that could resolve those cycles) in order to make
changes in the correct order. At the time I was a junior developer in that
problem space. My solution consisted of an O(scary) algorithm; consisting of
classes, patterns and all the good things that make your code "simple" and
"understandable" (it was not). Customers eventually threw graphs with a few
million edges at it and we needed a new solution. I have no idea how I
happened upon Tarjan's Strongly Connected Components Algorithm but some
hundreds of lines of code was replaced with dozens. Minutes turned into
milliseconds.

Here's the thing about simplicity: even though the code was simple, even I (as
the author) didn't understand it at the time - I trusted the guy with the PHD.
Many years later I finally understand how it works. It is an incredible
masterwork of simplicity but as it turns out something that is simple is not
always understandable.

Simplicity probably has a simple definition in the dictionary, but in practice
it can be quite complex to make something simple. So you can't just say "make
your code simple" because it's really hard to do that.

~~~
lestertj
I agree. There seems to be two interpretations of "simple" \- simple in being
concise like that of a beautiful mathematical equation, or simple in being
easy to follow and understand. I assume the latter is preferable when
factoring in having other pairs of eyes reading/maintaining your code,
especially since the latter does not always imply less efficient code

~~~
etherealG
Actually, I think the interpretation of simplicity as ease is an awful thing
in the context of programming and should be actively discouraged. Rich
Hickey’s talk “simple made easy” is the best explanation I’ve ever seen of
this.

------
User23
There is a major problem with how programmers are judged.

Say you are given a seriously challenging and apparently problem; that is to
say the naive approaches are all hideous train wrecks. You work on it long and
hard, until you have a key insight that allows you to implement the simplest
most elegant solution.

Now a naive observer will look at it, say well that's obvious, and then ask
why you wasted a week to write 40 lines of code.

~~~
fpisfun
Anyone who thinks more lines of code equals better software should not be
working in this industry. Hopefully the naive observer you're referring to
would be someone with no background in software development

~~~
redblacktree
> someone with no background in software development

These people are often management, unfortunately.

------
pzone
_Your apparent mental prowesses will fail to impress those who find it easy to
do the same. I have met my share of college students and professors who excel
at dropping the name of a few philosophers, at using words only 1% of the
population knows about… but, at a certain level, it does nothing for them.
People simply roll their eyes and move on…_

Solid life advice.

~~~
_tulpa
My pet peeve on HN is people writing comments like they're gonna be peer
reviewed. Either the less common words that they use are obviously out of
place like someone just discovered a thesaurus ( _conflated_ is my favourite
example), or it's consistently formal and quasi-academic so I have to put
extra effort into reading it. Either way it just makes the authour sound like
a pretentions wanker.

~~~
mythrwy
Yep. "Orthogonal" is one of my favorites. Along with "order of magnitude".

~~~
sincerely
“order of magnitude” is a pretty useful concept, to be fair.

~~~
combatentropy
But it's twice as long as saying "ten times."

"The server is an order of magnitude faster than our old one."

"The server is 10 times faster than our old one."

\--

More often heard: "The server is an order of magnitude more performant than
our legacy server."

------
agentultra
First, you're not stupid/dumb/whatever.

This idea of simplistic programming obfuscates the reality that the enterprise
of software programming is one of the most complex endeavors humans have
undertook. We desire simplicity because the reality is terrifying: that
programming is far too complex for us to manage. That we're not smart enough
to keep up. If we keep on using simple tools this reality will only continue
to get uglier.

When I first started programming it was all PEEK, POKE, GOTO 10. Life was
simple. Single processor, some registers, main memory, and an incredibly slow
disk drive. Mastery could be achieved with a book and a few weeks off in the
summer.

Since then I've worked on Mozilla, Linux, Openstack... I've written
interpreters and JIT compilers, graphics engines, REST APIs, databases,
eventually consisted distributed programming systems... it has only exploded
in complexity.

A modern computer is a microscopic distributed system. There are no less than
four cores in most computers. Several hierarchies of caches. Multiple channels
between cores, main memory, and other buses. There's a clock in there that's
probably wrong and an application that is running and coordinating over the
terribly slow network with other processes running on other computers... it's
a bit much to take in.

And yet we manage to ship software constantly.

We can do that because of abstractions.

Some abstractions are harder to understand than others. Some are made up by
other programmers and given strange names and come loaded with a bunch of
jargon. Others borrow theirs from existing literature like, say, mathematics.

I think more programmers are becoming interested in functional programming
techniques and are learning to get over the hump of learning them because they
care deeply about reliability, correctness, and expressiveness and they still
want to write quick, simple programs.

You can write 4M lines of carefully crafted C and hope you didn't miss a case
or off-by-one error. And that you wrote the logic correctly.

Or you could write 30k lines of Haskell and know that only errors in the logic
will be present at most. And with a little more effort you might even be able
to encode your propositions in your types and cover your bases there too.

It might come with a lot of jargon and seemingly-impenetrable concepts but
it's worth learning.

------
quickthrower2
Simple vs. non-simple isn't the best way to think about code.

Rather I would think about the requirements of the code. Who is going to be
reading it? Maintaining it? Do advanced language features give some kind of
advantage (runs faster?, less likely to have bugs?, more extensible?). Will
new team members likely introduce bugs? Is spaghettti code better or worse
than using less known patterns/language features?

Don't use advanced language features in production code for these reasons: (i)
impress people or (ii) develop your CV.

Don't avoid using advanced language features just because someone wrote a blog
post saying it's a bad thing to do.

In a nutshell: Think.

~~~
fpisfun
The whole idea of calling functional features advanced language features is a
bit ridiculous I think. Yes, something like java only recently started
supporting functional programming, but the paradigm has existed for a very
long time.

~~~
quickthrower2
For me it is how those functional features are used that one needs to be
careful of. I like the idea of the code that you read and think "yep that's
right", rather than - OK I need half a day and a whiteboard to understand
this.

However the exact same piece of code might be wrong in one team, and right for
another, depending on their experience and backgrounds.

------
hbt
The blog post barely gets into the idea of what simplicity means in
programming.

If you have any interest in the topic, I recommend Rich Hickey talk
"Simplicity matters"
[https://www.youtube.com/watch?v=rI8tNMsozo0](https://www.youtube.com/watch?v=rI8tNMsozo0)

My personal favorite is: Living with complexity 2010 by Don Norman (Author of
Design of everyday things)

[https://www.amazon.ca/Living-Complexity-Donald-
Norman/dp/026...](https://www.amazon.ca/Living-Complexity-Donald-
Norman/dp/0262014866)

------
AceJohnny2
I really liked this, because it resonates with my approach.

I think I first realized the basics of this some time in college. As a
teenager around '96 I discovered IRC, and hung around chatrooms being, well, a
teenager. I discovered smileys, & how 2 use abbrevs to pack more in < chars.
Also 1337speek... Only a few years later did I realize that what was more
impressive was being able to (just as quickly) form clear complete sentences.

Also related, Pascal's comment in a quickly-written letter to a friend: "I
would have written a shorter letter, but I did not have the time."

Also related, Kernighan's quote on debugging: "Everyone knows that debugging
is twice as hard as writing a program in the first place. So if you're as
clever as you can be when you write it, how will you ever debug it?"

Ultimately, I must admit that I still try to show off in my work and
presentation, but I have learned that a work that is beautiful by its
simplicity and humility has way more staying power than a complicated and
sophisticated one ;)

~~~
zimpenfish
> Only a few years later did I realize that what was more impressive was being
> able to (just as quickly) form clear complete sentences.

What's even more impressive still is knowing when to use which rather than
locking yourself into a prescriptivist hole.

------
lou1306
I agree that overcomplicating code is bad, but then again, what is
"simplistic"?

Let's talk Python. To me, using comprehensions is way simpler than loops.
Using

    
    
      for i, item in enumerate(my_list):
        # do some stuff with i and item
    

is way simpler than

    
    
      for i in range(len(my_list)):
        # do some stuff with i and my_list[i]
    

And still, I bet that most C/Java folks will look at these things with
disdain.

Also, higher-order functions. They do sound strange, at first. And yet they're
a great tool to combine simple pieces of code. I'm starting to think that
"elegance" is just the ability to build complex interactions of simple
elements. Think chess, or languages like Lisp and Smalltalk, or Euler's
identity.

~~~
dizzystar
The first is Pythonic code. I'm guessing the author isn't talking about
conventional code, but a more agnostic point of creating complexity for
complexity sake, which, unfortunately, is a very common issue.

The other way can also be a problem. If you are manually writing out
range(len(stuff)) in Python on all your loops, you are writing code that is
complicated, overly verbose, difficult to understand, and error-prone.

~~~
squiggleblaz
Actually I don't think he was successfully making that agnostic point.

It's more like: don't gold plate it, and don't use abstractions that you
learnt later.

Not gold plating things seems obvious. I think there's a TDD advocate who has
an example of when he created a wiki that stored its data in a text file.
Purely by accident. But it worked perfectly for his use case; he didn't
actually need to fire up the latest distributed NoSql blah blah blah. And
perhaps that's something worth considering.

Not using abstractions learnt later in life tho. I think that's a problem. It
took me years of contorting my head to fit in some of the customary Haskell
abstractions like monads and functors. Today I probably couldn't describe them
accurately, but I'm sure I benefit from when I think in terms of them. For
instance, it seems that the code is better if I write a method which accepts
an object then does something, vs writing a method which might accept an
object, then tests for null, and if not null it does something. (And similarly
for looping constructions for instance. You write a more superficial level of
code that knows about nulls or arrays and a deeper level of code which
doesn't. Directly thinking "monad" literally helps me here.) It's simpler, but
it's not at all more simplistic.

And so at this point, I want to distinguish between complex/complicated and
simple/simplistic. Things which are complicated or simplistic are bad because
they're simpler or more complex than they should be. Things which are complex
or simple are inevitable and complaining about them is unproductive, like
complaining about the weather.

------
dang
“Mr. William Faulkner got into the act by observing that you never crawl out
on a limb. Said you had no courage, never been known to use a word that might
send the reader to the dictionary.”

“Poor Faulkner. Does he really think big emotions come from big words? He
thinks I don’t know the ten-dollar words. I know them all right. But there are
older and simpler and better words, and those are the ones I use. Did you read
his last book? It’s all sauce-writing now, but he was good once. Before the
sauce, or when he knew how to handle it.”

[https://quoteinvestigator.com/2016/01/26/dictionary/](https://quoteinvestigator.com/2016/01/26/dictionary/)

------
lhnz
I've been thinking about this lately, too.

I strongly believe this, to the extent that I have a preference for code which
is simple but incorrect over complicated but correct.

Obviously simple and correct is best, but if I can't get that (at least in the
short-term) I would sacrifice correctness for simplicity.

You can often incrementally improve a simple solution, but it is very
difficult to simplify a complicated solution.

~~~
combatentropy
[https://en.wikipedia.org/wiki/Worse_is_better](https://en.wikipedia.org/wiki/Worse_is_better)

------
samiralajmovic
Discarding previous knowledge where it is applicable and simpler is obviously
unwarranted. Similarly to how we utilize Newtons laws within a lower energy
and mass range, we should prefer the simpler equations where they make sense.
However, I'm not sure that a for loop is actually simpler than map reduce as
it depends on the context. Who is reading your code? How complex is the code
inside the for loop? What kind of problem are you solving? The vocabulary
associated with functional programming is better equipped to handle
mathematical expressions than imperative code and in this case, simpler.

In essence; adding complexity for the sake of complexity or to come of as
intelligent is bad...

------
ld00d
I've been working on a project lately that was designed by a really smart guy.
It follows the OOP patterns and IoC and all of that. Trouble is you can
introduce such complexity that maintenance from someone a few years later can
get incredibly difficult. A lot of this code I'm working in has implicit
dependencies that are really hard to trace w/o stepping through line by line.
If the code was more explicit, maybe it would offend the ideologists, and
maybe it wouldn't be as flexible as it is (debateable), but it sure as hell
would be easier to maintain.

------
scelerat
"If I had more time, I would have written a shorter letter."

It sounds like the author is conflating sophistication with complexity. In my
experience, "simplistic" programming leads to _greater_ complexity. It is the
very sophistication and use of more advanced programming and structural
patterns he rails against that in fact enables concise, maintainable code.

------
RickJWag
Nice article. Code is written for the maintenance programmer to understand.
Simple is better.

------
fuball63
I think the sentiment is also true for devops/infrastructure. I like to use
the term "minimalistic" instead of simple, because I think some people
associate simple with naive and slapshod.

~~~
combatentropy
I like minimalism too, but people associate that with laziness. You can't win!

------
luord
Good thing I have zero interest in functional programming and other cyclical
fads. I just concern myself with keeping my code understandable, maintainable
(with the help of my teams) and tested.

------
Koshkin
"Simplisticity" is in the eyes of the beholder. (Many serious programmers see
the C++ template language as overly simplistic.)

------
dvt
> I like the concept of “simplistic programming” by which I mean “programming
> that is so simple that people will criticize you for it”. At first, that
> sounds strange… can we really get criticized for being “too simple”? Of
> course, we do.

Oh man, this hits home.

I've attempted to be a voice of reason on this front so many times, I've
practically given up on it. I've come to the conclusion that most programmers
suffer from an intellectual Napoleon complex (which I've seen in academic
Philosophy, as well). I've argued for the use of simple "for loops" in lieu of
complex map-reduce logic, argued against overly-complex threading logic where
threading wasn't necessary, argued against using Spark where the dataset was
so tiny, it could be handled by my iPhone. All my suggestions often fall on
deaf ears. The counter-argument tends to be some contrived edge-case which (by
that point in the discussion), I'm simply too fatigued to argue against. I've
lost this war of attrition many (many) times.

The irony is that most OSS code tends to be "so simple it's dumb" \-- why?
Because simple code is easy to contribute to! I think if more professional
programmers actually looked at _real_ code outside of their corporate
Bitbucket, working as a programmer would be much more enjoyable.

~~~
Y_Y
Is map-reduce really less simple than a for-loop? I agree with your other
examples, but I see these too things as totally equivalent (unless you're in a
language that make a dog's dinner of this type of thing, like old C++).

~~~
dvt
I think so, consider[1]:

    
    
         var r = array.map(x => x*x).reduce((total, num) => total + num, 0);
    

vs its for-loop counterpart:

    
    
        var r = 0.0;
        for (var j = 0; j < array.length;j++){
            var x = array[j];
            r += x*x;
        }
    

Maybe I'm just not as smart as everyone else, but I only have to keep like two
things in my mind when looking at the for loop (easy), whereas in the map-
reduce case, I need to have a very "holistic" view of what's going on (hard).

[1] [https://stackoverflow.com/questions/17546450/for-array-is-
it...](https://stackoverflow.com/questions/17546450/for-array-is-it-more-
efficient-to-use-map-reduce-instead-of-foreach-in)

~~~
nulagrithom
This is interesting to me because the map reduce has _way_ less cognitive load
for me.

With map reduce I see the following:

\- We've got an array

\- We're going to loop through it and square everything

\- We're going to take that and add it all together

\- The result is r

When I read the for-loop counterpart:

\- We have a variable called r that we're initializing to 0

\- We're starting a loop with j as the index initialized to 0 iterating
through an array

\- We've got a variable x on each iteration that is the current position in
the array

\- We're adding the square of x to r

Maybe it's a personal quirk. for-loops make me feel stupid.

~~~
amzans
The main advantage that I’ve seen when writing and reading functional instead
of procedural/imperative code, is that the intention is usually clear.

We have a list of numbers that we want to square and add up, instead of the
more mechanical steps with the loop approach.

------
catnaroek
Can these experts advocating “simplicity” offer a concrete way to measure it?

------
bryanrasmussen
I think we teach Newton's 3 laws because they are largely correct.

------
jmull
Sorry for my little pedantic observation:

The author wants the word "simple" here, not "simplistic".

The reason I even bring it up is that simplistic means overly simple, and
that's a real problem in software development in my experience.

Overly simple means you aren't actually dealing with significant issues the
problem space. If anyone ends up using your simplistic software, they will
have to solve the problems you ignore in a non-optimal way.

Simplistic -- overly simple -- is the flip-side to overly complex and can
cause just as many problems since it pushed extra complications elsewhere.

What we'd like is software that is as simple as it can be, but no simpler.

~~~
spenczar5
I think he _does_ mean "simplistic." He means "so simple that people criticize
you for it" which lines up with simplistic.

------
idooontcare
Kiss rules are good for lifestyle and everything!

------
mnm1
"If you can write a program using nothing but the simplest syntax, it is a net
win."

In other words, write everything in Brainfuck FTW? Seriously?

~~~
AnimalMuppet
That's not simple. It's a very minimalistic syntax, but it is definitely _not_
simple.

