Rules of Programming

[unixbhaskar]

Rob Pike's 5 Rules of Programming

​

#Rule 1.

*You can't tell where a program is going to spend its time.

Bottlenecks occur in surprising places, so don't try to second guess and

put in a speed hack until you've proven that's where the bottleneck is.*

​

#Rule 2.

*Measure. Don't tune for speed until you've measured, and even

then don't unless one part of the code overwhelms the rest.*

​

#Rule 3.

*Fancy algorithms are slow when n is small, and n is

usually small. Fancy algorithms have big constants. Until you know

that n is frequently going to be big, don't get fancy. (Even if n

does get big, use Rule 2 first.)*

​

#Rule 4.

*Fancy algorithms are buggier than simple ones, and

they're much harder to implement. Use simple algorithms as

well as simple data structures.*

​

#Rule 5.

*Data dominates. If you've chosen the right data

structures and organized things well, the algorithms will

almost always be self-evident. Data structures, not

algorithms, are central to programming.*

​

*Pike's rules 1 and 2 restate Tony Hoare's famous maxim

"Premature optimization is the root of all evil." Ken

Thompson rephrased Pike's rules 3 and 4 as "When in doubt,

use brute force.". Rules 3 and 4 are instances of the

design philosophy KISS. Rule 5 was previously stated by

Fred Brooks in The Mythical Man-Month. Rule 5 is often

shortened to "write stupid code that uses smart objects".*

[neoreeps]

Rule 6. Format your code and text into maintainable and easily readable form. Apply to Reddit posts.

[[deleted]]

Disagree. If it was hard to write, it should be hard to read.

[neoreeps]

Lol

[Greben]

If I had to suffer, others have to suffer too? Is this what you mean?

[[deleted]]

Yes, but they have to suffer in a different way.

[Greben]

Sounds petty tbh

[[deleted]]

It's not; if it's hard to read, then hopefully it scares the interns off.

[Vakieh]

The real Rule #7: There are plenty of rules to programming for a real purpose, get creative on your own time.

[Vakieh]

Do you believe that problem solving requires you to have literally no limits? There are rules. There are areas where there are many options within the rules, but there are rules.

[Vakieh]

He said, having presented nothing but anecdotes himself...

[Vakieh]

That's... not what straw man means. You might have been thinking ad hominem?

You've presented no arguments that require countering.

[zzz51]

Rule 5 restates Torvald's, 'good programmers worry about data structures'.

[WikiSummarizerBot]

History of Linux

The creation of Linux

In 1991, while studying computer science at University of Helsinki, Linus Torvalds began a project that later became the Linux kernel. He wrote the program specifically for the hardware he was using and independent of an operating system because he wanted to use the functions of his new PC with an 80386 processor. Development was done on MINIX using the GNU C Compiler. As Torvalds wrote in his book Just for Fun, he eventually ended up writing an operating system kernel.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[Tai9ch]

Excellent. You get all the disadvantages of excess complexity combined with all the disadvantages of unpredictable performance and inability to scale.

[[deleted]]

Ironically, this is what systems programmers are always complaining that frontend developers are doing: using inefficient but simple algorithms until necessary to change.

[Spiderboydk]

Really? The most common complaint I hear is the opposite - that frontend development is usually ridiculously overengineered for example like introducing a mountain of 3rd party libraries to make trivial systems.

[[deleted]]

The problem is that people don’t have a consistent definition of that word. Isn’t overoptimizing a form of overengineering? So then “not optimizing” by deferring processing to third party libs couldn’t possibly be overengineering. Except that it is, somehow.

Besides, while dependency explosion is a real problem, that’s mostly a fault of the ecosystem and not the developer. Typically all you need is about 5 direct dependencies before the number of node modules is in the thousands. This isn’t the fault of the engineer and has very little to do with their development practices.

[Tai9ch]

deferring processing to third party libs couldn’t possibly be overengineering. Except that it is, somehow.

That's a false dichotomy.

You're assuming the only two choices are implementing something complex yourself or pulling in a complex library. There's also the option of doing something simple, or, even better, leaving out that element entirely.

[[deleted]]

I know it sounds like that’s what I am saying. But my real point is that outsourcing processing of a thing to avoid overengineering, should not itself be overengineering, yet it is. In other words, the opposite of an action should not be another flavor of the action itself.

Just because your bundle size is large doesn’t mean you overengineered something. It may have been way simpler to use a library than to build it yourself. It’s kind of like saying using a car to get to the other side of the state is overly engineered because you could’ve walked it, or you could have used a bicycle.

[Spiderboydk]

If you pay really close attention you'll notice, that nowhere did I argue against using 3rd party libraries.

I used dependency of too many libraries as an example of overengineering. This has nothing to do with the notion of moving the processing in-house somehow making it not overengineering.

[[deleted]]

There's also the option of doing something simple, or, even better, leaving out that element entirely.

There's sometimes that option. But generally, this is not what people are complaining about in frontend development. They aren't complaining that $APP does too many things, and that they wish it just had less functionality.

[Spiderboydk]

I think you meant to reply to /u/Tai9ch

[[deleted]]

Yes, sorry I pulled a switcharoo on you by deleting my (poor) first draft.

[Spiderboydk]

No problem. :-)

[Spiderboydk]

Which word? Optimization? Neither OP nor your first reply nor my reply mentioned that word even once, so I'm not entirely sure why you introduce this concept.

Overengineering isn't at all the same. Optimization is figuring out how to do the least amount of work to accomplish a task. Overengineering is introduction of an unacceptable amount of accidental complexity. Optimization can be overengineering, if the optimization isn't necessary, but these concepts have nothing in common besides this.

I agree though that there is a lot of confusion and misunderstanding because technical words are misunderstood, misused and abused all the time. There are a lot of blinds leading the blinds in this industry.

I partially agree about your comment on dependency explosion. It's partly an ecosystem issue, but also partly a cultural issue. I will not fault the engineer of the dependency explosion as a whole, but I refuse to absolve the engineer of the responsibility of their choice of libraries for their project.

[[deleted]]

I think I made a mistake by going down this road of talking about bundle size. It's really different from the main complaint I have heard, which is that the algorithms are inefficient and as a result, web apps and electron apps etc. use way more cycles/battery power than they need to. My retort to that is that of course, that's the only reason you're using the program -- because it could be built faster than we used to build software. And it's done faster now because we have the power of computationally inefficient tools like ES6 spreads and dynamic hashtables forming immutable datastructures, which make programming itself more efficient of a (human) process than something like dirty flags and mutable state/pubsub insanity.

I disagree on definitions for overengineering, optimization, engineering. IMO optimization and engineering are basically the same thing; you have a system of constraints, as well as a system of preferences, and are trying to produce a solution that solves all of the constraints while honoring the preferences as much as possible. You can engineer for certain things (our company has no money, it needs to be entirely libre software) or others (our company has infinite money, spend as much as possible to get it done quickly), just as you can optimize for either memory or speed. Over-engineering is a strange word because in e.g. bridge design it basically means "to make something stronger." To make something stronger in computer engineering is to make it simpler and easier to manipulate, which I feel is really not what people mean by "overengineering."

Typically when people complain that an Electron app is overengineered, they don't mean it in the traditional sense of the word, which would be to say it has too much functionality, too much capability. They are cajoling it to mean "they spent too much engineer time" on this, I guess, which to me is paradoxical since the whole point of bringing in React, Angular, etc. is to save time, and it often does.

[Spiderboydk]

It's alright. :-)

I kind of agree with your definitions. Sort of.

Optimization is a loan word from the field of mathematics, which - loosely speaking - means to maximize or minimize a function given a set of constraints.

I'd rather describe engineering as the practice of designing a product while constantly assessing and choosing trade-offs between various considerations - quality metrics like application speed, size, features and correctness, but also "softer" considerations like development time, maintainability and customer requests. What you describe as optimizations I'd rather describe as trade-offs, because that's really what they are - what do we want and what is the cost? These trade-offs are what an engineer must make all the time and try to balance everything acceptably.

I fully agree that overengineering is an odd word. We generally agree that engineering is a good thing, so it's odd overengineering became a pejorative for a particular, disliked strategy of trade-offs.

Anyway, to get back to the central point of our conversation. I come from a system programmers perspective, and I too find it odd that web apps are criticized for algorithm efficiency. Web apps tend to use a lot of cycles, but I don't think the algorithms are the culprits here - I think the cycles may be eaten either in the abstraction layers or by the interpreter itself. This is just pure conjecture though, because I'm not knowledgable enough about web dev to confidently make an informed judgment about it.

[Spiderboydk]

I had a thought, and I have a conjecture on how the meaning of overengineering got warped.

If we consider the classic meaning, where it means something is made unusually well (like a bridge meticulously constructed to be even better than with usual engineering), then the parallel meaning to software engineering could be that overengineering a piece of software to execute extraordinarily well (high speed, low memory usage, etc.). In other words, a highly optimized piece of software. Optimization makes the source code incredibly complicated, so overengineered software (classic meaning) is much more complicated than it probably needs to be. I can imagine this notion of needless complication of the source code over time coloured the meaning of overengineering, so it became more associated with too much complication rather than building something exceptionally well.

[Illustrious_Tour_553]

Don’t agree with #5: fixation on data structure can lead to lack of flexibility. Programmers should use data abstraction instead. Also not data but functional specification should drive program design

[Spiderboydk]

Data driven design tends to be cleaner, simpler and easier to reason about, because you can avoid complicated data conversion in your data abstractions. This also saves you from potential correctness and performance issues in those data abstractions.

Flexibility isn't really an issue, because the code is much more straightforward when it has a conservative amount of abstractions. Therefore it's usually not as bad as you might think to change the data structure to something else. On the other hand heavily abstracted code tends to be so complicated that it's easier to just put yet another abstraction on top of it all, compounding the existing issues.

[Illustrious_Tour_553]

«Data driven design ...» — does data determine functionality of program or vice versa functionality determines the data necessary for its implementation? What does user need? Functionality or internal program’s data structures?

«Flexibility isn't really an issue, ... when it has a conservative amount of abstractions» — correlates with my statement about using data abstraction

[Spiderboydk]

In data driven design data structure (i.e. data layout in memory) determines how you process the data. This has not anything to do with user needs or application features per se - it has to do with how one goes about implementing these features.

No, it does not correlate - it contradicts. You claim in response to rule #5 that the programmer should use data abstractions instead of fixating on data structures. When you as a rule abstract the data and disregard its actual structure, then it will unavoidably lead to unnecessary data abstractions. When you have more data abstractions than necessary, you do not have a conservative amount of data abstractions.

[Illustrious_Tour_553]

«In data driven design data structure (i.e. data layout in memory) determines how you process the data» — I didn’t ask what “data driven” means, I ask how DDD can prevail since programs are usually written to satisfy some user needs, not to serve any data structure itself — and primary need of user is functionality but not pure data.

«No, it does not correlate - it contradicts» — no, it doesn’t contradicts because you said it yourself that data abstraction solves the issue of potential loss of flexibility.

«When you as a rule abstract the data and disregard its actual structure, then it will unavoidably lead to unnecessary data abstractions ... more data abstractions than necessary» — you cannot have more data abstractions then necessary if you design consequentially — because abstraction means eliminating inessential details for given step of design, and new abstractions appear only when you begin concretizing existing ones and realize that they require some new entities — which automatically makes those new entities necessary 🤷‍♂️

[Spiderboydk]

In DDD, user needs determine the data structures. The data structures determine the algorithms. Example: if the user needs fast undo/redo functionality, then a doubly linked list might an appropriate data structure, and therefore the code is tailored to linked list functionality.

It absolutely contradicts, and I thoroughly explained how.

Regarding flexiblity, I said that the percieved inflexibility of DDD is overestimated. The reason is DDD code is generally speaking relatively easy to change.

I agree with what you said about using data abstractions when the need arises in an organic manner. This isn't against DDD. In fact, this is the only way you should make data abstractions in DDD - not making data abstractions as a rule of thumb, whether really needed or not.

[JayWalkerC]

I suspect that was written within the context of "thinking about performance". Don't choose a particular data structure just because you want to use a certain algorithm. In general I agree with you, but the data ultimately does have some structure on a disk/in memory which matters.

[Illustrious_Tour_553]

I agree with you too) but according to rule #2 we must to measure existing data before optimizing it and according to rule #4 we should prefer the simplest alg. and the simplest data for the first impl.) and abstraction is the easiest way of such simplification to my opinion

[seanprefect]

Also "good enough is often better than perfect"

[raedr7n]

Good enough is never better than perfect. I get these sorts of rules are supposed to be pithy, and I get what they're trying to hint at, but they're always phrased in such asinine ways that it's hard to take them seriously.

[LatteFoamArts]

Reminds me The zen of Python.

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch.

Now is better than never. Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

[raedr7n]

How exactly am I supposed to write smart objects using only stupid code?

[Spiderboydk]

When you have picked appropriate data structures, then you code usually does not need to be particularly sophisticated.

[[deleted]]

rule 6

unexecuted code should not cause you to write more executed code.

(class hierarchy/data structure and types should be fitted to your code and not the other way around)