On Mon, Jul 18, 2011 at 4:25 PM, David Goehrig <d...@nexttolast.com> wrote:
> While some level of formalism will be useful when discussing > the behavior and specification of this system, it should not be a > prerequisite for use. Yeah, that I agree with. Or more precisely: a developer should need to be educated in the system's formalism in order to effectively develop. We want our programming model to support a gradual learning curve and progressive disclosure. I believe that how we model UIs - especially with regards to transclusion, transformation, and mashups - will have a huge influence on how effectively we can gradually expose developers to the formal aspects of a programming model. Tangible values, naked objects, dataflow wires, live programming, and so on allow users to grow familiar with a model as a normal part of controlling or extending their environment. Not all formal models are well suited to this sort of UI tweaking and progressive disclosure. We should choose a formal model that is well suited to it... such as reactive demand programming. ;-) > I wish programming was less formal and ridgid. Real progress would be made > when an ordinary individual with a reasonable grasp of their native tongue > could roughly describe their requirements and the computer could deduce the > proper implementation via a process of successive revision and > interrogation. > 'Formal' does not imply 'rigid'. We can have a great deal of flexibility and resilience in formal systems, assuming we design for those goals. And we should distinguish between the *process* of programming, and the *product*. I.e. you might be confusing 'formal methods' with 'formal semantics'. Formal semantics allow formal methods, don't require them. I would not want to use an interrogative session as 'source code', but I would not mind if we spoke to some high-quality 'office-assistant' that helps write code or offers assistance on our behalf. Treat this more as a problem of CSCW and expert systems, rather than an issue of language semantics. A good user-agent could even learn peculiarities of the developer, learning to read gestures and incomplete thoughts. > > Until we break the program free from its representation, we will not have > tools sufficient to the task. > Until we break the language free from its implementation, we will not develop sufficient tools for the task. Trying to develop, say, a graphical editor for data plumbing code is hard enough when there is only one 'formal semantics' to target.
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
