Hacker News Reader

> Yeah, that's a terrible tutorial.

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.