Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

31–40 of 178 posts

Re: Early vs. Beginning Coders

#31
post #14

This is good. I've had problems that were somewhat related to what the author talks about. 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 loo…

That's only "basics" if you've got the wrong idea. There are millions of possible mistakes, no beginners' guide can explicitly address every one. People told you to just use the string - wasn't that a good enough answer?

Re: Early vs. Beginning Coders

#32
Zed Shaw is a natural when it comes to teaching beginners. I recommend his "Learn The Hard Way" books to everyone who is interested in learning to code because they make zero assumptions and start at the VERY beginning. It's stupidly hard to find great books for complete noobs.

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

Re: Early vs. Beginning Coders

#33
post #23
post #9

Earlier quoted context omitted.

There's something interesting here too in that what many call variables are actually a bit more like "assignables". The upshot is that only in programming do variables behave this way---distinct and unlike mere "names" which we're more familiar with from day-to-day life. So often one "learns (programming) variables" in how they're implemented instead of merely what they mean . Their meaning is much more hairy than me…

Actually, the brunt of the confusion is not the variable, but the '=' sign, which in mathematics means 'is equal to', while in a programming language means 'assign to'. This indirectly changes the semantics of the variable within the statement, and confuses people. This is why `x + 5 = 10` makes sense in mathematics, but not in a programming language.

This is one case where I wish Pascal had won. := for assignment, = for comparison.

Re: Early vs. Beginning Coders

#34
IMHO, Zed is right. I have been looking for books targeted to beginner programmers so I could recommend them to my friends, but most books unfortunately fail on this point.

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.

Re: Early vs. Beginning Coders

#35
post #16

I was bitten by this as well, I thought the book was for an "early programmer" not a total beginner. 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 your parenthetical at the end is most important to the marketing strategy behind the way the book is named as opposed to your suggestions. In my experience discussing with people who do want to learn to program, their first question is generally "What's the best/easiest language to start with?". Having no knowledge of coding whatsoever leads one to focus on comparatively superficial things like language, so I can imagine more beginners being drawn to "Here's how to use Python" vs. "Here's how to program".

Re: Early vs. Beginning Coders

#36
post #21

I've been teaching coding to beginners for the past year now...and even after having done coding workshops/tutorials for many years previous, I've found I can never overestimate how wide the knowledge gap is for new coders. 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 woul…

"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'…

Uh...the reasons can vary quite wildly...so I'll stick to one scope: Why does production code suck even when it's been written by competent programmers? I would argue that in a non-trivial system, it becomes difficult to program components that reliably interact with each other. If one team changes the interface to their component, that is not as "deterministic" from your perspective, if the production workflow doesn't have adequate automated testing and so-forth.

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

Re: Early vs. Beginning Coders

#38
post #31
post #14

This is good. I've had problems that were somewhat related to what the author talks about. 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 loo…

That's only "basics" if you've got the wrong idea. There are millions of possible mistakes, no beginners' guide can explicitly address every one. People told you to just use the string - wasn't that a good enough answer?

> People told you to just use the string - wasn't that a good enough answer?

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

Re: Early vs. Beginning Coders

#39
The only important trait I see that matters for either of these groups is a willingness to try things, push buttons, see what happens.

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.

Re: Early vs. Beginning Coders

#40
post #21

I've been teaching coding to beginners for the past year now...and even after having done coding workshops/tutorials for many years previous, I've found I can never overestimate how wide the knowledge gap is for new coders. 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 woul…

This is pretty ridiculous, man. I don't think I know a beginner programmer who would be so stuck on "every character matters." (Which isn't even true, to some level, in many langauges - ; in JavaScript and Python? Whitespace in languages besides Python?)

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/)

Post reply on HN