Early vs. Beginning Coders • Hacker News Board

Re: Early vs. Beginning Coders

#121

Post by icebraining » Wed, Jun 17, 2015, 8:57 PM UTC

xentronium wrote: post #106

danso wrote: post #45

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?) I guess YMMV...but most beginners I've worked with are confounded by why code interpreters are so literal. The double-equals sign versus an equals sign is one prom…

Notably, pascal uses `:=` and is one of the better first languages in my opinion for many more reasons (easy to grasp language core, simple non-null terminated strings, no actual need to learn pointers until the very advanced stages). Today I mostly advice other people to start with python though, because pascal feels somewhat dated and undertooled.

I think Python's behavior of disallowing assignment in expressions is good enough to avoid those mistakes; it's an anti-pattern anyway in the vast majority of cases.

Re: Early vs. Beginning Coders

#122

Post by sirclueless » Wed, Jun 17, 2015, 8:59 PM UTC

MarcScott wrote: post #113

"My favorite is how they think you should teach programming without teaching “coding”, as if that’s how they learned it." I often wonder about this. In the UK, with the drive to get every child 'coding', there are a large number of teachers that constantly talk about how the main skill that we should be teaching is 'Computational Thinking'. I wax and wane back and forth over this topic, in a very chicken and egg way.…

I don't think these things are all that different, in the very early stages.

The very first part of computational thinking is understanding that you can make a very specific and precise procedure to accomplish a task. If a student is at an age where reading and writing is easy, then learning the syntax of a language is a fine way to accomplish this. The student will spend a lot of time with each finicky word and symbol to make the computer behave, and while they may not recognize that they are defining an abstract procedure, the result is hopefully some intuition that the computer is a very predictable and reliable machine that does exactly what the code says, even if it's not what you meant. With exposure to more languages and by writing more programs, hopefully a student begins to recognize patterns and abstractions in their code, and that's the point at which they become real computational thinkers.

If a student isn't ready for that, there are still fun things to try. One cute one I've seen is "program your parent" exercise at a workshop. The child can make their parent move one step forwards or back, turn left or right, pick up and put down an object, and put one thing inside another. Can they make their parent pour a glass of juice? Or put a lego back in the box?

I don't think there is a chicken and egg problem here, because learning to make a dumb machine perform a task by following a procedure is the essence of computational thinking. Learning the basic syntax of a language is probably the most efficacious way to experience this for many students of many ages, even if the explicit goal is "do well on an AP test" or something mundane.

Re: Early vs. Beginning Coders

#123

Post by kedean » Wed, Jun 17, 2015, 9:06 PM UTC

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

While that is generally true, one should remember that programmers spend a lot of their time trying to help abstract that all away. I wouldn't ask my OS to open the top left cabinet and take out a glass, I would ask it to give me a glass. The OS was built by people who already know the optimal glass fetching method, so I just need to tell it what I want, not how.

The problem there is that if you want to get anything original done, you're gonna need to start getting to that low level where the abstraction isn't there. We sort of side-step this in education by starting with heavily abstracted systems like greenfoot, where you ONLY say what you 'want to happen', like 'object should move left'. Once students raised on those systems start to encounter real problems, they falter, because they've never had to cope with the computers stupidity before.

Re: Early vs. Beginning Coders

#124

Post by icebraining » Wed, Jun 17, 2015, 9:06 PM UTC

pdw wrote: post #112

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

It is a silly convention, really. Algol-60 didn't require them, and neither did any language in the Algol family (Pascal, Ada, Modula-2, etc). It used to be something peculiar to Fortran and C, but today every language imitates C...

Did Algol-60 have first class functions? It's not like Python just forces you to type the parenthesis to be meticulous; not typing them is perfectly valid code, it just means a different thing.

Re: Early vs. Beginning Coders

#125

Post by jamii » Wed, Jun 17, 2015, 9:10 PM UTC

jerf wrote: post #66

someguy2948 wrote: post #55

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…

To expand on the database point, there is a great paper by Stonebraker and Hellerstein covering the lessons learned and forgotten over the last 35 years of database research - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.113....

Re: Early vs. Beginning Coders

#126

Post by jordanpg » Wed, Jun 17, 2015, 9:38 PM UTC

dkersten wrote: post #43

jordanpg wrote: post #39

The only important trait I see that matters for either of these groups is a willingness to try things, push buttons, see what happens. A beginner worries about breaking the computer and doesn't yet understand that any question they have can be typed into a search engine verbatim and will probably be answered with 20 SO posts and 50 blogs posts. And early programmer is stumbling down this road. I don't know that this…

and ignore the din of people on the internet who claim to effortlessly, expertly jump among 10 languages as part of their day-to-day. The problem with this isn't whether or not that claim is true, but rather that (as you say) its not the right thing for a beginner. Its perfectly fine (desirable, even, IMHO) for an intermediate-to-expert programmer to know many (different) languages and use a few of them regularly (al…

I don't disagree with any of this.

My point is more about the sorts of stories and claims that a beginner will encounter while poking around the usual sites. One could be forgiven for wondering if most HN commentators are 60 year-old polyglots with a security clearance and two failed startups under their belt. It can seem daunting in the right context.

Re: Early vs. Beginning Coders

#127

Post by vectorjohn » Wed, Jun 17, 2015, 9:53 PM UTC

Lawtonfogle wrote: post #104

alphast0rm wrote: post #94

Earlier quoted context omitted.

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

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…

I saw this exact demonstration (PB&J) in I think 5th or 6th grade. Which would have been 1995/1996. This was before I had any interest in software. But I do remember that, in fact I was thinking about it when reading earlier comments in this thread! So maybe it stuck with me and helped in some way.

Re: Early vs. Beginning Coders

#128

Post by rhinoceraptor » Wed, Jun 17, 2015, 9:56 PM UTC

tehwalrus wrote: post #101

jackmaney wrote: post #72

Earlier quoted context omitted.

Perl doesn't require "()" after the name of a function to call the function. In fact, parentheses aren't required for function calls at all. The code: use strict; use warnings; sub foo { print "In foo\n"; print "args = " . join(",",@_) . "\n" if @_; } foo; foo "a", "b", "c"; yields the output: In foo In foo args = a,b,c

Neither does ruby. (Which is really really confusing if you spend your days in python, and occasionally have to edit something in ruby.)

It's even more confusing if you have to figure out if you're calling a method or referencing a variable.

The code could be assigning a new variable from a method return value, or just from an existing variable.

Re: Early vs. Beginning Coders

#129

Post by vectorjohn » Wed, Jun 17, 2015, 10:01 PM UTC

lelandbatey wrote: post #115

kevinschumacher wrote: post #88

Earlier quoted context omitted.

"what's a tokenizer? what's an interpreter?", said the beginner.

I think of even greater note is: > I don't think we needed to know how to use anything but strings, functions, and arrays Strings, functions and arrays comprise a huge amount of information. Many C programs of rather frightening complexity and functionality could be written with just those primitives. When we think of a beginner, we have to imagine that they have the computer science knowledge of a child. Would you a…

When I was new to programming, and almost 100% self taught, I wanted to make a game.

It was Q-BASIC, in about 1998. I made a top-down space shooter where you fly a ship, and meteors and other objects come down the screen and you shoot them.

Somehow, I had missed or glossed over the part of my self teaching that included arrays. I didn't know what that was. My program was written with variables like $ax1, $ax2, etc (asteroid X position 1), and collision detection was a big pyramid of "if $ax1 > $ax2 AND $ax1 I was always wondering how someone would write a program where there was some configurable number of things on the screen? What if I wanted to crank up the difficulty and have 20 simultaneous things moving!?

So yeah, you can get a lot done with some really basic stuff.

Re: Early vs. Beginning Coders

#130

Post by lmm » Wed, Jun 17, 2015, 10:12 PM UTC

orbitur wrote: post #38

lmm wrote: post #31

Earlier quoted context omitted.

That's only "basics" if you've got the wrong idea. There are millions of possible mistakes, no beginners' guide can explicitly address every one. People told you to just use the string - wasn't that a good enough answer?

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