Thanks for responding, Sean. But I hope you provide your own ideas and concepts, also, rather than just reacting to mine. :)
On Thu, Aug 29, 2013 at 6:23 PM, Sean McDirmid <smcd...@microsoft.com>wrote: > My response:**** > > ** ** > > 1) Formal justification of human behavior is a lofty goal, especially with > today’s technology. We know how to empirically measure simple reflexes (say > Fitt’s or Hicks’ law), but anything complex gets pummeled by noise in the > form of bias and diversity. And how do those simple processes compose into > cognition. Focusing just on what can be will lead to very LCD (lowest > common denominator) designs. And when we do finally figure it out, I’m > afraid we’ll be at the point of singularity anyway when we’ve learned how > to design something better than us (and they’ll have no problem > programming!). > Well, my goal isn't to "justify human behavior" in the wild, but rather to help guide it: * I provide a basis for formally justifiable intuitions * I provide an environment that supports exploratory programming and learning * I provide type-systems, design patterns, idioms that guide thoughts in certain terms * The valid intuitions will develop under these conditions. Even more so if I accomplish my goal at integrating programming with HCI. Under those conditions, the intuitions can have a very long time to develop, many years as children grow to adolescence and adulthood. The implicit understanding of composition, reactivity, authority, process control, etc. will transfer from their user experience to their programming experience. I believe a very high LCD can be achieved. Compositional properties can address: robustness and resilience, consistency and inconsistency-tolerance, process and resource control, live update and orthogonal persistence, security and safety, roles and responsibilities. One area I have not been able to address is "correctness". Actually, I'm pretty sure that correctness cannot ever be addressed in a composable manner, due to its highly context-sensitive nature. I think even AIs will benefit from compositional properties. The thing is, it won't be one big AI that has everyone's best interests at heart; I believe it will be a million AIs... and making them integrate will still require solving all these issues. > **** > > ** ** > > I think enforcing rigid philosophies in languages is useful (languages > shape thinking) but also comes at a cost, since you then alienate code (and > their programmers) who cannot live up to your strict standards. The use > cases for linear types, for example, is important but fairly niche; most > programmers need flexibility over guarantees. > The perception that 'flexibility' and 'guarantees' are somehow in conflict is an incorrect one, but is unfortunately widespread. I suppose a fear is that the "API makers" will constrain the "API users" more than strictly necessary. In practice, these features - fine-grained, formal, and precise - result in greater flexibility and lower impedance, i.e. since the API designers don't resort to gatekeeper patterns or DSL interpreters or other overbearing mechanisms to protect their contracts or invariants. Basically, without such guarantees, programmers are often forced to "be flexible" in private, on their own turf. :( As an example: call/cc patterns offer a lot of flexibility compared to the traditional call-return paradigm. There are many use-cases where something like call/cc would be convenient, e.g. for 'port based objects' - a design pattern where framework code is interwoven with multiple functions in client-object code. But the problem is that a current continuation might be forgotten or called twice, which may wreak havoc on the framework's invariants. If we could flag the cc as linear, we could address this, and gain the flexibility of the cc - such as simpler threading or ability to temporarily "return" to a different framework than the one that called us. There are quite a few 'flexible' patterns - both for dataflow and control-flow - that become safer and thus easier to express and integrate in the presence of linear types. The weaker variations on linear types - affine types (use at most once) and relevant types (use at least once) - are also useful for various purposes. I especially like affine types to control fan-in; e.g. I can create a bag of affine types like 'tickets' to a limited resource - big enough to be flexible, small enough to keep implementations simple (no 'zero one infinity' nonsense). [next e-mail!] > Accidents are merely unexpected innovations. Not everything good and > useful will fall out of the principles we know about or follow. I will > throw in one more essential principle that should act as a last-resort > default “worse is better;” aka the New Jersey principle J. Sometimes we > don’t know the “right” answer, but just putting in a plausible answer is > better than pondering forever what the right answer would be. Sometimes we > just “don’t know” and need more experience to develop new principles. ** **** ** **** "Worse is better" principle is very practical and valuable when we don't already have working solutions. Worse is better than nothing. But I think that motto is not for scenarios where many incumbent solutions exist, already vying to be at the top of that 'better' heap. 'Worse is better' just leads to being better in a few ways and worse in many others. King of a very local hill - if you're persistent, and only if you keep working at it. These days, what good is a marginal improvement? There is a significant cost for migration, experimentation, validation, documentation, learning, training, and the end result is a system that -- if it weren't for problem-specific lessons-learned streamlining the experience -- would seem hardly better than the one you left. Sometimes we don't know the "right" answer, but we already have many forgotten or competing "workable" answers. In these conditions, we have time to ponder what a right answer might be. Sometimes we just "don't know" but, rather than reinventing old mistakes, we should study what has failed or succeeded in the past, and combine or refine OLD principles. This might be a source of differences in our philosophies. :)
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
