3 ms·

but is that helpful? i mean, i love lots of various reference sites, and have enjoyed autocomplete and inline "labeling" of functions in IDEs, but I keep thinki

by th0ma5 14y ago

but is that helpful? i mean, i love lots of various reference sites, and have enjoyed autocomplete and inline "labeling" of functions in IDEs, but I keep thinking about his talk that went big a bit ago, and keep thinking of these things he's developing as just analytic or test harnesses to zero in on a goal that he's actually already programmed. so, to ask for our tools to have these qualities built in assumes it knows anything about the total picture. for instance, processing's language is a small subset, so maybe it isn't the best example, but someone new to programming in processing might not realize that specifying fill 30 times means that only the last one is the effective one for the subsequent drawing. anyway, there's a lot of uninformed things you can do with any language, and i don't know that blurring the lines between input and interface give us any new insights for the actual act of coding. i think it is great for analysis of coding after the fact, however. like a JIT compiler or other compile time optimizations are great, but it assumes a complete and observable solution that has been expressed already. another example that is maybe in the neighborhood of a valid response to your reply is like the heap size in java. if i know i what i'm doing and why, i could set it rather high to achieve a goal, but mostly i don't mess with it because its a great reminder i'm making a bigger mess maybe than i should be for whatever problem i'm working with... however, it seems that victor's ideology is that the heap should always know how big it should be given anything i might want to express, and that somehow the halting problem wouldn't apply.

thedudemabry 14y ago
Regarding your fill() example, I believe his point was that uninformed decisions are a reflection of the interface exposed. Since the fill color is an implicit global variable, and not exposed anywhere in the interface, there is no way to discover its existence or behavior except via trial and error or reading the documentation. If the fill color were either exposed via the programming interface, or were explicit, then no meta-knowledge would be required to use it. Similarly, the heap size limits in Java are global limits implicit to the system, not to the program being designed. His solution to the larger problem—data growing beyond available resources–might involve providing a better visualization of the data. Something more responsive than the feedback loop provided by heap limits. Getting an OutOfMemoryException doesn't help you to understand how the data grew beyond expectations; it is always followed by a heap dump. What if you could better understand the patterns of allocation during design instead?

by th0ma5 14y ago

thedudemabry 14y ago

Regarding your fill() example, I believe his point was that uninformed decisions are a reflection of the interface exposed. Since the fill color is an implicit global variable, and not exposed anywhere in the interface, there is no way to discover its existence or behavior except via trial and error or reading the documentation. If the fill color were either exposed via the programming interface, or were explicit, then no meta-knowledge would be required to use it. Similarly, the heap size limits in Java are global limits implicit to the system, not to the program being designed. His solution to the larger problem—data growing beyond available resources–might involve providing a better visualization of the data. Something more responsive than the feedback loop provided by heap limits. Getting an OutOfMemoryException doesn't help you to understand how the data grew beyond expectations; it is always followed by a heap dump. What if you could better understand the patterns of allocation during design instead?