
Erlang creator on how to get started and learning to program - stevefink
http://erlang.org/pipermail/erlang-questions/2011-July/059966.html
======
asymptotic
There are several important threads that Joe Armstrong brings up that people
are completely missing.

1) Typing in code directly into a shell necessarily implies you ignore all the
tools and IDEs that many beginners clamour for. In fact, in my experience,
coding into Notepad is a far superior learning experience than using an IDE.
Nothing stands between you and your gaping ignorance, and you're forced to
grapple with all the hideous details without pretty colours or intelligent
auto-completion.

2) Typing in code offers you the chance to _deliberately type it in
incorrectly and see what happens_. This is my favourite method of learning.
Take a known good example, and say "Hmm, if I just do...that...to that line,
what happens?". And then stare at the error output, immerse yourself in it.
Just as with people, there is no better way of learning about a language, a
tool, or an idea than when it is put under stress or unusual circumstances.

3) Tools necessarily abstract away some process, whereas when you're learning
a new concept or idea the last thing you want is to shy away from the details
of a process. This point reminds me of learning about long division in Year 7
at secondary school, and being forced to draw all these long arrows making
clear which digits were going where. My maths teacher explained the rationale
as "You have to go through all the motions, regardless of how silly or tedious
they may seem now. Eventually you'll just naturally drop them to one side and
not need them any more."

------
leftnode
One key point he mentions is actually typing in the examples while you're
reading and understanding what they mean. This is essential when learning a
new language. You simply won't memorize the syntax without doing it (at least
us mere mortals won't, there's always super-programmers who can just get it by
glancing at it once).

~~~
khwang
My friends always wonder why I take the time to type in example code by hand.
I want to know what the code does, not just peace together things arbitrarily!

~~~
kenjackson
How does typing the code help you understand what the code does? Couldn't the
time spent typing actually be used to help understand the code?

~~~
upthedale
The point is that the act of typing it does help understand the code.

I don't know if there's any psychological basis for this, or if anyone else
does this, but personally I jot down loads of notes when learning things and
playing with ideas. However, I rarely read back over them. Instead, just the
act of writing them down is sufficient to stick them in my brain.

I guess the same applies to learning with code samples.

~~~
kenjackson
_The point is that the act of typing it does help understand the code._

I guess it works for some people, but not me. And I've copied a lot of code.
I'm from the generation of kids that would copy hundreds of lines of code from
Compute! magazine. I rarely understood the code as I was typing it. Only after
when I could look at it holistically and tweak it, could I understand it.

~~~
jerf
The primary purpose of typing in modern code is just to make you _slow down_
and really, _really_ read it.

Unfortunately, looking back with hindsight, Compute! et al were not good
places to learn about code because the programs in the back were optimized so
heavily that there was hardly anything to get a grasp on. Especially the
programs that were just a long, long series of DATA statements and a small
stub to load them somewhere, then jump to them. Tweaking them afterwards was
your only hope.

~~~
kenjackson
But wouldn't just really-really reading it do the same thing more efficiently.

I've learned tons from using Firebug. In part because I could start with
prewritten code and tweak, and read, and tweak, and read. If I had to enter
all the code manually into Firebug (no copy and paste), I think I'd have
better muscle memory for typing some of the stuff, but I don't think I'd be a
better developer for it (not that I'm a web dev, but just sayin).

~~~
chc
Most people's brains aren't trained for reading things properly unless it's
with the intent of immediately applying what they read. They can _try really
hard_ to read carefully, but their brains are simply not in the right mode to
absorb the material the same way they would if it were being put to use. It's
hard to even become consciously aware of how poorly you're learning, because
it _feels_ like you're really concentrating.

I've finally gotten to the point where I can tell when my brain isn't learning
like it should, but I still can't just will that mental state away.

------
ukdm
"After 30 years you will get the hang of this and be a good programmer."

I wonder if a genuine beginner reading that line would be put off instantly or
encouraged to find out if it really would take that long?

~~~
mechanical_fish
Given that this sentence occurs immediately after a five-line example of a
working program, the beginner would probably say "but, you just got something
working in five lines! what are you talking about?"

It takes time to learn the truth. I remember when I first read the results of
the various productivity studies cited in McConnell's _Code Complete_ , the
ones which estimate that the typical programmer creates a _handful_ of lines
of bug-free code per day, on average. It seemed like such a stupidly small
number, then. Not so unbelievable now. The _bug-free_ part is harder than it
looks.

~~~
glassx
I think we should take it as "You'll still have plenty of stuff to learn even
after 30 years, just like today." Which is encouraging if you're a learning-
addict like me :)

By the way, I completely agree with him. After years of Eclipse or Visual
Studio, it was refreshing for me going back to basics, firing vim and getting
stuff done without any distractions.

~~~
kenjackson
_After years of Eclipse or Visual Studio, it was refreshing for me going back
to basics, firing vim and getting stuff done without any distractions._

What distracts you? When I'm coding I see the text editor, that's it. But I
guess if it distracts you, then it distracts you. My aunt can't cook with the
radio on, because it distracts her. To me it adds to the experience, but I
guess to each their own.

~~~
ldh
Personally I think the text editors in all IDEs I've tried are awful anyway.
Plus IDEs are sometimes fiddly to get set up right for a given language; it's
easy to sink way too much time into getting things set up when you could just
be writing working code. Also, it's probably helpful to learn a new language
without the instant crutch of auto-completion features.

~~~
roel_v
"Also, it's probably helpful to learn a new language without the instant
crutch of auto-completion features."

How is that? Why is poring over the API docs of a library to find out if you
need GetSize(), get_count() or Count() better than having the computer look it
up for you while you're typing? Auto-complete doesn't help in learning a
language, only in using an API - and at that it's _good_.

I guess I'm being all Statler and Waldorf here, but the hipster 'look at me I
only need a text editor' is bullshit. In the OP the author boasts about using
makefiles FFS! If there is one over-'engineered', obscure, bandaid-over-
bandaid 'solution' for problems that only exist because of historical cruft
and that is inscrutable to beginners, it's make!

~~~
ldh
_I guess I'm being all Statler and Waldorf here, but the hipster 'look at me I
only need a text editor' is bullshit._

I'll grant you that it's been a fairly annoying meme over the last year or
two, but people are being productive every day using text editors and they
probably don't care whether you think it's bullshit or not. Be productive and
use what you like. Since you have such a strong reaction to it I'd love to
know why you think it's "bullshit".

~~~
roel_v
Of course, I use vim every day too. I also use Visual Studio every day, and
the things for which I use Visual Studio would take me 3 times as long if I
had to do that with vim - and vice versa.

It's a good thing too that most people don't pay too much attention to what I
think, it would have a rather devastating effect on the world I'm afraid.

(what I think is bullshit is the reflex where somebody learns something new
and before reaching the level of competence where one starts finding flaws and
drawbacks of said thing starts advocating it to the rest of the world as the
silver bullet that will solve all problems. I recognize the pattern all too
well since I've fallen so often for it myself. It's the exuberance of youth I
guess.)

------
ovidiu
I remember the time I wanted to learn "C++" and bought a Visual C++ book.
There were so many references to MFC and sdk-specific things that it made the
learning process truly frustrating.

This is why I always pick learn-by-example guides when studying a new
programming language and this is why I try to understand the core first.

Erlang is also a great programming language to start programming with because
it's so simple and based on existing mathematical knowledge that many
beginners already have (functions).

~~~
billmcneale
> Erlang is also a great programming language to start programming with
> because it's so simple and based on existing mathematical knowledge that
> many beginners already have (functions).

I strongly disagree with that. Erlang is simple neither in semantics nor in
syntax (good luck putting your . and ; in the right place when you are
learning).

The tools are also extremely poor, starting with the compiler's own error
messages. This is the last place you want to confuse beginners if you want
them to have fun learning a language.

~~~
ovidiu
The compiler messages are reasonable. It's inconvenient that errors are
reported per function and not per line, but if you write short functions, and
you should, the messages are just fine.

You're clearly exaggerating when stating that Erlang has "extremely poor"
tools without giving any serious arguments.

~~~
slowpoke
>but if you write short functions

Yeah, you should do that. You know that though because (I assume) you are a
veteran programmer - or at least not a newbie, to whom this might not be as
obvious as it is to you and me. Don't forget we are talking about people
_learning_ to program here.

------
malkia
Reminds of this - Peter Norvig's - "Teach Yourself Programming in Ten Years"
<http://norvig.com/21-days.html> -

Nowadays I setup cygwin, have cl.exe in my PATH (too bad the 64-bit bit
version is separated). Have the WindowsDDK installed (liked it better than
Windows SDK, as it allows me to compile for old systems)

Same for Linux (arm, x86, x64 machines) and OSX. The terminal is always there.

Along with FAR (Windows), Midnight Commander (OSX, linux), emacs (aquamacs on
OSX) and build tools - make mainly, or shell script, batch files.

Now why? Well because I can manage it better this way. XCode4 brings the
things very nice, yet the created project is quite big to control outside.
MSVC same thing, but worse when comes to do multiple settings or dependencies.

Still... for a big company, studio - MSVC is the easiest for most people (I
wish otherwise).

~~~
paganel
Hooray for Midnight Commander, I thought I was the only one still using it :)

~~~
malkia
And if you ever happen to use Windows, please take a look at FAR Commander
(from the guy that created RAR). It's also open sourced.

------
econgeeker
Joe Armstrong (one of the erlang creators) wrote a book for Pragmatic
Programmers. This is the book I used to learn erlang. It was quite an
interesting ride, and I think it is an excellent book for learning the
language.

I think erlang is a really fantastic language, and the only language that I
personally trust for concurrency. It is battle tested, and once you spend a
couple weeks learning the syntax, quite a delight to develop in.

------
jbp
That's the approach Zed's LPTHW (<http://learnpythonthehardway.org/>) takes.

~~~
StavrosK
It's more like <http://www.korokithakis.net/tutorials/python/> (full
disclosure: I wrote it).

~~~
jbp
Your tutorial works for some one already familiar with programming but not
with Python. It may work for the originator of that thread.

But LPTHW is more along the lines of Joe's advice: >> Then buy a decent book
and type in the programs by hand. >> One at a time thinking as you go.

LPTHW does exactly that. Actually typing the programs has magic to it.

~~~
StavrosK
Ah, yes, I didn't consider that. You are correct in that aspect.

------
nivertech
It's important to be as "close to the metal" as possible, _when you learning_.
But once you understand the basics - find and use tools. For example, if you
Erlang/OTP programmer in the open-source environment - you need to know rebar
PERIOD.

~~~
kennywinker
One point of view. I learned from the top-down. I learned to pour concrete
over rebar before I learned to build frames and rebar.

It's working for me so far. I still don't know lots of low level things that I
use every day, but that doesn't stop me from using them. And the unknown is
shrinking, too.

~~~
defen
Rebar in this case is actually an erlang program for automating builds :-)

------
signa11
Another thing that I have found useful, is to play with the same toy programs
in different languages. For example once I am a bit familiar with basic
constructs of the language I try out a simple newton-raphson, taylor series
calculation, sieve of eratosthenes, a tftp server (protocol _is_ trivial) etc.

To me, at least, this gives a real feel for the language in something more
involved than either fibonacci, or hello- world.

Oh yes, emphatically agree to emacs and the shell thing. No distractions,
while learning the core of a language...

------
TY
<trolling> Code examples in that message have bugs. This doesn't work:

    
    
      >A=1
    
      >A=2
    

It should be:

    
    
      >A=1.
    
      >A=2.
    

I wonder if the author has much programming experience, particularly in
Erlang. </trolling>

On a serious note, I totally agree with Joe - the best way to learn
programming is by doing it (unless your initials spell EWD) - one step at a
time.

------
the_cat_kittles
A little extreme, but I like the sentiment. Hard to argue that syntax
highlighting is a learning impediment thought.

~~~
kaeluka
he IS using emacs

------
malingo
I'd say in addition to shell, editor, compiler, one should also have a
version-control system handy. After manually working through a handful of
simple examples, a more complex undertaking will be very nonlinear; what
better way to reinforce the learning than to keep track of the enhancements,
improvements and fixes, and reasons for each change?

This falls into the same category as copying examples by hand: being very
deliberate, thinking through and providing rationale for each change you make.

------
mikhailfranco
The 'Zen of Joe' follow-up

[http://erlang.org/pipermail/erlang-
questions/2011-July/05999...](http://erlang.org/pipermail/erlang-
questions/2011-July/059996.html)

    
    
      "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."
    

Mik

------
kidmenot
I agree with most of what Joe has said.

But I love IDEs with features that help me with refactoring. That doesn't seem
to be a dangerous shortcut to me.

Granted, by the time you know what refactoring even means AND you know that
you should do it, you most probably already know a thing or two about
programming, but hey.

------
alexmr
I agree with this. As a newbie, it's easy to get caught up in finding the
perfect tools and waste a lot of cycles with that. I do use textmate because
the syntax highlighting makes it easier for me to read, but anything more
complex than that seems pointless (at least at my stage).

------
kennywinker
Yeah, that's a terrible tutorial.

a) so much magic going on. He argues against magic (IDE's, build tools), and
yet there are about 5 magic commands in 5 lines of code. (module(), compile(),
export_all, ->, c()). As a reasonably experienced programmer who's never seen
erlang code, I ought to be able to infer most of what those operators/function
are doing but I can't.

b) Why would a super smart programmer be the right person to tell me the best
way to start learning to program? I would like to hear from a highly
successful TEACHER of programming.

c) I started with IDE's (HyperCard, RealBasic, and Xcode). Yes he is right
that there is a lot of magic going on you don't understand, but you can slowly
chip away at that all the while making useful things.

All that said, I really liked his comment about "After 30 years you will get
the hang of this and be a good programmer." That's a great attitude. You'll be
a novice for most of your life. Possibly all of it. That's a big part of why I
like programming... there is always more to learn.

~~~
seanwoods
Regarding (a), it depends on what your definition of "magic" is. In this case,
the commands he uses are basic OTP primitives that Erlang programmers will
encounter on a regular basis. IDEs and such create higher level abstractions
that desugar to these primitives.

As soon as you encounter a primitive that the IDE doesn't handle on your
behalf, you're lost.

One thing I would add to Joe's comment is that if you don't know what a
command/function does, look it up. This is really painful in the beginning but
pays off significantly as you hone your skills.

~~~
loverde
It's easy to bash IDEs for their coddling effect, and there are some
legitimate arguments against them.

But looking up documentation is precisely one of the things that IDEs are much
better at then text editors. Hover over some code and up pops the
documentation. Plus you can usually navigate directly to the actual source.

Another example is "includes/requires/imports/pick your language". Typing
those in manually is simply busy work that distracts from the task at hand.

Your other comment is also a strawman: "As soon as you encounter a primitive
that the IDE doesn't handle on your behalf, you're lost." It could easily be
replaced with: "As soon as you encounter a primitive that you don't know how
to enter in your text editor, you're lost."

Don't get me wrong. I agree that some aspects of IDEs, especially "Wizards",
have a significant negative impact on developer understanding. But they also
have powerful positive impacts as well that we shouldn't dismiss so easily.

------
perspective
I'm constantly telling off my friend (an established programmer, just not with
C#) for using Resharper with VS2010. He responds with "But it helps! It's
easier to use!", then asks me "What's the difference between a reference and a
'using' statement?".

------
schiptsov
Yeah, most of amateurs think that they must have Eclipse^Wa typewriter to
write a poetry. ^_^

------
ams6110
I learned C# and ASP.NET this way. Emacs, csc.exe, and Microsoft .NET for
Programmers by Fergal Grimes (Manning). Great book if you like learning
languages this way.

------
humanfromearth
Forget about git? U crazy?

------
nomeatno
There is no meat here. Just use an editor and in 30 years you should be able
to program, don't use tools. That's all.

Hey boys, poor content for HN, the only valid point is who is the author of
the post.

