When working on source files with wide-ranging scopes, I wish source editors could pin the declaration lines to the top of the window like section headers, something like this
Conversation
A lot of people replying with “just write short functions” need to read number-none.com/blow/john_carm
13
19
134
"The hardest problem in computer science is naming things", as they say. But it's not only the name itself, but the fact that introducing a name introduces a new vertex of unbounded degree into your program's data and control flow graph.
Quote Tweet
Replying to @kastiglione @jckarter and @hillelogram
The part that really got me, was that small functions make for a graph, but where their execution is linear, you've got an mismatched representation.
3
13
75
it’s also funny that “write short functions” can be actively harmful in languages with more advanced type systems because its like “oh you wanted to factor that code out? goodluck writing the signature...”
1
9
haskell is *more* resilient to this problem because global inference and completely ignoring type representation lets you punt on these problems for internal apis, but swift/rust need to grow crap like existential returns to make factoring tolerable
2
4
but in the case of rust there’s limits where certain type system magicks *only* exist within a single function. For instance Rust provides no way to indicate methods only borrow a subset of fields, but within a function body it naturally understands these disjoint accesses
1
4
Yeah we run up against this stuff a bunch at YesLogic. Not just for disjoint accesses, but sometimes you want existential lifetimes, say if you construct something within a function, then return part of it. Atm it's impossible to factor that out into a separate definition.
Non-lexical lifetimes are great and all, but it's frustrating when the type checker can do things that aren't expressible in the types.
1