Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

Post reply on HN
Print view View original

111–120 of 178 posts

Re: Early vs. Beginning Coders

#111

Post by Nimitz14 »

dvanduzer wrote: post #70
mcgrootz wrote: post #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.

If you're behind this distinction, I'd ask that you abandon the negative slang about someone who is new to a topic. 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 s…

or use the normal term: newbie

Re: Early vs. Beginning Coders

#112

Post by pdw »

top1nice1gtsrtd wrote: post #13

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…

It is a silly convention, really. Algol-60 didn't require them, and neither did any language in the Algol family (Pascal, Ada, Modula-2, etc). It used to be something peculiar to Fortran and C, but today every language imitates C...

Re: Early vs. Beginning Coders

#113

Post by MarcScott »

"My favorite is how they think you should teach programming without teaching “coding”, as if that’s how they learned it."

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.

Re: Early vs. Beginning Coders

#114

Post by wolf550e »

SCHiM wrote: 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…

This has nothing to do with learning a programming language and everything to do with learning how to process text in a computer. Being a C programmer doesn't mean you have only a PDP-11's understanding of text ("it can be ASCII or EBCDIC, and I know how to convert between the two!").

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.

Re: Early vs. Beginning Coders

#115

Post by lelandbatey »

kevinschumacher wrote: post #88
bwy wrote: 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…

"what's a tokenizer? what's an interpreter?", said the beginner.

I think of even greater note is:

> 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?

Re: Early vs. Beginning Coders

#116

Post by blt »

MarcScott wrote: post #113

"My favorite is how they think you should teach programming without teaching “coding”, as if that’s how they learned it." 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.…

There's no better way to improve your "computational thinking" than to write code.

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

Re: Early vs. Beginning Coders

#117

Post by Terr_ »

schoen wrote: post #60

Is there a book somewhere that tries to set out all of the things that experts know about computing that they don't remember learning? (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…

> things that experts know about computing that they don't remember learning?

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.

Re: Early vs. Beginning Coders

#118

Post by ezyang »

skrebbel wrote: post #109
jakobegger wrote: post #105

Earlier quoted context omitted.

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 entirel…

You are almost certainly misstating the Haskell programmer's question, because C makes it very easy to test if two function pointers are equal (intensional equality) whereas Haskell makes it very hard.

Re: Early vs. Beginning Coders

#119

Post by jameshart »

keithpeter wrote: post #108
danso wrote: 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 exer…

There are always ways in. Kids are learning the concept and demands of precise 'command syntax' by typing commands in to the Minecraft terminal, or using command blocks. Maybe in the future people will be moaning about how kids these days with their gesture and voice based control interfaces never learned the precision needed for coding the way they did when they were younger: by typing in specific sequences of symbols to turn them into 'emoticons' in chat windows...

Re: Early vs. Beginning Coders

#120

Post by nekopa »

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

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 wri…

bwy, I am writing this to you, from a current teacher to maybe a future teacher. I have a big issue with this line of your response:

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.

Post reply on HN