Simplistic programming is underrated
lemire.me
lemire.me
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.
It's both hard and underrated - it's underrated because it's so hard that a lot of developers haven't developed the skill of writing simple code, and so don't recognize the value when others do it.
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.
These people are often management, unfortunately.
Solid life advice.
On the other hand, it's all relative. After having worked in Silicon Valley for over 15 years, I think the more common mistake is knowing too little philosophy rather than too much. (Of course, I agree that 5 dollar words confuse issues more often than they illuminate them.)
It wouldn't hurt a lot of engineers and tech companies to learn more about the past and be more literate.
As an example, off the top of my head, here is a concept which comes up a lot in software:
"The Map is not the Territory"
https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
Likewise:
https://en.wikipedia.org/wiki/Ludic_fallacy
You don't have to do statistics / big data for very long before you hit philosophy. It bottoms out pretty quickly, i.e. how do you learn about the world. Likewise programming is about making things, and sometimes about modelling the world, and there are a lot of useful philosophical concepts in that realm too.
This is without even getting into the "morals" of technology, which is a big thing in the news lately.
"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."
You probably hear it a lot, because it's generally important to make functions orthogonal with respect to each other so they may be modified without effecting one another.
I'll agree that order of magnitude is starting to feel like it's overused as rhetoric in programming circles, even though it too is a very important concept in engineering.
I suspect there are many others in my situation here, specially those whose native language is of latin origin, because latin-based words are considered more formal/academic in english, yet they're much easier for us to learn!
Just keep that in mind when judging other's comments please ;)
I'm talking about comments that my younger self would have written when I thought I would add weight to my argument by trying to sound smarter (so I'd be a hypocrite to judge comments harshly anyway).
I consider myself guilty of doing this, but that's because (most of the time) I actually proof-read my comments before posting them, and consider whether they provide a useful addition to the discussion. If one of my comments look like they're going to be peer-reviewed, it's because they're self-reviewed, and you don't get to see the long tail of comments that I typed out and then deleted because a) they didn't add anything useful to the discussion or b) I could not express my thoughts clearly enough.
You could've written something like this instead:
I'm guilty of this, but that's because I self-review and consider whether I'm actually contributing to the discussion before posting. You don't get to see vast majority of un-submitted comments because they either didn't add anything useful or they weren't clear enough.
Same message, but much easier to read.
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.
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.
However the exact same piece of code might be wrong in one team, and right for another, depending on their experience and backgrounds.
If you have any interest in the topic, I recommend Rich Hickey talk "Simplicity matters" 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...
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 ;)
What's even more impressive still is knowing when to use which rather than locking yourself into a prescriptivist hole.
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
for i in range(len(my_list)):
# do some stuff with i and my_list[i]
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.
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.
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.
In a trivial example like this, between two similar executions, I'd tend toward the C-like one for readability. Only use the language feature if it really saves a lot of lines or abstractions etc.
So java8 if I could rewrite 100 lines of code so that a whole function is just one lambda and nothing else, sure go for it. That's just a StackOverflow away for anyone. But I wouldn't toss in a lambda with a bunch of (insert new language feature) all on one line. I wouldn't expect another programmer to know all that yet.
I could make an awful enumerate implementation in C:
#define enumerate(item, array) for (int i = 0; i < sizeof(array)/sizeof(array[0]); i++) { item = array[i];
#define enumerate_end }
...
enumerate(int number, numbers)
printf("Number is %i\n", number);
enumerate_end
I think higher-order functions are a great tool when they're used to remove complexity. The tricky part is that your reader needs to already understand how they work. If adding the definition of a higher-order function would make your code longer than simply not using it, I think it's a bad case to use it.
“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.”
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.
In essence; adding complexity for the sake of complexity or to come of as intelligent is bad...
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.
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.
var r = array.map(x => x*x).reduce((total, num) => total + num, 0);
var r = 0.0;
for (var j = 0; j < array.length;j++){
var x = array[j];
r += x*x;
}
[1] https://stackoverflow.com/questions/17546450/for-array-is-it...
It should be written like this, IMO:
var r = array
.map(square)
.reduce(sum, 0);
1. Separating out actions by line
2. Pass named functions that describe what they do
var r = array.reduce((total, num) => total + (num * num), 0);
"Simple" is great until you're debugging off by one errors or any other errors between chair and keyboard. Complexity, in the sense that this guy rails against, is expressiveness. And, expressive code beats "simple" code every day of the week.
--Quick edit Imagine that loop in assembly. It's objectively "less complex" yet you didn't express it that way. Why? I think the answer to that question is the heart of the positive argument for programming abstractions (and the "complexity" they bring).
Except that it's not. Read the SO answer I linked.
> The nooks for bugs in your "simple" loop are so profound that, in a language with expressive maps, I wouldn't accept that code in a review.
Yep, I've definitely worked with people like you. With all due respect, I just think you're fundamentally wrong. Off-by-1 errors will happen no matter what, and even a rudimentary test suite can catch those.
I was referring to mental overhead; though in a more modern language like rust the performance implications would be far less profound than the linked SO discussion.
I don't think off-by-1 errors are that big of a foot gun, compared to, like, having a null as part of the language, or pointers, or about a million other things.
> I was referring to mental overhead
Gotcha. I still think that "linear step-by-step" thinking like "you take stuff out of a bucket, and then do stuff to it" is easier to parse than map-reduce, which requires you to have a "big picture" view of the whole process.
No? Not only can they happen, but I'd argue that it's easier for them to occur when using `reduce`, because you have to remember the initializer. Omitting it has no effect in the given example, but the given example is contrived. It's not rare to be dealing with something more complex than a list of numbers, so let's try that instead.
Let's say your items are a list of nodes. You want to sum their payloads to determine their aggregate cost. And, like kgwxd[1], you see `map` as superfluous. You've got this. You write:
nodes.reduce((sum, x) => sum + x.value)
I would say that's not an off by one error. Its a similar scale and type of error, but not the same.
let square = (n) => n*n
let sum = (s,n) => s+n
let r = array.map (square).reduce (sum,0)I tend to think there's some additional overhead from Javascript's particular object oriented implementation of mapping and reducing when compared with haskell's i.e.
f xs = foldr + 0 (map (\x -> x * x) xs)
Is it habit? Probably. But I really find it hard to understand why maps and folds are simpler than manual iterative loops.
f = foldr (\x total -> total + (x * x)) 0
but this is actually a counter argument. look at all these ways of doing this simple operation with higher order functions. plenty of replies from intellectual napoleons like me, too. whereas with the for loop, there's nothing much to say, which seems like a good thing.
i genuinely don't know how to feel about this.
Yes, obviously they can learn, and I don't think learning a bad thing (It's absolutely a necessary skill for a programmer, or anybody), but if the only place in the code that ever uses map/reduce is that one location, then programmers that come by it are likely not going to get a lot out of the time they're going to sink trying to figure it out. If it was just a basic loop, then overall people will likely spend less time figuring it out. For one piece of code it's not that big of a deal, but if your code-base is just full of fun little one-liners everywhere, it quickly becomes a mess to understand.
But with that, if your code is already full of stuff like map/reduce, then I think using map/reduce instead of the basic loop may very-well be preferred for readability (Though of course, your citation brings up performance concerns, which should also be taken into consideration). I think most important is just keeping the code-base consistent.
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.
> - We're going to take that and add it all together
Here, we have an imaginary variable: namely, "that." Something that we need to keep track of and is not explicitly referenced anywhere. It's relatively easy when you only have one of these things, but with complex map-reducer logic, you can end up having a whole bunch of these.
In the for-loop, everything I use is explicitly referenced. There's no "that" -- everything is "r" or "x" or "j."
We have a list of numbers that we want to square and add up, instead of the more mechanical steps with the loop approach.
(loop for x in a summing ( * x x ))
And in fact, many languages have only one or the other as a standard idiom. So it's really pretty simple: Use the one that's a standard idiom in the language that you're using.
Your language offers both? It's still pretty simple: Use the one that's better understood by the people that you're working with.
They understand both? The project still probably leans one way or the other. Prefer the one that is more commonly used in the project. Projects wind up using subsets of languages; using things outside the subset, while valid, looks "odd" within the project.
It's all about minimizing the cognitive load on the reader. It's not about what the writer prefers.
I can write that using various maps, folds, flat_maps, and reduces, but no one else would understand what is going on in the code. Maybe someone will post the right idiomatic functional way to do that, but nothing elegant comes to mind.
If not, then map / reduce offers non-trivial performance benefits over a for loop. Mapping, as far as I'm aware, is "embarrassingly parallel", assuming the function that's mapped is pure? I think?
I call it the low talent to ego ratio.
While I disagree on the map -> reduce I agree on the other positions you articulated.
Resume 1:
> Did simplistic programming using for loops.
Resume 2:
> Map reduce using spark.
Guess which resume gets picked up by filters? Noone wants to get caught with their pants down when they have to look for their next job.
Pressure to "keep up" is unfortunate reality of our profession. Resume Driven Development is a thing.
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.
In other words, write everything in Brainfuck FTW? Seriously?