[fwd to fonc] When I speak of merging programming and HCI, I refer more to the experience than the communities. I'm fine with creating a new HCI experience - perhaps one supporting ubiquitous computing, augmented reality.
I can't say my principles are "right"! Just that they are, and that I believe they're useful. If you don't like call/cc, I could offer similar stories about futures/promises (popular in some systems), or adaptive pipelines that adjust to downstream preferences (my original use case). There are actually several ways to compose predictive/learning systems. The simple compositions: they can be chained, hierarchical, or run in parallel (combining independent estimates). More complicated composition: use speculative evaluation to feed predicted behaviors and sensory inputs back into the model. (Speculation is also useful in on-the-fly planning loops and constraint models.) I think plodding along in search of new knowledge is fine. But my impression is that many PL projects are ignoring old research, plodding the old ground, making old mistakes. We can't know everything before we begin, but we don't need to. Just know what has succeeded or failed before, and have a hypothesis for why. On Aug 29, 2013 8:50 PM, "Sean McDirmid" <[email protected]> wrote: > My own ideas are quite mundane on this subject since I take design at > face value. It is not something that can be formally validated, and is more > of an experiential practice. I disagree that formally “right” answers are > even possible at this point, and would have a hard time arguing with > someone who did given that we would be talking past each other with two > very different world views! **** > > ** ** > > Also, this might be interesting: HCI started out as a way of figuring out > how humans programmed computers, since there was very little interacting > with computers otherwise. The visual programming field was then heavily > intertwined with HCI in the 90s, before HCI broke off into its current > CHI/UIST form today. But I have to wonder: is merging HCI and programming > worth it? I say this, because I don’t believe the HCI community is a very > good role model; their techniques can be incredibly dicey. They don’t have > a formal notion of right, of course, but even their informal methodologies > are often contrived and not very useful (CHI has lots of papers, there are > a few good ones that do well enough in their arguments). **** > > ** ** > > Composition is quite thorny outside of PL. There is no way to compose > neural networks, most machine learning techniques result in models that are > neither composable or decomposable! There is a fundamental limitation here > that we in math/PL haven’t had to deal with yet. But this limitation arises > in nature: we can often decompose systems logically in our head (e.g. the > various biological systems of an organism), but we can’t really compose > them…they just arise organically. **** > > ** ** > > I don’t think call/cc is a good example of flexibility vs. guarantees. Not > many programmers use it directly, and those that do are very disciplined > about it. I would love to see someone push linear types just to see how far > they can go, and if they promote rather than limit flexibility like you > claim. I’m suspecting not, but would be happy to be wrong. **** > > ** ** > > “worse is better” is very agile and prevents us from freezing up when our > principles, intuitions, and formal theories fail to provide us with > answers. Basically, we are arguing about how much we know and can know. My > opinion is that there are just so many things we don’t know very well, and > we’ll have to plod along in the pursuit of results as well as knowledge. > This contrasts with the waterfall method, which assumes we can know > everything before we begin. These different philosophies even surface in PL > designs (e.g. Python vs. Haskell). **** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David Barbour > *Sent:* Friday, August 30, 2013 11:20 AM > *To:* [email protected] > *Cc:* Fundamentals of New Computing > *Subject:* Re: Interaction Design for Languages**** > > ** ** > > 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 <[email protected]> > 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. :)**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out.**** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out. >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
