3 ms·

The concept of dependency distance is actually equally useful in programming languages. For example, instead of writing if condition: #...a lot of co

The concept of dependency distance is actually equally useful in programming languages. For example, instead of writing if condition: #...a lot of code... value = process() return value else: #...return error information (e.g. in a web app) return error_information I always try to write something like this instead if not condition: return error_information #...a lot of code... value = process() return value This make reading and understanding the code much easier since things that belong together are close together. This seems trivial but there is a lot of code that is written like the first block and therefore harder to understand. Sometimes, small things can make a large difference. That said, I am probably a bit over-sensitive to this kind of problem as a German, since we also have the habit of holding back the vital information in a sentence until the very last word.

ppod 11y ago
There are a lot of interesting resonances between theoretical linguistics and programming language theory. An obvious one is Subject Verb Object order: dog.bite(man) or bite(dog, man) Another one is the Liskov substitution principle and hyponym substitution. Or polymorphism and word sense disambiguation. There's also a scope thing with co-reference resolution and global variables.
jxramos 11y ago
I had refactored a fella's script the other day that made extensive use of the precondition tucked wayyyyy at the bottom in a else clause. It wasn't the cleanest explanation I provided him about why its better to tuck preconditions at the top so the failure and exit is immediately apprehended next to the conditional rather than way at the bottom. I also cited reason of unnecessary indentation but the connection you make here makes great sense and could have aided me in the explanation at the time. Good thinking.
vog 11y ago
This fits quite well in the large advice (expressed e.g. by Martin Fowler) that a function should not contain deeply nested if/then/else constructs, but a flat series of "if" statements each finishing with a "return" statement. And if this is impossible, break the function into smaller functions such that each of them is composed like that. This advice is especially helpful when coding complex conditionals in business logic. (but small enough so you don't need/want a generic rules engine and rules DSL for that.)
contingencies 11y ago
I agree and have the same habit. (I have German genes but speak no German, only native English and fluent Chinese plus a smattering of other predominantly Asian languages whose grammar tends to be similar to Chinese with a very low dependency length) To the follow-up commenters discussing OOP syntax versus function-orientation, I always refer to the monkey quote, which seems relevant here: The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. - Joe Armstrong

ppod 11y ago

There are a lot of interesting resonances between theoretical linguistics and programming language theory. An obvious one is Subject Verb Object order: dog.bite(man) or bite(dog, man) Another one is the Liskov substitution principle and hyponym substitution. Or polymorphism and word sense disambiguation. There's also a scope thing with co-reference resolution and global variables.

jxramos 11y ago

I had refactored a fella's script the other day that made extensive use of the precondition tucked wayyyyy at the bottom in a else clause. It wasn't the cleanest explanation I provided him about why its better to tuck preconditions at the top so the failure and exit is immediately apprehended next to the conditional rather than way at the bottom. I also cited reason of unnecessary indentation but the connection you make here makes great sense and could have aided me in the explanation at the time. Good thinking.

vog 11y ago

This fits quite well in the large advice (expressed e.g. by Martin Fowler) that a function should not contain deeply nested if/then/else constructs, but a flat series of "if" statements each finishing with a "return" statement. And if this is impossible, break the function into smaller functions such that each of them is composed like that. This advice is especially helpful when coding complex conditionals in business logic. (but small enough so you don't need/want a generic rules engine and rules DSL for that.)

contingencies 11y ago

I agree and have the same habit. (I have German genes but speak no German, only native English and fluent Chinese plus a smattering of other predominantly Asian languages whose grammar tends to be similar to Chinese with a very low dependency length) To the follow-up commenters discussing OOP syntax versus function-orientation, I always refer to the monkey quote, which seems relevant here: The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. - Joe Armstrong