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

[Grzegorz Junka]

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 
> <mailto: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 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/d4b4d2bf/attachment.htm>