[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?

[Vlad Dumitrescu]

I remembered an interesting method that might be relevant in this
discussion too. It is called the Mikado method and earlier was available as
a free download, but now I see that the autors have published a book
https://mikadomethod.wordpress.com/. The first chapter is available for
reading at
https://manning-content.s3.amazonaws.com/download/3/558b9be-92a7-4ebf-90ba-c7fdd830aea7/MikadoMethod_CH01.pdf

The method is meant mainly for refactoring existing code, but I think it
could work for new code too. The idea is to set a goal and try a naive
implementation. See what errors there are and set fixing them as
prerequisites to the goal. Draw a tree of these prerequisites and how they
depend on each other. The important and unintuitive next step is to revert
all changes to a working state. Only then, choose an unsolved prerequisite
and iterate the process until the initial goal is solved.

There are no discarded branches, but the graph of the things that were
tried and their dependencies is illustrative of the development process and
can be annotated with information about "why"s. Maybe this is a pragmatic
middle ground between keeping everything and keeping only the final branch?

best regards,
Vlad



On Tue, May 3, 2016 at 9:19 AM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:

>
> On Tue, May 3, 2016 at 3:29 AM, Richard A. O'Keefe <ok@REDACTED>
> wrote:
>
>> But there's a reason why twists and turns might need recording.
>> I don't know about you, but more than once I've had the experience that
>> the
>> 'final "right" turn' was actually wrong, and to get working code I've had
>> to go
>> back to something I'd rejected on (what I know see to be) mistaken
>> grounds.
>>
>> Now that doesn't mean everything has to be in the version we give to the
>> compiler.  Keeping (possibly wrongly) discarded stuff is the job of the
>> version
>> control system.
>>
>> And of course an *idea* that is tried in one derivation line and then
>> abandoned
>> may turn out to be very useful for solving a different problem.
>>
>
> This is true and would be useful, but I think I can see a problem (which
> might very well be the reason why it isn't something people already do):
> after a while, there will be literally thousands of discarded stuff. How am
> I supposed to search and find the alternative that works, especially if I
> am now working on a different problem than 6 months ago when the stuff was
> originally written? Is this search faster than starting from scratch? IMHO
> the answer is that what needs to be saved is a higher-level description,
> not a complete brain dump of the process.
>
> There is also a difference between what is interesting for teaching people
> (beginners) and what is interesting for future reference for the team that
> develops the code. These categories need different levels of detail,
> different kind of information.
>
> best regards,
> Vlad
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160503/cf794f84/attachment.htm>