Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

11–20 of 178 posts

Re: Early vs. Beginning Coders

#11
post #2

tldr: - Books written for "beginners" target people who already know how to code - Author's book targets people before that - Most programmers are bad at teaching people how to code - Recommends some arbitrary phraseology to differentiate levels of ability - Until someone learns the basics of 4 languages they don't really know how to code - Demands people only use the term "beginner" for people who can't code, and "e…

> it comes off mostly like a whiny complaint

And how would you say your post comes off?

Re: Early vs. Beginning Coders

#12
post #9
post #7

This is a nice article. 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.

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.

Re: Early vs. Beginning Coders

#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 of the convention silly to finding the convention silly was amusing to feel. Like it makes sense to a parser but not to a flesh-and-blood contextual-clues-using human. We don't vocalize "open paren close paren" whenever we say an intransitive verb. We just "know" that it's intransitive. Anyway, great article.

Re: Early vs. Beginning Coders

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

Re: Early vs. Beginning Coders

#15
post #7

This is a nice article. 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.

I still remember when I was about 8 or 9 years old, learning Basic, and not understanding why I couldn't do something like this:

    10 LET X + 2*Y = 5
    20 LET X - Y = 10
    30 PRINT X
(Yes, now I know about Prolog).

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.

Re: Early vs. Beginning Coders

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

Re: Early vs. Beginning Coders

#17
post #2

tldr: - Books written for "beginners" target people who already know how to code - Author's book targets people before that - Most programmers are bad at teaching people how to code - Recommends some arbitrary phraseology to differentiate levels of ability - Until someone learns the basics of 4 languages they don't really know how to code - Demands people only use the term "beginner" for people who can't code, and "e…

> it comes off mostly like a whiny complaint And how would you say your post comes off?

A warning for people who value their time.

Re: Early vs. Beginning Coders

#18
post #2

tldr: - Books written for "beginners" target people who already know how to code - Author's book targets people before that - Most programmers are bad at teaching people how to code - Recommends some arbitrary phraseology to differentiate levels of ability - Until someone learns the basics of 4 languages they don't really know how to code - Demands people only use the term "beginner" for people who can't code, and "e…

It's a pervasive, persistent problem. It's exceedingly common to talk with coworkers, or people at a meetup, who assume a bunch of domain knowledge for their domain, and are dismissive when you don't know that knowledge. And then you find they aren't aware of some other domain. The worst is when the same ideas are used in different domains under different names. There is often no level-setting, either. Compare statistics, machine-learning, and CS language about the same topic.

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.

Re: Early vs. Beginning Coders

#19
post #17

Earlier quoted context omitted.

> it comes off mostly like a whiny complaint And how would you say your post comes off?

A warning for people who value their time.

It's also a fairly short read. I cull media mercilessly, but this was easy enough to just read, in full.

Re: Early vs. Beginning Coders

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

A variable in algebra is exactly what you consider a constant in a programming language. If I say "x = 5" in algebra,that means "x represents the value 5" (and I can substitute one for the other anywhere). The variable x can't suddenly represent the value 6 halfway through my calculations. Variables in Racket and Erlang work exactly as in algebra: single-assignment binding.
Post reply on HN