2 ms·

In each, it took me between few weeks to few months to fully understand their code-base, and I have about 6 years of experience with JavaScript. This does not s

In each, it took me between few weeks to few months to fully understand their code-base, and I have about 6 years of experience with JavaScript. This does not seem reasonable to me at all. Correct me if I'm wrong, but for entire large codebases, isn't this normal? The problem is that we still don't have enough developed tools to truly analyze internal/white-box code relationships (or perhaps we do, but they're buried in research circles). Expressive programming languages seem to only go so far. Most IDEs have symbol tables, tree visualization, but those are hardly enough. UML was a failure. In contrast, our black-box analysis tools, like the various system tracers (DTrace, SystemTap, s/l/ftrace, etc.), debuggers, disassemblers, decompilers and fuzzers, are relatively well advanced. I don't know if moving to image-based environments would help with this, though that'd be too profound a leap.

falcolas 12y ago
Hmm. This is an interesting topic to think about. Why aren't the tools for analyzing White Boxes as good as those we have for Black Boxes? I would say it's due to the differences in boundaries. For example, Black Box tools have it simple. Capture anything that crosses in the direction of Black to White. Capturing what goes from White to Black is much harder, though, since there are less visible boundaries on what can be accessed. For example - if I write a black box which utilizes a environment variable, you have to be tracking what memory a program accesses to see this from outside the program. White boxes, on the other hand, have very few boundaries, and those which exist are fuzzy at best. Sure, there are technically functions and modules and scopes, but these boundaries are soft; frequently and easily pierced. Global variables, shared memory, inlined functions, tail call optimization, continuation passing... all of these make it incredibly difficult to reason about and trace program flow, because the program flow depends so heavily on the global context. Functionally pure programming paradigms might be our best bet in the long run: when a "function" produces deterministic output for given input, we suddenly create a network of predictable black boxes within our white box, giving us the edges we need in order to implement our tracing and automated reasoning tools.
forgottenpass 12y ago
Correct me if I'm wrong, but for entire large codebases, isn't this normal? Perfectly normal for large codebases. You can have a low LOC that leverages only well known platforms, libraries and frameworks but you'll get a pretty cookie-cutter product. You can choose to do something technologically novel, but expect to pay for it in LOC.

falcolas 12y ago

Hmm. This is an interesting topic to think about. Why aren't the tools for analyzing White Boxes as good as those we have for Black Boxes? I would say it's due to the differences in boundaries. For example, Black Box tools have it simple. Capture anything that crosses in the direction of Black to White. Capturing what goes from White to Black is much harder, though, since there are less visible boundaries on what can be accessed. For example - if I write a black box which utilizes a environment variable, you have to be tracking what memory a program accesses to see this from outside the program. White boxes, on the other hand, have very few boundaries, and those which exist are fuzzy at best. Sure, there are technically functions and modules and scopes, but these boundaries are soft; frequently and easily pierced. Global variables, shared memory, inlined functions, tail call optimization, continuation passing... all of these make it incredibly difficult to reason about and trace program flow, because the program flow depends so heavily on the global context. Functionally pure programming paradigms might be our best bet in the long run: when a "function" produces deterministic output for given input, we suddenly create a network of predictable black boxes within our white box, giving us the edges we need in order to implement our tracing and automated reasoning tools.

forgottenpass 12y ago

Correct me if I'm wrong, but for entire large codebases, isn't this normal? Perfectly normal for large codebases. You can have a low LOC that leverages only well known platforms, libraries and frameworks but you'll get a pretty cookie-cutter product. You can choose to do something technologically novel, but expect to pay for it in LOC.