5 ms·
My weird mental model: You have a tree of possible states/program flow. Conditions prune the tree. Prune the tree as early as possible so that you have to do wo
by Waterluvian 1y ago
My weird mental model: You have a tree of possible states/program flow. Conditions prune the tree. Prune the tree as early as possible so that you have to do work on fewer branches.
Don’t meticulously evaluate and potentially prune every single branch, only to find you have to prune the whole limb anyways.
Or even weirder: conditionals are about figuring out what work doesn’t need to be done. Loops are the “work.”
Ultimately I want my functions to be about one thing: walking the program tree or doing work.
- Brian_K_White 1y agoperfectly good models
- 0xWTF 1y agoCan I float an adjacent model? Classes are nouns, functions are verbs.
- slipnslider 1y agoI remember being taught that in CS101 and still use it today 15 years later. It's a good and simple and easy to follow pattern
- pshc 1y agohttp://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- Waterluvian 1y agoDidn’t the Apollo guidance computers work with VERB and NOUN?
- BobbyJo 1y agoI like to think of it completely differently: Functions are where you hide things, Classes are where you expose things. Functions to me are more about scoping things down than about performing logic. The whole program is about performing logic.
- acbart 1y agoAnd then at some point someone shows you how Classes can be verbs, and functions can be nouns, and your brain hurts for a while. You overuse that paradigm for a while, and eventually learn to find the appropriate balance of ideas.
- nailer 1y agoHaven’t seen that yet after 25 years. It just always seems like lazy naming when this isn’t followed. Maybe I missed something.
- cdaringe 1y agoAgreed. Compelling receipts required.
- angra_mainyu 1y agoI have to agree, particularly if you look at functions as pipelines: data/events go in, other data/events go out. If I had to hazard some kind of heuristic with 99% applicability, it'd be to always strive to have code with as few indentations (branches) as possible. If your code is getting too indented, those deep Vs are either a sign that your implementation has a strong mismatch with the underlying problem or you need to break things up into smaller functions.
- kiviuq 1y agoExample: Object Algebra pattern represents data types ("nouns") as functions.
- 2muchcoffeeman 1y agoWriting code is like writing though. None of these ideas for structuring code are the be all and end all of coding. Things evolve, sometimes old idea are good, sometimes new. Like how the phrase “to boldly go where no man has gone before” will bring out pendants.
- AStonesThrow 1y ago
- deleted 1y ago[deleted]
- kjkjadksj 1y agoWorking with python for a while and I still don’t bother with classes. Only when I “borrow” other code do I mess with them. It just seems like a flowery way to organize functions. I prefer to just write the functions. Maybe its because my first languages lacked classes that I don’t much like to reach for them. I don’t even like loops and prefer to functionalize them and run in parallel if sensible. I know this makes me a bit of a python heathen but my code runs fast as a result.
- BoorishBears 1y agoMy mental model: align with the world the very specific code I'm writing lives in. From domain specifics, to existing patterns in the codebase, to the stage in the data pipeline I'm at, performance profile, etc. I used to try and form these kinds of rules and heuristics for code constructs, but eventually accepted they're at the wrong level of abstraction to be worth keeping around once you write enough code. It's telling they tend to resort to made up function names or single letters because at that point you're setting up a bit of a punching bag with an "island of code" where nothing exists outside of it, and almost any rule can make sense. - Perfect example is the "redundancies and dead conditions" mentioned: we're making the really convenient assumption that `g` is the only caller of `h` and will forever be the only caller of `h` in order to claim we exposed a dead branch using this rule... That works on the island, but in an actual codebase there's typically a reason why `g` and `h` weren't collapsed into each other to start.
- jonahx 1y agoI feel this kind of critique, which I see often as a response to articles like this, is so easy as to be meaningless. How is one supposed to ever talk about general principles without using simplified examples? Aren't you just saying "Real code is more complicated than your toy example"? Well sure, trivially so. But that's by design. > Perfect example is the "redundancies and dead conditions" mentioned: we're making the really convenient assumption that `g` is the only caller of `h` and will forever be the only caller of `h` in order to claim we exposed a dead branch using this rule... Not really. He's just saying that when you push conditional logic "up" into one place, it's often more readable and sometimes you might notice things you otherwise wouldn't. And then he created the simplest possible example (but that's a good thing!) to demonstrate how that might work. It's not a claim that it always will work that way or that real code won't be more complicated.
- BoorishBears 1y agoWell I guess some comments need to be considered in totality, rather contextomies that enforce whatever point you're trying to make :) I spelled out the problem pretty clearly. > I used to try and form these kinds of rules and heuristics for code constructs, but eventually accepted they're at the wrong level of abstraction to be worth keeping around once you write enough code. It's the wrong level of abstraction to form (useful) principles at, and the example chosen is just a symptom of that. I'm not sure why we're acting like I said the core problem with this article is that it uses simple examples.
- igregoryca 1y agoThis aligns nicely with how things look in the "small-step" flavour of PL theory / lambda calculus. In the lingo, expressions are evaluated by repeatedly getting "rewritten", according to rules called reduction rules. e.g., (1 + 2) + 4 might get rewritten to 3 + 4, which would then get rewritten to 7. There are two sorts of these rules. There are "congruence" rules, which direct where work is to be done ("which subexpression to evaluate next?"); and then there are "computation" rules (as Pierce [1] calls them), which actually rewrite the expression, and thus change the program state. "Strict"/"non-lazy" languages (virtually every popular general-purpose language? except Haskell) are full of congruence rules – all subexpressions must be fully evaluated before a parent expression can be evaluated. The important exceptions are special constructs like conditionals and indefinite loops. For conditionals in particular, a computation rule will kick in before congruence rules direct all subexpressions to be evaluated. This prunes the expression tree, now in a very literal sense. [1]: Benjamin C. Pierce, Types and Programming Languages (recommended!)
- nagaiaida 1y agoit's not that weird, this taken to its logical conclusion is effectively prolog's execution model