Simplistic programming is underrated

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 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 ;)

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.

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.

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

> - 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."