[erlang-questions] Ways to get started

[Joe Armstrong]

On Tue, Jul 12, 2011 at 4:58 PM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
> On Mon, Jul 11, 2011 at 22:49, Joe Armstrong <erlang@REDACTED> wrote:
>>
>> Your brain is a zillion times better than the best IDE. programs
>> form in you brain not in an IDE.
>>
>
> Very true. I often sit pondering on a problem. Ride the bike and
> ponder on the problem. Play computer games while the brain ponders on
> the problem unconsciously. Go see Rich Hickey's "Hammock Driven
> Development",
>
> http://blip.tv/clojure/hammock-driven-development-4475586
>
> Then, as soon as the solution to the problem forms in the brain, it is
> often a quick task of 10-15 minutes to write the 50-100 lines of code
> which solves it. The only thing that makes the old guys seem to darn
> effective at producing code is that they cheat. They have done it
> before and they just have to alter small things to make it right. And
> they know what code not to write (Code lines are spent, not produced -
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
> ).
>
> The hard part of programming is to get the right solution. The tools
> you use matter almost nothing as they usually don't help you get the
> right solution.

Yes - at a rough guess

    90% of time = understanding the problem
    10% coding the final version

(in the 90% I'll write lots of code to throw away - no point in having
a revision control system for this bit) - I don't want to keep it

As for the gits etc. I just learn half a dozen commands and stick to them

Time spent of fixing your tools is time not spent on thinking
about the problem.

The most efficient code is the code that is never written -

I throw away (say) 50% of all the code I write. When I was a beginner
I would throw away 75% my goal would be to throw away 0% that would
mean I had though long and hard enough before writing the code
to only write good that was good enough to keep.

(These are only rough figures - I guess I reckon on writing
things two or three times, years ago was  up at six times,
Knuth says everything should be rewritten seven times)



>
> The point in addition is focus. If you have focus on getting a git
> repo on github, focus on configuring and installing rebar, focus on
> getting an IDE - then you are not spending time on understanding
> Erlang.

Yup - also I cannot really understand why people want to
learn specialist tools for the development of things in language X
if such tools cannot be used with language Y.

rebar is great if you understand what it is abstracting, otherwise
useless.

I use emacs, shell scripts, make and xterm for *everything*.
I use this for writing erlang,c,java,javascript,TCL,assembler,bash
scripts, makefiles, html, css, I also make sure that emacs, make etc.
work the same way on OS-X,ubuntu and windows.

In the early 80's I wrote about 150K lines of FORTRAN with
a line editor (full screen editors had not been invented)
all the files were in one directory (the OS didn't have hierarchal
directories) and there was a ten character limit on file names.

There was no revision control system - 10 programmers worked on the same system.

I don't actually believe that modern tools would have made me
significantly more efficient. To circumvent the limitations we invented
ad hock versions of email, revision control, etc. Not fancy things but
they got the job done.

As today most of my time in the 80's was spent understanding the
problem - since this takes 90% of the time providing tool support
in the other 10% is not likely to help productivty.

Programming languages hit directly at the 90% because they are
tools for thought - GIT etc does not help me think. Prolog/Haskell/Erlang
provide ways of thought that are superior to C/C++/Java.

Give me better ways of thinking with bad tools support rather than
bad ways of thinking with good tool support.

I still use printf debugging in all languages.

I think that things like debugging cause compensation mechanisms to
come into place - if language X is very difficult to debug then you
think a little harder before writing the program.

Also true of fancy revision control systems - if I've got one fine,
If not I'll compensate by thinking a little more.

Most programming takes place in my head - tapping the stuff in
is the last part of a long and mostly invisible process.

There should be a name for this development process.

Zen development - no tools - just your brain - all we are doing
in making pleasing patterns of zeros and ones that follow the way
of programming. If we follow the way the programs will please us.

/Joe




> A virtue I learned as a programmer is to keep focus on one
> thing at a time. Whenever you are on a task and another thing you
> should do pops up, write it down somewhere and ignore it for now. Our
> brains, when we work, are not multi-core machines.
>
> You can always go back and add a build system when the code you are
> writing gets too big to handle as separate compiles. You can always
> add Version Control later. Programs are like seeds. They are planted
> and then they grow under nurture and care. Don't plan for the Giant
> Sequoia when all you have is a sapling.
>
> --
> J.
>