On Tue, Aug 13, 2013 at 11:22 PM, alex <alex_at_lurk.org> wrote:
>
> > The end goal is a program that is 'on target'. Only the
> > final program matters; getting there is largely a question of efficiency.
>
> As you say it's a learning and exploratory experience, and so it is
> not just a question of efficiency, towards a fixed or idealised goal.
>
You seem to be implying that "learning and exploratory experience" is not
valued for efficiency reasons.
As it happens, efficient refinement of software requirements is a big
concern in real development.
I think live coding/programming is an opportunity to drop
entrenched thinking in software engineering, and open things up for
> new kinds of programmers and find new motivations for programming.
>
I agree. Though, there are many different of opportunities to "drop
entrenched thinking". The people in the trenches seem reluctant to poke
their heads up and look for them.
>
> > With 'live coding' the show must go on. There are no take-backs in front
> of
> > an audience. The intermediate outputs matter. The end-state of the code
> does
> > not.
>
> In live coding there may not be an audience beyond the programmer.
>
Right. I suppose you would say a violinist playing in a room by herself is
'playing live'.
When there is, then yes that does change things, but in agile
> programming there could be an audience too, as the client is included
> in the design process.
>
Agile programming isn't live programming. It has a short cycle. Totally
different.
>
> > A live coder is strumming and manipulating that code like an
> > instrument, but generally not developing an independently usable program.
> > Some live coders even delete their code at the end, to make it extra
> super
> > clear that they aren't programming.
>
> Of course we are programming, we are just programming for the moment,
> not for multiple future moments.
It's ridiculous to call it programming without a program to prove it.
You might as well call kendo 'carpentry' because they both involve knocking
on wood.
"Using a command line" is not called "programming" until you start building
a script.
Code is part of your experience - a medium or material - but not part of
your product.
> > Different purposes, different priorities, different concerns, different
> > communities. I feel there is a need to distinguish them.
>
> I agree there are different purposes, priorities and concerns at play,
> but they are intermeshed and interdependent. It would be a shame to
see them considered separately, and I'm sure that would result missed
> opportunities.
>
Many of the technical requirements overlap, and some of those that do not
overlap are also not in conflict. I agree it's worth paying attention to
what the other community is doing. (That's why I'm here.)
>
> There are different but related concerns related to on-line
> programming, which includes the outside world in the live feedback
> loop. Examples of this include live coding in front of an audience,
> live systems programming, live coding in conference presentations,
> live coding with clients, and so on.
>
Yes, those are all relevant. I'd personally like to see rapid prototyping
supported at business meetings. And I'm also interested in on-the-fly
programming (e.g. for smart homes) in augmented reality.
Received on Wed Aug 14 2013 - 08:01:37 BST