Re: [fonc] Final STEP progress report abandoned?
Alan Kay alan.n...@yahoo.com writes: 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!). I think a quite modest improvement would be more powerful calculators. For example, we already augment our arithmetic when we go shopping, why don't we augment our statistical ability when making judgements? We can be bad at estimating probabilities, but we're far worse at combining them correctly; for example the common error of not taking into account population bias when interpreting test results[1]. If we carried around a statistical calculator app with a simple UI (eg. graphs, tiles and sliders; not RPN) then we can enter numbers individually and have the device carry out the tricky combinations for us. When we don't need to estimate the numbers, eg. if they're given in a paper, report, magazine, etc. then a machine-readable representation like a barcode could be given alongside. This would allow us to intuit the values graphically, rather than slipping up on our parsing of the representation. [1] http://yudkowsky.net/rational/bayes/ Cheers, Chris ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Open source tools for sensemaking and augmenting human thinking
Alan- Thomas Watson of IBM said: http://www-03.ibm.com/ibm/history/multimedia/think_trans.html And we must study through reading, listening, discussing, observing and thinking. We must not neglect any one of those ways of study. The trouble with most of us is that we fall down on the latter -- thinking -- because it's hard work for people to think, And, as Dr. Nicholas Murray Butler said recently, 'all of the problems of the world could be settled easily if men were only willing to think.' Whether that last statement is true, the idea of better tools to think with has been a dream of many since Memex and Augment. I've long wanted some sort of tool that would run on top of Google search results to try to tease out, say, some sort of concept map to understand the landscape of ideas related to a search, and then further, to integrate and score and organize search results as I work my way through them. You could perhaps do something like that by hand with something like Evernote and a web clipping utility, but that would just be a shadow of what I'm imagining as full support for sensemaking about web content. I agree such tools for improving human reasoning are important -- especially for my general goal of helping people to see how it would be better to use technologies of abundance like computers from an abundance-oriented mindset rather than a scarcity-based mindset. Below are some general thoughts on that, including links about stuff I've worked towards for that end. --Paul Fernhout Rambling thoughts on sensemaking and augmenting human thinking If you look around, you will find versions of such tools have already been developed as proprietary works at the costs of billions of dollars of tax-payer dollars over the past decade or two. That work was done mostly by the Defense/Intelligence community and the industries that surround it, but also some by other groups who have specific needs in business, education, and so on. My wife and I have worked towards such thinking tools, mostly from a narrative perspective intended so get decision makers to look at issues from multiple points of view, although I would like to expand that out to include some other things like structured arguments. Some previous systems we contributed core parts to an the Cognitive Edge Sensemaker Suite and Singapore's RAHS (Risk Assessment and Horizon Scanning system): http://www.sensemaker-suite.com/smsite/index.gsp http://app.rahs.gov.sg/public/www/home.aspx We tried to get Cognitive Edge to open source those tools, but not much luck. However, they are pretty much all based on ideas my wife found looking through the literature in areas like decision support. Whatever one might think of Singapore (it's been called Disneyland with the death penalty) and potential use of RAHS, here are some discussion of the general issue including some pitfalls (we worked with David Snowden on this, and my wife was director of research of Cognitive Edge for a time, and this is his statement on the project, which was funded by defense/intelligence funds): http://web.archive.org/web/20071010013005/http://www.cognitive-edge.com/2007/03/unwired.php However Wired manages to wander off the rails to fantasy land with its reporting of the RAHS project. I realised when they contacted me that there was a danger of them choosing to sensationalize the project by linking it to the Total Information Awareness (TIA) project in DARPA and the name of John Poindexter. So right up front I explained the difference. There had been two DARPA projects, working off two very different philosophies. One (TIA) sought to obtain and search all possible data to detect the possibility of terrorist events. That raised civil liberties concerns and much controversy in the USA leading to resignations and programme closure. A parallel program Genoa II took a very different philosophy, based on understanding nuanced narrative supporting the cognitive processes of decision makers and increasing the number of cultural and political perspectives available to policy makers. I was a part of that program, and proud to be so. It also forms the basis of our work for RAHS and contains neither the approach, not the philosophy of TIA. Here is an example of my wanting to apply such tools to democratic decision making, which links to tools at SRI and elsewhere: http://barcamp.org/w/page/47222818/Tools%20for%20Collective%20Sensemaking%20and%20Civic%20Engagement Key links from there from SRI as systems which help promote coming up with counter-examples: SEAS - Structured Evidential Argumentation System (Proprietary, used for structured arguments by intelligence analysts) http://www.ai.sri.com/~seas/ Angler (Proprietary, used to overcome bias by intelligence analysts) http://www.ai.sri.com/~angler/ Angler is a tool that helps intelligence/policy professionals Explore, understand, and overcome cognitive biases, and
[fonc] People and evidence
Kenneth Clarke once remarked that People in the Middle Ages were as passionately interested in truth as we are, but their sense of evidence was very different. Marshall McLuhan said I can't see it until I believe it Neil Postman once remarked that People today have to accept twice as much on faith: *both* religion and science! In a letter to Kepler of August 1610, Galileo complained that some of the philosophers who opposed his discoveries had refused even to look through a telescope: My dear Kepler, I wish that we might laugh at the remarkable stupidity of the common herd. What do you have to say about the principal philosophers of this academy who are filled with the stubbornness of an asp and do not want to look at either the planets, the moon or the telescope, even though I have freely and deliberately offered them the opportunity a thousand times? Truly, just as the asp stops its ears, so do these philosophers shut their eyes to the light of truth. Many of the commenters on this list have missed that evidence and data requires a fruitful context -- even to consider them! -- and that better tools and data will only tend to help those who are already set up epistemologically to use them wisely. (And don't forget the scientists I mentioned who have been shown to be deeply influenced by the context of their own employers.) The fault is not in our stars ... Cheers, Alan___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] People and evidence
Alan Kay alan.n...@yahoo.com writes: Many of the commenters on this list have missed that evidence and data requires a fruitful context -- even to consider them! -- and that better tools and data will only tend to help those who are already set up epistemologically to use them wisely. (And don't forget the scientists I mentioned who have been shown to be deeply influenced by the context of their own employers.) The fault is not in our stars ... This is certainly true; giving large numbers of people (eg. via schooling) the *inclination* to question their reasoning processes would be a revolutionary change. Unfortunately I wouldn't know where to begin to bring such a change about. What I do know, from my computer science/software engineering background and my own experience in trying to justify my everyday decisions, is that there is still a lot of potential for incremental hill-climbing for those few of us who already have this inclination (see lesswrong.com for a growing community). At the moment I usually conclude that it's not worth the investment to sanity-check my day-to-day decisions in depth, but this balance can be tipped by technological support, allowing me to do it out of habit. Another example of an incremental improvement, again for those who recognise the need, could be to have (electronic) lab books prompt the user for justifications when they spot certain cues in their input. For example: User: Events were modelled as a markov chain... Tooltip: Model spotted. Why is markov chain a realistic model? User: Established by http://my-journal.com/it-really-is-markov.pdf System: Thanks. The point of such a system wouldn't be to verify what we tell it, but simply to make us think twice about what we're doing. Even though these incremental improvements will hopefully be thrown away by some revolutionary change, they make it easier for us to come up with that change. This is my method of tackling unsolvable problems. For example, if I were stuck in a sub-optimal language and couldn't envisage what a better language might look like, I would spend my time improving the infrastructure (compiler, IDE, etc.) so that when anyone does come up with an idea, it's easy for them to build and try it. Cheers, Chris ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] People and evidence
On Mon, Sep 9, 2013 at 11:54 AM, Chris Warburton chriswa...@googlemail.comwrote: Alan Kay alan.n...@yahoo.com writes: Many of the commenters on this list have missed that evidence and data requires a fruitful context -- even to consider them! -- and that better tools and data will only tend to help those who are already set up epistemologically to use them wisely. (And don't forget the scientists I mentioned who have been shown to be deeply influenced by the context of their own employers.) The fault is not in our stars ... This is certainly true; giving large numbers of people (eg. via schooling) the *inclination* to question their reasoning processes would be a revolutionary change. Unfortunately I wouldn't know where to begin to bring such a change about. Look at Kay and others' projects to introduce children to programming. They don't just make programming interfaces that are easy to manipulate. They also consider the education that's required to use them well, and how to motivate children to go through the effort. -- Tom Lieber http://AllTom.com/ http://infinite-sketchpad.com/ ___ 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] Final STEP progress report abandoned?
On Fri, Sep 6, 2013 at 1:19 AM, Chris Warburton chriswa...@googlemail.comwrote: David Barbour dmbarb...@gmail.com writes: But favoring a simpler programming model - e.g. one with only integers, and where the only operation is to add or compare them -might also help. If the problem domain is X then I agree a minimal X-specific DSL is a good idea, although purely numeric problems are often amenable to more direct solutions; eg. dynamic programming, gradient-based methods, etc. A rather nice property: given any general purpose concatenative language, we can create a DSL for genetic programming by developing a set of high-level words... then using those as the primitives for the GP. The main issue, I think, is a more flexible environment model. The stack doesn't offer very flexible interactions. A document (zipper) or graph could be modeled as an object on the stack, though. Best, Dave ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Final STEP progress report abandoned?
On Mon, Sep 9, 2013 at 2:11 AM, Chris Warburton chriswa...@googlemail.comwrote: I think a quite modest improvement would be more powerful calculators. Smart phones? :) (But seriously.) Honestly, one of the things I would really want in a more powerful calculator is a powerful array of sensors that can turn parts of my environment into usable numbers. What is the distance between these two trees? What is the GPS coordinate? What chemicals are detected in the area? Even better if this happened all the time, so I can ask questions about recent events. Unfortunately, we lack the energy technologies for it. (Storage is much less an issue; we have lots of storage, and useful exponential decay and compression models to remove the boring stuff.) ___ 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] Fwd: Re: Programming by Demonstration (was Software Crisis (was Re: Final STEP progress report abandoned?))
-- Forwarded message -- From: John Carlson yottz...@gmail.com Date: Sep 9, 2013 8:58 PM Subject: Re: [fonc] Programming by Demonstration (was Software Crisis (was Re: Final STEP progress report abandoned?)) To: Alan Kay alan.n...@yahoo.com Cc: Thanks, Alan, for this reference. It looks like the difference between SmallStar and TWB/TE are mostly domain and how control structures were constructed. Our domain was formatting and mapping between EDI/X12 and proprietary files. SmallStar's domain was the desktop. TWB had a current add position (PC) for control structures...we used the lookup operation on a table containing rows of anded predicates and a procedure. These domain specific *visual* languages have lost out to domain specific modelling. More recently there has been model transformation by demonstration (MTBD) and learning by demonstration (I believe these have lost conditionals in favor of selectors) as well as Lively Kernel and Bret Victor's work. On Sep 9, 2013 7:55 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 ___
