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

161–170 of 178 posts

Re: Early vs. Beginning Coders

#161

Post by codexjourneys »

macNchz wrote: post #78
jordanpg wrote: post #54

Earlier quoted context omitted.

I just don't see it. No one would ever recommend learning Spanish and Mandarin at the same time, for any reason. All of the things you said are true, and yet the beginner has only so much time, so much patience, so much learning to do in one day. Given this, I see larger advantages to spending all of that time and energy in one ecosystem. There are many perspectives on, say, Java coding styles, patterns, and idioms.…

Learning two programming languages at the same time is definitely not comparable to learning Spanish and Mandarin at the same time...those two languages are so different that you won't gain anything from it. Learning, say, Spanish and Italian at the same time might be a better analogy, since you'll start to see word roots and constructions that are shared among romance languages. I think learning more than one progra…

Although I can't speak to learning two spoken languages simultaneously, learning a language similar to one I already knew (I knew Spanish, tried to learn Italian) was insanely difficult, because my brain couldn't distinguish them enough. It would get in a loop of searching for Italian words and running into Spanish words and then mixing them up.

On the other hand, learning German after already knowing Spanish was much easier -- and it was much easier to see the similarities and differences between the languages, because my brain would find the Spanish phrase while searching for the German one, and vice versa, but wouldn't get stuck in a loop about it.

Re: Early vs. Beginning Coders

#162

Post by schoen »

JoshTriplett wrote: post #152
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…

> Another example might be "if a field is included in a protocol and neither that layer nor a lower layer is encrypted with a key that you don't know, you can see the contents of the field by sniffing packets on the network segment". It might be challenging to find a citation for this claim! The term of art here (as used in patent law, for instance) would be "person having ordinary skill in the art". Something like t…

Patent cases are definitely going to include expert testimony on what someone with ordinary skill in the art knows or believes, but other kinds of court cases (or types of participation in a case) don't always have a simple opportunity to introduce expert testimony -- like writing an amicus brief.

So it would be pretty awesome to have the Book of Tacit Computing Knowledge somewhere.

Re: Early vs. Beginning Coders

#163

Post by codygman »

cbd1984 wrote: post #158
skrebbel wrote: post #109

Earlier quoted context omitted.

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

In Haskell, the facetious answer is simple: No instance for (Eq (a0 -> a0)) arising from a use of `==' That is, functions aren't comparable (for equality, anyway), so the type system won't allow you to compare them. The better answer is either "Look at their type signatures" or "See if they evaluate to the same values when given the same input"; the first is trivial, the second won't, in general, terminate, so you ne…

Why the down votes?

Re: Early vs. Beginning Coders

#164

Post by analog31 »

alphast0rm wrote: post #94
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,…

Oddly enough, you could repeat this exercise today, strictly with the computer itself. How would you request from a friend a list of the files in a particular folder whose names end with a particular extension? If it's a GUI based system, you have to be just as explicit as with the glass of water. In fact, written instructions for performing computer operations are often page after page of pictures of dialogs with circles and arrows, plus paragraphs of text. And your dialogs don't look the same because you have a newer version of the OS.

And people get them wrong.

This didn't really strike me until I started using Linux, even though I had originally learned on command line based computers. The same instructions for Linux users are a few lines that you enter into a terminal. I've even noticed a trend towards documenting Windows operations via a series of commands entered into the DOS box.

Re: Early vs. Beginning Coders

#165

Post by greenyoda »

FigBug wrote: post #156
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…

I was recently working on a case and I need a definition of software library. Couldn't find one anywhere. So many of the basics of programming are undefined it makes arguing about programming incredibly difficult -- see every discussion of what a functional language is or strong vs weak typing.

Wikipedia has an article on libraries, which includes the following definition:

"In computer science, a library is a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked."

https://en.wikipedia.org/wiki/Library_%28computing%29

Re: Early vs. Beginning Coders

#166

Post by [deleted] »

ezyang wrote: post #118
skrebbel wrote: post #109

Earlier quoted context omitted.

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

[deleted]

Re: Early vs. Beginning Coders

#167

Post by technomancy »

lmm wrote: post #33
zeroxfe wrote: 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.

This is one case where I wish Pascal had won. := for assignment, = for comparison.

Lisps have the distinction between `let` and `set!` which makes the distinction even clearer IMO.

Re: Early vs. Beginning Coders

#168

Post by technomancy »

jdeisenberg wrote: post #20
jacquesm wrote: post #12

Earlier quoted context omitted.

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.

True of Erlang but not of Racket; the latter can change "definitions" using set!.

Re: Early vs. Beginning Coders

#169

Post by technomancy »

uniclaude wrote: post #34

IMHO, Zed is right. I have been looking for books targeted to beginner programmers so I could recommend them to my friends, but most books unfortunately fail on this point. A Notable exception I found is "Learn you a Haskell for Great Good!". It is as good for beginning coders as it is for early (or advanced) ones. The author made the effort to describe some relatively basic things, and it was simple enough (okay, wi…

> I have been looking for books targeted to beginner programmers so I could recommend them to my friends, but most books unfortunately fail on this point.

My favourite book for this by far is How to Design Programs: http://htdp.org

It assumes knowledge of arithmetic and maybe a tiny bit of algebra but not much else.

Re: Early vs. Beginning Coders

#170

Post by michaelfeathers »

Zed points to a very real problem - it's easy for us to forget what we know. But there's another problem with targeting beginners. They are all over the place in terms of experience.

Computing is so tightly woven into our world not that it's hard to find people who have more than a passing interest in it who have not find some way to try to code as kids. Even with those who haven't, there's a gulf between people who have tried to do a little HTML editing (and know what a file is) and people who haven't. There's no one place to start. From Zed's description it looks like he's starting from the lowest possible point, but what are the demographics like there? How many people are in that space and are they mostly adults or children?

I think this is one of the main reasons why you don't see much beginner's material.

Post reply on HN