Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

131–140 of 178 posts

Re: Early vs. Beginning Coders

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

I would find some resource of assumed knowledge useful in my career field of chemistry and biology, but what really resonated with me from zedshaw's piece was something even more basic to the field. The biggest hurdle I had to learning to code was finding a text editor. The next big hurdle I had was finding somewhere to host my one-page HTML site. I ended up asking a friend who suggested Sublime Text and Amazon AWS. At that point I'd been reading HN for two years and had heard of these things, but not understood their central utility (or the utility of similar such general services) to doing anything with code. This is the level of beginner that I would hope zedshaw's efforts would target, someone like me from last year.

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.

Re: Early vs. Beginning Coders

#132
post #130
post #38

Earlier quoted context omitted.

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

"Don't do that" is the right answer when you're asking the wrong question. It's an invitation to take a step back and ask how to do what you actually want to do, at a higher level.

No; the correct answer in that case is "Why are you trying to do that?"

Re: Early vs. Beginning Coders

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

You're exhibiting exactly the phenomenon the OP was talking about. > 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 a…

Indeed, CS 61A had a prerequisite placement exam which tested students' ability to write a recursive program. Everyone in the class had already passed that, otherwise they were sent to CS 3. So those students were definitely "early programmers" in this sense.

Re: Early vs. Beginning Coders

#134

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…

But there's a good reason for that convention in any language with first class functions. Otherwise you would have something inconsistent like "no parens required if the call is on a line by itself, but they are required in any other expression" (i.e. assignment or another function call).

Re: Early vs. Beginning Coders

#135

I can still visualize what it's like to know nothing, because when I saw a BASIC program for the first time when I was ten, I thought the = signs denoted mathematical equality (equations). How the heck can X be equal to Y + 1, if in the next line, Y is equal to X - 2? 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 bin…

> I thought the = signs denoted mathematical equality (equations).

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.

Re: Early vs. Beginning Coders

#136
post #23

Earlier quoted context omitted.

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.

Equals sign in mathematics is overloaded: "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,…

Not even definition, but "assignment". Definitions do not change.

Re: Early vs. Beginning Coders

#137
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.

Sure, but that operation, "assign", takes as its left value a different kind of thing than "relate" or "equate" does.

Re: Early vs. Beginning Coders

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

Variable to me means 'can change', Constant to me means 'can't change'. It's the mathematical way to use variables in a way that confuses me, though I can see how if you only use 'constant' to refer to an entity like Pi can make sense. 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.

"Variable" in math doesn't mean change, it means that the relation a variable is involved in holds over any variation of valid denotations of that variable. So the notion of variance is external to the proposition, whereas in programming the variation is internalized.

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

Re: Early vs. Beginning Coders

#140
post #130

Earlier quoted context omitted.

"Don't do that" is the right answer when you're asking the wrong question. It's an invitation to take a step back and ask how to do what you actually want to do, at a higher level.

No; the correct answer in that case is "Why are you trying to do that?"

That's what pedants do.

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.

Post reply on HN