(In Zed Shaw's conception, this might correspond to "learn computing the hard way".)

I see his examples and other examples here in this discussion, and it makes me wonder about the value (or existence) of a very thorough reference.

I've also encountered this when working with lawyers who wanted to have a reference to cite to courts about very basic facts about computing and the Internet. In some cases, when we looked at the specifications for particular technologies or protocols, they didn't actually assert the facts that the lawyers wanted to cite to, because the authors thought they were obvious. I remember this happening with the BitTorrent spec, for example -- there was something or other that a lawyer wanted to claim about BitTorrent, and Bram didn't specifically say it was true in the BitTorrent spec because no BitTorrent implementer would have had any doubt or confusion about it. It would have been taken for granted by everyone. But the result is that you couldn't say "the BitTorrent spec says that" this is true.

Another example might be "if a field is included in a protocol and neither that layer nor a lower layer is encrypted with a key that you don't know, you can see the contents of the field by sniffing packets on the network segment". It might be challenging to find a citation for this claim!

So we could also wish for a "all our tacit knowledge about computing, programming, and computer networking, made explicit" kind of reference. (I'm not sure what kind of structure for this would be most helpful pedagogically.)

I want to emphasize that while learning abstract functions, and understanding that code syntax is an abstraction for electrons moving through logic gates are fundamental concepts for an early programmer, learning those concepts was less frustrating for me than finding somewhere to write the text I had learned from codecademy. I am a chemist by formal training, I took an extremely abstract multivariable calc course in college that taught me Big and Little O, and functionalized concepts most people learn by rote "drills," and I consider learning new concepts my strongest career skill. I don't mean to humblebrag here, but rather to refute the only-somewhat-popular sentiment I've seen on HN that non-coders "can't get shit done." No. I am a non-coder that does shit. In moving from chemistry to neurobiology and biophysics, there are basic skills that can't be found in a textbook, like _this is a pipette_, and _this is a flask to grow cells_, and if you don't know those things you won't be able to do experiments, and you'll fail the informal subtext of an interview. The best resource I've found in (three years of reading HN anonymously) for analogous tool-teaching in code has been Michael Hartl's book on learning Rails, so thanks again mhartl! The first two chapters of that resource were more treacherous (but ultimately well-guided and successful) than teaching myself d3.js. A true, zero-level, adult beginner's guide to some code---manipulating an excel sheet in Python, writing an API-interacting tweet bot---would be a great boon to people like me.

    I don't know if it's as basic as @schoen wanted
    but it might be close.

Does my memory deceive me?

The term of art here (as used in patent law, for instance) would be "person having ordinary skill in the art". Something like that (if you don't encrypt something in a network protocol, it can be sniffed) is "obvious to a person having ordinary skill in the art".

But yeah, that does make it difficult to cite sources for them. And in particular, it's difficult to throw the book at someone who doesn't take those things as obvious when there's no such book.

Another "obvious" thing that I don't know a citation for: it's impossible to store a piece of information in a binary such that it cannot be read by a person who has a copy of that binary. (Practical corollary: there's no such thing as a piece of information that's too secret to include in an Open Source driver, but that can be included in a binary driver.)

So it would be pretty awesome to have the Book of Tacit Computing Knowledge somewhere.

"In computer science, a library is a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked."

https://en.wikipedia.org/wiki/Library_%28computing%29

After a certain point, you can learn a lot about something by teaching it, because doing so forces you to re-evaluate things which you've internalized and forgotten.

When I was learning C# and was already quite fluent in C/C++. I had a big problem with the C# type system/management. I'd been reading guides that were in the first category the author mentions, eg. "not really a beginner, but new to this language".

I was trying to retrieve the bytes that a certain string represented. I was looking for ages and everywhere everyone mentioned that "this shouldn't be done", "just use the string", etc. A stack overflow answer mentions a way to use an 'encoding' to get the bytes and this seemed to be the only way.

How strange I thought, I just want access to a pointer to that value, why do I have to jump through all these hoops. None of the guides I was reading provided an answer, until I found a _real_ beginners book. This book, helpfully starting at the real beginning of every language: the type system, finally gave me the answer I was looking for:

.net stores/handles all strings by encoding them with a default encoding. It turned out that the whole notion of 'strings are only bytes' that I carried over from C++ does not work in C#. All those other helpful guides gleefully glossed over this, and started right in at lambdas and integration with various core libraries. Instead of focusing at the basics first.

When I learned C# (in 2003?), I learned that String in an array of Char and Char is 16 bit, and that .NET used the same encoding as Windows NT (UTF-16 in native endian).

I knew that both WinNT and Java made the mistake of being designed at a time when people assumed 16 bits are enough and consequently caused the surrogate pairs mess. I knew that Java assumes UTF-16BE and Windows assumes UTF-16LE. I knew what UTF-16 means in C/C++ and how to work with it or transform such data to and from UTF-8 and UCS-4.

When learning a new programming language, I know to look up whether strings are mutable and whether they're sequences of bytes, code units or code points. If they's immutable, I look up how to create a copy instead of a reference when using substring and when they're not bytearrays I look up how real bytearrays are called in this language.

Should early programmers be taught this? Absolutely. At what stage? I don't know. But they must be taught from the start that this has nothing to do with a programming language and everything to do with how data is represented in memory.

I'm always interested in the internals; but it's often surprisingly hard to find information on the internals. There are few books, and you'll often need to read lots of source code and specifications and reverse engineer things to find out how stuff works under the hood.

For someone from a C background, that's not advanced: it's simply what strings are. The whole idea that characters aren't bytes may be very strange to someone who's only ever done C and C++. It's probably just as strange to them as the idea that there's any relationship between bytes and "the characters that make up a piece of text" is to someone entirely new to programming.

In a related anecdote, I was once in a room with 4 C programmers and a Haskell programmer who was trying to write his first C program. The Haskell guy asked "hm ok so how can I compare two functions to see if they're the same?" and after a 20 minute discussion the C guys still couldn't understand why you would possibly want that and the Haskell guy still didn't know how to continue (I was one of the C guys). All had many years of programming experience, but the frames of reference were simply so different.

I think it's smart of Zed to confront people with multiple programming languages from the beginning, so that this kind of issue thing never really becomes a problem.

It's more work in C and C++ (and a lot of other languages) to treat strings correctly, but unless you're talking about a C programmer who's been living under a rock for 20 years, most of them are familiar with the issues around Unicode, UTF-*, etc., and they choose to ignore the issue when they can get away with it. When it's important, there are libraries like iconv and ICU for handling it. C++ even has some character conversion builtin to the locale system, but it's super ugly (which goes without saying, because almost everything in C++ is ugly ;-)

As far as your anecdote goes, I know both C and Haskell, and the question doesn't make any sense to me either. It's provably impossible to compare two functions for equality. Even in Haskell, function types don't derive from the Eq type class, so it wouldn't be possible.

    No instance for (Eq (a0 -> a0)) arising from a use of `=='

The better answer is either "Look at their type signatures" or "See if they evaluate to the same values when given the same input"; the first is trivial, the second won't, in general, terminate, so you need a more nuanced conception of "equality" to apply in this instance. This is non-trivial to come up with.

Kent Pitman has an interesting essay on this problem from a Common Lisp perspective: "The Best of Intentions: EQUAL Rights—and Wrongs—in Lisp"

http://www.nhplace.com/kent/PS/EQUAL.html

"Don't do that" isn't a sufficient answer without explaining exactly why, though. And if you aren't asking the right question, then the explanation might even seem obtuse.

In my experience mentoring new developers, it's much more helpful to ask "what is your goal?" instead of "don't do that."

When I was a kid learning line number BASIC, adults answered my questions knowing that I'd figure out The Right Way before anyone hired me to write the code for radiation treatment devices.

The tech community's obsession with "The Five Why's" is toxic. When asking questions, you always have to first prove that you deserve an answer. It becomes a process of trying to anticipate any potential reason someone might have to argue "You're doing it wrong" - and preempt that. You can't just ask a question: you have to both ask and justify.

Mostly I just don't bother, and I suspect that I'm not alone. And I have a degree and industry experience. It must be incredibly frustrating and discouraging for beginners.

A why can reduce the amount of code written by 100%.

Like, in Java, for a long time I didn't know there was an output stream that you could write a string directly, so I was always getting the bytes to write it. I wouldn't call that a formative experience.

This ties into another of my pet-peeves: people who answer my "how do I do this" question with "don't do that". Quite often I have very good reason for wanting to do that (getting around another bug, esoteric requirements, etc). Whenever I answer a question, I'll first tell them exactly how to do what they're asking for, and THEN explain why doing that is usually a bad idea, and THEN show some alternatives that will probably do what they want.

http://4.bp.blogspot.com/-KzOtz-8coJU/Uga2fN7SNmI/AAAAAAAAKI...

> > I was trying to retrieve the bytes that a certain string represented.

Blind links aren't polite. :)

Yesterday I was talking to a student who had taken the university's first-year CS course, which is in Java...she complained about how missing just one punctuation mark meant the whole program would fail...While I can't passionately advocate for the use of Java in first-year courses (too much boilerplate, and the OOP part is generally just hand-waved-away)...I've realized that the exactness of code must be emphasized to beginners. And not just as something to live with, but something to (eventually) cherish (for intermediate coders, this manifests itself in the realization that dynamic languages pay a price for their flexibility over statically-typed languages).

Is it a pain in the ass that missing a closing quotation mark will cause your program to outright crash, at best, or silently and inexplicably carry on, at worst? Sure. But it's not illogical. Computers are dumb. The explicitness of code is the compromise we humans make to translate our intellectual desire to deterministic, wide-scale operations. It cannot be overemphasized how dumb computers are, especially if you're going to be dealing with them at the programmatic level...and this is an inextricable facet of working with them. It's also an advantage...predictable and deterministic is better than fuzziness, when it comes down to doing things exactly right, in an automated fashion.

I think grokking the exactness of code will provide insight to the human condition. While using the wrong word in a program will cause it to fail...we perceive human communication as being much more forgiving with not-quite-right phrasing and word choices? But is that true? How do you know, really? How many times have you done something, like forget to say "Please", and the other person silently regards you as an asshole...and your perception is that the transaction went just fine? Or what if you say the right thing but your body (or attire) says another? Fuzziness in human communication is fun and exciting, but I wouldn't say that it's ultimately more forgiving than human-to-computer communication. At least with the latter, you have a chance to audit it at the most granular level...and this ability to debug is also inherent to the practice of coding, and a direct consequence of the structure of programming languages.

Bring in a few loaves of bread, jars of peanut butter, and jars of jelly, with a few utensils. Also, lots of paper napkins.

Have the students spend 10-15 minutes writing a 'how to make PB&J sandwiches'. Select volunteers to read their instructions while you follow them as a computer would. Explain that this is how computers work.

Get some bread: grabs entire loaf of bread, uses the entire loaf for following instructions.

Open the loaf of bread: Rips open the entire package.

Open the jar of peanut butter: Fails to rip the lid off.

Spread peanut butter onto bread: Grab a big handful of peanut butter and spread it messily over the bread.

You can demonstrate how a more flexible language allows you to not just stop and crash (ie. Unknown command 'open peanut butter') but can result in far worse results.

You can even get into the different levels of languages by showing the difference between a motion by motion (assembly) instructions vs. one which assumes general sandwhich knowledge (C/C++/etc).

And people get them wrong.

This didn't really strike me until I started using Linux, even though I had originally learned on command line based computers. The same instructions for Linux users are a few lines that you enter into a terminal. I've even noticed a trend towards documenting Windows operations via a series of commands entered into the DOS box.

The problem there is that if you want to get anything original done, you're gonna need to start getting to that low level where the abstraction isn't there. We sort of side-step this in education by starting with heavily abstracted systems like greenfoot, where you ONLY say what you 'want to happen', like 'object should move left'. Once students raised on those systems start to encounter real problems, they falter, because they've never had to cope with the computers stupidity before.

OA refers to more experienced programmers forgetting that they typed programs from computer magazines and soaked up the basics that way - that is a specific point in history wasn't it, the early 1980s with BASIC listings to type and try to save on the cassette. I'm older and did BASIC exercises line by line on a teletype connected via an accoustic coupler and a modem (19" rack with dial on the front) to a remote mainframe. And yes, we got line noise sometimes. And we learned about the need for exactness.

Have we reached a point in history where the machines are so shiny there is no way in? Should we give people recycled laptops with a command line linux install and suggest that they have to assemble their own UI out of bits and pieces of old school window managers? A prize for the most way out desktop?

And yet so much code has so many bugs, defects and errors in it. If writing code was as mechanical and deterministic as you think it is (and should be?), then why does so much production code suck?

In other words, production code can suck because you've failed to anticipate all the non-deterministic things that may interact with your system. Or you may have poorly anticipated them...which can manifest itself in the form of bloated, overly cautious or overly permissable code that becomes too hard to reason with or debug.

But this is moving far away from the original topic of why beginning coders have such problems...sure, when they start working on production code and have to deal with the complexities of the real world, they'll have to adapt. But before they get there, they have to have faith -- at first -- then the ability to confidently reason about code, step by step, in the same way that (hopefully) they've done with math equations...I'm pretty patient when teaching most beginners...but one thing that still sets me off is when someone says, "Well, the code worked 5 minutes ago, and now it doesn't"...and instead of actually thinking through the reasons why that might be (and the reasons could be quite complex, to be honest)...they just accept that as something that just happens with programming. Or even worse, start pasting in random code that worked somewhere else...which literally makes as much sense as adding random digits to an equation to get it to "work".

For example, for beginners, it is not immediately evident that the two following code snippets are equivalent:

    a = "Hello world"
    b = a.lower()
    print(b)

    print("Hello world".lower())

Code has bugs because people don't think like computers.

The way I would explain it is to have them take a imagine writing a code tokenizer and interpreter of a simple language themselves. That's what the intro CS class I took at Berkeley, 61A, had us code with a subset of Lisp, with a lot of help, of course. I don't think we needed to know how to use anything but strings, functions, and arrays, although it did involve recursion. This problem will never be broached again once they realize there's code reading their code. Of course it's arbitrary.

(project, in case you're curious: http://www-inst.eecs.berkeley.edu/~cs61a/fa14/proj/scheme/)

> The way I would explain it is to have them take a imagine writing a code tokenizer and interpreter of a simple language themselves.

For instance, the OP had a part about how a beginner doesn't know that `|` is called "pipe". It follows pretty logically that they are significantly less likely to know what a tokenizer or interpreter is, let alone be able to imagine writing one. Your intro CS class at Berkeley where you did this stuff in Lisp was catering to (in the OP's parlance) early programmers, not beginner programmers.

The whole point is that there's a difference between people who know nothing and people who know things but need practice applying them. There are lots and lots of people who don't know anything about programming, whether you think it's ridiculous or not.

I guess YMMV...but most beginners I've worked with are confounded by why code interpreters are so literal. The double-equals sign versus an equals sign is one prominent example...it's not that they can't understand why rules exist...but they seem to think the negative consequences (complete program failure) seem to outweigh the tininess of the error.

After dealing with `=` vs `==` errors in beginners' code...something that I almost never screw up on my own as a coder...I've begun to respect the convention in R to use `<-` as the assignment operator...

I can relate. I remember when I first started programming (a little less than a year ago) I spent 2 hours trying to debug a simple function which was working fine in my IDE as I stepped through it but was failing a unit test provided by my class on R. It turns out that the instructor never explained the concept of ending functions with return statements before giving the assignment. I vividly remember screaming something along the lines of "why the fuck can't it just understand what I'm trying to do".

> I don't think we needed to know how to use anything but strings, functions, and arrays

Strings, functions and arrays comprise a huge amount of information. Many C programs of rather frightening complexity and functionality could be written with just those primitives.

When we think of a beginner, we have to imagine that they have the computer science knowledge of a child. Would you ask a child about strings and functions?

It was Q-BASIC, in about 1998. I made a top-down space shooter where you fly a ship, and meteors and other objects come down the screen and you shoot them.

Somehow, I had missed or glossed over the part of my self teaching that included arrays. I didn't know what that was. My program was written with variables like $ax1, $ax2, etc (asteroid X position 1), and collision detection was a big pyramid of "if $ax1 > $ax2 AND $ax1 < $ax2 + $awidth ...".

I was always wondering how someone would write a program where there was some configurable number of things on the screen? What if I wanted to crank up the difficulty and have 20 simultaneous things moving!?

So yeah, you can get a lot done with some really basic stuff.

@sanderjd, you may think I'm exhibiting what the article was talking about, but I'd like to know if you have any other qualms besides using the terms tokenizer and interpreter. +@kevinschumacher. Obviously I'm not going to just tell them "ok now let's write a tokenizer and interpreter." The beginners I know know what (non-programming) tokens are and I'm sure they would be 100% comfortable with an explanation. Same thing with an interpreter - they're using the god-damned thing from the start, if they start with anything other than C or Java.

@danso, @Thriptic - I think I know what's happening. You're confounding frustration with confusion. I guess I shouldn't have wasted my time. Every beginner programmer, especially, but hell, even an experienced programmer (! think about this - of course we do), gets frustrated with the character-by-character exactness of programming sometimes. That doesn't mean they don't understand or think it's totally unreasonable. Very different.

Thanks guys for explaining the downvotes. Let me end by reiterating something I've said a few times now since the beginning - this is based on beginners I know. I.e., my bio and econ-major friends taking the same 61A class I did. I'd like to know, @sanderjd, whether you have some extra information about the class that I don't? Because I took the class 3 years ago and I know at least half the students are beginners. This is the first class people learning how to program seriously take. I don't know what else I need to say to convince you.

@danso the reason why I'm spending so much time on this is because I'm a student teacher thinking about going into programming education as well. I think it's very important to make the distinction between confusion and frustration. Otherwise, your efforts may be futilely spent on explanation when all they want is to get things working. If they're getting confused on things like "=" vs "==" or why that missing semicolon annoys the compiler, don't go back and explain that the interpreter is this thing with very strict constraints and everything you type matters. That's not the point. Explain what's wrong, why, and how to fix it!!! "Oh, in this language, we terminate lines with semicolons except blocks like if's and loops," "= is for assignment and == is for comparison." They'll get better with practice.

Otherwise, your efforts may be futilely spent on explanation when all they want is to get things working.

Now this attitude is fine in a work environment, or many other places. But this is death for learning. Learning is not about getting things to work, it is about understanding why things work, so you can apply that understanding elsewhere, to unrelated fields even.

So, for example, I do agree with you when you say: don't go back and explain that the interpreter is this thing with very strict constraints and everything you type matters But I disagree with what you say next: That's not the point. Explain what's wrong, why, and how to fix it!!!

What would be better, in my experience, is to lead the student to find out, for themselves, what is wrong, you can supply the why, and get them to figure out how to fix it. These are what we in teaching call teachable moments, random events which present an opportunity to give the student a deep learning experience, one which will stick with them for a long time.

Your 'explain what's wrong, why, and how to fix it!!!' can be done via google, doesn't add to a real learning experience, and can turn people into cargo cultists.

The code:

    use strict;
    use warnings;
    
    sub foo { print "In foo\n"; print "args = " . join(",",@_) . "\n" if @_; }

    foo;

    foo "a", "b", "c";

    In foo
    In foo
    args = a,b,c

(Which is really really confusing if you spend your days in python, and occasionally have to edit something in ruby.)

The code could be assigning a new variable from a method return value, or just from an existing variable.

Later, I tried using high values for line numbers just for the heck of it. Can I make a BASIC program that begins at line 100,000 instead of 10? By binary search (of course, not knowing such a word) I found that the highest line number I could use was 65,000 + something. I developed the misconception that this must somehow be because the computer has 64 kilobytes of memory.

I had the same confusion! My very first roadblock in programming was when the teacher told me to write `x = x + 1` on the blackboard, which didn't make any sense, mathematically.

A beginner worries about breaking the computer and doesn't yet understand that any question they have can be typed into a search engine verbatim and will probably be answered with 20 SO posts and 50 blogs posts. And early programmer is stumbling down this road.

I don't know that this ethos can be communicated with a book.

I would also recommend that beginners/early programmers learn 1 programming language really well, and ignore the din of people on the internet who claim to effortlessly, expertly jump among 10 languages as part of their day-to-day.

That's a dangerous approach. The first language is very hard to learn, because, well, it's your first. And when you stick to one language, you easily conflate the syntax and the semantics.

So when you learn a second language, you have to unlearn the syntax of the first, in addition to learn the genuinely different concepts. Distinguishing the similar stuff in new clothes from the actual new stuff is hard. Simply put, learning the second languages will be very hard as well.

Now your programmer has two data point, and knows with their gut that learning a new programming language is hard. This sets expectation, an will make it harder to learn additional languages. It will take some time to realise learning a new language, besides a few insane exceptions like C++, is not that hard.

> ignore the din of people on the internet who claim to effortlessly, expertly jump among 10 languages as part of their day-to-day.

Jumping from language to language may not be that easy. But one can certainly be an expert at 20 programming languages. Once you see the commonalities, there isn't much to learn. Really, a good course in programming languages is enough to get you started. The hard part is memorising 20 big programming frameworks, with all their warts, special cases and so on. Still, if you know the concepts, learning the vocabulary takes little time.

All of the things you said are true, and yet the beginner has only so much time, so much patience, so much learning to do in one day.

Given this, I see larger advantages to spending all of that time and energy in one ecosystem. There are many perspectives on, say, Java coding styles, patterns, and idioms. One need not go outside a language to do that.

And I would further argue that you simply cannot (usefully) see the global commonalities and idioms among languages until you've been doing this for a while. Years.

As for experienced programmers, I've not known any "experts" at 20 languages, ever. My point was really that this idea is simply the result of run-of-the-mill internet hyperbole.

I think learning more than one programming language at the same time is a great way to help you tease out basic programming concepts from the vagaries in the syntax of an individual language. How to types work? Scopes? Functions? Loops? Arrays? Hash tables? Those are all things that, once you really grok as separate from, say, whitespace problems in Python or curly brace issues in C, allow you to much more easily read and eventually pick up other languages.

On the other hand, learning German after already knowing Spanish was much easier -- and it was much easier to see the similarities and differences between the languages, because my brain would find the Spanish phrase while searching for the German one, and vice versa, but wouldn't get stuck in a loop about it.

American? :-)

Huge portions of the world (Europe and Asia especially) raise children bilingually.

I suspect, (but don't know) this even facilitates the learning of other languages, later on.

I found that switching between languages made the beginner stages of learning much faster. If I got stuck on a concept in one language, jumping to another language often clarified what that feature means. I still use this strategy today.

I learned variables and addition while in javascript, loops and classes in Java, iterators and hash tables (dictionaries) in Python, functions in Clojure, pointers in Go, etc.

Trying to learn all of those things in one language only would have been much more difficult, boring, and I believe I would know a lot less than I currently do.

That's assuming you are not shown the commonalities explicitly, and have to figure them out by yourself. A course on programming languages teaches just that, and it takes only a semester (possibly a brutal one, but still).

> I've not known any "experts" at 20 languages, ever.

Lucky you. I've never met any expert, period.

Anyway, expertise in a language is not interesting. You want to be an expert at programming. Then translating your thoughts in any language is easy —including languages you don't know.

My "expert at 20 languages" isn't really an expert in those languages. She's an expert at programming, and proficient in 20 languages. Personally, that's what I strive for. I'll leave language lawyering to the compiler writers. (I may write a compiler someday, but it will be for a simple language of my own design. I have no interest in cancerous horrors such as C++ —which by the way is the language I happen to know best.)

I am currently going through Learn Python the Hard Way and at the end of one exercise I was doing the extra credit stuff (research online all python formatting characters) and typed in the question verbatim, one of the top answers was from SO, went there to check it out and one of the first answers was:

"So you are going through Learn python the Hard Way and are to lazy to find the answer"

I mean, I understand some of what that person was trying to say, there is some basic etiquette you should follow when asking questions online, but I am very sure a beginner would not know it. And the question wasn't even "Tell me all the python formatting characters" it was asking where to find a list of them. Another answer did point them to the python docs, but I felt that whoever asked the question would be hesitant about using SO again when they have another problem, which is a shame.

The problem with this isn't whether or not that claim is true, but rather that (as you say) its not the right thing for a beginner. Its perfectly fine (desirable, even, IMHO) for an intermediate-to-expert programmer to know many (different) languages and use a few of them regularly (although perhaps outside of JS and whatever you use on the backend, probably daily is a bit much maybe), but this is all distraction for a beginner. Beginners should focus on learning programming concepts, not on learning programming languages (but one language is a requirement, otherwise you can't learn by doing!) Although, Zeds point about learning the basics of four languages still holds - you can do that and then focus on one.

My point is more about the sorts of stories and claims that a beginner will encounter while poking around the usual sites. One could be forgiven for wondering if most HN commentators are 60 year-old polyglots with a security clearance and two failed startups under their belt. It can seem daunting in the right context.

For example, a beginner might phrase queries like "jquery how do I make text appear on screen", whereas a more experienced person might query something like "jquery element insert value".

I'm totally behind this distinction, and I hope more content publishers adopt something like this.

The hacker tradition is revered in large part because it seems to be so egalitarian. We all came from humble beginnings. Anyone who can grasp enough of the mathematics of the stuff can make the gizmo do something magical.

It's a common to be self deprecating about our former ignorant selves, and maybe some people find it encouraging to hear something like "don't worry, I was once a noob myself." But really, the word emphasizes the moments where you felt like an idiot. That doesn't help a beginner.

https://en.wikipedia.org/wiki/Shoshin

Hindsight and all, it seems the book would have better titled "Learn to Program the Hard Way (using Python)". Or "Learn to Program the Hard Way (using Ruby)". A total beginner is really trying to learn how to build a program, not trying to learn a particular language (whether they know that or not).

I think it took me three years to understand what a variable was. And I still don't know why it took me so long to understand and why I suddenly understood it.

It's not that I didn't know that assigning '1' to 'a' would result in 'a' having a value of '1', but I didn't understand the concept and workings behind it. I just thought it was magic.

    10 LET X + 2*Y = 5
    20 LET X - Y = 10
    30 PRINT X

The only person around me who knew anything about programming was my grandfather, but when I asked him how to get user's input, he began explaining something about interrupts (he only programmed mainframes and got out of the field in early 80s), which left me even more confused and believing that this is just too advanced for me.

So often one "learns (programming) variables" in how they're implemented instead of merely what they mean. Their meaning is much more hairy than mere naming.

Programming and Mathematics have a lot in common but it would be a mistake to take all your knowledge about terminology from one domain and apply it un-thinkingly to another.

I disagree. A constant is not expected to change, a variable is absolutely expected to change.

The difference is that a mathematical variable changes "between invocations" of a mathematical statement. An "assignable" changes "within invocations".

(Technically we ought to talk about variables assigned in "for all" style or "there exists" style bindings. There's still a sense of holding under all variations, but the "thing" that "holds" changes.)

On the other hand, constant is different in each domain. Pi, the constant, is emphatically not a variable in mathematics.

This is why `x + 5 = 10` makes sense in mathematics, but not in a programming language.

"In mathematics, the equals sign can be used as a simple statement of fact in a specific case (x = 2), or to create definitions (let x = 2), conditional statements (if x = 2, then...), or to express a universal equivalence (x + 1)2 = x2 + 2x + 1."

In most programming languages, the equals sign is reserved only for definition.

If you wanted to be explicit about this in maths, you can use := and I think that notation would solve a lot of beginner and early programmer problems.

Registers, memory access, jumping and comparisons seem like easy enough things to understand (maybe?), and could help demystify a lot of things.

A Notable exception I found is "Learn you a Haskell for Great Good!". It is as good for beginning coders as it is for early (or advanced) ones.

The author made the effort to describe some relatively basic things, and it was simple enough (okay, with a few calls to me here and there) for an Art major friend of mine to start with programming, and with Haskell. I can't recommend this book enough.

My favourite book for this by far is How to Design Programs: http://htdp.org

It assumes knowledge of arithmetic and maybe a tiny bit of algebra but not much else.

The problem is, I can't wrap my head around many of the concepts I read about here in the HN comments and elsewhere on programming blogs and such. No matter how much I try to understand it (and by understand it, I mean fully grasp what the person is talking about without having to look up every other word or phrase), I can't seem to put it all together. Things like inverted trees, functional programming (I've heard of Haskell and I'd love to learn it, but I have no head for mathematics at that level), polymorphism, and so on.

Maybe I need to just practice more; maybe I need to pick something interesting from Github and dive into the code to try to understand it better (preferably something well documented of course). Or maybe I need to just stop, and accept that I can whip out a script or simple web thingy if I really need to, and stick to being a hardware guy, which I'm actually good at.

Grab Learn You A Haskell[1] and have fun. ;)

[1]: http://learnyouahaskell.com

...but it makes you feel stupid if you don't. Better to use "Real World OCaml" if you're more interested in the ideas themselves than in their formalizations or related nomenclature.

Exactly. That's where I'm at right now; I know what Haskell is, I love the idea of it, I've enjoyed some of the fruits of it (XMonad). But it was when I tried to dig deeper into it that I felt lost, and yes, stupid. I've never been a math whiz; I am great at visualizing concepts but truly grasping the theory behind them is where I get lost. Based on my junior high school testing, I was placed in Advanced Algebra in my first year of high school. I nearly failed the class because it took me all year to grok the distributive property. I look back on that and I feel ashamed, because once I understood it, it seemed so damn simple! And so it is when I try to advance beyond my current level of programming skill; I hit brick walls and I feel like I left my sledgehammer at home. My pocketknife, even though I know every millimeter of it, won't cut through those walls.

Having found Haskell materials as simply not suited for me I decided - quite a few years back - to learn Haskell (or the concepts behind Haskell, at least) my own way: by learning first Erlang (it sounded cool), then Scheme (mainly to be able to read many, many papers that use it), then OCaml and Scala (because the type systems and pragmatism) and finally Clean (to fill the last gaps in my knowledge). I progressed from dynamic to static typing and from eager to non-eager evaluation. It took me I think about 2 years to do all this and, of course, it wasn't that easy, but somewhat surprisingly it worked. I never wrote - and I'm not sure I ever will, but that's a completely different matter - any non-trivial Haskell code, yet I'm able to read and enjoy Haskell-related papers.

It's important to realise that there is always more than one way to learn things. You should know yourself well enough to see when the "normal" way simply isn't for you; this way you can go search for alternative ways. I guarantee that you'll find them, if you search hard enough :)

The stuff you don't know all needs to be studied. People don't happen on functional programming or build trees a propos of nothing; they studied it, either in college or on their own.

Find a good book and dig into it. If you want to learn stuff like functional programming, read The Little Schemer. If you want to learn about trees and other data structures and algorithms, make a few pots of coffee and work your way through the Algorithms bible by CLRS.

Polymorphism is actually pretty easy once you understand the ins and outs of OOP. It just sounds scary. I've taught a first-year high school beginner programming class about polymorphism by the end of the year.

I did study programming in college (well, tech school, so that's likely part of my problem), but it was SQL/400 on IBM AS/400 machines and was geared towards direct employment at one specific company. In other words, it bored me to death, and I switched to web design halfway through. I really didn't learn anything there that I hadn't already taught myself, and I was surprised to find that I was the only person in the class (including the instructor!) who knew what Linux was. We had an AIX server that had been donated by some company a few years before, and it was sitting there unused, like a monolith from another era, until the instructor allowed me to work on it in my spare time. I managed to get it up and running, and set it up as a local webserver so we could practice server-side scripting with more control over the environment, and learn a bit more about how web servers do what they do.

And that's the core of it I think; my passion is for tinkering and fixing things, and while there's a lot of that kind of thing in the programming world at large, I'm really more of a hands-on, direct kind of person rather than an abstract thinker. My sister is a website and graphic designer in her spare time, and she and I have often talked about starting our own hosting service geared towards creative professionals, with me handling the back end and her doing the front end and marketing. Maybe I should pursue that instead of wasting time trying to learn advanced programming concepts when I'm not actually seeking employment as a programmer.

You can decrease/increase the scope of the project part way through depending on how smoothly things are progressing. Fully executing on a simplified initial version is much better than half way executing on a grander vision.

Don't be afraid to ask for help if you get stuck. You will be amazed at everything that you have learned by the end.

This stuck out to me as being just the beginnings of the quintessential issue:

   A beginner’s hurdle is training their brain to grasp the concrete problem of using syntax to create computation and then understanding that the syntax is just a proxy for how computation works. The early coder is past this, but now has to work up the abstraction stack to convert ideas and fuzzy descriptions into concrete solutions. It’s this traversing of abstraction and concrete implementation that I believe takes someone past the early stage and into the junior programmer world.

If, as the article states, 4 is the magic number of languages to learn up front, perhaps there should be a 4th level of programming guides....one for the journeyman who knows the syntax, can articulate the complex algorithmic issues that need to be addressed, but isn't quite at that "mastery" or "advanced" level.

Code tags are okay if you manually line-wrap, or you can precede quotes with a > and everyone should recognize it for a quote.

Obviously I can't expect to pick up a brand new technology and instantly expect to be a wizard, but I do expect that I can pick up a new technology and be functioning at a high level in a week or two, tops, because it's almost certainly just a respelling/reskinning of some technology I've used before.

(The whole "young guys who know way more than their old-fogey elders" was, in my opinion, an isolated one-time event when we transition from mainframe tech to desktop tech. Despite its recurrence on HN, I think "age discrimination" is naturally receding and will just naturally go away as the people on this side of that transition continue to age, and skill up.)

"Oh, look, the JS community has discovered $TECHNIQUE. Ah, yes, I remember playing with this in 2003. Does any of them remember the ways in which it went bad and never took off, or are they just spouting hype? Ah, I see they've opted for hype. Well, this ends predictably."

Not that $TECHNIQUE is necessarily bad, mind you, it's just that none of these ideas are new and it would be nice to see one of these frameworks pop out every so often written by someone who up-front acknowledges the previous weaknesses of $TECHNIQUE and tries to address them, even if only through user education, somehow.

(And while no language community is immune to this, the last two years of JS has been noticeably worse about this than any other community I know.)

Could you be so kind as to mention some examples of javascript libraries or techniques that are recycling failed concepts from past decades?

Event-based programming was not discovered by Node. It was the dominant paradigm for decades, plural, on the desktop, and still is how all GUIs work, on all platforms, current and past. I've got a big blog post on deck about this one, actually, so I'll save the well-known pitfalls for that.

All of the async stuff that they've come up with has been tried before, and none of it is a miracle cure, though some of them are certainly better than callback hell. Still, many of them still have well-known problems with composability and program flow comprehension. This has been a rich source of people overestimating how green the grass is on the other side; for instance, Python has everything ES6 is going to have anytime soon, and it's still fairly klunky in many of these cases, IMHO. Not to mention the fact I've been outright stunned to see people in 2015 rehashing claims that cooperative multitasking is superior to preemptive multitasking because it gives you "more control" over the performance, which is roughly up there with seeing someone actively advocate for spaghetti programming because it gives you "more control".

Reactive programming dates back to Visicalc (note the fourth paragraph of the wiki page cites spreadsheets as an example); it has well-known problems with cyclic dependencies, which are shockingly easy to accidentally introduce. It strikes me as likely that the nature of web pages will tend to contain this problem, unless you're literally building a spreadsheet; this strikes me as one of the better tech fits. (The more you partition your problems structurally with "pages" and discrete "submissions" to the server, the less likely you are to spaghetti tangle your data flows accidentally, the way a single-spreadsheet application can so easily. The structure induced by the web is in this case harnessed to your advantage.) I wouldn't try to build a game with reactive programming, though.

The idea of using "binding" in your UI, as in Angular, was actually tried by multiple GUI technologies, and generally was hard to work with at scale (made easy things easy and medium things very hard). I'm pretty sure Microsoft had it at least twice on the desktop and once in ASP.Net; none of them stuck. The same effect may save you here, though... GUIs are generally in "pages" as well. Less sure about that. Adding binding to a pre-existing language can also cause inner platform effect, where you have to embed a full language for expressions inside the original programming language: [1] But this is one of those cases where advances may make something more practical than it used to be... dynamic scripting languages require a lot less work to make that work than the olden days, where the fact you were literally writing a new inner language really sucked (i.e., lots of new bugs the outer language didn't have).

Going to a bit of a wider range, NoSQL databases preceded SQL databases, which are called SQL databases precisely because there were databases, then there were SQL databases. Non-SQL databases had problems with being non-standard and causing your application to be too intimately tied to one of the very pieces of the tech stack most likely to fail one of your requirements and need replacing. That said, I will also point out that SQL databases really were in some sense too successful, and they should never have been the "only" choice. (But too many underinformed people still read too much hype and flee SQL databases when they really shouldn't.)

And I'll end my message with a clear restatement of my point, so it's both the beginning and the end: The point is very much NOT that any of these things are "bad" or "failed"... the point is that they are not new, and it would be advantageous to look back at our historical experiences with the tech where possible to learn what the pitfalls are. This is something that both the people writing the techs ought to be doing, and even if they do, the people using the techs really ought to as well, especially when it comes time to decide which tech to use.

[1]: https://docs.angularjs.org/guide/expression

It's all the same thing under the hood, just better syntax and tooling. Data structures and algorithms.

Does that mean there's no reason to switch? No.. since some languages are better at representing some ideas; some languages have better abstractions for certain ideas; etc.

I think starting with a lower level language helps with this way of thinking. If you learn everything about C (for example), and later learn a higher level language, it's easy to think of how you would implement a certain feature of the higher level language.

I can think of two counter examples for this.

First, Lisp with its meta-programming is completely unlike any other language that doesn't support such concepts. No programming I did(In C-like languages) ever prepared me for something like Lisp.

Secondly, Haskell with laziness, immutability and a powerful type system is completely unlike any other mainstream language out there. You would struggle to even begin to express your programs in Haskell if you are not familiar enough with it. Imperative code and Haskell code are almost always completely different. If you have some experience with imperative languages, most of that experience would translate over to other imperative languages. However, an extremely small portion of my imperative language experience translated over to Haskell.

I cannot agree with this more. A lot of people seem to think that a "better" language to learn programming with is one that is "easier" or "more forgiving", but everyone I know who started with C became excellent programmers whereas ability among the group who started with something else is somewhat more hit or miss.

For example, I know exactly how garbage collection works.. since I once had to write a GC for a project. So when I use a higher lang, that part isn't magic... it's just something someone else already wrote for me.

Whereas, if you started with a higher level lang, you could get by without ever learning how a GC works. Yes, you could dive into the details of your language, but there's no requirement for you to do it.

And I think that explains what you've noticed... it's hit or miss because those who chose to dive into the details of their lang eventually became excellent developers...

How much of this is survivorship bias?

The heart of programming isn't learning syntax, it's in learning how to translate solutions into sequences of symbolic operations, which can then be translated in turn into the syntax of a specific language.

Beginners also need to learn to use a keyboard, an IDE, and a debugger, and probably also a package manager, a distribution tool or system, and how to look stuff up online.

So the cognitive load is huge.

But it's the mental model that trips people up. You literally can't do anything with code until you learn the core symbolic grammar for the most common operations. And even after you do that, there's always more to learn as you can go deeper into more sophisticated models like functional programming.

It's not at all obvious to outsiders how that grammar works. (Which is why programmers tend to be so bad at UX - operations and relationships that are "obvious" to someone with programming aptitude are completely unintuitive to people from other backgrounds.)

The problem expressed in this article is a fundamental bottleneck of education. The communication between teacher and student is often misinterpreted at both ends and the subject matter is never perfectly conveyed or received.

I feel what really lacks in the learn to code community is teaching one how to actually learn. Lay a positive attitude towards failure and a framework of problem solving first, the content and understanding of a language will come after.

One area I struggle with in tutoring is how to inspire/invoke/detect disciplined motivation. What I mean is, whenever I sit down to show someone something, I'm constantly questioning myself "wait, do they actually want to learn this level of detail, or am I just giving too much information that's going in one ear and out the other?" If someone is definitely motivated to learn that's great (and really inspiring for me as a teacher to do better at explaining things precisely).

If this nomenclature were more understood, I would like to say something like "Sorry, what you're trying to do is more of an early/junior task, and right now you need to stick with the Beginning basics". I just don't know how to phrase that without sounding condescending.

Computing is so tightly woven into our world not that it's hard to find people who have more than a passing interest in it who have not find some way to try to code as kids. Even with those who haven't, there's a gulf between people who have tried to do a little HTML editing (and know what a file is) and people who haven't. There's no one place to start. From Zed's description it looks like he's starting from the lowest possible point, but what are the demographics like there? How many people are in that space and are they mostly adults or children?

I think this is one of the main reasons why you don't see much beginner's material.

I often wonder about this. In the UK, with the drive to get every child 'coding', there are a large number of teachers that constantly talk about how the main skill that we should be teaching is 'Computational Thinking'.

I wax and wane back and forth over this topic, in a very chicken and egg way. However, I usually end up coming to the conclusion that learning computational thinking is great, but you need to know how to code (i.e. learn the basic syntax of a language) before you can possibly learn how to think computationally.

I would be very interested to hear the opinions of actual developers, as to their opinions on the topic.

The very first part of computational thinking is understanding that you can make a very specific and precise procedure to accomplish a task. If a student is at an age where reading and writing is easy, then learning the syntax of a language is a fine way to accomplish this. The student will spend a lot of time with each finicky word and symbol to make the computer behave, and while they may not recognize that they are defining an abstract procedure, the result is hopefully some intuition that the computer is a very predictable and reliable machine that does exactly what the code says, even if it's not what you meant. With exposure to more languages and by writing more programs, hopefully a student begins to recognize patterns and abstractions in their code, and that's the point at which they become real computational thinkers.

If a student isn't ready for that, there are still fun things to try. One cute one I've seen is "program your parent" exercise at a workshop. The child can make their parent move one step forwards or back, turn left or right, pick up and put down an object, and put one thing inside another. Can they make their parent pour a glass of juice? Or put a lego back in the box?

I don't think there is a chicken and egg problem here, because learning to make a dumb machine perform a task by following a procedure is the essence of computational thinking. Learning the basic syntax of a language is probably the most efficacious way to experience this for many students of many ages, even if the explicit goal is "do well on an AP test" or something mundane.

There are other good ways, but writing code is the best way.

This means, an expert in one language is going to be "Beginner" instead of "Early" in some some ways...but "Early" instead of "Beginner" in other ways.

Anecdotally, as a software engineer working with C++, I had to spend a whole months trying to understand event-driven programming of other languages. I didn't really need tutorials on loops and recursions but I sure as hell needed to understand how a typical program in that language works.

I am a instructor for Software Carpentry[1] , the goal of these workshops from my experience is to try and help mostly scientists get started on the journey to becoming early programmers.

In biological sciences with more and more data becoming available, the Expert blindness Zed speaks of is a major problem. We need to invent better systems and actually take heed of research based teaching methods as SW does if we wish to improve this situation.

https://software-carpentry.org/

  Elementary Differential Equations (third year math)
  Elementary Symbolic Dynamics (grad-level)

> An Introduction to Group Theory

(500 pages)

I tried though his blog comments, and at the help email he has for his HTLXTHW courses, but never got a response.

I dunno if he just never noticed it, or if he's actually ignoring me for some reason, but having already typed out this question with all the necessary context, I figure I may as well post it a public place where it's relevant, so here:

Hi Zed,

So, I found [this comment of yours on HN](https://news.ycombinator.com/item?id=1484030) by googling:

> site:https://news.ycombinator.com zedshaw engelmann

and was pleasantly surprised find you explicitly mentioning Siegfried Engelmann and Direct Instruction.

Here's the story:

I learned about your "Learn X the Hard Way" series through a friend who had learned Python from your course.

He told me he heard you knew about Zig and DI.

I immediately said something like:

> Nah, pretty much nobody has heard about DI, much less properly appreciates it.

> Probably Zed just meant lowercase "direct instruction" in the literal, non-technical sense of "instruction that is somehow relatively "direct"".

> He's probably never heard of uppercase "Direct Instruction" in the technical sense of "working by Engelmann's Theory of Instruction".

But then I googled, and yeah, aforementioned pleasant surprise.

(I am just not going to say anything, outside of these brackets, about "blasdel" there.

If medicine was like education, the entire field would be dominated by the anti-vaxxers.

Hey, blasdel! supporting "Constructivism" is morally at least as bad as supporting anti-vaccination!

Bah, whatever. Okay, got that out of my system. Anyway. xD )

So now I'm really curious:

You said you "learned quite a bit about how to teach effectively from [Zig and Wes]".

But how did you learn from them?

You haven't slogged your way through the "Theory of Instruction: Principles and Applications" text itself, have you?

I have, and wow was that a dense read... Which is frustrating, because as you're reading, you can see, abstractly, how they could've meta-applied the principles they're laying out to teaching the principles themselves --[the open module on Engelmann's work at AthabascaU](http://psych.athabascau.ca/html/387/OpenModules/Engelmann/) includes a small proof-of-concept of that, after all-- but apparently they just didn't feel it was worth the extra work, I guess...?

(Zig did [say that the theory is important for "legitimacy"](http://zigsite.com/video/theory_of_direct_instruction_2009.h...) --ie, having a response in the academic sphere to the damn "Constructivists" with their ridiculous conclusion-jumping-Piaget stuff and so on-- and that's the only practical motivation I've ever heard him express for why they wrote that tome in the first place.)

Have you read any of the stuff he's written for a "popular" audience, like these?:

- [Could John Stuart Mill Have Saved Our Schools?](http://www.amazon.com/Could-John-Stuart-Saved-Schools-ebook/...)

- [Teaching Needy Kids in Our Backward System](http://www.amazon.com/Teaching-Needy-Kids-Backward-System/dp...)

- [War Against the Schools' Academic Child Abuse](http://www.amazon.com/War-Against-Schools-Academic-Child/dp/...)

(god has Zig got a way with picking titles...)

But basically what I really want to ask you, which all that was just to establish context for, is just:

In developing your Python course, how did you use your knowledge of DI?

The 'for-dummy' books are only a tiny sliver, and it's often hard to tell from skimming a book (or from the ToC on Amazon) what a particular book's target is.

And how would you say your post comes off?

    - Books written for "beginners" target people who already know how to code