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

91–100 of 178 posts

Re: Early vs. Beginning Coders

#91

Post by Joeri »

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

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…

The way I would explain it to them is to imagine the compiler as being dustin hoffman's rain man. He'll do exactly what you tell him to do, provided you say it in exactly the right way, because he takes everything 100% literally.

Re: Early vs. Beginning Coders

#92

Post by pbreit »

No. Just change the name of the book to "Learn Programming The Hard Way (Python Edition)". By putting the language in the title it sounds like it is for an experience programmer learning a new language, not for learning how to program.

Re: Early vs. Beginning Coders

#93

Post by morganvachon »

klibertp wrote: post #81
octatoan wrote: post #61

Earlier quoted context omitted.

Haskell does not need you to learn mathematics (category theory, if you've heard of it). Grab Learn You A Haskell[1] and have fun. ;) [1]: http://learnyouahaskell.com

> Haskell does not need you to learn mathematics ...but it makes you feel stupid if you don't. Better to use "Real World OCaml" if you're more interested in the ideas themselves than in their formalizations or related nomenclature.

> ...but it makes you feel stupid if you don't.

Exactly. That's where I'm at right now; I know what Haskell is, I love the idea of it, I've enjoyed some of the fruits of it (XMonad). But it was when I tried to dig deeper into it that I felt lost, and yes, stupid. I've never been a math whiz; I am great at visualizing concepts but truly grasping the theory behind them is where I get lost. Based on my junior high school testing, I was placed in Advanced Algebra in my first year of high school. I nearly failed the class because it took me all year to grok the distributive property. I look back on that and I feel ashamed, because once I understood it, it seemed so damn simple! And so it is when I try to advance beyond my current level of programming skill; I hit brick walls and I feel like I left my sledgehammer at home. My pocketknife, even though I know every millimeter of it, won't cut through those walls.

Re: Early vs. Beginning Coders

#94

Post by alphast0rm »

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…

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, turn the faucet on until the glass is 80% full... etc.

Re: Early vs. Beginning Coders

#95

Post by lukas099 »

pbreit wrote: post #92

No. Just change the name of the book to "Learn Programming The Hard Way (Python Edition)". By putting the language in the title it sounds like it is for an experience programmer learning a new language, not for learning how to program.

True. When I started a major in CS, I had no programming experience. I started "Learn Python the Hard Way", but when I found out that I needed to learn C for Compilers, I tried to switch to "Learn C the Hard Way", thinking the two books were equivalent. They weren't.

Re: Early vs. Beginning Coders

#96

Post by afarrell »

c22 wrote: post #62
rgbrenner wrote: post #47

Earlier quoted context omitted.

jerf is right.. you have a mental model of how a programming language works, and a new language is just changing the syntax used to represent those same concepts. Does that mean there's no reason to switch? No.. since some languages are better at representing some ideas; some languages have better abstractions for certain ideas; etc. I think starting with a lower level language helps with this way of thinking. If you…

> I think starting with a lower level language helps with this way of thinking. If you learn everything about C (for example), and later learn a higher level language, it's easy to think of how you would implement a certain feature of the higher level language. I cannot agree with this more. A lot of people seem to think that a "better" language to learn programming with is one that is "easier" or "more forgiving", b…

> everyone I know who started with C became excellent programmers whereas ability among the group who started with something else is somewhat more hit or miss.

How much of this is survivorship bias?

Re: Early vs. Beginning Coders

#97

Post by bkmartin »

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…

And the name of the book???

Re: Early vs. Beginning Coders

#98

Post by learnstats2 »

zeroxfe wrote: post #23
tel wrote: 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.

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, you can use := and I think that notation would solve a lot of beginner and early programmer problems.

Re: Early vs. Beginning Coders

#99

Post by klibertp »

morganvachon wrote: post #93
klibertp wrote: post #81

Earlier quoted context omitted.

> Haskell does not need you to learn mathematics ...but it makes you feel stupid if you don't. Better to use "Real World OCaml" if you're more interested in the ideas themselves than in their formalizations or related nomenclature.

> ...but it makes you feel stupid if you don't. Exactly. That's where I'm at right now; I know what Haskell is, I love the idea of it, I've enjoyed some of the fruits of it (XMonad). But it was when I tried to dig deeper into it that I felt lost, and yes, stupid. I've never been a math whiz; I am great at visualizing concepts but truly grasping the theory behind them is where I get lost. Based on my junior high schoo…

I don't think the concepts are hard to understand, I think that - in Haskell - they're just being presented in a way that is incompatible with my way of thinking.

Having found Haskell materials as simply not suited for me I decided - quite a few years back - to learn Haskell (or the concepts behind Haskell, at least) my own way: by learning first Erlang (it sounded cool), then Scheme (mainly to be able to read many, many papers that use it), then OCaml and Scala (because the type systems and pragmatism) and finally Clean (to fill the last gaps in my knowledge). I progressed from dynamic to static typing and from eager to non-eager evaluation. It took me I think about 2 years to do all this and, of course, it wasn't that easy, but somewhat surprisingly it worked. I never wrote - and I'm not sure I ever will, but that's a completely different matter - any non-trivial Haskell code, yet I'm able to read and enjoy Haskell-related papers.

It's important to realise that there is always more than one way to learn things. You should know yourself well enough to see when the "normal" way simply isn't for you; this way you can go search for alternative ways. I guarantee that you'll find them, if you search hard enough :)

Re: Early vs. Beginning Coders

#100

Post by schoen »

egypturnash wrote: post #80
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…

Polite spelling correction: "tacit", not "tactic".

Thank you, that was simply a muscle memory problem.
Post reply on HN