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

[Vlad Dumitrescu]

Hi,

On Mon, May 2, 2016 at 2:28 AM, Richard A. O'Keefe <ok@REDACTED>
wrote:

> On 29/04/16 7:47 PM, Vlad Dumitrescu wrote:
>
>>
>> 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/ <
>> http://cs.brown.edu/%7Espr/codebubbles/>) tries a non-linear editing
>> experience where you can see dependencies explicitly.
>>
>
> I had a fairly brief look at CodeBubbles.  The set-up guide calls it
> "alpha" and "version 0.50"
> and has a copyright date of 2010.  The codebubbles Wiki doesn't seem to
> have been updated
> for quite a few years.  It may be that CodeBubbles itself is more up to
> date, but
> it's a bit worrying when the documentation isn't.  I am deeply unhappy
> about anything that
> requires Eclipse.  I have no trouble with Xcode or NetBeans, but find
> trying to get even Hello
> World going dauntingly complex in Eclipse.  I also read through the
> tutorial, and saw very little
> that I wasn't already familiar with in Smalltalk.  The tutorial says that
> it shows relationships
> "between BUBBLES" and refers to "CALLS".
>
> For what it's worth, Smalltalk is precisely where my "why can't I see the
> structure" journey
> started and what the annotations I've been working on were developed for.
> Let's face it,
> an IDE cannot display information it has not been told about.
>
> Can you explain what relationships CodeBubbles displays?
>

I haven't been using CodeBubbles, only looked at it when it was "young". I
took it as an example of what could be done (a different way to look at the
code than simple text), not necessarily an example of how it should be
done. If I was more familiar with Smalltalk, I would have used it as an
example too.

Regarding Eclipse, it is a huge beast and IMHO most of the complexity and
issues are because it has fallen victim to its own success - with a huge
third-party ecosystem, one can't discard old APIs and improve them in
non-backward compatible ways. This is a reason why I am moving (slowly, but
leisurely, as a friend of mine would say) the implementation core parts of
erlide from Java to Erlang, with the goal of being able to provide
interesting information about a code base that any IDE or editor could use.
The challenging part is that this information has to be available even for
incomplete or invalid code, as well as for code containing preprocessor
directives.

Tools can help in many ways, I think a big problem is that every other
coder would like a different kind of support :-) If there is not enough
user pressure behind a tool/feature, then it will wither and eventually die.

>  Let's face it, an IDE cannot display information it has not been told
about.

Yes, it can (depending on how one understands "told about"). Consider xref
-- one doesn't explicitly annotate the code, the information is there and
is gathered by the tool. Finding unused functions is otherwise quite
tedious. Similar gathering of relevant information from non-local places in
the code are helpful for example for showing documentation or type specs
while one is typing. It's possible to even scan for all spawn calls and
draw a diagram of the processes in an application. Going the other way
around, an IDE can make usage of tools easier - for example when starting
to type a function spec, it can run typer in the background and suggest a
reasonable starting point. And so on. All these small things can add up to
a lot.

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