[FoRK] [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)

David Barbour dmbarbour at gmail.com
Tue Sep 10 10:25:58 PDT 2013


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 <yottzumm at gmail.com> 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" <dmbarbour at gmail.com> 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 <paul_homer at yahoo.ca> 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
>> fonc at vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
> _______________________________________________
> fonc mailing list
> fonc at vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
-------------- next part --------------
_______________________________________________
fonc mailing list
fonc at vpri.org
http://vpri.org/mailman/listinfo/fonc


More information about the FoRK mailing list