Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Ah, yes, I had forgotten about nests and birds. IIRC, they're more like channels than promises, but channels can serve a similar purpose. So again, the idea seems to be to leave a token indicating where something should go, and a token indicating where it should be picked up? Aside: I haven't explicated it here, but I believe it much better to avoid state embedded at the surface of the UI, for a lot of reasons (like persistence, disruption tolerance, simpler consistency properties, simpler undo or upgrade via history edits). Avoiding state can be achieved by makePromise if I use linear types. Negative or fractional types can do a similar job. A fractional type can model piping a time-varying signal through a promise. Best, Dave On Tue, Sep 10, 2013 at 10:35 PM, Darius Bacon wit...@gmail.com wrote: On Wed, Sep 11, 2013 at 12:24 AM, David Barbour dmbarb...@gmail.com wrote: One PL concept you didn't mention is promises/futures. How might those be realized in a UI? There's precedent: ToonTalk represents promises and resolvers in its UI as nests and birds. (Some reasons this may miss the mark: It's been many years since I played with ToonTalk; IIRC the system supports declarative concurrency and nothing more powerful; I don't understand you about negative and fractional types, though it sounds interesting: http://www.cs.indiana.edu/~sabry/papers/rational.pdf ) Darius In the type system of a PL, promises can be modeled as a pair: makePromise :: 1 - (resolver * future) Or we can potentially model promises using fractional or negative types, as developed by Amr Sabry, which has an advantage of addressing sums in a symmetric manner: receive :: 1 - (1/a * a) return :: (1/a * a) - 1 receive+ :: 0 - (-a + a) return+ :: (-a + a) - 0 But what would this look like in a UI model? My intuition is leaving some sort of IOU where a value is needed then going to some other location to provide it (perhaps after a copy and a few transforms). I suspect this behavior might be convenient for a user, but it potentially leaves parts of the UI or system in an indefinite limbo state while a promise is unfulfilled. Though, perhaps that could be addressed by requiring the promises to be fulfilled before operations will 'commit' (i.e. enforcing type-safe UI transactions). ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Here's a short description, if you don't want to haul through the entire thesis: On Mon, Sep 9, 2013 at 7:54 PM, Alan Kay alan.n...@yahoo.com wrote: Check out Smallstar by Dan Halbert at Xerox PARC (written up in a PARC bluebook) Cheers, Alan -- *From:* John Carlson yottz...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Monday, September 9, 2013 3:47 PM *Subject:* Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?) 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 dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
mail got sent too fast...from Watch What I Do: http://acypher.com/wwid/Chapters/05SmallStar.html On Tue, Sep 10, 2013 at 11:36 AM, John Carlson yottz...@gmail.com wrote: Here's a short description, if you don't want to haul through the entire thesis: On Mon, Sep 9, 2013 at 7:54 PM, Alan Kay alan.n...@yahoo.com wrote: Check out Smallstar by Dan Halbert at Xerox PARC (written up in a PARC bluebook) Cheers, Alan -- *From:* John Carlson yottz...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Monday, September 9, 2013 3:47 PM *Subject:* Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?) 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 dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Thanks for this ref. It looks interesting. On Mon, Sep 9, 2013 at 7:33 PM, K. K. Subramaniam kksubbu...@gmail.comwrote: On Tuesday 10 September 2013 06:24 AM, Alan Kay wrote: Check out Smallstar by Dan Halbert at Xerox PARC (written up in a PARC bluebook) Available online at http://danhalbert.org/pbe-**html.htmhttp://danhalbert.org/pbe-html.htm BTW, Dan Halbert is the author of the more command in Unix. Regards .. Subbu __**_ fonc mailing list fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
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 yottz...@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 dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
It may be helpful to view everything as an editor. Something like SUIT (the Simple User Interface Toolkit): http://research.microsoft.com/en-us/um/people/rdeline/publications/uist-91.pdf I'm thinking the web is finally getting to a point where everything is editable again. On Tue, Sep 10, 2013 at 12:54 PM, John Carlson yottz...@gmail.com wrote: 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 dmbarb...@gmail.comwrote: 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 yottz...@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 dmbarb...@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 -
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
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 dmbarb...@gmail.com 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 yottz...@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 dmbarb...@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,
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Does Minecraft have a way to compile a world (particularly redstone) to machine code? Is it still a challenge to go from a 3D representation to a machine language or machine representation? We have at several levels with Minecraft: the machine, the JVM, Minecraft byte code, Minecraft source code, the minecraft world, and activity within the world. Can we reduce this to the machine, the world, and activity? I believe this is a STEP goal, even blurring the lines between the world and the machine through FPGAs, so we get down to just the machine and activity. How much circuitry would a Minecraft world take up? Has anyone done calculations? Could it fit on a raspberry pi like machine? This may be relevant: http://pi.minecraft.net/ :(requires X11 apparently) John On Tue, Sep 10, 2013 at 12:54 PM, John Carlson yottz...@gmail.com wrote: 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 dmbarb...@gmail.comwrote: 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 yottz...@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 dmbarb...@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
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
This is a good list of concept components. I think branching should be open - I.e. modeled as a collection where only one item is 'active' at a time. There is a clear duality between sums and products, and interestingly a lot of the same UIs apply (i.e. prisms/lenses, zippers for sum types). (But there can be some awkwardness distributing sums over products.) Recursion is an interesting case. One can model it as a closed value, or as a fixpoint combinator. But to keep the UI/PL extensible, it might be better to avoid closed loops (especially if they maintain state). Open loop recursion happens easily and naturally enough if we have any shared state resources, such as a database or tuple space... or the world itself (via sensors and actuators). Exceptions: in general, exceptions are not difficult to model as choices/branches (a path of a sum type). I've usually considered this a better way to model them. This can be combined with searching the environment for some advice on how to handle the condition - I.e. in terms of a dynamic scoped 'special' variable, or (in a concatenative language) literally searching a stack or other environment model. Keyboard/video/mouse/audio would be a good start for signals on the UI side. I've been wondering how to get a lot of useful control signals quickly... Maybe integrate with ROS from WillowGarage? On Sep 10, 2013 10:54 AM, John Carlson yottz...@gmail.com wrote: 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 dmbarb...@gmail.comwrote: 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 yottz...@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
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
If your sum/product is or/and, I tend to agree there is difficulty. We chose to use a normalized representation: the same number of factors for each term, true used liberally as a factor. In many cases, there were only two branches to take. I spent a great deal of time coming up with a table which handled repetition, mandatory, optional and floating components in the product, but it got so difficult to be implemented and tested especially, that I gave up and implemented 997 acknowledgements in C++. I think our translation analyst may have been unique among EDI/X12 analysts for not using components designed specifically for X12 beyond the 997 acknowledge code. Instead we used something like tab-separated values to parse the X12...which was much less flexible...we couldn't read the separators from X12 file--they had to be constants in the code. However, it might be possible that he used my fancy table, but I never heard of any bug reports, so I doubt it. That's where I learn the rule don't make anything so complex you can't debug it, or automate tests for it. This is likely why we see much more XML than X12 these days. If you don't know what X12 is, think of a mixture between s-expressions and comma separated values. On Sep 10, 2013 7:13 PM, David Barbour dmbarb...@gmail.com wrote: This is a good list of concept components. I think branching should be open - I.e. modeled as a collection where only one item is 'active' at a time. There is a clear duality between sums and products, and interestingly a lot of the same UIs apply (i.e. prisms/lenses, zippers for sum types). (But there can be some awkwardness distributing sums over products.) Recursion is an interesting case. One can model it as a closed value, or as a fixpoint combinator. But to keep the UI/PL extensible, it might be better to avoid closed loops (especially if they maintain state). Open loop recursion happens easily and naturally enough if we have any shared state resources, such as a database or tuple space... or the world itself (via sensors and actuators). Exceptions: in general, exceptions are not difficult to model as choices/branches (a path of a sum type). I've usually considered this a better way to model them. This can be combined with searching the environment for some advice on how to handle the condition - I.e. in terms of a dynamic scoped 'special' variable, or (in a concatenative language) literally searching a stack or other environment model. Keyboard/video/mouse/audio would be a good start for signals on the UI side. I've been wondering how to get a lot of useful control signals quickly... Maybe integrate with ROS from WillowGarage? On Sep 10, 2013 10:54 AM, John Carlson yottz...@gmail.com wrote: 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 dmbarb...@gmail.comwrote: 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
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Yes, sum (x + y) vs. product (x * y) corresponds to 'or vs. and' or 'union vs. struct'. For many purposes, they are very similar: associative, commutative, identity elements, ability to focus attention and operations on just x or just y. We can model zippers and lenses for each, which is kind of cool. In widget form, products are obvious (typical hbox or vbox). Sums, OTOH, are rarely represented directly because we tend to hide the inactive values. One might model a sum in terms of a radio-button with an associated active form - i.e. instead of hiding the inactive values, they're marked inactive - but still accessible for manipulations. (We could have optional views that hide the inactive forms.) There are differences between sums and products: products have `copy` x - (x * x) (adding 1 bit of info) sums have `merge` (x + x) - x (losing 1 bit of info) And in general we want to deal with cases like: factoring :: (x*y) + (x*z) - x*(y+z) distribution :: x * (y + z) - (x * y) + (x * z) The problem with if/then/else statements is that they're closed to extension: they force the merge, and any intermediate decisions, to be syntactically local. This is inflexible. It is also, often, very inefficient - i.e. in some cases it means we repeatedly branch our behavior by observing the same values, rather than just keeping the same branch available for extension. I'm not sure what you were trying to explain with the same number of factors for each term or what you mean by true as a factor. (My thought is that you're using 'true' like I might have used the unit type, 1.) But I think the main difficulties for sum vs. product regard something else entirely: distribution, in a distributed system. An issue is that `x*(y+z)` cannot really be distributed unless we know whether we are in y or z at the *same place and time* as we know x. Perhaps this isn't as much a problem in a UI, since we may be forced to move values to the same place and time to get them into the same UI in the first place. In other thoughts... One PL concept you didn't mention is promises/futures. How might those be realized in a UI? In the type system of a PL, promises can be modeled as a pair: makePromise :: 1 - (resolver * future) Or we can potentially model promises using fractional or negative types, as developed by Amr Sabry, which has an advantage of addressing sums in a symmetric manner: receive :: 1 - (1/a * a) return :: (1/a * a) - 1 receive+ :: 0 - (-a + a) return+ :: (-a + a) - 0 But what would this look like in a UI model? My intuition is leaving some sort of IOU where a value is needed then going to some other location to provide it (perhaps after a copy and a few transforms). I suspect this behavior might be convenient for a user, but it potentially leaves parts of the UI or system in an indefinite limbo state while a promise is unfulfilled. Though, perhaps that could be addressed by requiring the promises to be fulfilled before operations will 'commit' (i.e. enforcing type-safe UI transactions). On Tue, Sep 10, 2013 at 7:45 PM, John Carlson yottz...@gmail.com wrote: If your sum/product is or/and, I tend to agree there is difficulty. We chose to use a normalized representation: the same number of factors for each term, true used liberally as a factor. In many cases, there were only two branches to take. I spent a great deal of time coming up with a table which handled repetition, mandatory, optional and floating components in the product, but it got so difficult to be implemented and tested especially, that I gave up and implemented 997 acknowledgements in C++. I think our translation analyst may have been unique among EDI/X12 analysts for not using components designed specifically for X12 beyond the 997 acknowledge code. Instead we used something like tab-separated values to parse the X12...which was much less flexible...we couldn't read the separators from X12 file--they had to be constants in the code. However, it might be possible that he used my fancy table, but I never heard of any bug reports, so I doubt it. That's where I learn the rule don't make anything so complex you can't debug it, or automate tests for it. This is likely why we see much more XML than X12 these days. If you don't know what X12 is, think of a mixture between s-expressions and comma separated values. On Sep 10, 2013 7:13 PM, David Barbour dmbarb...@gmail.com wrote: This is a good list of concept components. I think branching should be open - I.e. modeled as a collection where only one item is 'active' at a time. There is a clear duality between sums and products, and interestingly a lot of the same UIs apply (i.e. prisms/lenses, zippers for sum types). (But there can be some awkwardness distributing sums over products.) Recursion is an interesting case. One can model it as a closed value, or as a fixpoint combinator. But to keep the UI/PL
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
On Wed, Sep 11, 2013 at 12:24 AM, David Barbour dmbarb...@gmail.com wrote: One PL concept you didn't mention is promises/futures. How might those be realized in a UI? There's precedent: ToonTalk represents promises and resolvers in its UI as nests and birds. (Some reasons this may miss the mark: It's been many years since I played with ToonTalk; IIRC the system supports declarative concurrency and nothing more powerful; I don't understand you about negative and fractional types, though it sounds interesting: http://www.cs.indiana.edu/~sabry/papers/rational.pdf ) Darius In the type system of a PL, promises can be modeled as a pair: makePromise :: 1 - (resolver * future) Or we can potentially model promises using fractional or negative types, as developed by Amr Sabry, which has an advantage of addressing sums in a symmetric manner: receive :: 1 - (1/a * a) return :: (1/a * a) - 1 receive+ :: 0 - (-a + a) return+ :: (-a + a) - 0 But what would this look like in a UI model? My intuition is leaving some sort of IOU where a value is needed then going to some other location to provide it (perhaps after a copy and a few transforms). I suspect this behavior might be convenient for a user, but it potentially leaves parts of the UI or system in an indefinite limbo state while a promise is unfulfilled. Though, perhaps that could be addressed by requiring the promises to be fulfilled before operations will 'commit' (i.e. enforcing type-safe UI transactions). ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Good point, Casey - it's not just software. I see shabby service and workmanship all around, an Industrial Crisis brought on by a preoccupation with short-term gain... although that in itself is amplified by modern software/communication technology. Hopefully that will all balance out and correct itself somewhat. I see computers diverging into shrinkwrapped consumer devices (probably a dead end just like old mass media) and industrial/DIY gear for serious programming. I'd tend to write good clean code for the latter. That's possible when you're writing for programmers, gamers, anyone willing to learn something in order to use your software effectively (provided, of course, that you're not in a fragmented landscape of rapidly iterating APIs or hardware). That's my optimistic scenario. In my pessimistic scenario I do see the kids getting dumber, because they're *only* using the internet for videos, games, chit-chat. They think the technology is pretty cool, but compared to previous generations they seem less interested in understanding it. What if this revolution lasts long enough to destroy most of the books, libraries, old-school factories, etc... and then collapses? It could set us back centuries. (I wonder how many sci-fi stories have already used that set-up... a couple hundred? :) Also, let's not forget that we're still in the middle of a major economic depression, so it's pretty difficult to predict anything based on current trends. On Mon, Sep 9, 2013 at 12:12 AM, Casey Ransberger casey.obrie...@gmail.comwrote: I don't think cut and paste has been the source of the problems with the systems I've worked on (could be a symptom of one or more of the problems.) What I see is long-term systems built around short-term, usually competitive goals, by people who are competing both with one another (for jobs, promotions, raises, social capital, etc,) and also cooperating with one another to compete with other businesses at the same time. Most people's programming habits seem to change dramatically, for example, when they expect to throw something away. Most programmers dump the company every 2-5 years for another (higher-paying) job, so it's *all* disposable code in effect. It's not just the programmers either, it's the decision makers at C-level too, who are quite often building the company to sell the company. Maybe the kids are getting dumber, but what I see when I look around is smart kids being pushed to ship before the bits are ready, and not being *allowed* to fix low-value bugs which gradually accumulate until a system is deep-sixed for being painful to work on. In other words, I don't believe there's a software crisis or any real shortage of programming talent (I know plenty of great programmers who regularly go without work, often because they're unimpressed with the offers they're seeing.) I think it's not a software crisis, I think it's a *management* crisis. I do think new tools to make managers/customers/investors/partners/users/programmers less stressed out could make the overall experience better for all involved, and with that I guess I'm talking about the continuing emergence of an engineering discipline in software. But that's in-house code. OTOH, FreeBSD has usually been pretty stable for me; I don't have to put out its fires very much. Why might this be? Let's try some fun game theory! http://www.nature.com/ncomms/2013/130801/ncomms3193/pdf/ncomms3193.pdf ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
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 dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
I'd recommend looking into quartz composer on mac os x. On Sep 9, 2013 5:11 PM, David Barbour dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Also, you could have an input zipper, a flippable conversion area, an output zipper, and a history of conversion stack. On Sep 9, 2013 5:11 PM, David Barbour dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
The trick here is to make the zippers at the meta or schema level. John On Sep 9, 2013 6:03 PM, John Carlson yottz...@gmail.com wrote: Also, you could have an input zipper, a flippable conversion area, an output zipper, and a history of conversion stack. On Sep 9, 2013 5:11 PM, David Barbour dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
Check out Smallstar by Dan Halbert at Xerox PARC (written up in a PARC bluebook) Cheers, Alan From: John Carlson yottz...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Monday, September 9, 2013 3:47 PM Subject: Re: [fonc] Software Crisis (was Re: Final STEP progress report abandoned?) 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 dmbarb...@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_ho...@yahoo.ca wrote: These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
I don't think cut and paste has been the source of the problems with the systems I've worked on (could be a symptom of one or more of the problems.) What I see is long-term systems built around short-term, usually competitive goals, by people who are competing both with one another (for jobs, promotions, raises, social capital, etc,) and also cooperating with one another to compete with other businesses at the same time. Most people's programming habits seem to change dramatically, for example, when they expect to throw something away. Most programmers dump the company every 2-5 years for another (higher-paying) job, so it's *all* disposable code in effect. It's not just the programmers either, it's the decision makers at C-level too, who are quite often building the company to sell the company. Maybe the kids are getting dumber, but what I see when I look around is smart kids being pushed to ship before the bits are ready, and not being *allowed* to fix low-value bugs which gradually accumulate until a system is deep-sixed for being painful to work on. In other words, I don't believe there's a software crisis or any real shortage of programming talent (I know plenty of great programmers who regularly go without work, often because they're unimpressed with the offers they're seeing.) I think it's not a software crisis, I think it's a *management* crisis. I do think new tools to make managers/customers/investors/partners/users/programmers less stressed out could make the overall experience better for all involved, and with that I guess I'm talking about the continuing emergence of an engineering discipline in software. But that's in-house code. OTOH, FreeBSD has usually been pretty stable for me; I don't have to put out its fires very much. Why might this be? Let's try some fun game theory! http://www.nature.com/ncomms/2013/130801/ncomms3193/pdf/ncomms3193.pdf On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer paul_ho...@yahoo.ca wrote: Hi Alan, Is the gift really that bad? It certainly is an interesting question. I'm a frequent blogger on the topic of what could probably be described as the ongoing 'software crisis'. We definitely build bigger systems these days, but the quality has likely been declining. There is great software out there, but the world is littered with lots of partially working code that causes lots of problems. Perhaps one could lay this on the feet of better documentation. That is, when I started coding it was hard to find out any information so I spent a lot of time just playing with the underlying pieces to really understand them and figure out how to use them appropriately. These days, the kids do a quick google, then just copypaste 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 cutpaste-able web pages. I definitely agree that we're terrible thinkers, and that for the most part as a species we are self-absorbed and often lazy, so I don't really expect that most programmers will have the same desire that I did to get down to really understanding the details. That type of curiosity is rare. The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cutpaste, 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... Paul. Sent from my iPad On 2013-09-08, at 10:45 AM, Alan Kay alan.n...@yahoo.com wrote: Hi Paul When I said even scientists go against their training I was also pointing out really deep problems in humanity's attempts at thinking (we are quite terrible thinkers!). If we still make most decisions without realizing why, and use conventional thinking tools as ways to rationalize them, then technologists providing vastly more efficient, wide and deep, sources for rationalizing is the opposite of a great gift. Imagine a Google that also retrieves counter-examples. Or one that actively tries to help find chains of
