Re: [PiLuD] Whiteboard programming?

[David Barbour]

On Tue, Dec 15, 2015 at 1:36 PM, Raoul Duke <rao...@gmail.com> wrote:

Can we ever successfully have a programming experience like standing up and drawing on a big digital whiteboard, doing boxes and arrows, and yet making real code?

Yes. Especially with augmented reality technologies, like Microsoft Hololens or Meta Glasses. We can use a whiteboard as a haptic programmer interface for sketching ideas, with the AR devices projecting feedback in real-time (rendering use cases, type errors, ambiguity, etc.). Pseudo-code can be understood in terms of constraint models. Further refinement of our sketches then helps narrow the constraints. We certainly aren't limited to whiteboards: notebooks, cards, game tokens, and other haptic elements can be introduced as needed.

Conveniently, this combines with virtual widgets. For example, you can draw the 'concept' of a slider or a checkbox, and the AR system can visually render a slider or checkbox. This would allow you to quickly tweak different arguments, recording their state in our virtual record instead of the physical space.

Consider a context of live programming and smart homes. You could open up a notebook that is (through your AR recognizers) virtually connected to your smarthome and turn off the lights with a flick of a virtual switch. Or you could open the same notebook to another page and start sketching out some music. 

These are some of the visions behind my Awelon project, blending the 'user experience' and the 'programmer experience' so there are no hard lines between them but instead a smooth continuum of editable views.

[David Barbour]

On Tue, Dec 15, 2015 at 3:24 PM, Raoul Duke <rao...@gmail.com> wrote:

The thing in my mind is:

(a) the pictures will be virtual / backed by computer power / not just
ink on plastic. It must round-trip. It must be 'integrated'. It must
be an aspect, a viewpoint, cf. coretalk
(http://www.baychi.org/bof/future/20030325c/)

There's a useful continuum between 'entirely virtual' and 'just ink on plastic' where we're still backed by computing power. I think there will be a sweet spot somewhere within this continuum. Purely virtual constructs can be awkward for humans to manipulate and access (e.g. fumbling through folders and search engines). But we can associate virtual constructs with a physical index (e.g. a set of rules like "if you see a whiteboard that looks like X, overlay the virtual model VX" except maintained automatically). This gives us intuitive physical access to virtual models. 

Connecting virtual models then becomes a physical activity: name the models (if you haven't already), then go to a fresh page to write down the names and compose or connect them.

[Sean McDirmid]

I’m working on this right now. The key seems to be “create by abstracting” or “programming by example”, the ability to sketch out a concrete artifact and then generalize it into an abstraction. So HoloLens, Sufrace (with stylus), are great for sketching and manipulating concrete artifacts, and then its just a matter of progressive abstraction (hopefully).

--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at https://groups.google.com/group/augmented-programming.
For more options, visit https://groups.google.com/d/optout.

[Raoul Duke]

On Tue, Dec 15, 2015 at 3:39 PM, Sean McDirmid <smc...@microsoft.com> wrote:
> I’m working on this right now. The key seems to be “create by abstracting”
> or “programming by example”, the ability to sketch out a concrete artifact
> and then generalize it into an abstraction. So HoloLens, Sufrace (with
> stylus), are great for sketching and manipulating concrete artifacts, and
> then its just a matter of progressive abstraction (hopefully).

That sounds like one of many possible interpretations of the roarschach test.

Like, I wouldn't mind having flowcharts/oml/etc. that are round-trip
live connected with crappy old Java code.

Basically I am wondering: Why do we draw things on whiteboards to
explain the code? By which personally I mean: Why isn't that part and
parcel of the blasted code all the time?

[Sean McDirmid]

This is a question I’m trying to figure out right now as well. Frankly, I want to move from "thinking to program" to "programming to think", meaning the programming environment should replace the whiteboard, but in order for that to happen, I think we really need different abstraction levels.

What we see as code is really just highly abstracted thought. It doesn't connect back to the concrete examples that led to these abstractions, there is no record, there are no mechanisms to convert concrete examples into code. So what we need is a second medium that exists alongside code to "think" though problems and mine abstractions from concrete problem solutions.

Right now, my thinking is to take the "log view" that normally just traces code execution, and make it into a two-way experience. Adding a line "hello world" to the log view will necessary cause a printf("hello world") statement to be added to the code. There are many ways to arrive at a value, from simply stating the value (very concrete) to taking existing values bound to variables and combining them in some way. So in the log value, you state the value you want, and then work out how to get it abstractly with the help of having a concrete execution context to guide that.

So replace log view with notebook or white board, and it at least provides a framework on how we should move forward.

-----Original Message-----
From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of Raoul Duke
Sent: Wednesday, December 16, 2015 7:43 AM
To: PiLuD <pi...@googlegroups.com>
Cc: augmented-...@googlegroups.com
Subject: Re: [PiLuD] Whiteboard programming?

[Raoul Duke]

Sounds cool. :-) Definitely exciting that somebody on Earth is trying
another tack, and is trying to take it as far as they can go.

[David Barbour]

On Tue, Dec 15, 2015 at 5:54 PM, Sean McDirmid <smc...@microsoft.com> wrote:

I want to move from "thinking to program" to "programming to think"

I agree. But I'd further extend this to actions other than thinking. Posting to a forum or mailing list could easily be modeled as actions updating a program's source code, for example. And once we begin modeling *actions* as acts of programming, we gain a great deal of ability to abstract actions, e.g. physical macros.

 

What we see as code is really just highly abstracted thought. It doesn't connect back to the concrete examples that led to these abstractions, there is no record, there are no mechanisms to convert concrete examples into code. So what we need is a second medium that exists alongside code to "think" though problems and mine abstractions from concrete problem solutions.

Or... we could shove all those concrete examples and records directly into our codebase. 

This is the route I'm taking with 'dictionary applications' [1] for example. A conventional application (e.g. a forum, or a game server) becomes a value represented in source code. The command pattern is especially useful: every 'command' also is a function represented in source code, applied to the previous value. This is a very cache friendly pattern: it's easy to compute the current value/state of the application. And it also allows undo, forking apps, abstraction of commands, etc..

For some very long running applications (but fewer than we might initially expect [2]), we do need a way to 'garbage collect' our source code. But instead of conventional GC, we can have a software agent that 'optimizes' our source code over time (guided and controlled by a few attributes). I describe this under 'managed dictionaries' in [1].

[1] https://awelonblue.wordpress.com/2015/11/17/wikilon-dictionary-applications/

[2] https://www.usenix.org/conference/osdi14/technical-sessions/presentation/devecsery

[Sean McDirmid]

Once you have your concrete example abstracted into source code, it is trivial to re-create that concrete example again, or any other concrete example that is an instance of the abstraction J. With live programming, it’s just a matter of loading that example up and then working on it through the log view. So in a way, it is already “directly” in your code base.

 

In order to crack this nut, we have to get away from thinking about “what the code looks like to do something” and more about “how could we come up with the code to do something.” Most PL-based thinking focuses on the former and not the latter…maybe wikilon is falling into the same trap?

 

From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of David Barbour
Sent: Wednesday, December 16, 2015 8:09 AM
To: pi...@googlegroups.com
Cc: augmented-...@googlegroups.com
Subject: Re: [PiLuD] Whiteboard programming?

 

On Tue, Dec 15, 2015 at 5:54 PM, Sean McDirmid <smc...@microsoft.com> wrote:

--

[Jonathan Edwards]

What I wanted to ask you at Yow is how you will surface control flow in this log? Otherwise you can't locate where to push changes to the log back into the code. And then how will you edit control flow from the log?

On Tue, Dec 15, 2015 at 3:54 PM -0800, "Sean McDirmid" <smc...@microsoft.com> wrote:

This is a question I’m trying to figure out right now as well. Frankly, I want to move from "thinking to program" to "programming to think", meaning the programming environment should replace the whiteboard, but in order for that to happen, I think we really need different abstraction levels.

What we see as code is really just highly abstracted thought. It doesn't connect back to the concrete examples that led to these abstractions, there is no record, there are no mechanisms to convert concrete examples into code. So what we need is a second medium that exists alongside code to "think" though problems and mine abstractions from concrete problem solutions. 

Right now, my thinking is to take the "log view" that normally just traces code execution, and make it into a two-way experience. Adding a line "hello world" to the log view will necessary cause a printf("hello world") statement to be added to the code. There are many ways to arrive at a value, from simply stating the value (very concrete) to taking existing values bound to variables and combining them in some way. So in the log value, you state the value you want, and then work out how to get it abstractly with the help of having a concrete execution context to guide that. 

So replace log view with notebook or white board, and it at least provides a framework on how we should move forward. 



-----Original Message-----
From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of Raoul Duke
Sent: Wednesday, December 16, 2015 7:43 AM
To: PiLuD 

Cc: augmented-...@googlegroups.com

[Sean McDirmid]

Loops are probably easy, say you have:

 

Hello world

Hello world

Hello world

Hello world

 

That could be four printfs or a loop with N=4 iterations. So in the latter case, you get a little loop widget with hello world in the iteration boxes, any changes to one iteration box affects all iteration boxes. Then you might want to generalize “4” into something more abstract that still produces “4”.

 

For “if” statements, it is more like getting rid of something you had in a previous execution context, to substitute behavior in a new execution context based on a condition.

 

So say we had:

 

Hot

 

And you now want:

 

Cold

 

So we edit the log view to suppress “Hot” and add the execution we want “Cold”

 

if false:

  Log(“Hot”)

else:

  Log(“Cold”)

 

Now, we work on generalizing “false”, so say we know it is related to a variable called temp, then we simply search for an f such that f(temp) is false. If temp’s concrete value is 5, then that could be temp > 5 or temp < 5 among other things. So just find something that fits, then try another example until you get the abstraction you want.

 

I’m calling it…human machine learning J.

[Raoul Duke]

While it might seem strange to do that to a regular programmer, on the other hand we have to acknowledge that we tend to do X intending to get Y, but get Y' as in Y+bugs that are think-os by us. So maybe doing things "backwards" can let us really get what we wanted in the first place.

[David Barbour]

On Tue, Dec 15, 2015 at 6:24 PM, Sean McDirmid <smc...@microsoft.com> wrote:

Once you have your concrete example abstracted into source code, it is trivial to re-create that concrete example again, or any other concrete example that is an instance of the abstraction J.

Wat? There is no abstraction that will let you trivially re-create one of Shakespeare's plays, nor a specific thread on LtU, nor a business transaction, nor even a single 140 character tweet. You need to *represent* this information. Otherwise it's just gone. 

 

 

we have to get away from thinking about “what the code looks like to do something” and more about “how could we come up with the code to do something.” 

I think both could use more attention. 

Focusing on how code is structured can be very useful and practical. Doing so can make code more readable, or extensible, or composable, or factorable, or streamable, or easy to render visually, etc.. Too many PLs prioritize just a few structural aspects to the detriment of the rest, which is a mistake.

And we also need to address how code is created in the first place - how we "come up with the code".

Most PLs have an unfortunate disconnect between 'first class functions' and 'source code' that makes it difficult to treat them equivalently (e.g. due to performance, opacity, serializability, mutability, second-class features). If we can eliminate this gap, then it gives us a lot of flexibility for how we choose to "come up with the code" because we can model whatever we want in a first-class way - e.g. modeling a constraint system or genetic programming.

Hosting applications (forums, blogs, wikis, etc.) directly in the codebase is another interesting answer, explored initially in spreadsheets and perhaps hypercard. This allows us to focus on representation and relationships, the concrete examples. Reusable abstractions are what we get later, when we find and refactor common patterns from these representations. Or earlier if we correctly anticipate the need for an abstraction, which seems to largely be a matter of experience.

maybe wikilon is falling into the same trap?

Wikilon isn't neglecting either aspect. But I am focusing on representing 'action' than 'thought' with regards to how we 'come up with code'. Our thoughts, of course, are reflected in our actions, especially if we attempt to write down our thoughts.

[Sean McDirmid]

If you created an abstraction around shakespeare’s plays, it could, or anything else for that matter (just look at RPG’s recent talk on machine-generated poetry!). The problem is recalling the example, which might be difficult. There is also always documentation and meta-text.

 

Of course, readability, extensibility, composability, factorability, etc… is all important. But cracking this “whiteboard” feature in particular, I guess, revolves around a concrete-abstract bidirectional mapping. You can’t explore all of them at once, and anyways, plenty of work has explored all of these features without any guidance on how the programmer actually thinks. It’s time to start from the programmer’s perspective and work our way from there. We want something that fundamentally “easier” not just “more clever!”

 

I’m just trying to be constructive here: when I read about your work, I feel so mentally taxed that I’m not sure what I should get out of it. It isn’t just you, but 90% of the PL papers are like that: they focus on features and actions, the encoding of solutions as code vs. the act of solving problems. We are truly lost in the wilderness. Try taking the programmer’s perspective in your work (and the stories you build around it). Talk from what they must do and what they are thinking when they are using your language to do something.

 

[Jonathan Edwards]

+1

--

[David Barbour]

On Wed, Dec 16, 2015 at 12:44 AM, Sean McDirmid <smc...@microsoft.com> wrote:

The problem is recalling the example, which might be difficult.

It certainly isn't trivial.

 

 

cracking this “whiteboard” feature in particular, I guess, revolves around a concrete-abstract bidirectional mapping.

I would tease apart two different major aspects of this problem. 

First, is understanding the whiteboard as code and how humans interact with that code. This aspect is almost purely structural. There is a physical-virtual bidirectional mapping, but both directions are very 'concrete'. I mean this in the same sense that rendered HTML isn't meaningfully more 'abstract' than the underlying markup text.

Second, is achieving the high-level code sketching and rapid prototyping 'feel' of work around a whiteboard. Content on a whiteboard represents high level thoughts, therefore we need a programming model that operates with high level thoughts and helps us refine them. Soft constraint solvers, programming by example, etc.. The 'concrete-abstract' mapping is normally called semantics. We need a semantics that gives us a suitable whiteboard-like programmer experience.

These aspects do interact, especially when we provide live feedback.

 

It’s time to start from the programmer’s perspective and work our way from there.  

I don't believe this 'perspective' has been neglected nearly so much as you seem to believe it has been. 

It's just that different designers have different visions for the programmer experience. You could look into Eve project and the 'Out of the Tarpit' paper for one vision. You could look into Smalltalk for some of Alan Kay's earlier visions. Forth language was yet another perspective on how we should interact with computers. My Awelon project is heavily oriented around the 'Personal Programming Environment as Extension of Self' short thesis I wrote on a mailing list a while back.

 

We want something that fundamentally “easier” not just “more clever!”

I certainly agree. And I bet Charles Moore was aiming for the same thing when he created Forth, which is undoubtedly simple compared to most PLs. 

Simplicity has certainly been a driving constraint in Awelon project: a simple purely functional bytecode, syntax as editable views of bytecode (no difficult to comprehend 'compiler' layer, unless you model one), human actions modeled as simple streams of code, etc..

 

 

90% of the PL papers are like that: they focus on features and actions, the encoding of solutions as code vs. the act of solving problems.

A focus on actions certainly doesn't exclude the 'act' of solving problems. While it isn't true of all PL designers, there are those that do consider not just 'encoding of solutions' but also the interaction and feedback obtained on the path to developing a solution, and the sort of thinking that goes into a solution, and even stuff like system discovery and documentation. 

[David Barbour]

On Wed, Dec 16, 2015 at 9:27 AM, David Barbour <dmba...@gmail.com> wrote:

It's just that different designers have different visions for the programmer experience. You could look into Eve project and the 'Out of the Tarpit' paper for one vision. You could look into Smalltalk for some of Alan Kay's earlier visions. Forth language was yet another perspective on how we should interact with computers. My Awelon project is heavily oriented around the 'Personal Programming Environment as Extension of Self' short thesis I wrote on a mailing list a while back.

Turning a few of these into links:

Charles Moore's "Programming a Problem-Oriented Language", a book he wrote just after his first version of Forth that explained some of the motivations surrounding its design. http://www.colorforth.com/POL.htm

The 'Out of the Tarpit' paper by Ben Moseley and Peter Marks describes functional-relational programming, taking the perspective that programmers should be dealing only with the essential complexity of their problems. Conventional forms of state and control flow are eliminated from the programming experience, though a relvar containing time-series data and some declarative caching can provide similar applications to what exist today. http://shaffner.us/cs/papers/tarpit.pdf

Aside: I recently re-read the above paper (last I read it was ~2009) and found it similar enough to contrast with my dictionary applications concepts. https://awelonblue.wordpress.com/2015/12/09/out-of-the-tarpit/

Eve project takes inspiration from the aforementioned paper. Further, its developers have received continuous feedback from hundreds of target audience 'programmers'. There is probably bias in their studies, but it's still impressive. http://eve-lang.com/ http://incidentalcomplexity.com/

A philosophy guiding my Awelon project is that programming should be regarded not as a language, but more as a medium or a canvas. That we should not live 'above' the program, but within it. Applications shouldn't have huge walls that prevent us from extracting or extending functionality, they should have the same accessibility as code. Data representations shouldn't have barriers that hinder abstraction or procedural generation. https://awelonblue.wordpress.com/2012/10/26/ubiquitous-programming-with-pen-and-paper/ https://awelonblue.wordpress.com/2014/08/07/code-is-material/ https://groups.google.com/d/msg/reactive-demand/gazxhLLXscQ/_2YpJ6b3-6sJ 

Alan Kay has plenty of thoughts on the programmer's perspective, and has explored many approaches to interacting with computers. These are not well organized on the Internet AFAICT. You can find the more recent ones through the VPRI FoNC mailing lists. https://www.mail-archive.com/fo...@vpri.org/index.html

And I can go on. 

There is Joseph Goguen, developer of several OBJ family languages (term rewriting) developing BOBJ (refinement of models with specific implementation strategies) shortly before his death. He was also also into fuzzy logic, and had some very interesting visions for how programmers should be solving problems, telling machines what to do in broad strokes then gradually refining or constraining behavior.

There is Seymour Papert, designer of Logo and author of the 'Mindstorms' book. He considered language not just as a problem solving tool, but also an educational one - something to shape the human as much as the human shapes the language.

There is Paul Chiusano, developing the Unison project, trying to tackle the problems he sees with how programming is performed today. The approach is similar to my own, but different in enough ways that I look forward to its progress.  http://unisonweb.org/2015-05-07/about.html#post-start

There are the authors of 'Plain English' programming, who believe that programming should be more like natural language sentences and simple imperative thinking, that OOP is too convoluted and that more than one loop per function is too complex. http://www.osmosian.com/ 

Taking a programmer's perspective is certainly no guarantee any convergence. Not least because there are a lot of different applications our imagined programmer could be developing, with different problems to make easier. Further, there are a lot of different 'tools' our programmer could be leaning upon during development, e.g. a REPL or unit tests or static analysis or intellisense or typed/constrained holes a system might help fill, etc..

So don't assume people haven't taken a programmer's perspective just because they reach very different conclusions. 

[Sean McDirmid]

Rendered HTML is a concrete instance of the underlying HTML code, which can definitely be (and often is) more abstract. Of course, they are both just concrete bits, but the interpretation of the latter into the former and other instances is given because of its abstractness.

 

Machine learning provides a good example of how to go from multiple concrete examples to an abstract solution. Humans do pretty much the same thing (our abstraction hardware works over multiple examples). We need to capture that somehow.

 

> I don't believe this 'perspective' has been neglected nearly so much as you seem to believe it has been. 

 

Lately it has been! When I say “90%”, I have to mostly go back to the 90s and 80s to find work in that 10% that does include a programmer experience perspective. I can definitely point out some papers (e.g. those related to Self), but after the PL community started on its academic/science kick at the end of the century, there hasn’t been much incentive to do such work or write from that perspective. When I read your blog posts, I’m not really getting the context I need to map your language innovations to programmer experience improvements. This is just a suggestion that might help you communicate what you are doing (or even improve the work).

 

[Raoul Duke]

I wish I were rich & could found an institute to fund all this & keep you in the beverages of your choice for life, no matter where you live.

[David Barbour]

On Wed, Dec 16, 2015 at 4:35 PM, Sean McDirmid <smc...@microsoft.com> wrote:

 

Machine learning provides a good example of how to go from multiple concrete examples to an abstract solution. Humans do pretty much the same thing (our abstraction hardware works over multiple examples). We need to capture that somehow.

I agree. 

 

 

> I don't believe this 'perspective' has been neglected nearly so much as you seem to believe it has been. 

 

Lately it has been! When I say “90%”, I have to mostly go back to the 90s and 80s to find work in that 10% that does include a programmer experience perspective.

I think your '90%' argument was entirely irrelevant. 

For a given programming paradigm, there is no need to re-hash the 'programmer perspective' arguments in every paper. With OOP, you'd get many of these arguments from papers written twenty to thirty years ago. But this doesn't mean a paper oriented around enhancing OOP in some minor way (performance, C++ 'concepts', etc.) is somehow ignoring the programmer's experience. It's just assuming the experience you want is pretty close to what you have.

Any programming paradigm is all about 'programmer perspective' - a set of assumptions, a way of thinking and solving, etc.. If you want more recent papers on programmer's perspective, simply look for more recent paradigms, or old paradigms that have been revived in some niche or another and needed the elevator pitch.

And then there are programming tools - specific languages built around a paradigm, IDEs, projectional editors and live programming environments. Sometimes domain specific (e.g. for developing multi-media systems). There are plenty of papers written about these and their 'programmer perspective' motivations. They just rarely have the flavor to make it into academic journals.

When I read your blog posts, I’m not really getting the context 

I usually try to provide context via hyperlinks in the first couple paragraphs. I have no desire to re-hash context in every post. But maybe I'll try to develop some nice summary posts for clearer context.

map your language innovations to programmer experience improvements

Your choice of words 'innovations' and 'improvements' connote a small change to an existing model. I have no idea what that model would be for Awelon project. The closest projects I've encountered - Eve, Unison, Tunes OS, OVAL - are or were more or less designing entirely new programmer experiences.

[Sean McDirmid]

> For a given programming paradigm, there is no need to re-hash the 'programmer perspective' arguments in every paper. With OOP, you'd get many of these arguments from papers written twenty to thirty years ago. But this doesn't mean a paper oriented around enhancing OOP in some minor way (performance, C++ 'concepts', etc.) is somehow ignoring the programmer's experience. It's just assuming the experience you want is pretty close to what you have.

 

I guess this is where we’ve fallen off the tracks. We have made so many assumptions about what is good that we no longer reconsider it? I guess you are ok if you are communicating with a group of people that share your values, background, and assumptions, but then when we are trying to change programming in drastic ways, we don’t really have the benefits of such groups, and relying on those groups would anyways just lead to more of the same incrementalism. And anyways, we should be constantly challenging the usefulness of FP, OOP, and so on! OOP is a good example of a paradigm that needs a reboot through challenged thinking.

 

> And then there are programming tools - specific languages built around a paradigm, IDEs, projectional editors and live programming environments. Sometimes domain specific (e.g. for developing multi-media systems). There are plenty of papers written about these and their 'programmer perspective' motivations. They just rarely have the flavor to make it into academic journals.

 

Again, PL academia is a club that you either fit into or not. It encourages incremental research by its heavy reliance on unjustified programmer experience assumptions. If you want to leave those assumptions behind, you simply won’t fit. 

 

> I usually try to provide context via hyperlinks in the first couple paragraphs. I have no desire to re-hash context in every post. But maybe I'll try to develop some nice summary posts for clearer context.

 

Treat each post/paper/essay as if it was your first! Every time you write an essay, your thinking has probably migrated away from the last time anyways, and the ongoing “story”  can always be improved.

 

> Your choice of words 'innovations' and 'improvements' connote a small change to an existing model. I have no idea what that model would be for Awelon project. The closest projects I've encountered - Eve, Unison, Tunes OS, OVAL - are or were more or less designing entirely new programmer experiences.

 

If you are focused on designing an experience, both innovation (idea application) and invention (idea generation) are useful (innovate when possible, invent when necessary). Take for example Eve: their goal is to design a decent experience, not randomly invent new concepts (they will invent has they need to, however). So I probably should have instead said:

 

“When I read your blog posts, I’m not really getting the context I need to map your language design to improvements in the programmer experience.”

 

This assumes the experience that you are designing could still be considered as programming J

[David Barbour]

On Wed, Dec 16, 2015 at 6:19 PM, Sean McDirmid <smc...@microsoft.com> wrote:

I guess this is where we’ve fallen off the tracks. We have made so many assumptions about what is good that we no longer reconsider it?

I wouldn't say that. Academics do like to argue about things, challenge old paradigms, introduce new ones. One doesn't need to look hard to find people trying to convince others to 'reconsider' OOP, for example.

The problem is more fundamental, a human foible: you can't learn something until you already almost know it. It is 'mentally taxing' to join in meaningful discussions about an unfamiliar subject or paradigm. It's relatively easy to go find something familiar to discuss or an old axe to grind. Consequently, we tend to re-hash the same arguments over and over (OOP vs FP, static vs dynamic, emacs vs. vim, etc.) and anyone who tries to say, "hey, hey, I've got something new over here" tends to get ignored by both parties.

And most everyone in industry just ignores the nerds until they gain the backing of an 800 pound gorilla (Google, Microsoft, Oracle, Sun, etc.).

 

Treat each post/paper/essay as if it was your first! Every time you write an essay, your thinking has probably migrated away from the last time anyways, and the ongoing “story”  can always be improved.

I agree about the thinking and the potential for improvement. OTOH, that needs to be balanced against both workload and the fact that refining old content and rehashing context can be a distraction, hiding the new content. 

There may be some nice middle ground, e.g. ensuring that the chain of 'context' links is relatively shallow. 

[Sean McDirmid]

Typically what happens is that the older paradigm is challenged by a newer (or just ‘other’) paradigm, but it is just as bad (and doesn’t even replace) the old one. So FP is pushed forward as the new hotness vs. OOP, but in reality, they both are on shaky experiential foundations. What’s more, there is little discussion on what OOP is actually useful for vs. what FP is actually useful for, we only talk about features and attributes at a design free level. If you want to fit in, you gotta join a club, which means drinking the Kool-Aid on one of these positions. You make very few friends if you are “pro-OOP and pro-FP” and/or “anti-OOP and anti-FP.”

 

Ideologies just cloud the ultimate story and goal, and conversations that are premised by ideology are boring and not very useful. And anyways, your language seems to be different enough that such premises are not going to be very useful even if you buy the underlying ideology.

 

 

 

 

 

 

From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of David Barbour
Sent: Thursday, December 17, 2015 9:00 AM
To: pi...@googlegroups.com
Cc: augmented-...@googlegroups.com
Subject: Re: [PiLuD] Whiteboard programming?

 

 

On Wed, Dec 16, 2015 at 6:19 PM, Sean McDirmid <smc...@microsoft.com> wrote:

--

[Raoul Duke]

> the old one. So FP is pushed forward as the new hotness vs. OOP, but in
> reality, they both are on shaky experiential foundations.

I do not outright disagree or anything. :-)

But, I recently had a thought that I wish things were done more with
Pure FP because to me it really pushes us closer to things that are
truly "components" that can be swapped in and out under the same API.
Other things purport to get us that, but there's always so much hidden
state / behaviour that it is hard / impossible to really even mock
them. Yes, people do mock them, but to me it seems like maybe mostly
it only works due to being on the main happy paths or some such.

So whatever the paradigms are, I want them to be paying attention to
how do we really make things that we can most easily & safely change
later, rather than having change be all be on a hope and a prayer, or
require a heckton of tests.

[Sean McDirmid]

I wonder if Parnas has done more harm than good? The primary problem with component reuse is actually known what components exist and can solve your problem. How often are you swapping components in and out under the same API? If state is involved and components are stateless, do changes in state requirements cause changes in component interfaces anyways? Hidden dependencies are bad, but so are overly verbose dependencies that you can't hide even when they aren't that important. Mocking is another area that we should think about. What does it mean to put a system in a runnable testable state from the very beginning? What is the best way to stub in missing functionality? If you change the rules of the game (starting with concrete examples that are generalized), what are the ideal abstractions to support that?

Pure FP promotes composability, but composability in a very technical sense that does not necessarily map to design needs. For example, if you want to compose various procedures that have fairly independent effects, it can be very difficult to "compose" them since everything must be threaded through.

-----Original Message-----
From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of Raoul Duke
Sent: Thursday, December 17, 2015 10:06 AM
To: augmented-programming <augmented-...@googlegroups.com>
Cc: pi...@googlegroups.com
Subject: Re: [PiLuD] Whiteboard programming?

--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.

Visit this group at https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgroups.google.com%2fgroup%2faugmented-programming.&data=01%7c01%7csmcdirm%40064d.mgd.microsoft.com%7cd0c14ef1fd154cfcfd5908d3068697e5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HI6Umd1puHZ8ykHc%2fw0GOdnjfpkSCPNBkuLQY8DctvE%3d
For more options, visit https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgroups.google.com%2fd%2foptout.&data=01%7c01%7csmcdirm%40064d.mgd.microsoft.com%7cd0c14ef1fd154cfcfd5908d3068697e5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sI3%2f%2bODrgZaIKvyuA1ipEvScFa77Mu9fCZ%2bhjL%2fSAC0%3d

[Raoul Duke]

Yes, I am happy to hear about better ways to do this! I think when you
talk about, "changing the rules of the game," that is a great
high-level description of what interests me about your work, or all
the stuff David does, and all the stuff he listed. Better Abstractions
would be very welcome by me (although I might not get much time to use
them since my day jobs probably won't adopt them right away?).

Pure FP is still appealing to me because I really feel like it does
fit what I want. But of course I can only choose from the few things
I've used or understood in life. And of course part of it is that I'm
already starting with bog-standard approaches to programming.

e.g. Given an old networked-messaging stack that must be changed out.
I wish I could run them side-by-side, or kinda more statically safely
swap bits and pieces in and out to test out the new, replacement
stack.

[David Barbour]

On Wed, Dec 16, 2015 at 8:19 PM, Sean McDirmid <smc...@microsoft.com> wrote:

if you want to compose various procedures that have fairly independent effects, it can be very difficult to "compose" them since everything must be threaded through

Composing monads is problematic. But there are other models that allow composition of effects but remain 'flat' like more conventional procedural programming. 

For example, Oleg Kiselyov recently advocates using a single Free monad called Eff with an extensible, open union of distinctly typed requests. http://okmij.org/ftp/Haskell/extensible/ 

For Awelon project, I favor modeling a region of 'shared' state between the program and the system. This shared state is used for effects: an outbox and inbox for messages, a list of published topics and subscriptions, a tuple space or blackboard, etc.. By simply 'yielding' occasionally (with a continuation in our shared state) we give our caller opportunity to perform effects: drain the outbox, inject messages to an inbox, manage subscriptions, etc..

The latter approach is also monadic with extensible effects, but it's a different monad - one favoring asynchronous effects, RESTful APIs, batch processing, concurrency models, and larger sequences of pure code between yields (which is easier on an optimizer or for parallelization).

In any case, we should not assume from Haskell's experience with stacks of monads that procedural effects are fundamentally difficult to compose in FP. It's more that the simpler, more extensible effects models hadn't been invented yet when early Haskell desperately needed an effects model. When searching for an analogy, Ptolmaic cycles come to mind.

[Sean McDirmid]

We should really keep an open mind about this. The procedural implicit imperative model has held on for so long because it is just so easy to get things working from the start (even if it has longer term maintenance costs). The story should come first, then whatever techniques can be used to make that story real can be applied. If it involves monads or a powerful effect system, so be it (of course, techniques have to be developed, but this should also be story driven).

 

So really, this is an example of being abstract or concrete:

 

> This shared state is used for effects: an outbox and inbox for messages, a list of published topics and subscriptions, a tuple space or blackboard, etc.. By simply 'yielding' occasionally (with a continuation in our shared state) we give our caller opportunity to perform effects: drain the outbox, inject messages to an inbox, manage subscriptions, etc..

 

This is a bit more concrete, but is it possible to walk us through a complete concrete example? You don’t even have to have it implemented, I’m just curious about what the experience would feel like in a real situation.

 

From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of David Barbour
Sent: Thursday, December 17, 2015 2:30 PM
To: pi...@googlegroups.com
Cc: augmented-...@googlegroups.com
Subject: Re: [PiLuD] Whiteboard programming?

 

 

 

On Wed, Dec 16, 2015 at 8:19 PM, Sean McDirmid <smc...@microsoft.com> wrote:

--

You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.

Visit this group at https://groups.google.com/group/augmented-programming.
For more options, visit https://groups.google.com/d/optout.

[John Carlson]

A number calculator for number calculations, a string calculator for string calculations, a date calculator to handle date calculations.  A collections calculator to deal with collections. A recorder to record, display, debug and reverse debug calculations in a thread.  A multiway conditional calculator  with (predicate, procedure) tuples.  All these may be archetype or prototype based.  Yes, I have a paper.   The problem is all these calculators were global, but they could be hidden.  There should be some way to scope calculators.

John Carlson

[David Barbour]

On Thu, Dec 17, 2015 at 6:03 PM, Sean McDirmid <smc...@microsoft.com> wrote:

The procedural implicit imperative model has held on for so long because it is just so easy to get things working from the start (even if it has longer term maintenance costs).

I don't believe this is a fundamental quality of procedural. Rather, it's a consequence of our environment - the operating systems and how their APIs are designed. It isn't difficult to design a new set of APIs that would favor a different model. E.g. functional reactive programming is easy to use when mouse and keyboard inputs are represented as signals rather than via polling or stateful callbacks.

 

The story should come first, then whatever techniques can be used to make that story real can be applied.

The story is important, but techniques and the story must co-evolve. We can tune our story to allow the techniques to be more efficient, accessible, transparent. Or we could rephrase this: the moment we insist such properties are part of our story, we may need to adjust other parts of our story.

 

So really, this is an example of being abstract or concrete:

 

> This shared state is used for effects: an outbox and inbox for messages, a list of published topics and subscriptions, a tuple space or blackboard, etc.. By simply 'yielding' occasionally (with a continuation in our shared state) we give our caller opportunity to perform effects: drain the outbox, inject messages to an inbox, manage subscriptions, etc..

 

This is a bit more concrete, but is it possible to walk us through a complete concrete example? You don’t even have to have it implemented, I’m just curious about what the experience would feel like in a real situation.

The primary experience is very much like procedural programming. If we were modeling a simple console app, our overall state might consist of:

• a queue of input strings on stdin
  
• a queue of output strings for stdout
• a queue of output strings for stderr
• an optional continuation
• private scratch space (stack, etc.)

Our application would process some input, push some output, then yield to our caller. Our caller, which models 'the system', would process some of the output, maybe inject some input, then continue. If our caller is interacting with other such processes, we could move queues around as a sort of shell pipeline model. 

The input and output could instead be a queue of messages for an actors system, or a set of subscriptions and publications for a pub/sub system, or a set of HTTP tasks, or turtle graphics, etc.. Even something application specific is okay, and easy enough to later wrap in a more generic model. The details aren't especially relevant. 

What matters is that we have opportunity for fine-grained IO, but also an opportunity to control when we interact with the system, or control which elements of our shared state are exposed to a subprogram, etc.. These properties greatly simplify reasoning about concurrency and security compared to 'shared state' in imperative languages. Further, the resulting application is easier to adapt, reuse, test, debug because it isn't binding to opaque external resources.

I had a recent discussion of similar nature on LtU that might help clarify the above points: http://lambda-the-ultimate.org/node/5287#comment-90974

Aside: Sharing a bunch of state like this might not be a nice fit for every programming language. It's a good fit for Awelon project because the languages I use are already concatenative, like Forth or Joy where the default is to pass the entire stack as the only input and return value for every word. I support 'yielding' through a simple bit of syntactic sugar.