Flat is good, turtles or not. I look at a map, I want to know how to get to Toledo--it's I-75 the whole way. Sweet.
If it's Toledo, Ohio. If it's Toledo, Spain, I need to use a "great circle" mapper that shows a curving arc that my jet will fly from Sarasota, Florida to Madrid airport, because the earth, so I'm told, "she's a-round".
But if I don't need to go to Spain, I-75 will do just fine for me. Why use round when flat will do? You're just making life difficult for yourself. You'll end up wasting a lot of time and you'll miss Monday Night Football.
Software development is like that. Sometimes you need to make round software, no getting around it (!?), but most of the time, flat will do nicely and it's SO much simpler.
What, you may ask, is flat software?
If you ask computer scientists, you'll get different answers, but to me, flat software is software that takes flat inputs and turns them into flat outputs.
OK, so what are flat inputs and what are flat outputs?
Here's a flat input:
Cash Client Security Type Transaction Date
Yes Stocks June 7, 1995
Here's an input that's not flat:
Cash Client Security Type Transaction Date
Yes Stocks, Bonds June 6-7, 1995
The not-flat input has more than one of each kind of thing.
To work with not-flat inputs or outputs, you need to repeat some part of the program more than once. In programmer-speak, you need to use a "loop" (or at least "recursion"). With flat inputs and outputs, though, whatever you do, you only need to do it once. Computer scientists have a special word for programs like this. It's called "functional programming".
This is not really new. I'm old enough to remember when almost all programs were flat programs. The inputs were on punch cards. They weren't just conceptually flat, they were ACTUALLY flat. If there were 20 steps in your program, you wrote 20 different programs. Each step took in a punch card, processed it, and punched a new card as an output to that intermediate step. Then you took that card and fed it into the card read with the program for the second step, and it processed that and punched another intermediate result. And so on. This was "functional programming" though we didn't know it at the time.
As computer hardware and software got more powerful, we got away from this model of programming and things got more complicated. I have often wished that we could get back to this simpler "flat world" model where it was possible to be much more certain about what the programs did.
Writing programs that only do each thing once is a HUGE simplification. The Wikipedia article on "functional programming" says that it "makes it much easier to understand and predict the behavior of a program".
But wait, what if you need to go to Spain, uh, I mean, work with a LOT of the same kinds of things? Well, that's somebody else's problem. You only make doors. You don't make the whole car all by yourself.
It's not practical to write everything this way, but wow, if you can use functional programming for the things that change most often, you're WAY better off. I can't prove it, but I strongly suspect that 80% of the parts of software systems that change frequently can be written using functional programming.
There's a problem with functional programming though. When done using text-based languages, functional programs often end up being one long line of code. Some people love it, but you need to be smarter than the average bear.
Doing it with text-based languages is harder than it needs to be. Here's the program I showed in my last post using a Blockly visual programming editor:
It has flat inputs and outputs! It's a "functional program"! But it's EASY to create using Blockly by dragging and combining colored blocks. It's easy to understand. It's easy to test. It's just EASY.
Easy is good. Just ask a Ford Motor Company door maker. He or she will tell you, "yeah, it's not rocket science". (Actually, they will tell you 这不是火箭科学.)
Bottom line: Don't do hard if you don't have to. Do easy when you can.
No comments:
Post a Comment