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

[Joe Armstrong]

I was thinking. There is another problem, which is not addressed.

We just publish final code - but not the process involved to get to the code.

Reading completed code does not answer the question "how did the author
get to the point where they wrote the code" - the mistakes we made along the
path and the lessons learned are not recorded.

When I teach programming I always make loads of mistakes. Sometimes
I see a mistake coming, which if I were programming at home I would correct
"in my head" and type in the correct version - so even if you recorded
my keystrokes you would not see what was going on "in my head".

Now since *most* programming does go on "in my head" before I even
get to type the program in, you won't learn much by watching me.

When I teach - I tell people what this internal dialogue is and make
the mistakes - so they can learn.

I think programming is a craft - and like all crafts has to be learned from
a good teacher.

I "know" a good program when I see one - but I have great difficulty putting
into words *why* it's good.

I still find pencil and paper, whiteboards, and writing down in clear English
what I'm trying to solve superior to any fancy software. Google is great
for searching for solutions to problems "once you know which problem
you want to solve"

Programming takes a long time to get good at - I've been doing it for
47 years and am still learning - this is because learning to program
is actually learning to think and different programming languages and
programming styles are really different ways of thinking.

After about 35 years of programming I found that most programming
moved "into my head" so it was better to think about what would happen
than to type in the program and see.

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.

Robert: What problem are you solving?
Joe:      Bla bla bla
Robert: That's not the problem, that's the solution.
             What was the problem?
Joe:      Ummm, Dunno

Clearly writing down what you problem is before solving it would be great.

Unfortunately I only ever have a clear description of my problem at the
very end when the problem is solved.

Chicken or egg first?

/Joe



On Mon, May 2, 2016 at 10:57 AM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
>
> On Mon, May 2, 2016 at 10:37 AM, Vance Shipley <vances@REDACTED> wrote:
>>
>> I have long had an interest in visualizing code and a dream of a visual
>> development environment. I've pretty much concluded that a "visual
>> programming language" is a pipe dream for all but trivial use cases however
>> graphical modeling is obvious.
>
> The thing that I found to be most difficult to handle with graphical tools
> is that if automatic layout is not good enough, then storing the layout is
> making it very difficult to handle merges and rebases. At my current job, we
> just switched from a graphical modeling tool (for UML-like state machines)
> to a text-based representation and rendering with GraphViz.
>
>
>>
>> On May 2, 2016 1:22 PM, "Vlad Dumitrescu" <vladdu55@REDACTED> wrote:
>>
>> > Going the other way around, an IDE can make usage of tools easier -
>>
>> I had always wanted to finish that project by going the other way,
>> starting with a graphical editor (e.g. dotty(*)) to create the model of a
>> communicating finite state machine in a graphviz file (foo_fsm.dot) with
>> annotations.  Feed that through a utility which created a template gen_fsm
>> behaviour callback module (foo_fsm.erl) with annotations so that it could be
>> read back into .dot for further graphical editing.
>>
>> Another, more generally useful, IDE utility I have always planned is a
>> graphical editor for supervision hierarchies.  I would love to start new
>> Erlang applications on a canvas with a palette of application master,
>> supervisor and worker.  Drag and drop the supervisors, connect them with
>> lines to their children, annotate with the child specifications and init
>> arguments and save it as a template application ready to call
>> application:start(foo).
>
> A graphical interface is not the only way to improve this kind of editing.
> It can be done with a tree view and a form-like interface. Eclipse has for
> example editors for its configuration files that look like the picture here
> https://dl.dropboxusercontent.com/u/2517505/editor1.png, which is arguably
> nicer than having to plow through 3-4 files with different formats among
> which XML is the worst.
>
>>
>> These aren't terribly difficult projects, trivial really compared to what
>> ROK is talking about, but yet (AFAIK) they don't exist.  If one was to
>> contemplate doing such a thing I understand that Eclipse has a Graphical
>> Editing Framework (GEF) which may form a good foundation for the graphical
>> editor.  Maybe I'll get around to it someday however it's been on my todo
>> list for 15 years now and yet I still use vim as my "IDE".
>
> Yes, GEF is cool, but it has a quite steep learning curve (which might be
> added to the steep curve of learning Eclipse, and the relatively steep curve
> of learning Java, depending on one's current knowledge).
>
> best regards,
> Vlad
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>