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."
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.
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.
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.
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).
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.
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).
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.
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?
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.
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.
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.
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'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".
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.)
Some make features are perhaps a bit obscure, but the basic structure of:
output.file: input.1 input.2
build_it input.* -o output.file
"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.
"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.
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).
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.)
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.
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.
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:
start() -> "hello world".
<?php echo "hello world";
(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:
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).
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.
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).
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.
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.
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.
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.
To me, at least, this gives a real feel for the language in something more involved than either fibonacci, or hello-
Oh yes, emphatically agree to emacs and the shell thing. No distractions, while learning the core of a language...
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.
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.
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.
print "Hello World"
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.
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.
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.
Hey boys, poor content for HN, the only valid point is who is the author of the post.