2 ms·

I've been gravitating towards the stance lately(independently of reading about K and the APL family style) of aiming towards "total-factor symbol reduction" - i

by chipsy 12y ago

I've been gravitating towards the stance lately(independently of reading about K and the APL family style) of aiming towards "total-factor symbol reduction" - i.e. a program coded with fewer symbols, and fewer unique symbols, is preferable to one that introduces many new symbols, or uses existing ones inefficiently. From this perspective, just factoring out imperative code into a named subroutine becomes a pain point because it adds new symbolic content - a new name, things being passed in, things being returned, things that were in scope suddenly falling outside of it. It is no longer an "organization tool" - you can add a level of block scope and a comment for that instead, and navigate the resulting large functions with code folding. And classes - well, classes become something to avoid! APL style simply moves this concept down to the per-character level of thought and advocates additional care towards certain measures of readability. "It is more likely," says the APL programmer, "that you will see a typo in a 2 character name than in a 10 character name." The language aids in this process by providing tools that drastically condense common operations and encouraging their use as the default.

MichaelGG 12y ago
Read John Carmack's writings on inlining (also discussed here on HN [1]) where inlining refers to keeping one function with all its work done in there, instead of calling out even to things like "myfuncstep1", "myfuncstep2", etc. I just hit a major bug due to that kind of thing, where stuff wasn't clear due to messy size of the code (customer insisted on C#). If the relevant sections had been sitting on screen, then I most likely would have noticed or never even made it in first place. I also started working with a new hire, one that isn't an FP proponent, and I'm shocked at the variable names. Even iterating a list of entry objects: I'd naturally write the list as 'es', and the current item 'e'. Versus 'entriesToProcess' and 'current entry'. Or even 'entries' and 'ent'. People's objections there seem to be that 'entries' is more readable than 'es'. While that may be true in isolation, I'm not sure it matters when working on a codebase above a few hundred lines. The amount if context is likely to be high enough that you're not going to be plucking one line out for changing, and the local context (and typing) should make it apparent it's a plural of e.g. entries, not employees. 1 https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345

by chipsy 12y ago

MichaelGG 12y ago

Read John Carmack's writings on inlining (also discussed here on HN [1]) where inlining refers to keeping one function with all its work done in there, instead of calling out even to things like "myfuncstep1", "myfuncstep2", etc. I just hit a major bug due to that kind of thing, where stuff wasn't clear due to messy size of the code (customer insisted on C#). If the relevant sections had been sitting on screen, then I most likely would have noticed or never even made it in first place. I also started working with a new hire, one that isn't an FP proponent, and I'm shocked at the variable names. Even iterating a list of entry objects: I'd naturally write the list as 'es', and the current item 'e'. Versus 'entriesToProcess' and 'current entry'. Or even 'entries' and 'ent'. People's objections there seem to be that 'entries' is more readable than 'es'. While that may be true in isolation, I'm not sure it matters when working on a codebase above a few hundred lines. The amount if context is likely to be high enough that you're not going to be plucking one line out for changing, and the local context (and typing) should make it apparent it's a plural of e.g. entries, not employees. 1 https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345