Casey Ransberger | 9 Sep 06:12 2013
Picon

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!



On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> 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 copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.  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 cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


Paul.

Sent from my iPad

On 2013-09-08, at 10:45 AM, Alan Kay <alan.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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 reasoning that are based on principles one -- or others -- claim to hold. Or one that looks at the system implications of local human desires and actions.

Etc.

I'm guessing that without a lot of training, most humans would not choose to use a real "thinking augmenter".

Best wishes,

Alan

From: Paul Homer <paul_homer <at> yahoo.ca>
To: Alan Kay <alan.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Cc: Fundamentals of New Computing <fonc <at> vpri.org>
Sent: Sunday, September 8, 2013 7:34 AM
Subject: Re: [fonc] Final STEP progress report abandoned?

Hi Alan,

I agree that there is, and probably will always be, a necessity to 'think outside of the box', although if the box was larger, it would be less necessary. But I wasn't really thinking about scientists and the pursuit of new knowledge, but rather the trillions? of mundane decisions that people regularly make on a daily basis. 

A tool like Wikipedia really helps in being able to access a refined chunk of knowledge, but the navigation and categorization are statically defined. Sometimes what I am trying to find is spread horizontally across a large number of pages. If, as a simple example, a person could have a dynamically generated Wikipedia page created just for them that factored in their current knowledge and the overall context of the situation then they'd be able to utilize that knowledge more appropriately. They could still choose to skim or ignore it, but if they wanted a deeper understanding, they could read the compiled research in a few minutes. 

The Web, particularly for programmers, has been a great tease for this. You can look up any coding example instantly (although you do have to sort through the bad examples and misinformation). The downside is that I find it far more common for people to not really understanding what is actually happening underneath, but I suspect that that is driven by increasing time pressures and expectations rather than but a shift in the way we relate to knowledge.

What I think would really help is not just to allow access to the breadth of knowledge, but to also enable individuals to get to the depth as well. Also the ability to quickly recognize lies, myths, propaganda, etc. 

Paul.

Sent from my iPad

On 2013-09-08, at 7:12 AM, Alan Kay <alan.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:

Hi Paul

I'm sure you are aware that yours is a very "Engelbartian" point of view, and I think there is still much value in trying to make things better in this direction.

However, it's also worth noting the studies over the last 40 years (and especially recently) that show how often even scientists go against their training and knowledge in their decisions, and are driven more by desire and environment than they realize. More knowledge is not the answer here -- but it's possible that very different kinds of training could help greatly.

Best wishes,

Alan

From: Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org>
To: Alan Kay <alan.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>; Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.org>; Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.org>
Sent: Saturday, September 7, 2013 12:24 PM
Subject: Re: [fonc] Final STEP progress report abandoned?

Hi Alan,

I can't predict what will come, but I definitely have a sense of where I think we should go. Collectively as a species, we know a great deal, but individually people still make important choices based on too little knowledge.

In a very abstract sense 'intelligence' is just a more dynamic offshoot of 'evolution'. A sort of hyper-evolution. It allows a faster route towards reacting to changes in the enviroment, but it is still very limited by individual perspectives of the world. I don't think we need AI in the classic Hollywood sense, but we could enable a sort of hyper-intelligence by giving people easily digestable access to our collective understanding. Not a 'borg' style single intelligence, but rather just the tools that can be used to make descisions that are more "accurate" than an individual would have made normally.

To me the path to get there lies within our understanding of data. It needs to be better organized, better understood and far more accessible. It can't keep getting caught up in silos, and it really needs ways to share it appropriately. The world changes dramatically when we've developed the ability to fuse all of our digitized information into one great structural model that has the capability to separate out fact from fiction. It's a long way off, but I've always thought it was possible...

Paul.

From: Alan Kay <alan.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
To: Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.org>
Sent: Tuesday, September 3, 2013 7:48:22 AM
Subject: Re: [fonc] Final STEP progress report abandoned?

Hi Jonathan

We are not soliciting proposals, but we like to hear the opinions of others on "burning issues" and "better directions" in computing.

Cheers,

Alan

From: Jonathan Edwards <edwards-EfZU8u+QLuNeoWH0uzbU5w@public.gmane.org.edu>
To: fonc <at> vpri.org
Sent: Tuesday, September 3, 2013 4:44 AM
Subject: Re: [fonc] Final STEP progress report abandoned?

That's great news! We desperately need fresh air. As you know, the way a problem is framed bounds its solutions. Do you already know what problems to work on or are you soliciting proposals?

Jonathan


From: Alan Kay <alan.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
To: Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.org>
Cc: 
Date: Mon, 2 Sep 2013 10:45:50 -0700 (PDT)
Subject: Re: [fonc] Final STEP progress report abandoned?
Hi Dan

It actually got written and given to NSF and approved, etc., a while ago, but needs a little more work before posting on the VPRI site. 

Meanwhile we've been consumed by setting up a number of additional, and wider scale, research projects, and this has occupied pretty much all of my time for the last 5-6 months.

Cheers,

Alan

From: Dan Melchione <dm.fonc-iAcbz4bWHyZl57MIdRCFDg@public.gmane.org>
To: fonc-uVco7kAcSAQ@public.gmane.org
Sent: Monday, September 2, 2013 10:40 AM
Subject: [fonc] Final STEP progress report abandoned?

Haven't seen much regarding this for a while.  Has it been been abandoned or put at such low priority that it is effectively abandoned?

_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc <at> vpri.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc







_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



<div><div dir="ltr">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.&nbsp;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."<div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.&nbsp;</div>
<div><br></div>
<div>Why might this be?&nbsp;Let's try some fun game theory!</div>
</div>
<div><br></div>
<div>
<a href="http://www.nature.com/ncomms/2013/130801/ncomms3193/pdf/ncomms3193.pdf">http://www.nature.com/ncomms/2013/130801/ncomms3193/pdf/ncomms3193.pdf</a><br>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div dir="auto">
<div>Hi Alan,</div>
<div><br></div>
<div>Is the gift really that bad? It certainly is an interesting question.&nbsp;</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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 copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?</div>
<div><br></div>
<div>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages. &nbsp;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.&nbsp;</div>
<div><br></div>
<div>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.</div>
<div><br></div>
<div>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...</div>
<div class="im">
<div><br></div>
<div><br></div>
<div>Paul.</div>
<div><br></div>
<div>Sent from my iPad</div>
</div>
<div><div class="h5">
<div>
<br>On 2013-09-08, at 10:45 AM, Alan Kay &lt;<a href="mailto:alan.nemo@..." target="_blank">alan.nemo@...</a>&gt; wrote:<br><br>
</div>
<blockquote type="cite"><div><div>
<div><span>Hi Paul</span></div>
<div>
<span><br></span>
</div>
<div>
<span>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!).</span><br>
</div>
<div><span><br></span></div>
<div><span>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.</span></div>
<div><br></div>
<div>
Imagine a Google that also retrieves counter-examples. Or one that actively tries to help find chains of reasoning that are based on principles one -- or others -- claim to hold. Or one that looks at the system implications of local human desires and actions.</div>
<div><br></div>
<div>
Etc.</div>
<div><br></div>
<div>
I'm guessing that without a lot of training, most humans would not choose to use a real "thinking augmenter".</div>
<div>
<br>
</div>
<div>Best wishes,</div>
<div>
<br>
</div>
<div>Alan</div>
<div><br></div>  <div>
 <div> <div dir="ltr">  <span>From:</span> Paul Homer &lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer <at> yahoo.ca</a>&gt;<br><span>To:</span> Alan Kay &lt;<a href="mailto:alan.nemo@..." target="_blank">alan.nemo@...</a>&gt; <br><span>Cc:</span> Fundamentals of New Computing &lt;<a href="mailto:fonc@..." target="_blank">fonc <at> vpri.org</a>&gt; <br><span>Sent:</span> Sunday, September 8, 2013 7:34 AM<br><span>Subject:</span> Re: [fonc] Final STEP progress report abandoned?<br> </div> <div>
<br><div><div>
<div>Hi Alan,</div>
<div><br></div>
<div>I agree that there is, and probably will always be, a necessity to 'think outside of the box', although if the box was larger, it would be less necessary.&nbsp;But I wasn't really thinking about scientists and the pursuit of new knowledge, but rather the trillions? of mundane decisions that people regularly make on a daily basis.&nbsp;</div>
<div><br></div>
<div>A tool like Wikipedia really helps in being able to access a refined chunk of knowledge, but the navigation and categorization are statically defined. Sometimes what I am trying to find is spread horizontally
 across a large number of pages. If, as a simple example, a person could have a dynamically generated Wikipedia page created just for them that factored in their current knowledge and the overall context of the situation then they'd be able to utilize that knowledge more appropriately. They could still choose to skim or ignore it, but if they wanted a deeper understanding, they could read the compiled research in a few minutes.&nbsp;</div>
<div><br></div>
<div>The Web, particularly for programmers, has been a great tease for this. You can look up any coding example instantly (although&nbsp;you do have to sort through the bad examples and misinformation). The downside is that I find it far more common for people to not really understanding what is actually happening underneath, but I suspect that that is driven by increasing time pressures and expectations rather than but a shift in the way we relate to knowledge.</div>
<div><br></div>
<div>What I think would
 really help is not just to allow access to the breadth of knowledge, but to also enable individuals to get to the depth as well. Also the ability to quickly recognize lies, myths, propaganda, etc.&nbsp;</div>
<div><br></div>
<div>
Paul.</div>
<div>
<br>Sent from my iPad</div>
<div>
<br>On 2013-09-08, at 7:12 AM, Alan Kay &lt;<a rel="nofollow" href="mailto:alan.nemo@..." target="_blank">alan.nemo@...</a>&gt; wrote:<br><br>
</div>
<blockquote type="cite">
<div><div>
<div><span>Hi Paul</span></div>
<div>
<span><br></span>
</div>
<div><span>I'm sure you are aware that yours is a very "Engelbartian" point of view, and I think there is still much value in trying to make things better in this direction.</span></div>
<div><span><br></span></div>
<div>
<span>However, it's also worth noting the studies over the last 40 years (and especially recently) that show how often even scientists go against their training and knowledge in their decisions, and are driven more by desire and environment than they realize. More knowledge is not the answer here -- but it's possible that very different kinds of training could help
 greatly.</span>
</div>
<div><span><br></span></div>
<div>
<span>Best wishes,</span>
</div>
<div><span><br></span></div>
<div>
<span>Alan</span>
</div>
<div><br></div>  <div> <div>
 <div dir="ltr">  <span>From:</span> Paul Homer &lt;<a rel="nofollow" href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;<br><span>To:</span> Alan Kay &lt;<a rel="nofollow" href="mailto:alan.nemo@..." target="_blank">alan.nemo@...</a>&gt;; Fundamentals of New Computing &lt;<a rel="nofollow" href="mailto:fonc@..." target="_blank">fonc@...</a>&gt;; Fundamentals of New Computing &lt;<a rel="nofollow" href="mailto:fonc <at> vpri.org" target="_blank">fonc@...</a>&gt; <br><span>Sent:</span> Saturday, September 7, 2013 12:24 PM<br><span>Subject:</span> Re: [fonc] Final STEP progress report
 abandoned?<br> </div> <div>
<br><div><div><div>
<div><span>Hi Alan,</span></div>
<div>
<span><br></span>
</div>
<div><span>I can't predict what will come, but I definitely have a sense of where I think we should go. Collectively as a species, we know a great deal, but individually people still make important choices based on too little knowledge. <br></span></div>
<div><span><br></span></div>
<div>
<span>In a very abstract sense 'intelligence' is just a more dynamic offshoot of 'evolution'. A sort of hyper-evolution. It allows a faster route towards reacting to changes in the enviroment, but it is still very limited by individual perspectives of the world. I don't think we need AI in the classic Hollywood sense, but we could enable a sort of hyper-intelligence by giving people easily digestable access to our collective understanding. Not a 'borg' style single intelligence, but rather just the tools that can be used to make descisions that are more "accurate" than an individual would have made normally.
 <br></span>
</div>
<div><span><br></span></div>
<div>
<span>To me the path to get there lies within our understanding of data. It needs to be better organized, better understood and far more accessible. It can't keep getting caught up in silos, and it really needs ways to share it appropriately. The world changes dramatically when we've developed the ability to fuse all of our digitized information into one great structural model that has the capability to separate out fact from fiction. It's a long way off, but I've always thought it was possible...</span>
</div>
<div>
<br><span></span>
</div>
<div>
<span>Paul.<br></span>
</div>
<div>
<br><blockquote>  <div>
 <div> <div dir="ltr">  <span>From:</span> Alan Kay &lt;<a rel="nofollow" href="mailto:alan.nemo@..." target="_blank">alan.nemo@...</a>&gt;<br><span>To:</span> Fundamentals of New Computing &lt;<a rel="nofollow" href="mailto:fonc@..." target="_blank">fonc@...</a>&gt; <br><span>Sent:</span> Tuesday,
 September 3, 2013 7:48:22 AM<br><span>Subject:</span> Re: [fonc] Final STEP progress report abandoned?<br> </div> <div>
<br><div><div><div>
<div><span>Hi Jonathan</span></div>
<div>
<span><br></span>
</div>
<div><span>We are not soliciting proposals, but we like to hear the opinions of others on "burning issues" and "better directions" in computing.</span></div>
<div><span><br></span></div>
<div>
<span>Cheers,</span>
</div>
<div><span><br></span></div>
<div>
<span>Alan</span>
</div>
<div><br></div>  <div> <div>
 <div dir="ltr">  <span>From:</span> Jonathan Edwards &lt;<a rel="nofollow" href="mailto:edwards@..." target="_blank">edwards@....edu</a>&gt;<br><span>To:</span>
 <a rel="nofollow" href="mailto:fonc@..." target="_blank">fonc <at> vpri.org</a> <br><span>Sent:</span> Tuesday, September 3, 2013 4:44 AM<br><span>Subject:</span> Re: [fonc] Final STEP progress report abandoned?<br> </div> <div>
<br><div><div dir="ltr">
<div>That's great news! We desperately need fresh air. As you know, the way a problem is framed bounds its solutions. Do you already know what problems to work on or are you soliciting proposals?</div>
<div>
<br>
</div>
<div>Jonathan</div>
<br><div>
<br><div><blockquote>From:&nbsp;Alan Kay &lt;<a rel="nofollow">alan.nemo@...</a>&gt;<br>
To:&nbsp;Fundamentals of New Computing &lt;<a rel="nofollow">fonc@...</a>&gt;<br>Cc:&nbsp;<br>Date:&nbsp;Mon, 2 Sep 2013 10:45:50 -0700 (PDT)<br>Subject:&nbsp;Re: [fonc] Final STEP progress report abandoned?<br><div><div>

<div><span>Hi Dan</span></div>
<div><span><br></span></div>
<div>
<span>It actually got written and given to NSF and approved, etc., a while ago, but needs a little more work before posting on the VPRI site.&nbsp;</span>
</div>
<div>

<span><br></span>
</div>
<div><span>Meanwhile we've been consumed by setting up a number of additional, and wider scale, research projects, and this has occupied pretty much all of my time for the last 5-6 months.</span></div>

<div><span><br></span></div>
<div>
<span>Cheers,</span>
</div>
<div><span><br></span></div>
<div>
<span>Alan</span>
</div>
<div><br></div>  <div> <div>
 <div dir="ltr">  <span>From:</span> Dan Melchione &lt;<a rel="nofollow">dm.fonc@...</a>&gt;<br><span>To:</span> <a rel="nofollow">fonc@...</a> <br><span>Sent:</span> Monday, September 2, 2013 10:40 AM<br><span>Subject:</span> [fonc] Final STEP progress report abandoned?<br> </div> <div>
<br><div>

<div dir="ltr">Haven't seen much regarding this for a while. &nbsp;Has it been been abandoned or put at such low priority that it is effectively abandoned?</div>
</div>
<br>_______________________________________________<br>

fonc mailing list<br><a rel="nofollow">fonc@...</a><br><a rel="nofollow">http://vpri.org/mailman/listinfo/fonc</a><br><br><br>
</div> </div> </div>
  </div></div>
<br>_______________________________________________<br>
fonc mailing list<br><a rel="nofollow">fonc@...</a><br><a rel="nofollow">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote></div>
<br>
</div>
</div></div>
<br>_______________________________________________<br>fonc mailing list<br><a rel="nofollow">fonc <at> vpri.org</a><br><a rel="nofollow">http://vpri.org/mailman/listinfo/fonc</a><br><br><br>
</div> </div> </div>  </div></div></div>
<br>_______________________________________________<br>fonc mailing list<br><a rel="nofollow" href="mailto:fonc@..." target="_blank">fonc@...</a><br><a rel="nofollow" href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br><br>
</div> </div> </div> </blockquote>
</div>   </div></div></div>
<br><br>
</div> </div> </div>  </div></div>
</blockquote>
</div></div>
<br><br>
</div> </div> </div>  </div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>

fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br><br>
</div>
</div></div>
Tom Novelli | 9 Sep 19:08 2013
Picon

Re: 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.obrien.r-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
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!


<div><div dir="ltr">Good point, Casey - it's not just software. &nbsp;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. &nbsp;Hopefully that will all balance out and correct itself somewhat.<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">I see computers diverging into shrinkwrapped consumer devices (probably a dead end just like old mass media) and industrial/DIY gear for serious programming. &nbsp;I'd tend to write good clean code for the latter. &nbsp;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).</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">That's my optimistic scenario. &nbsp;In my pessimistic scenario I do see the kids getting dumber, because they're *only* using the internet for videos, games, chit-chat. &nbsp;They think the technology is pretty cool, but compared to previous generations they seem less interested in understanding it. &nbsp;What if this revolution lasts long enough to destroy most of the books, libraries, old-school factories, etc... and then collapses? &nbsp;It could set us back centuries. &nbsp;(I wonder how many sci-fi stories have already used that set-up... a couple hundred? :)</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 9, 2013 at 12:12 AM, Casey Ransberger <span dir="ltr">&lt;<a href="mailto:casey.obrien.r@..." target="_blank">casey.obrien.r@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div dir="ltr">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.&nbsp;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."<div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.&nbsp;</div>
<div><br></div>
<div>Why might this be?&nbsp;Let's try some fun game theory!</div>

</div>
<div><br></div>
<div>
<a href="http://www.nature.com/ncomms/2013/130801/ncomms3193/pdf/ncomms3193.pdf" target="_blank">http://www.nature.com/ncomms/2013/130801/ncomms3193/pdf/ncomms3193.pdf</a><br>
</div>
<div class="gmail_extra">
<br>
</div>
</div></blockquote>
</div></div>
</div></div>
David Barbour | 10 Sep 00:11 2013
Picon

Re: 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_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...

<div><div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>
These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div></div>
John Carlson | 10 Sep 00:47 2013
Picon

Re: 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" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div>
<p dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</p>

<div class="gmail_quote">On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@...">dmbarbour@...</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
Alan Kay | 10 Sep 02:54 2013
Picon

Re: 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 <yottzumm <at> gmail.com>
To: Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.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" <dmbarbour <at> gmail.com> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


<div><div>
<div><span>Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC "bluebook")</span></div>
<div><span><br></span></div>
<div><span>Cheers,</span></div>
<div><span><br></span></div>
<div><span>Alan</span></div>
<div><br></div>  <div> <div> <div dir="ltr">  <span>From:</span> John Carlson &lt;yottzumm <at> gmail.com&gt;<br><span>To:</span> Fundamentals of New Computing &lt;fonc@...&gt; <br><span>Sent:</span> Monday, September 9, 2013 3:47 PM<br><span>Subject:</span> Re: [fonc] Software Crisis (was Re: Final STEP progress report	abandoned?)<br> </div> <div class="y_msg_container">
<br><div>
<div dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with
 variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</div>

<div class="yiv0587709289gmail_quote">On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a rel="nofollow" ymailto="mailto:dmbarbour <at> gmail.com" target="_blank" href="mailto:dmbarbour@...">dmbarbour <at> gmail.com</a>&gt; wrote:<br><blockquote class="yiv0587709289gmail_quote">
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="yiv0587709289gmail_extra"><div class="yiv0587709289gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a rel="nofollow" ymailto="mailto:paul_homer@..." target="_blank" href="mailto:paul_homer@...">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="yiv0587709289gmail_quote"><div><div class="yiv0587709289gmail_extra"><div class="yiv0587709289gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="yiv0587709289gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a rel="nofollow" ymailto="mailto:fonc@..." target="_blank" href="mailto:fonc@...">fonc@...</a><br><a rel="nofollow" target="_blank" href="http://vpri.org/mailman/listinfo/fonc">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
<br>_______________________________________________<br>fonc mailing list<br><a ymailto="mailto:fonc@..." href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br><br>
</div> </div> </div>  </div></div>
K. K. Subramaniam | 10 Sep 04:33 2013
Picon

Re: Software Crisis (was Re: Final STEP progress report abandoned?)

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.htm

BTW, Dan Halbert is the author of the "more" command in Unix.

Regards .. Subbu
David Barbour | 10 Sep 18:49 2013
Picon

Re: 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.ml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
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.htm

BTW, Dan Halbert is the author of the "more" command in Unix.

Regards .. Subbu

_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div>
<div dir="ltr">Thanks for this ref. It looks interesting.</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 7:33 PM, K. K. Subramaniam <span dir="ltr">&lt;<a href="mailto:kksubbu.ml@..." target="_blank">kksubbu.ml@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="im">On Tuesday 10 September 2013 06:24 AM, Alan Kay wrote:<br><blockquote class="gmail_quote">
Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC<br>
"bluebook")<br>
</blockquote>
<br>
</div>
Available online at <a href="http://danhalbert.org/pbe-html.htm" target="_blank">http://danhalbert.org/pbe-html.htm</a><br><br>
BTW, Dan Halbert is the author of the "more" command in Unix.<br><br>
Regards .. Subbu<div class="HOEnZb"><div class="h5">
<br>
_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br>
</div></div>
</blockquote>
</div>
<br>
</div>
</div>
John Carlson | 10 Sep 18:36 2013
Picon

Re: 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.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC "bluebook")

Cheers,

Alan

From: John Carlson <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.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" <dmbarbour <at> gmail.com> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc <at> vpri.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


<div>
<div dir="ltr">Here's a short description, if you don't want to haul through the entire thesis:<div><br></div>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 7:54 PM, Alan Kay <span dir="ltr">&lt;<a href="mailto:alan.nemo@..." target="_blank">alan.nemo@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div><div>
<div><span>Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC "bluebook")</span></div>
<div><span><br></span></div>
<div>
<span>Cheers,</span>
</div>
<div><span><br></span></div>
<div>
<span>Alan</span>
</div>
<div><br></div>  <div> <div>
 <div dir="ltr">  <span>From:</span> John Carlson &lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;<br><span>To:</span> Fundamentals of New Computing &lt;<a href="mailto:fonc@..." target="_blank">fonc@...</a>&gt; <br><span>Sent:</span> Monday, September 9, 2013 3:47 PM<br><span>Subject:</span> Re: [fonc] Software Crisis (was Re: Final STEP progress report	abandoned?)<br> </div>
<div><div class="h5"> <div>
<br><div>
<div dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with
 variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</div>

<div>On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a rel="nofollow" href="mailto:dmbarbour@..." target="_blank">dmbarbour <at> gmail.com</a>&gt; wrote:<br><blockquote>

<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div><div>
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a rel="nofollow" href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote><div><div><div>
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote>
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a rel="nofollow" href="mailto:fonc@..." target="_blank">fonc <at> vpri.org</a><br><a rel="nofollow" href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
<br>_______________________________________________<br>fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br><br>
</div> </div></div>
</div> </div>  </div></div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
John Carlson | 10 Sep 18:38 2013
Picon

Re: Software Crisis (was Re: Final STEP progress report abandoned?)

mail got sent too fast...from "Watch What I Do":



On Tue, Sep 10, 2013 at 11:36 AM, John Carlson <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.nemo-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC "bluebook")

Cheers,

Alan

From: John Carlson <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.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" <dmbarbour <at> gmail.com> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc <at> vpri.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



<div>
<div dir="ltr">mail got sent too fast...from "Watch What I Do":<div><br></div>
<div>
<a href="http://acypher.com/wwid/Chapters/05SmallStar.html">http://acypher.com/wwid/Chapters/05SmallStar.html</a><br>
</div>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 11:36 AM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div dir="ltr">Here's a short description, if you don't want to haul through the entire thesis:<div><br></div>
</div>
<div class="HOEnZb"><div class="h5">
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 7:54 PM, Alan Kay <span dir="ltr">&lt;<a href="mailto:alan.nemo@..." target="_blank">alan.nemo@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div><div>
<div><span>Check out "Smallstar" by Dan Halbert at Xerox PARC (written up in a PARC "bluebook")</span></div>

<div><span><br></span></div>
<div>

<span>Cheers,</span>
</div>
<div><span><br></span></div>
<div>

<span>Alan</span>
</div>
<div><br></div>  <div> <div>

 <div dir="ltr">  <span>From:</span> John Carlson &lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;<br><span>To:</span> Fundamentals of New Computing &lt;<a href="mailto:fonc@..." target="_blank">fonc@...</a>&gt; <br><span>Sent:</span> Monday, September 9, 2013 3:47 PM<br><span>Subject:</span> Re: [fonc] Software Crisis (was Re: Final STEP progress report	abandoned?)<br> </div>
<div><div> <div>
<br><div>
<div dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with
 variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</div>

<div>On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a rel="nofollow" href="mailto:dmbarbour@..." target="_blank">dmbarbour <at> gmail.com</a>&gt; wrote:<br><blockquote>

<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div><div>
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a rel="nofollow" href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote><div><div><div>
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote>
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a rel="nofollow" href="mailto:fonc@..." target="_blank">fonc <at> vpri.org</a><br><a rel="nofollow" href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
<br>_______________________________________________<br>fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br><br>
</div> </div></div>
</div> </div>  </div></div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div></div>
</blockquote>
</div>
<br>
</div>
</div>
David Barbour | 10 Sep 19:25 2013
Picon

Re: 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

One thing you can do is create a bunch of named widgets that work together with copy and paste.  As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.  You'll probably want to create very small functions, which can also be stored in widgets (lambdas).  Widgets will show up when their scope is entered, or you could have an inspect mode.

On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


<div><div dir="ltr">
<div>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:&nbsp;<br>
</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.&nbsp;</div>
<div><br></div>
<div>To unify PL and UI, widgets must&nbsp;be values, behaviors, signals, code.</div>
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>
<div><br></div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<p dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</p>

<div class="gmail_quote">
<div><div class="h5">On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt; wrote:<br type="attribution">
</div></div>
<blockquote class="gmail_quote">
<div><div class="h5">
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>
</div></div>
<div class="im">_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</div>
</blockquote>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div></div>
David Barbour | 10 Sep 19:27 2013
Picon

Re: Software Crisis (was Re: Final STEP progress report abandoned?)


On Tue, Sep 10, 2013 at 10:25 AM, David Barbour <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.


Ideally, as it would be in a secure PL. Cf. Gilad Bracha's Newspeak and the 'Mirrors' concept.
 
<div><div dir="ltr">
<br><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 10, 2013 at 10:25 AM, David Barbour <span dir="ltr">&lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div dir="ltr">
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>
<div><div class="h5">
<div><br></div>
</div></div>
</div></blockquote>
<div><br></div>
<div>Ideally, as it would be in a secure PL. Cf. Gilad Bracha's Newspeak and the 'Mirrors' concept.</div>
<div>&nbsp;</div>
</div></div>
</div></div>
John Carlson | 10 Sep 19:54 2013
Picon

Re: 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 <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

One thing you can do is create a bunch of named widgets that work together with copy and paste.  As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.  You'll probably want to create very small functions, which can also be stored in widgets (lambdas).  Widgets will show up when their scope is entered, or you could have an inspect mode.

On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


<div>
<div dir="ltr">To unify PL and UI:<div><br></div>
<div>values: Date Calculator, String Calculator, Numeric Calculator, Zipper/Document Visualizer</div>
<div>behavior, code: &nbsp;Recorder (the container), Script, Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified Control Structure)</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Also, Exceptions (has anyone seen a UI for this?)</div>
<div>signals: &nbsp;Mouse, along with x,y coordinates</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Keyboard and Keystrokes</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Audio: waveform and controls</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Webcam: &nbsp;video and controls</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Networking: &nbsp;the extend/receive I/O operation</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; System interface: &nbsp;pipes, command prompt</div>
<div><br></div>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <span dir="ltr">&lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div dir="ltr">
<div>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:&nbsp;<br>
</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.&nbsp;</div>

<div><br></div>
<div>To unify PL and UI, widgets must&nbsp;be values, behaviors, signals, code.</div>
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>
<div><div class="h5">
<div><br></div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<p dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</p>

<div class="gmail_quote">
<div><div>On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt; wrote:<br type="attribution">
</div></div>
<blockquote class="gmail_quote">
<div><div>
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>
</div></div>
<div>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</div>
</blockquote>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
John Carlson | 10 Sep 20:06 2013
Picon

Re: 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

One thing you can do is create a bunch of named widgets that work together with copy and paste.  As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.  You'll probably want to create very small functions, which can also be stored in widgets (lambdas).  Widgets will show up when their scope is entered, or you could have an inspect mode.

On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



<div>
<div dir="ltr">It may be helpful to view everything as an editor. &nbsp;Something like SUIT (the Simple User Interface Toolkit):&nbsp;<a href="http://research.microsoft.com/en-us/um/people/rdeline/publications/uist-91.pdf">http://research.microsoft.com/en-us/um/people/rdeline/publications/uist-91.pdf</a> &nbsp;I'm thinking the web is finally getting to a point where everything is editable again.</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:54 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div dir="ltr">To unify PL and UI:<div><br></div>
<div>values: Date Calculator, String Calculator, Numeric Calculator, Zipper/Document Visualizer</div>
<div>behavior, code: &nbsp;Recorder (the container), Script, Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified Control Structure)</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Also, Exceptions (has anyone seen a UI for this?)</div>
<div>signals: &nbsp;Mouse, along with x,y coordinates</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Keyboard and Keystrokes</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Audio: waveform and controls</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Webcam: &nbsp;video and controls</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Networking: &nbsp;the extend/receive I/O operation</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; System interface: &nbsp;pipes, command prompt</div>
<div><br></div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <span dir="ltr">&lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div dir="ltr">
<div>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:&nbsp;<br>
</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.&nbsp;</div>

<div><br></div>
<div>To unify PL and UI, widgets must&nbsp;be values, behaviors, signals, code.</div>
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>

<div><div>
<div><br></div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<p dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</p>

<div class="gmail_quote">
<div><div>On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt; wrote:<br type="attribution">
</div></div>
<blockquote class="gmail_quote">
<div><div>
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>
</div></div>
<div>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</div>
</blockquote>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
John Carlson | 10 Sep 20:29 2013
Picon

Re: 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

One thing you can do is create a bunch of named widgets that work together with copy and paste.  As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.  You'll probably want to create very small functions, which can also be stored in widgets (lambdas).  Widgets will show up when their scope is entered, or you could have an inspect mode.

On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



<div><div dir="ltr">
<div>Does Minecraft have a way to compile a world (particularly redstone) to machine code? &nbsp;Is it still a challenge to go from a 3D representation to a machine language or machine representation? &nbsp;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. &nbsp;Can we reduce this to the machine, the world, and activity? &nbsp;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. &nbsp;How much circuitry would a Minecraft world take up? &nbsp;Has anyone done calculations? &nbsp;Could it fit on a raspberry pi like machine? &nbsp;This may be relevant:&nbsp;<a href="http://pi.minecraft.net/">http://pi.minecraft.net/</a> :(requires X11 apparently)<br>
</div>
<div><br></div>
<div>John<br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:54 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div dir="ltr">To unify PL and UI:<div><br></div>
<div>values: Date Calculator, String Calculator, Numeric Calculator, Zipper/Document Visualizer</div>

<div>behavior, code: &nbsp;Recorder (the container), Script, Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified Control Structure)</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Also, Exceptions (has anyone seen a UI for this?)</div>
<div>signals: &nbsp;Mouse, along with x,y coordinates</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Keyboard and Keystrokes</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Audio: waveform and controls</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Webcam: &nbsp;video and controls</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Networking: &nbsp;the extend/receive I/O operation</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; System interface: &nbsp;pipes, command prompt</div>
<div><br></div>
</div>
<div>
<div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <span dir="ltr">&lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div dir="ltr">
<div>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:&nbsp;<br>
</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.&nbsp;</div>

<div><br></div>
<div>To unify PL and UI, widgets must&nbsp;be values, behaviors, signals, code.</div>
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>

<div><div>
<div><br></div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<p dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</p>

<div class="gmail_quote">
<div><div>On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt; wrote:<br type="attribution">
</div></div>
<blockquote class="gmail_quote">
<div><div>
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>
</div></div>
<div>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</div>
</blockquote>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div></div>
David Barbour | 11 Sep 02:13 2013
Picon

Re: 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" <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

One thing you can do is create a bunch of named widgets that work together with copy and paste.  As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.  You'll probably want to create very small functions, which can also be stored in widgets (lambdas).  Widgets will show up when their scope is entered, or you could have an inspect mode.

On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div>
<p dir="ltr">This is a good list of concept components.</p>
<p dir="ltr">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.)</p>

<p dir="ltr">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).</p>

<p dir="ltr">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.</p>

<p dir="ltr">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?</p>
<div class="gmail_quote">On Sep 10, 2013 10:54 AM, "John Carlson" &lt;<a href="mailto:yottzumm@...">yottzumm@...</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">
<div dir="ltr">To unify PL and UI:<div><br></div>
<div>values: Date Calculator, String Calculator, Numeric Calculator, Zipper/Document Visualizer</div>
<div>behavior, code: &nbsp;Recorder (the container), Script, Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified Control Structure)</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Also, Exceptions (has anyone seen a UI for this?)</div>
<div>signals: &nbsp;Mouse, along with x,y coordinates</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Keyboard and Keystrokes</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Audio: waveform and controls</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Webcam: &nbsp;video and controls</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Networking: &nbsp;the extend/receive I/O operation</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; System interface: &nbsp;pipes, command prompt</div>
<div><br></div>
</div>
<div class="gmail_extra">

<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <span dir="ltr">&lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div dir="ltr">
<div>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:&nbsp;<br>
</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.&nbsp;</div>

<div><br></div>
<div>To unify PL and UI, widgets must&nbsp;be values, behaviors, signals, code.</div>
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>

<div><div>
<div><br></div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<p dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</p>

<div class="gmail_quote">
<div><div>On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt; wrote:<br type="attribution">
</div></div>
<blockquote class="gmail_quote">
<div><div>
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>
</div></div>
<div>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</div>
</blockquote>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
John Carlson | 11 Sep 04:45 2013
Picon

Re: 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" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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" <yottzumm <at> 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 <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

One thing you can do is create a bunch of named widgets that work together with copy and paste.  As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.  You'll probably want to create very small functions, which can also be stored in widgets (lambdas).  Widgets will show up when their scope is entered, or you could have an inspect mode.

On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div>
<p dir="ltr">If your sum/product is or/and, I tend to agree there is difficulty.&nbsp; We chose to use a normalized representation:&nbsp; the same number of factors for each term, "true" used liberally as a factor.&nbsp; In many cases, there were only two branches to take.&nbsp; 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++.&nbsp; 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.&nbsp; 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.&nbsp; However, it might be possible that he used my fancy table, but I never heard of any bug reports, so I doubt it.&nbsp; That's where I learn the rule don't make anything so complex you can't debug it, or automate tests for it.&nbsp; This is likely why we see much more XML than X12 these days.&nbsp; If you don't know what X12 is,&nbsp; think of a mixture between s-expressions and comma separated values.</p>

<div class="gmail_quote">On Sep 10, 2013 7:13 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@...">dmbarbour@...</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">
<p dir="ltr">This is a good list of concept components.</p>
<p dir="ltr">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.)</p>

<p dir="ltr">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).</p>

<p dir="ltr">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.</p>

<p dir="ltr">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?</p>
<div class="gmail_quote">On Sep 10, 2013 10:54 AM, "John Carlson" &lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm <at> gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">

<div dir="ltr">To unify PL and UI:<div><br></div>
<div>values: Date Calculator, String Calculator, Numeric Calculator, Zipper/Document Visualizer</div>
<div>behavior, code: &nbsp;Recorder (the container), Script, Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified Control Structure)</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Also, Exceptions (has anyone seen a UI for this?)</div>
<div>signals: &nbsp;Mouse, along with x,y coordinates</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Keyboard and Keystrokes</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Audio: waveform and controls</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Webcam: &nbsp;video and controls</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Networking: &nbsp;the extend/receive I/O operation</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; System interface: &nbsp;pipes, command prompt</div>
<div><br></div>
</div>
<div class="gmail_extra">

<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <span dir="ltr">&lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div dir="ltr">
<div>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:&nbsp;<br>
</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.&nbsp;</div>

<div><br></div>
<div>To unify PL and UI, widgets must&nbsp;be values, behaviors, signals, code.</div>
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>

<div><div>
<div><br></div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<p dir="ltr">One thing you can do is create a bunch of named widgets that work together with copy and paste.&nbsp; As long as you can do type safety, and can appropriately deal with variable explosion/collapsing.&nbsp; You'll probably want to create very small functions, which can also be stored in widgets (lambdas).&nbsp; Widgets will show up when their scope is entered, or you could have an inspect mode.</p>

<div class="gmail_quote">
<div><div>On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt; wrote:<br type="attribution">
</div></div>
<blockquote class="gmail_quote">
<div><div>
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>
</div></div>
<div>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</div>
</blockquote>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
David Barbour | 11 Sep 06:24 2013
Picon

Re: 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 <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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" <dmbarbour <at> 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" <yottzumm <at> 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 <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.

<div><div dir="ltr">Yes, sum (x + y) vs. product (x * y) corresponds to 'or vs. and' or 'union vs. struct'.<div><br></div>
<div>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. &nbsp;</div>
<div><br></div>
<div>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.)</div>
<div><br></div>
<div>There are differences between sums and products:&nbsp;</div>
<div><br></div>
<div>&nbsp; &nbsp; products have `copy` x -&gt; (x * x) &nbsp;(adding 1 bit of info)</div>
<div>&nbsp; &nbsp; sums have `merge` (x + x) -&gt; x (losing 1 bit of info)</div>
<div><br></div>
<div>And in general we want to deal with cases like:<br>
</div>
<div><br></div>
<div>&nbsp; &nbsp; &nbsp; factoring :: (x*y) + (x*z) -&gt; x*(y+z)</div>
<div>&nbsp; &nbsp; &nbsp; distribution :: x * (y + z) -&gt; (x * y) + (x * z)</div>
<div>
&nbsp; &nbsp;&nbsp;<br>
</div>
<div>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.&nbsp;<br>
</div>
<div><br></div>
<div>
<div>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.&nbsp;</div>
</div>
<div><br></div>
<div><br></div>
<div>In other thoughts...</div>
<div><br></div>
<div>One PL concept you didn't mention is promises/futures. How might those be realized in a UI?</div>
<div><br></div>
<div>In the type system of a PL, promises can be modeled as a pair:</div>
<div><br></div>
<div>&nbsp; &nbsp; &nbsp; makePromise :: &nbsp;1 -&gt; (resolver * future)</div>
<div><br></div>
<div>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:</div>
<div><br></div>
<div>&nbsp; &nbsp; &nbsp; receive :: &nbsp;1 -&gt; &nbsp;(1/a * a)</div>
<div>&nbsp; &nbsp; &nbsp; return :: (1/a * a) -&gt; 1</div>
<div>&nbsp; &nbsp; &nbsp; receive+ :: 0 -&gt; (-a + a)</div>
<div>&nbsp; &nbsp; &nbsp; return+ :: (-a + a) -&gt; 0</div>
<div><br></div>
<div>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).&nbsp;</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><div><div><div><div><div><div><div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 10, 2013 at 7:45 PM, John Carlson <span dir="ltr">&lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<p dir="ltr">If your sum/product is or/and, I tend to agree there is difficulty.&nbsp; We chose to use a normalized representation:&nbsp; the same number of factors for each term, "true" used liberally as a factor.&nbsp; In many cases, there were only two branches to take.&nbsp; 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++.&nbsp; 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.&nbsp; 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.&nbsp; However, it might be possible that he used my fancy table, but I never heard of any bug reports, so I doubt it.&nbsp; That's where I learn the rule don't make anything so complex you can't debug it, or automate tests for it.&nbsp; This is likely why we see much more XML than X12 these days.&nbsp; If you don't know what X12 is,&nbsp; think of a mixture between s-expressions and comma separated values.</p>
<div class=""><div class="h5">

<div class="gmail_quote">On Sep 10, 2013 7:13 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour <at> gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">

<p dir="ltr">This is a good list of concept components.</p>
<p dir="ltr">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.)</p>

<p dir="ltr">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).</p>

<p dir="ltr">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.</p>

<p dir="ltr">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?</p>
<div class="gmail_quote">On Sep 10, 2013 10:54 AM, "John Carlson" &lt;<a href="mailto:yottzumm@..." target="_blank">yottzumm <at> gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">

<div dir="ltr">To unify PL and UI:<div><br></div>
<div>values: Date Calculator, String Calculator, Numeric Calculator, Zipper/Document Visualizer</div>
<div>behavior, code: &nbsp;Recorder (the container), Script, Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified Control Structure)</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Also, Exceptions (has anyone seen a UI for this?)</div>
<div>signals: &nbsp;Mouse, along with x,y coordinates</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Keyboard and Keystrokes</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Audio: waveform and controls</div>

<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Webcam: &nbsp;video and controls</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Networking: &nbsp;the extend/receive I/O operation</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; System interface: &nbsp;pipes, command prompt</div>
<div><br></div>
</div>
<div class="gmail_extra">

<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <span dir="ltr">&lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div dir="ltr">
<div>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:&nbsp;<br>
</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.</div>

<div><br></div>
<div>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.&nbsp;</div>

<div><br></div>
<div>To unify PL and UI, widgets must&nbsp;be values, behaviors, signals, code.</div>
<div><br></div>
<div>And any "looking under the hood" must be formally represented as reflection or introspection, just as it would be in a PL.</div>

<div><div>
<div><br></div>
</div></div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div></div>
</blockquote>
</div></div></div></div></div></div></div></div></div></div></div>
</div></div>
Darius Bacon | 11 Sep 07:35 2013
Picon

Re: Software Crisis (was Re: Final STEP progress report abandoned?)

On Wed, Sep 11, 2013 at 12:24 AM, David Barbour <dmbarbour@...> 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).
David Barbour | 11 Sep 19:03 2013
Picon

Re: 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 <withal-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Wed, Sep 11, 2013 at 12:24 AM, David Barbour <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div><div dir="ltr">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?<div>
<br>
</div>
<div>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.</div>
<div><br></div>
<div>Best,</div>
<div><br></div>
<div>Dave</div>
<div><br></div>
<div><div class="gmail_extra">
<br><div class="gmail_quote">On Tue, Sep 10, 2013 at 10:35 PM, Darius Bacon <span dir="ltr">&lt;<a href="mailto:withal@..." target="_blank">withal@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="im">On Wed, Sep 11, 2013 at 12:24 AM, David Barbour &lt;<a href="mailto:dmbarbour@...">dmbarbour@...</a>&gt; wrote:<br>

&gt; One PL concept you didn't mention is promises/futures. How might those be realized in a UI?<br><br>
</div>There's precedent: ToonTalk represents promises and resolvers in its<br>
UI as nests and birds. (Some reasons this may miss the mark: It's been<br>
many years since I played with ToonTalk; IIRC the system supports<br>
declarative concurrency and nothing more powerful; I don't understand<br>
you about negative and fractional types, though it sounds interesting:<br><a href="http://www.cs.indiana.edu/~sabry/papers/rational.pdf" target="_blank">http://www.cs.indiana.edu/~sabry/papers/rational.pdf</a> )<br><span class=""><br>
Darius<br></span><div class="im">
<br><br>
&gt; In the type system of a PL, promises can be modeled as a pair:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; makePromise :: &nbsp;1 -&gt; (resolver * future)<br>
&gt;<br>
&gt; 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:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; receive :: &nbsp;1 -&gt; &nbsp;(1/a * a)<br>
&gt; &nbsp; &nbsp; &nbsp; return :: (1/a * a) -&gt; 1<br>
&gt; &nbsp; &nbsp; &nbsp; receive+ :: 0 -&gt; (-a + a)<br>
&gt; &nbsp; &nbsp; &nbsp; return+ :: (-a + a) -&gt; 0<br>
&gt;<br>
&gt; 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).<br>
</div>
<div class=""><div class="h5">_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br>
</div></div>
</blockquote>
</div>
<br>
</div></div>
</div></div>
David Barbour | 10 Sep 19:25 2013
Picon

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 <yottzumm <at> gmail.com> wrote:

> One thing you can do is create a bunch of named widgets that work together
> with copy and paste.  As long as you can do type safety, and can
> appropriately deal with variable explosion/collapsing.  You'll probably
> want to create very small functions, which can also be stored in widgets
> (lambdas).  Widgets will show up when their scope is entered, or you could
> have an inspect mode.
> On Sep 9, 2013 5:11 PM, "David Barbour" <dmbarbour <at> gmail.com> wrote:
>
>> I like Paul's idea here - form a "pit of success" even for people who
>> tend to copy-paste.
>>
>> I'm very interested in unifying PL with HCI/UI such that actions like
>> copy-paste actually have formal meaning. If you copy a time-varying field
>> from a UI form, maybe you can paste it as a signal into a software agent.
>> Similarly with buttons becoming capabilities. (Really, if we can use a
>> form, it should be easy to program something to use it for us. And vice
>> versa.) All UI actions can be 'acts of programming', if we find the right
>> way to formalize it. I think the trick, then, is to turn the UI into a good
>> PL.
>>
>> To make copy-and-paste code more robust, what can we do?
>>
>> Can we make our code more adaptive? Able to introspect its environment?
>>
>> Can we reduce the number of environmental dependencies? Control namespace
>> entanglement? Could we make it easier to grab all the dependencies for code
>> when we copy it?
>>
>> Can we make it more provable?
>>
>> And conversely, can we provide IDEs that can help the "kids" understand
>> the code they take - visualize and graph its behavior, see how it
>> integrates with its environment, etc? I think there's a lot we can do. Most
>> of my thoughts center on language design and IDE design, but there may also
>> be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that
>> also make it easy to interactively explore and understand code before using
>> it.
>>
>>
>> On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer <at> yahoo.ca> wrote:
>>
>>>
>>> These days, the "kids" do a quick google, then just copy&paste the
>>> results into the code base, mostly unaware of what the underlying 'magic'
>>> instructions actually do. So example code is possibly a bad thing?
>>>
>>> But even if that's true, we've let the genie out of the bottle and he
>>> is't going back in. To fix the quality of software, for example, we can't
>>> just ban all cut&paste-able web pages.
>>>
>>> The alternate route out of the problem is to exploit these types of
>>> human deficiencies. If some programmers just want to cut&paste, then
>>> perhaps all we can do is too just make sure that what they are using is
>>> high enough quality. If someday they want more depth, then it should be
>>> available in easily digestible forms, even if few will ever travel that
>>> route.
>>>
>>> If most people really don't want to think deeply about about their
>>> problems, then I think that the best we can do is ensure that their hasty
>>> decisions are based on as accurate knowledge as possible. It's far better
>>> than them just flipping a coin. In a sense it moves up our decision making
>>> to a higher level of abstraction. Some people lose the 'why' of the
>>> decision, but their underlying choice ultimately is superior, and the 'why'
>>> can still be found by doing digging into the data. In a way, isn't that
>>> what we've already done with micro-code, chips and assembler? Or machinery?
>>> Gradually we move up towards broader problems...
>>>
>>>>
>>>>
>> _______________________________________________
>> fonc mailing list
>> fonc <at> vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
> _______________________________________________
> fonc mailing list
> fonc <at> vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
_______________________________________________
fonc mailing list
fonc <at> vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
FoRK mailing list
http://xent.com/mailman/listinfo/fork
John Carlson | 10 Sep 00:57 2013
Picon

Re: 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" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div>
<p dir="ltr">I'd recommend looking into quartz composer on mac os x.</p>
<div class="gmail_quote">On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@...">dmbarbour@...</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
John Carlson | 10 Sep 01:03 2013
Picon

Re: 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" <dmbarbour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div>
<p dir="ltr">Also, you could have an input zipper, a flippable conversion area, an output zipper, and a history of conversion stack.</p>
<div class="gmail_quote">On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@...">dmbarbour@...</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">
<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</div>
John Carlson | 10 Sep 01:37 2013
Picon

Re: 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" <yottzumm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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" <dmbarbour <at> gmail.com> wrote:
I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.

I'm very interested in unifying PL with HCI/UI such that actions like copy-paste actually have formal meaning. If you copy a time-varying field from a UI form, maybe you can paste it as a signal into a software agent. Similarly with buttons becoming capabilities. (Really, if we can use a form, it should be easy to program something to use it for us. And vice versa.) All UI actions can be 'acts of programming', if we find the right way to formalize it. I think the trick, then, is to turn the UI into a good PL.

To make copy-and-paste code more robust, what can we do?

Can we make our code more adaptive? Able to introspect its environment?

Can we reduce the number of environmental dependencies? Control namespace entanglement? Could we make it easier to grab all the dependencies for code when we copy it? 

Can we make it more provable?

And conversely, can we provide IDEs that can help the "kids" understand the code they take - visualize and graph its behavior, see how it integrates with its environment, etc? I think there's a lot we can do. Most of my thoughts center on language design and IDE design, but there may also be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that also make it easy to interactively explore and understand code before using it.


On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <paul_homer-FFYn/CNdgSA@public.gmane.org> wrote:

These days, the "kids" do a quick google, then just copy&paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?

But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&paste-able web pages.

The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.

If most people really don't want to think deeply about about their problems, then I think that the best we can do is ensure that their hasty decisions are based on as accurate knowledge as possible. It's far better than them just flipping a coin. In a sense it moves up our decision making to a higher level of abstraction. Some people lose the 'why' of the decision, but their underlying choice ultimately is superior, and the 'why' can still be found by doing digging into the data. In a way, isn't that what we've already done with micro-code, chips and assembler? Or machinery? Gradually we move up towards broader problems...


_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc

<div>
<p dir="ltr">The trick here is to make the zippers at the meta or schema level.</p>
<p dir="ltr">John</p>
<div class="gmail_quote">On Sep 9, 2013 6:03 PM, "John Carlson" &lt;<a href="mailto:yottzumm@...">yottzumm@...</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">
<p dir="ltr">Also, you could have an input zipper, a flippable conversion area, an output zipper, and a history of conversion stack.</p>
<div class="gmail_quote">On Sep 9, 2013 5:11 PM, "David Barbour" &lt;<a href="mailto:dmbarbour@..." target="_blank">dmbarbour <at> gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">

<div dir="ltr">
<div>I like Paul's idea here - form a "pit of success" even for people who tend to copy-paste.</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div>To make copy-and-paste code more robust, what can we do?</div>
<div><br></div>
<div>Can we make our code more adaptive? Able to introspect its environment?</div>
<div><br></div>
<div>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?&nbsp;<br><br>Can we make it more provable?</div>
<div><br></div>
<div>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.</div>

<div><br></div>
<div class="gmail_extra"><div class="gmail_quote">
<br>On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <span dir="ltr">&lt;<a href="mailto:paul_homer@..." target="_blank">paul_homer@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote">
<br>

These days, the "kids" do a quick google, then just copy&amp;paste the results into the code base, mostly unaware of what the underlying 'magic' instructions actually do. So example code is possibly a bad thing?<br><br>But even if that's true, we've let the genie out of the bottle and he is't going back in. To fix the quality of software, for example, we can't just ban all cut&amp;paste-able web pages.<br><br>The alternate route out of the problem is to exploit these types of human deficiencies. If some programmers just want to cut&amp;paste, then perhaps all we can do is too just make sure that what they are using is high enough quality. If someday they want more depth, then it should be available in easily digestible forms, even if few will ever travel that route.<br><br>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...<br><blockquote class="gmail_quote">
<div>

<div><div><br></div></div>
</div>
</blockquote>
</div></div></div></blockquote>
</div></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@..." target="_blank">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
</blockquote>
</div>
</div>

Gmane