Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

171–178 of 178 posts

Re: Early vs. Beginning Coders

#171

Earlier quoted context omitted.

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

True: minecraft is the new teletype - I like it

Re: Early vs. Beginning Coders

#172

Earlier quoted context omitted.

Day one CS 101 class. Bring in a few loaves of bread, jars of peanut butter, and jars of jelly, with a few utensils. Also, lots of paper napkins. Have the students spend 10-15 minutes writing a 'how to make PB&J sandwiches'. Select volunteers to read their instructions while you follow them as a computer would. Explain that this is how computers work. Get some bread: grabs entire loaf of bread, uses the entire loaf f…

One problem is that programmers accept this stupidity from the machine rather than try to fix it. For example, if the computer had a definition of a good PBJ and some sort of solver, it might just figure out how to construct a PBJ with the given materials. Or maybe it would ask for clarification of some steps. Of course we don't want to treat all problems as general cases to be solved on the fly, but I don't think we…

Programmers don't accept it, which is why higher level languages exist. At some point it reaches 'good enough' and most of us settle with some language, but there are always others pushing out new languages to fix some shortcoming they see.

Re: Early vs. Beginning Coders

#173
post #120
post #103

Earlier quoted context omitted.

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

Sure. Of course explaining the why is most important.

Re: Early vs. Beginning Coders

#174

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.

> A variable in algebra is exactly what you consider a constant in a programming language.

I disagree. A constant is not expected to change, a variable is absolutely expected to change.

The difference is that a mathematical variable changes "between invocations" of a mathematical statement. An "assignable" changes "within invocations".

Re: Early vs. Beginning Coders

#175
post #118

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.

I think they might have meant "whether two functions are structurally identical"—i.e. whether their post-link-load-phase object-code hashes the same, presuming they're both position-independent.

Re: Early vs. Beginning Coders

#176
post #157

Earlier quoted context omitted.

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

Dunno. If someone asked me how to get the bytes of a string, I would ask why. Not because theres The Right Way to do things, but because they might be doing things The Hard Way. A why can reduce the amount of code written by 100%.

Sure, but when someone is first learning, frequently the true answer to "why are you doing that" is "to see what happens" (even if they have some flimsy justification within their pet-project at the time.) Giving them the answer lets them go back to experimenting so they can see, for themselves, why the path they're heading down might not be such a good idea. Formative experiences and such.

Re: Early vs. Beginning Coders

#177
post #176
post #157

Earlier quoted context omitted.

Dunno. If someone asked me how to get the bytes of a string, I would ask why. Not because theres The Right Way to do things, but because they might be doing things The Hard Way. A why can reduce the amount of code written by 100%.

Sure, but when someone is first learning, frequently the true answer to "why are you doing that" is "to see what happens" (even if they have some flimsy justification within their pet-project at the time.) Giving them the answer lets them go back to experimenting so they can see, for themselves, why the path they're heading down might not be such a good idea. Formative experiences and such.

Yeah, that's a fine answer. But they might just not know of the other way to do things.

Like, in Java, for a long time I didn't know there was an output stream that you could write a string directly, so I was always getting the bytes to write it. I wouldn't call that a formative experience.

Re: Early vs. Beginning Coders

#178
post #66

Earlier quoted context omitted.

I've been hearing for years about how the javascript community is constantly rehashing things from the mainframe world or the desktop world. I haven't really been programming long enough to see it happen, though, (my first programming book was along the lines of "how to AJAX"). Could you be so kind as to mention some examples of javascript libraries or techniques that are recycling failed concepts from past decades?

"Failed" is too strong. Many of them are good ideas for certain use cases, but also have certain well-known problems, which is frankly true of everything. Event-based programming was not discovered by Node. It was the dominant paradigm for decades, plural, on the desktop, and still is how all GUIs work, on all platforms, current and past. I've got a big blog post on deck about this one, actually, so I'll save the wel…

This was a very pleasant read, thank you!
Post reply on HN