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."
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).
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!
I find it boring to just copy the code, so I often tend to introduce small variation: change variable names, change the order of parameters, the order of instructions... that way it's less tedious and I feel I understand better the original code.
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.
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.
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.
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).
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.
"But wouldn't just really-really reading it do the same thing more efficiently."
If it works for you, go nuts. It's a surprisingly rare skill, but I think it exists. Every once in a while I can reach that level (mostly in code reviews; for some reason that makes it easier).
I do this, too, even sometimes writing out code in a notebook. For example, I gained a clearer understanding of recursive algorithms after I "expanded" a few examples by hand.
You type the code in so that you get practice at typing the code in since in order to write code you have to type code in...a lot of it. If you don't then you're only learning 1/2 of writing code.
Another reason is because anyone who's good at coding learned it this way. Anyone who's bad at coding tends to just copy paste. Usually, you should copy what people who are good at something do.
He said it similarly in his book, "Programming is not a spectator sport." It takes forever to read a book this way, but it helps to slow down and get it.
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.
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.
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.
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.
"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!
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".
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.)
OK I'll concede that make on its own in its most basic form isn't all that bad (although it's not hard to make anything look good by comparing it with Ant); it's the autotools toolchain that makes it such a jungle. Which is, strictly speaking, separate from make, and is what I was mostly agitating against.
"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. "
Right, because using vim or emacs is a matter of apt-get and off you go rollseyes . I'm pretty sure the configuration-to-actually using it for productive work ratio for vim and emacs users is way higher than for your average VS or Eclipse user who most of the time wouldn't even know how to configure it.
Relax. I'm not saying I don't think IDEs are useful or that I don't use one myself. The point of TFA is that there's some benefit, especially when learning a language, to just getting down to the business of writing text, compiling, and running it with as little other cognitive load as possible.
"Right, because using vim or emacs is a matter of apt-get and off you go rollseyes "
Uh, yes? Isn't that exactly what was demonstrated in the article? Substitute Notepad or whatever is on hand instead of vim/emacs if you want - what configuration could possibly be needed for producing a text file? Fancy editing features are nice, but again - the point is to just get down to writing code. Maybe your overreaction to the ghastly notion of using vim or emacs belies your assumption that hipster straw men are trying to steal your IDE from you and make you write Rails code in Vim.
Anyway, I'll bet you an upvote you couldn't present a similarly concise example of how to write, compile, and run an Erlang program using an IDE.
Yeah I get riled up too easily the last few weeks, and over absolutely trivial things - I should get some vacation.
Anyway I don't disagree with the notion that starting with a basic setup gives one a deeper insight into the tools. I have C++ noobs call g++ from the command line and then link object files manually. Also I've used vim since 1997 and still do daily, so it's not like I'm unfamiliar with 'plain' text editors. But hardly anybody who does 'real' work with just the editor without configuration - the amount of time spend on vim-users to save a few keystrokes attests to that. The whole reason to use vim or emacs is because they're so configurable.
I don't know about Erlang, but using Visual Studio I can make and run a C++ program without having to touch the keyboard, apart from typing the name of the project. I'm not sure what the amount of keystrokes to run a useless most basic program has to do with how easy it is to learn.
What annoyed me was the tone in TFA belittling the use of IDE's. After some size of a project, IDE's do have added value in exploring API's, structure of the project etc. There's no need to project one's idea that somehow using one or the other is 'morally superior' or makes one 'a better programmer'.
(it's quite ironic that I'm saying this, since for years I was a vim 'advocate', basically meaning to me that I took every opportunity to show people how superior vim was for every task imaginable; even if I had to spend 1/2 day writing a macro in vim's obscure macro language to accomplish a task that could've been done in 10 minutes by hand..I've come around now and I guess that's why I react so strongly now, much like ex-smokers who are often the most obnoxious anti-smoking campaigners).
Ah. Ok, thanks - I totally get where you're coming from now and can definitely relate to your sentiment. The "you must use an IDE" crowd irks me just as much as the "you must use only Vim" one.
Maybe it's an inevitable part of a developer's progression to annoyingly latch onto some tool or another as "the one way", but hopefully we eventually emerge from that phase and have a better perspective on how each tool can be useful in combination with others.
I've been telling anyone who will listen that the world would be a much better place if Vim or Emacs could be embedded as the text editor in your favorite IDE. Use the IDE's refactoring, auto-completion, and workflow features and still have the full power of the editor's text manipulation, macros, and configurability. (To anticipate suggestions, I do believe that jVi in Netbeans is the next best thing to a full-fledged Vim, and love it dearly.)
Re: you last point, I 100% agree. I have tried the basic integration that Vim has with Visual Studio but it's a hack and I never stuck to it.
Then since 2005 or so, whenever it came out, I've been using ViEmu, a Visual Studio plugin that makes the VS text editor work like vim, complete with (parts of) the macro language. It's so awesome I can't help myself but bringing it up every time a topic remotely related to it comes up.
But this wasn't about productive work, just about learning from scratch. In my experience, he's right about starting with a text editor and shell.
Anecdote: a complex toolchain that I have worked with for cross-compiling programs for an ARM development board was easier to set up for the command line - using an IDE just added more steps, more mystery and more problems.
No, it was also about a production setup. The author boasted about how he after 20 or 30 or whatever years of writing software still only used a text editor and make.
And a programming language where of 5 lines of the most simple program only one is really concerned with what the program actually does, is not a suitable beginner's language, or at least is not of particular use to demonstrate the most basic concepts of programming. From the article:
(arguably one would have to add the second command for calling it from the command line to this for a fair comparison; on the other hand the command for starting the Erlang shell wasn't included in the 5 lines either:
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).
> 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.
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.
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.
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).
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.
I prefer Learning Python by Mark Lutz. I've read a ton of programming books, and I can't recall one the didn't recommend typing the exercises by hand, reading the code carefully line-by-line to understand exactly what is going on. Few quality language books say "go ahead and copy and paste the code from the books website, and don't worry about what the code is actually doing."
I have studied some programming in uni and have done some simple programs in C and Matlab, I've done HTML in school on my own, and I have read plenty of articles about some programming ideas.
tl;dr - I know some stuff about programming but I'm not a practicing programmer.
So, your style is excellent for me, because I don't have to read yet another absolute beginner tutorial, and cheat-sheets and reference manuals are way too big to give me any immediate benefit.
That's exactly why wrote it, I wanted people to get an immediate feel for the language and enough of the syntax to begin writing simple programs right away. I'm glad you like it!
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.
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.
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...
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.
"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."
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.
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).
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.
That's not a tutorial. Neither the question, nor his answer was about a tutorial.
> He argues against magic (IDE's, build tools),
Because they are learning impediments most of the times.
> 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.
And as a reasonably experienced programmer, I can understand all of it. Anecdotes don't mean much. But seriously, aren't `module`, `export_all` kind of mnemonics?
That wasn't the point of it though. He was showing how simple it is - you right a simple program, import it in shell, check how it works, repeat. You can pick a decent erlang book and it will tell you the basic axioms.
His point was you don't need loads of tools to learn them - you build on the basic blocks, and introducing git, vim, emacs, eclipse etc is a lot of cognitive overhead.
> 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.
To each its own - I would like to hear from someone who actually programs and is a good programmer. Advises aren't meant to be followed literally - if you find it useful, take it or else drop it.
You've defined magic to the point that there is no non-magical thing. This is not a useful definition. Those are core Erlang components; if those are magic, then in the simple Python program
print "Hello World"
the print statement and the double quotes are "magic" too.
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.
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.
'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'
For the longest time, I was shackled to the notion that programming was an art form that required an early age discovery, much like Olympian athletes requiring life-long training to have a chance at competing(usually.) Since I've overcome that mental obstacle, my late discovery serves more to create drive rather than hindrance, but reading comments like that is still very encouraging.
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?".
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.
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."