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

[Vlad Dumitrescu]

Hi Joe and all,

On Thu, Apr 28, 2016 at 10:53 PM, Joe Armstrong <erlang@REDACTED> wrote:

> To me systems should be made of black boxes that communicate through
> well-specified protocols - so the top level description would tell me
> how the boxes were connected together and describe the protocols
> at a high level of abstraction.
>

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.


> A big problem with code is that we throw away the design documents
> necessary to write the code - and don't say what specifications the code
> fulfills.
>

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.

> My *belief* is that if this structure were made explicit,
> > perhaps by textual structure, perhaps by annotations, perhaps
> > by some graphical form (but probably derived from annotations),
> > it would be easier to understand medium-sized wodges of code.
>
> I'm beginning to wonder if the problem is with editors - I use
> emacs erlang mode which has no help for structuring and organising
> files.
>
> For writing text and lectures I use emacs org-mode with wiki like links.
>
> Hierarchical structure (in org mode) is really easy to see and change
> and with wiki links is pretty powerful.
>
> I'm beginning to think that a wiki style of programming might work.
>
> In a wiki if you click on a link and no page exists you are prompted
> to write some text - we could make a similar thing to develop
> programs.
>
...

> Another idea I had was "monkey patching done right"
>
> The problem is this:
>
>     What I'm writing a module "a" I think
>     "I wish module z exported foo, and I wish file.erl exported boo
>
> Now I don't want to have to stop what I'm doing in a and add something
>  to z (since then I'll get distracted and mess around with z) - and
> goodness
> changing file.erl is really difficult - I'll have to argue blue in the
> face and write
> an eep - just think about adding something to lists.erl
>

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

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.

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  (https://en.wikipedia.org/wiki/Task-focused_interface), hiding
aspects that are currently irrelevant. CodeBubbles (
http://cs.brown.edu/~spr/codebubbles/) tries a non-linear editing
experience where you can see dependencies explicitly.

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160429/c8a70c77/attachment.htm>