<div dir="ltr">Hi Joe and all,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 10:53 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">To me systems should be made of black boxes that communicate through<br>
well-specified protocols - so the top level description would tell me<br>
how the boxes were connected together and describe the protocols<br>
at a high level of abstraction.<br></blockquote><div><br></div><div>That's just half the story, right? Somewhere, the system has to do something with those messages and use "normal" sequential programming. So structuring that code is just as important.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A big problem with code is that we throw away the design documents<br>
necessary to write the code - and don't say what specifications the code<br>
fulfills.<span><br></span></blockquote><div> </div><div>There are tools that can process MSCs in textual form (that can be stored alongside the code and referred from it) and the documentation generators can produce graphical representations (Doxygen has support for this, for example). So the tools are there (or can be written), it is mostly a matter of using them. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> My *belief* is that if this structure were made explicit,<br>
> perhaps by textual structure, perhaps by annotations, perhaps<br>
> by some graphical form (but probably derived from annotations),<br>
> it would be easier to understand medium-sized wodges of code.<br>
<br>
</span>I'm beginning to wonder if the problem is with editors - I use<br>
emacs erlang mode which has no help for structuring and organising<br>
files.<br>
<br>
For writing text and lectures I use emacs org-mode with wiki like links.<br>
<br>
Hierarchical structure (in org mode) is really easy to see and change<br>
and with wiki links is pretty powerful.<br>
<br>
I'm beginning to think that a wiki style of programming might work.<br>
<br>
In a wiki if you click on a link and no page exists you are prompted<br>
to write some text - we could make a similar thing to develop<br>
programs.<span><br></span></blockquote><div>...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Another idea I had was "monkey patching done right"<br>
<br>
The problem is this:<br>
<br>
    What I'm writing a module "a" I think<br>
    "I wish module z exported foo, and I wish file.erl exported boo<br>
<br>
Now I don't want to have to stop what I'm doing in a and add something<br>
 to z (since then I'll get distracted and mess around with z) - and goodness<br>
changing file.erl is really difficult - I'll have to argue blue in the<br>
face and write<br>
an eep - just think about adding something to lists.erl<br></blockquote><div> </div><div><div>I have many (more or less wild) similar ideas about how to better support development, but most of them require an IDE and many people want an all-text-and-command-line experience. My belief is that would change once they get a better feeling of the IDE experience, but unfortunately I am a bit stuck with more mundane implementation issues...</div><div><br></div><div>For example, the code editor could be editing a "virtual file" where functions names in the definitions are qualified with a module name. These functions get written and compiled into the respective modules, but are shown together. As I write code, for example calling a function, the referred code is pulled in the editor and if it didn't existed it is created. So we get a dynamic view of the code, relevant to what I'm currently doing.</div></div><div><br></div><div>There are already tools experimenting with such ways of structuring code. For example, Eclipse has Mylyn which can provide a filtered view of the code  (<a href="https://en.wikipedia.org/wiki/Task-focused_interface" target="_blank">https://en.wikipedia.org/wiki/Task-focused_interface</a>), hiding aspects that are currently irrelevant. CodeBubbles (<a href="http://cs.brown.edu/~spr/codebubbles/" target="_blank">http://cs.brown.edu/~spr/codebubbles/</a>) tries a non-linear editing experience where you can see dependencies explicitly.</div><div><br></div><div>best regards,</div><div>Vlad</div><div> </div></div></div></div>