To unify PL and UI:
values: Date Calculator, String Calculator, Numeric Calculator,
Zipper/Document Visualizer
behavior, code: Recorder (the container), Script,
Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified
Control Structure)
Also, Exceptions (has anyone seen a UI for this?)
signals: Mouse, along with x,y coordinates
Keyboard and Keystrokes
Audio: waveform and controls
Webcam: video and controls
Networking: the extend/receive I/O operation
System interface: pipes, command prompt
On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <[email protected]> wrote:
> I think we cannot rely on 'inspection' - ability to view source and so on
> - except in a very shallow way - e.g. to find capabilities directly
> underlying a form. Relying on deep inspection seems to have several
> problems:
>
> 1) First it would take a lot more study and knowledge to figure out the
> intention of code, to distinguish the significant behavior from the
> insignificant. Intentions could be easily obfuscated.
>
> 2) Since it would be difficult to embed this 'study and knowledge' into
> our programs, it would become very difficult to automate composition,
> transclusion, view-transforms, and programmatic manipulation of UIs. We
> would rely on too much problem-specific knowledge.
>
> 3) When so much logic is embedded in the surface of the UI, it becomes
> easy for widgets to become entangled with the ambient logic and state. This
> makes it infeasible to extract, at a fine granularity, a few specific
> signals and capabilities from one form for use in another.
>
> 4) Relying on deep inspection can violate encapsulation and security
> properties. It would be difficult to move beyond a closed system into the
> wider world - cross-application mashups, agents that integrate independent
> services, and so on.
>
> If I'm to unify PL with UI, I cannot assume that I have access to the code
> underlying the UI. Instead, I must ensure that the UI is a good PL at the
> surface layer. We can understand UIs to be programming languages, but often
> they are not very good languages with respect to composition, modularity,
> appropriate level of abstraction. That's the problem to solve - at the
> surface layer, not (just) under-the-hood.
>
> In such a system, "copy-and-paste code" could be *exactly the same* as
> "copy-and-paste UI", though there may be different types of values
> involved. We could have blocks of code that can be composed or directly
> applied to UI elements - programmatically transforming or operating on
> them. The moment users are forced to 'look under the hood' and extract
> specification, the ideal fails. UI and PL are separated. There are now two
> distinct surface syntaxes, two distinct meanings and semantics, and a gap
> between them bridged with arcane logic.
>
> To unify PL and UI, widgets must *be* values, behaviors, signals, code.
>
> And any "looking under the hood" must be formally represented as
> reflection or introspection, just as it would be in a PL.
>
> On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <[email protected]> wrote:
>
>> One thing you can do is create a bunch of named widgets that work
>> together with copy and paste. As long as you can do type safety, and can
>> appropriately deal with variable explosion/collapsing. You'll probably
>> want to create very small functions, which can also be stored in widgets
>> (lambdas). Widgets will show up when their scope is entered, or you could
>> have an inspect mode.
>> On Sep 9, 2013 5:11 PM, "David Barbour" <[email protected]> wrote:
>>
>>> I like Paul's idea here - form a "pit of success" even for people who
>>> tend to copy-paste.
>>>
>>> I'm very interested in unifying PL with HCI/UI such that actions like
>>> copy-paste actually have formal meaning. If you copy a time-varying field
>>> from a UI form, maybe you can paste it as a signal into a software agent.
>>> Similarly with buttons becoming capabilities. (Really, if we can use a
>>> form, it should be easy to program something to use it for us. And vice
>>> versa.) All UI actions can be 'acts of programming', if we find the right
>>> way to formalize it. I think the trick, then, is to turn the UI into a good
>>> PL.
>>>
>>> To make copy-and-paste code more robust, what can we do?
>>>
>>> Can we make our code more adaptive? Able to introspect its environment?
>>>
>>> Can we reduce the number of environmental dependencies? Control
>>> namespace entanglement? Could we make it easier to grab all the
>>> dependencies for code when we copy it?
>>>
>>> Can we make it more provable?
>>>
>>> And conversely, can we provide IDEs that can help the "kids" understand
>>> the code they take - visualize and graph its behavior, see how it
>>> integrates with its environment, etc? I think there's a lot we can do. Most
>>> of my thoughts center on language design and IDE design, but there may also
>>> be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that
>>> also make it easy to interactively explore and understand code before using
>>> it.
>>>
>>>
>>> On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <[email protected]> wrote:
>>>
>>>>
>>>> These days, the "kids" do a quick google, then just copy&paste the
>>>> results into the code base, mostly unaware of what the underlying 'magic'
>>>> instructions actually do. So example code is possibly a bad thing?
>>>>
>>>> But even if that's true, we've let the genie out of the bottle and he
>>>> is't going back in. To fix the quality of software, for example, we can't
>>>> just ban all cut&paste-able web pages.
>>>>
>>>> The alternate route out of the problem is to exploit these types of
>>>> human deficiencies. If some programmers just want to cut&paste, then
>>>> perhaps all we can do is too just make sure that what they are using is
>>>> high enough quality. If someday they want more depth, then it should be
>>>> available in easily digestible forms, even if few will ever travel that
>>>> route.
>>>>
>>>> If most people really don't want to think deeply about about their
>>>> problems, then I think that the best we can do is ensure that their hasty
>>>> decisions are based on as accurate knowledge as possible. It's far better
>>>> than them just flipping a coin. In a sense it moves up our decision making
>>>> to a higher level of abstraction. Some people lose the 'why' of the
>>>> decision, but their underlying choice ultimately is superior, and the 'why'
>>>> can still be found by doing digging into the data. In a way, isn't that
>>>> what we've already done with micro-code, chips and assembler? Or machinery?
>>>> Gradually we move up towards broader problems...
>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> fonc mailing list
>>> [email protected]
>>> http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>> _______________________________________________
>> fonc mailing list
>> [email protected]
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
