Comment by Waterluvian

Comment by Waterluvian a day ago

21 replies

View on Hacker News

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.

igregoryca a day ago

This 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!)

Reply View 0 replies
0xWTF a day ago

Can I float an adjacent model? Classes are nouns, functions are verbs.

Reply View 13 replies
  • BobbyJo a day ago

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

    Reply View 0 replies
  • acbart a day ago

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

    Reply View 6 replies
    • 2muchcoffeeman 16 hours ago

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

      Reply View 1 reply
      • AStonesThrow 16 hours ago

        I don't believe that anyone wears pendants much on that show, unless you mean the communicators people wear in TNG. I did have a Romulan keychain once, though.

        Reply View 0 replies
    • kiviuq 21 hours ago

      Example: Object Algebra pattern represents data types ("nouns") as functions.

      Reply View 0 replies
    • nailer a day ago

      Haven’t seen that yet after 25 years. It just always seems like lazy naming when this isn’t followed. Maybe I missed something.

      Reply View 2 replies
      • angra_mainyu a day ago

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

        Reply View 0 replies
      • cdaringe 10 hours ago

        Agreed. Compelling receipts required.

        Reply View 0 replies
  • Waterluvian a day ago

    Didn’t the Apollo guidance computers work with VERB and NOUN?

    Reply View 0 replies
  • slipnslider a day ago

    I 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

    Reply View 0 replies
  • [removed] a day ago
    [deleted]
    Reply View 0 replies
  • kjkjadksj a day ago

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

    Reply View 0 replies
nagaiaida 20 hours ago

it's not that weird, this taken to its logical conclusion is effectively prolog's execution model

Reply View 0 replies
BoorishBears a day ago

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

Reply View 3 replies
  • jonahx a day ago

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

    Reply View 2 replies
    • BoorishBears 4 hours ago

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

      Reply View 1 reply
      • jonahx 2 hours ago

        Because that was the only evidence you offered to back up the claim you just quoted. I understood the claim... it might be interesting if you presented some specific example of your own as counter-evidence, instead of straw-manning the article's intentionally simple example as too simplistic.

        Your argument sounds like, "I'm so smart and enlightened, I've moved beyond simple heuristics like this." Okay, but the author is also a smart, experienced programmer and is apparently still finding them useful. I am also experienced, and personally find them useful.

        I'm not against some argument that there is actually an even better, deeper way to look at these things. But you didn't make that argument. And, perhaps unfairly (you tell me) I suspect your response to that will be that it's all too gossamer, or would take too long to explain....

        Reply View 0 replies