Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cognitive load is what matters

github.com

Post reply on HN
Print view View original

451–460 of 552 posts

Re: Cognitive load is what matters

#451

Post by djtango »

dehrmann wrote: post #182
djtango wrote: post #52

Earlier quoted context omitted.

IMO you touch on the real heart of the issue at the end - the real world and business is messy and really _is_ just a pile of if statements. When the problem itself is technical or can be generalised then abstractions can eliminate the need for 1000s of if-statement developers but if the domain itself is messy and poorly specified then the only ways abstractions (and tooling) can help is to bake in flexibility, becau…

In most assembly languages, the instructions are essentially load and store, arithmetic operations, and branch and jump. Almost everything is abstractions around how to handle branching and memory.

Right and a compiler is mostly technical.

Re: Cognitive load is what matters

#452

Post by defanor »

whilenot-dev wrote: post #447
defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

> one would have to look up what "isSecure" means, while "(condition4 && !condition5)" would have shown it at once You would feel the need to look up a variable called isSecure , but would not need to look up condition4 or condition5 ? I think the point TFA was making is that one could read isSecure and assume what kind of implementation to expect, whereas with condition4 I wouldn't even know what to look for, or I'd…

> You would feel the need to look up a variable called isSecure, but would not need to look up condition4 or condition5?

I assume that those "conditions" are placeholders, not to be read literally in the example (since the example is not about poorly named variables, but about complex conditions), so I did not mean them literally, either. Supposedly those would be more informative names, such as "channel_encrypted", "checksum_verified".

> [...] describe wishful thinking by straight-up lying

This was what I had in mind upon seeing that "isSecure" bit, too: could easily be a lie (or understood differently by different people). But taking a little more effort to check then, and/or having to remember what those variables actually mean. It is a commonly debatable topic though, where the good balance is, similarly to splitting code into small functions: people tend to balance between spaghetti code and extreme splitting.

My point though is not to argue with those particular points here, but that we have no such practices/rules universally considered simple and formally stated/verifiable.

Re: Cognitive load is what matters

#454

Post by edem »

xmprt wrote: post #142

This is one of the reasons I fear AI will harm the software engineering industry. AI doesn't have any of these limitation so it can write extremely complex and unreadable code that works... until it doesn't. And then no one can fix it. It's also why I urge junior engineers to not rely on AI so much because even though it makes writing code so much faster, it prevents them from learning the quirks of the codebase and…

id argue that it already harmed the industry

Re: Cognitive load is what matters

#455

Post by Cthulhu_ »

defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

Likewise, some people prefer ternary statements for short checks; I want to agree because ternaries are one of the first things you learn after if/else/while/for, but at the same time... they're a shorthand, and shorthand is short but not necessarily more readable.

For one-off things like value = condition ? a : b I don't mind much, but I will make an issue as soon as it spans more than one line or if it's nested.

Re: Cognitive load is what matters

#456

Post by wreath »

zakirullin wrote: post #346
YZF wrote: post #316

Earlier quoted context omitted.

The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arguments. I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you…

> I like the article but the people who need it won't understand it That's true. One doesn't change his mindset just after reading. Even after some mentorship the results are far from satisfying. Engineers can completely agree with you on the topic, only to go and do just the opposite. It seems like the hardest thing to do is to build a feedback loop - "what decisions I made in past -> what it led to". Usually that l…

In an industry where most people stay for around 2 years (at least pre 2022), people arent even there to see the results of their decisions.

Re: Cognitive load is what matters

#457

Post by mabster »

Cthulhu_ wrote: post #455
defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

Likewise, some people prefer ternary statements for short checks; I want to agree because ternaries are one of the first things you learn after if/else/while/for, but at the same time... they're a shorthand, and shorthand is short but not necessarily more readable. For one-off things like value = condition ? a : b I don't mind much, but I will make an issue as soon as it spans more than one line or if it's nested.

I particularly don't like ternaries with side-effects or control flow. In particular with control flow I prefer it always tabbed in otherwise sometimes I miss it -- if statements are much better for this.

Re: Cognitive load is what matters

#458

Post by brabel »

cyberax wrote: post #442
brabel wrote: post #436

Earlier quoted context omitted.

That’s only true in languages that do not have Algebraic Data Types and pattern matching, which nowadays is a minority of languages (even Java has it).

Visitors additionally allow you to decouple graph traversal from the processing. It is still needed even in the languages with pattern matching. There's also the question of exhaustiveness checking. With visitors, you can typically opt-in to either checking that you handle everything. Or use the default no-ops for anything that you're not interested in. So if you look at compilers for languages with pattern matching…

The example you posted is very interesting as it used both a visitor and ADTs. It seems the need for the Visitor comes from the generics in this case? Probably a Rust specific limitation. I don’t understand why you mention exhaustiveness though, it’s obviously easy have comprehensive or partial matching with ADT.

Re: Cognitive load is what matters

#459

Post by hollowturtle »

Like another user said it depends on each developer background what's simpler and what's not. For example I have a problem with intermediate variables for improving readability, like isAllowed, it really is more readable but more often than not in large codebases what the name implies is not what the conditional check is or it is but it's not exaustive. So i have to inspect the variable to see what it actually is. The thing is that comments and variable names must be maintained as well as code, so it implies a certain degree of cognitive load to maintain. While a conditional like (condition2 || condition3) looks bad it still is more straightforward

Re: Cognitive load is what matters

#460

Post by epolanski »

defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

Indeed, familiarity is 95% the reason why one would find a solution more, or less simple.
Post reply on HN