Comment by candiodari | Hacker News Reader

Comment by candiodari | Hacker News Reader

Parent Full thread

It's just a cycle: procedural programming -> data oriented programming -> object oriented programming -> functional programming

procedural programming -> 'I hate all these imperative sequences ("flowcharts"), it's all about the data anyway !'

data oriented programming -> 'I hate keeping all these data relationships in sync, can't the data do that itself ?'

object oriented programming -> 'all this behavior is too complex, often does things I don't intend, can't it be simpler ?'

functional programming -> "it's simple, but way too dense (like algebra), can't we just write out what happens in sequences of imperative statements ?"

So we arrive at Wapper's "Battlestar" law of programming paradigms:

"All Of This Has Happened Before And All Of It Will Happen Again"

Object oriented programming is where really complex and large programs go. I agree with Pike : my favorite is data-oriented programming. Read the data and relationships, but only document them, don't encode the data schema directly. But here's the kicker:

The issue with these Pike 5 rules is that while some things are simple (and yes, people can screw up and make simple things complex), there are many things that are complex and can't be made simpler without destroying the functionality of the program. There is no way to make a CAD drawing program that is anything remotely close to these rules. Making such a program simple and predictable, while possible, also destroys its function.

> There is no way to make a CAD drawing program that is anything remotely close to these rules.

Eh? A CAD program will have a lot of features, but that's not the same as using complex algorithms. For the bits where you do use complex algorithms, with a good architecture you can confine the complexity to plugins and corners of the program.

All of the other rules would apply to almost anything, surely?

Maybe the best example of irreducible complexity would be a video player; the algorithm is handed to you in a multi-hundred-page spec and there's nothing you can do to avoid that.

>.. there are many things that are complex and can't be made simpler without destroying the functionality of the program.

This is because we haven't figured out how to make them simple yet. I believe all problems can be made simple, once we come up with the proper system. Maybe we don't have the correct abstractions yet or just haven't figured out the best data layout. We've only been collectively programming for a few years now I think we have plenty of room left to advance the field. I'm not ready to just throw in the towel and say impossible.

Have architects figured out how to make designing any sort of building and bridge simple?

Maybe with powerful AI and Holodeck-like programs we can make it simple for humans to tell the computer to do anything they want easily, but short of that, I'm not seeing why every program would be simple to build.

However, the more powerful your tools, the more complex buildings and programs you're able to create. Programming hasn't necessarily gotten easier with more powerful abstractions, rather we create more complex programs now.

Agreed. Our field is still incredibly young, speaking as if we've tried everything that can be tried sounds a lot like when physicists were figuring out relativity. Many believed that the problems were simply unsolvable, that all of physics had been figured out in the late 1800s. Obviously they were wrong, and I think many of today's computer scientists will be wrong as well. Our field has a long way to go before it matures, in the meantime we need to find better abstractions.

Claiming that it's "all a cycle" is incredibly short sighted considering the time-scale.

You forgot logic programming -> I don't care how, just walk all feasible paths

Heh, good one. But maybe slightly changed to:

I don't care how well (as in perf)

unless you meant something else (not skilled at logic programming).

Reply on news.ycombinator.com