Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stanford study shows success of different programming styles in CS class

ed.stanford.edu

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Stanford study shows success of different programming styles in CS class

#31

Post by datenwolf »

Dewie wrote: post #22
datenwolf wrote: post #13

Earlier quoted context omitted.

> Test what you write as quickly as you can. Until you run into that one problem where you can't test between the small steps, because you need the whole thing to be up (to some degree) and working for any test to work. Operating system kernels would be an example of that: The best test for a *nix OS kernel is, if it can run a shell. You need all the essential syscalls to do something sensible and if any of the requi…

> Operating system kernels would be an example of that: The best test for a *nix OS kernel is, if it can run a shell. You need all the essential syscalls to do something sensible and if any of the required parts doesn't work the whole thing fails. How do you test kernel? Run a virtualised kernel? I think at least DragonflyBSD supports that.

Kernel debugging always has been kind of a dark art. What helps greatly is if you can tap into the CPU using some hardware debugging (JTAG or similar).

Today you can also exploit the busmaster DMA capabilities of IEEE1394 to peek into system memory.

However the still most widely used method is pushing debug messaged directly into a UART output register, bypassing any driver infrastructure, and hooking up a serial terminal on the other end.

Re: Stanford study shows success of different programming styles in CS class

#32

Post by Derander »

willvarfar wrote: post #27
ynniv wrote: post #15

It sounds like they discovered that some people already knew how to program.

> 70 students enrolled in an introductory undergraduate course in programming methodology I'm curious about that too; is this course optional? Would people who can already program take this course?

I TA for this class. The class is optional for non-engineering majors but has enrollment >= 700 people per quarter. So many people at Stanford take the class that it's a bit of a cultural phenomenon.

There are three "intro" programming classes at Stanford. CS106A is "intro to java", CS106B is "intro to C++", CS106X is CS106A + CS106B + a bit more in one quarter. People who already know how to program are encouraged to take one of the latter two, although there is always a contingent of people with /some/ background in 106A.

Re: Stanford study shows success of different programming styles in CS class

#33

Post by skywhopper »

It's not necessarily surprising that they might be able to detect students who will likely perform poorly in the course overall by monitoring their behavior early on. But the real challenge is not in determining which students are struggling, but rather in when and how you should intervene to improve these students' chances of success.

Re: Stanford study shows success of different programming styles in CS class

#34

Post by markbnj »

>> Alpha students, explained co-author Piech, moved efficiently from one point to another as they wrote code, creating a streamlined program. Beta and gamma students, on the other hand, wrote themselves into so-called “sink states” in which their programs slammed into dead ends from which they had to back out before they could resume progress.

Very interesting, and intuitively right to me. The difference is likely in the ability to create and maintain a consistent mental model of the program's structure and behavior during the implementation.

Re: Stanford study shows success of different programming styles in CS class

#35

Post by humanarity »

partition wrote: post #3

What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Is this the next programming motto after "Don't Repeat Yourself"? Don't Get Stuck! Now how does one avoid getting stuck while programming? I still get stuck a lot, but these really helped: - Test what you write as quickly as you can. - Hold it in your head! Or you won't have a clue what all y…

Yeah I really reckon that "what is the simplest thing that could possibly work" is the vital question. If you stray from that, getting stuck wastes what could otherwise be productive effort. I do have to wonder tho -- why is programming so complicated? Silicon and neurons so fundamentally different that we're always going to be fighting ourselves -- or one day we're going to have interfaces make programming way more natural?

Re: Stanford study shows success of different programming styles in CS class

#36

Post by MichaelGG »

Derander wrote: post #32
willvarfar wrote: post #27

Earlier quoted context omitted.

> 70 students enrolled in an introductory undergraduate course in programming methodology I'm curious about that too; is this course optional? Would people who can already program take this course?

I TA for this class. The class is optional for non-engineering majors but has enrollment >= 700 people per quarter. So many people at Stanford take the class that it's a bit of a cultural phenomenon. There are three "intro" programming classes at Stanford. CS106A is "intro to java", CS106B is "intro to C++", CS106X is CS106A + CS106B + a bit more in one quarter. People who already know how to program are encouraged t…

For non-engineering people, Java seems like a slightly odd choice, is it not? So much overhead in learning, plus overhead if they did want to integrate coding into their lives in a light way. Why not Racket or a scripting language? As much as it pains me, even JS might be of better use.

Or is it just the case that these people just wanna take one course from the "real" CS for a non-coding reason?

Re: Stanford study shows success of different programming styles in CS class

#37

Post by auxym »

khalilravanna wrote: post #28
willvarfar wrote: post #27

Earlier quoted context omitted.

> 70 students enrolled in an introductory undergraduate course in programming methodology I'm curious about that too; is this course optional? Would people who can already program take this course?

Anecdotally, at my university (graduated 2013 so still a recent experience), a lot of CS students took the intro to programming course. In fact, it was (and still is) a requirement for a BS in CS at the school. The only way you could get out of it was if you had taken AP CS in high school and passed the test for the credits. A large majority of my CS friends in that class had all been programming for either a little…

Similar experience in my two first-year Matlab classes in mechanical engineering.

Re: Stanford study shows success of different programming styles in CS class

#38

Post by AustinBGibbons »

Hey! I worked on the preliminary efforts of this project in 2012, and was also a grader for the course. (I'm "Gibbons, A." in the citation list)

Many people are making great points - there's a wealth of uncontrolled variables (ie some students already know how to program), but it was a fascinating dataset and I could even see the paradigms play out over the quarter during discussions with my students, both experienced programmers and students getting their first exposure to programming.

I would offer as a larger takeaway that work like this has the potential to vastly increase our understanding of learning and development with the rise of MOOCs, ipads-in-every-classroom, and of course IDEs that save every incremental compilation :-)

Oh and as another mention - working with Marcelo and Paulo was awesome, both are super passionate, intelligent dudes.

Re: Stanford study shows success of different programming styles in CS class

#39

Post by the_watcher »

>> the authors did not find any correlation between the amount of “tinkering” — which is often thought to signify lack of programming expertise — and course performance. However, the authors found that students who changed their programming style — going from being a “planner” to a “tinkerer,” or vice versa — were the ones who performed best, suggesting that behavior change (rather than learning one single behavior) was determinant for course performance.

Not being flippant: The conclusion here seems to be evidence of an ability to learn something new, regardless of what, is strongly indicative of performance.

Re: Stanford study shows success of different programming styles in CS class

#40

Post by taeric »

lmm wrote: post #29
datenwolf wrote: post #13

Earlier quoted context omitted.

> Test what you write as quickly as you can. Until you run into that one problem where you can't test between the small steps, because you need the whole thing to be up (to some degree) and working for any test to work. Operating system kernels would be an example of that: The best test for a *nix OS kernel is, if it can run a shell. You need all the essential syscalls to do something sensible and if any of the requi…

> Operating system kernels would be an example of that: The best test for a *nix OS kernel is, if it can run a shell. You need all the essential syscalls to do something sensible and if any of the required parts doesn't work the whole thing fails. So start with something simpler. Start by making a kernel that can run /bin/true, that never reclaims memory, that only boots on whichever VM you're using for testing. You…

If you haven't, you really need to see this post.[1] Starting simple and writing a test driven algorithm is not necessarily bad. However, realize that you are really just turning the act of finding the optimum solution into a search space where you have to assume mostly forward progress at all times. Not a safe assumption. At all.

And, because I love the solution, here is a link to my sudoku solver.[2] I will confess some more tests along the way would have been wise, though I was blessed by a problem I could just try out quickly. (That is, running the entire program is already fast. Not sure of the value on running the tiny parts faster.)

[1] http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

[2] http://taeric.github.io/Sudoku.html

Post reply on HN