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

[Josh Adams]

I suppose I will contribute a tiny bit too this conversation. Have any of
you looked at unison? http://unisonweb.org/2015-05-07/about.html#post-start

I've built a visual programming language, and while it works and is in
production use for some healthcare purposes, I found a million issues that
made me hate it. Unison strikes me as unbelievably interesting and its
editor looks like what I would want.

It also covers distribution and has the concept of a dht for program
functions which strikes me as awesome. Would love to hear what you good
folks think of it.

Josh
On May 2, 2016 9:20 AM, "Grzegorz Junka" <list1@REDACTED> wrote:

I don't agree that tools help in general, but only in specific tasks.
Dialyzer, Xref, common test, all help in their specific tasks. In
particular, the tools mentioned in this thread would help other developers
to understand some existing code written by someone else. They probably
wouldn't help me to understand my own code better, although they could
probably help me to find more bugs or to help me restructure the code if I
ever needed to.

Before I can start writing a new program I always start with a pen and
paper, away from the computer. Only once I have everything "sorted out" in
my mind, I start coding using Emacs. It's the closest you can get to pen
and paper. I am comfortable using IDEs but I don't tend to use them unless
required by the task at hand (e.g. when doing GUI's or when they are better
supported than command line, e.g. XCode, or Visual Studio).

So, I wouldn't exaggerate the tools, although different people approach
this problem differently. Some people study better reading a book and some
watching video. Some people are better programmers with an IDE and for some
(like me) it's an unnecessary burden (and overload of my brain). Having
said that, the one area when tools are indispensable and should always be
worked on is the automation of daunting and obvious tasks that I, as a
developer, shouldn't have to do. Running tests is one example. Installing
software, keeping backups, renaming function names in multiple files,
intelligently searching for specific code fragments, etc. The more of them
and the more things they can do automatically for me the more time I have
to write code in Emacs.

However, many of those tools seem to be intelligent because they have too
many options. A tool works great when it has few options working 99% of the
time with default values, but can be extended to a great deal when the
extra mile is needed. Many tools, often IDEs, burden users with these
unnecessary options. When I need to rename a function name in all my files
and a tool that could do it for me shows me 100 options, I would rather
prefer to do it manually.

Greg

On 02/05/2016 12:50, Vlad Dumitrescu wrote:


On Mon, May 2, 2016 at 1:56 PM, Joe Armstrong <erlang@REDACTED> wrote:

> Virtually all the code I write is in the form of "micro experiments" -
> since I'm not sure what will happen if I do something. The "big" or
> complete program
> can be written once all the micro-experiments have been done.
>
> When I can't write the code - it is always because I haven't
> understood the problem - this is very frustrating I *think* I've
> understood the problem - yet the fact I can't write the code is a
> clear sign that I have not understood the problem - but I do not yet
> know why.
>
> Loading the problem into my brain, sleeping, more study, playing the piano,
> a glass of wine, stoking the cat usually solves the problem (or not).
>
> IDE's in all their glory help me type the solution to my problem into
> the computer - but they do not help me formulate the correct problem
> in the first place.
>

All true, Joe, we can't know what we don't know and no amount of the
technology we are talking about (i.e. not things that stimulate the brain's
creativity and whatnot) will help with that.

However, helper tools can help us be faster and more flexible when writing
the micro-experiments, which means we can try more of them in the same
amount of time and if we have a slightly higher-level view over them maybe
we can easier see new ways to combine them, that would otherwise get hidden
in the boilerplate code. The tools can also help write a correct final
version, too (even if it is just by eliminating the need to always have to
stop typing and ask "was it keysearch(Key, List) or keysearch(List, Key)?")

Also, most of the developer time is spent not thinking about new stuff, but
reading/understanding/debugging/improving existing code, and here tools can
help a lot by filtering parts irrelevant for the current task, or by
providing a higher-level view of the code, or by making it easy to follow
the execution of the code. There was a time when I could run code in my
head and I got most often correct results, but that's not working any
more...

Anyway, even if they are far from perfect, I think everybody can agree that
tools help. I consider pen and paper as tools too, by the way. I think that
the issue is that everybody has their own thought processes and need tools
that fit those, but we can't create custom tools for every person.

Going back to a more practical discussion and considering I am a tool
developer, I welcome all inputs regarding what kind of tools would help you
(as in, all of you) best. I have already started looking at a prototype for
an editor for an application's supervision structure, as Vance talked
about. I probably won't be able to do everything myself, but it's possible
that many people have tools that they wrote for themselves and use with
success - maybe those can be shared?

best regards,
Vlad



_______________________________________________
erlang-questions mailing
listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160502/c3426f40/attachment.htm>