Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

101–110 of 178 posts

Re: Early vs. Beginning Coders

#101

I actually worked on teaching my 71 year old father Python using this book. One point of difficulty that struck me during that exercise was that I as a programmer had completely internalized the idea that an open paren and a close paren right after a function is a natural way to invoke a function with zero arguments (e.g.: exit() exits Python's prompt. exit doesn't.). The whiplash I felt from finding the questioning…

Perl doesn't require "()" after the name of a function to call the function. In fact, parentheses aren't required for function calls at all. The code: use strict; use warnings; sub foo { print "In foo\n"; print "args = " . join(",",@_) . "\n" if @_; } foo; foo "a", "b", "c"; yields the output: In foo In foo args = a,b,c

Neither does ruby.

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

Re: Early vs. Beginning Coders

#102

I actually worked on teaching my 71 year old father Python using this book. One point of difficulty that struck me during that exercise was that I as a programmer had completely internalized the idea that an open paren and a close paren right after a function is a natural way to invoke a function with zero arguments (e.g.: exit() exits Python's prompt. exit doesn't.). The whiplash I felt from finding the questioning…

Perl doesn't require "()" after the name of a function to call the function. In fact, parentheses aren't required for function calls at all. The code: use strict; use warnings; sub foo { print "In foo\n"; print "args = " . join(",",@_) . "\n" if @_; } foo; foo "a", "b", "c"; yields the output: In foo In foo args = a,b,c

[deleted]

Re: Early vs. Beginning Coders

#103
post #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…

I can't edit my original comment but I'm surprised it was unpopular and the repeated concerns are so petty. I can respond to most of the things you guys brought up:

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

Re: Early vs. Beginning Coders

#104
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…

A good analogy I've heard to explain this is how you'd request a glass of water from the kitchen from a friend versus a computer. You can simply tell your friend "get me a glass of water" and they'll understand what you're asking. With a computer though, you must be completely explicit with your instructions, for example: walk to the kitchen, open the top left cabinet, take out a glass, put it underneath the faucet,…

Day one CS 101 class.

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

Re: Early vs. Beginning Coders

#105
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…

I'd actually consider that kind of knowledge pretty advanced. Beginners (and early up to even junior coders) usually don't know much about the internals of their environment; they just use stuff.

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.

Re: Early vs. Beginning Coders

#106
post #45
post #40

Earlier quoted context omitted.

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…

> 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?) 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 prom…

Notably, pascal uses `:=` and is one of the better first languages in my opinion for many more reasons (easy to grasp language core, simple non-null terminated strings, no actual need to learn pointers until the very advanced stages). Today I mostly advice other people to start with python though, because pascal feels somewhat dated and undertooled.

Re: Early vs. Beginning Coders

#107
I tried to contact Zed about a month back, to ask him this question.

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?

Re: Early vs. Beginning Coders

#108
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…

Thinking about the OA, your student, and the people who don't know how to find | character and about what people tinker with now.

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?

Re: Early vs. Beginning Coders

#109
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…

I'd actually consider that kind of knowledge pretty advanced. Beginners (and early up to even junior coders) usually don't know much about the internals of their environment; they just use stuff. 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 th…

> I'd actually consider that kind of knowledge pretty advanced.

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.

Re: Early vs. Beginning Coders

#110

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…

Just a side note to your "will probably be answered with 20 SO posts":

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.

Post reply on HN