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

41–50 of 53 posts

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

#41

Post by spion »

kifler wrote: post #25
ynniv wrote: post #15

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

Having recently (last year) enrolled in a Computer Programming program, I can say this is likely the case. The class has a number of people who are simply enrolled to get a piece of paper that states they know how to code and then there are those that are breaking new ground in learning. I have the logic down quite well but my biggest issue is the syntax - it would appear that Stanford thinks I'm doomed to fail.

One of the most touted advantages of Scheme (and other Lisps) as a teaching language is precisely the (lack of) syntax which allows the student to focus on logic.

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

#42

Post by GrinningFool » 

    > "The discovery of these “sink states,” and how students 
    > got into them, offers opportunities beyond predicting 
    > grades: They open the door for developing systems to 
    > encourage students to go down more fruitful paths before 
    > they become lost in the programming weeds."
In the real world, my most valuable learning experiences have been those dead ends. Because I don't repeat those mistakes - better to make them and learn from them than to be steered away from them before they happen.

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

#43

Post by jeo1234 »

MichaelGG wrote: post #36
Derander wrote: post #32

Earlier quoted context omitted.

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?

I think the best language to teach as an intro to coding for non-engineering, non-compsci folks would be python or maybe ruby.

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

#44

Post by lmm »

taeric wrote: post #40
lmm wrote: post #29

Earlier quoted context omitted.

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

I've seen it, but it's just utterly alien to my experience. Partly the problems I encounter professionally don't look much like Sudoku; partly the things that are important on a large codebase are different from the things that are important in a small example. But mostly I think people realise they're not getting somewhere - and if they don't, others will point it out. That's partly why TDD tends to be found in the same place as agile with daily standups - you get that daily outside view that stops you just spinning your wheels the way that blogger did.

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

#45

Post by convivialdingo »

Completely anecdotal, but I vividly remember my own experience learning to program.

I learned in a vacuum, having nobody around with any software experience. I was given a PC and then saved up for an Amiga 500 (and later a $500 Lattice C compiler). My only link to software was through the bookstore and magazines.

Being a nerd, my main motivation at the time (of course) was to make a D&D game. I remember my first code was in Basic (no subroutines!) so I eventually learned to create subroutines based on line numbers (100-900 was main, 1000 was map, 1100 was character A, etc)

I managed to make about 50% of a single game before I ran out of memory. So I then set out to shrink (optimize) what I had made. After reading an article on dungeon map creation, I figured out that large arrays could replace the hand-coded drawing I had written. Check.

Ok, so now I start doing everything in arrays and pretty soon my code is smaller but "fixing stuff" (maintaining code) was stupidly hard. Oh okay, so I learned then some that data and code should be together rather than global (encapsulation).

I then needed to create random maps. After struggling with that, I read a paper on fractals, and implemented my first algorithm.

You can probably guess by now where I'm going with all this... I had crudely recreated many things by knocking up against hardware and brain limitations and figuring out how to work around them.

I progressed into Pascal, C, C++, assembly and eventually created my own assembler and graphical operating system at 16 years old. It was not a thing of beauty, but it did work. (Time was free, and compilers weren't cheap.)

I think that most people learn programming by failing, hitting traps, finding limits, crashing, burning and trying again. The only real identifier of outcomes, in the long term, is the willingness to continue trying and learning from mistakes.

So from my point of view, the outcomes of the paper are arbitrary in the long term. I would definitely had been a "Gamma" programmer. I hit every problem, and got terribly stuck. It took years for me to progress, learn good practices and become a proficient developer.

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

#46

Post by marssaxman »

spion wrote: post #41
kifler wrote: post #25

Earlier quoted context omitted.

Having recently (last year) enrolled in a Computer Programming program, I can say this is likely the case. The class has a number of people who are simply enrolled to get a piece of paper that states they know how to code and then there are those that are breaking new ground in learning. I have the logic down quite well but my biggest issue is the syntax - it would appear that Stanford thinks I'm doomed to fail.

One of the most touted advantages of Scheme (and other Lisps) as a teaching language is precisely the (lack of) syntax which allows the student to focus on logic.

One might as well claim that C++ has no syntax, as its source code is nothing but a linear series of undifferentiated octets. Scheme and other lisps have plenty of syntax; it's just expressed at a different level of abstraction than the one most languages use.

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

#47

Post by taeric »

lmm wrote: post #44
taeric wrote: post #40

Earlier quoted context omitted.

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…

I've seen it, but it's just utterly alien to my experience. Partly the problems I encounter professionally don't look much like Sudoku; partly the things that are important on a large codebase are different from the things that are important in a small example. But mostly I think people realise they're not getting somewhere - and if they don't, others will point it out. That's partly why TDD tends to be found in the…

I have seen exactly this style of thinking happen in a large code base. Some of it was my own, sadly.

The odd thing to me, is you say this still of problem doesn't happen in a large code base. But, to me, this style of problem just happens many times in a large codebase. That is, large problems are just made up of smaller problems. Have I ever used the DLX problem? No. Do I appreciate that it is a good way to look at a problem you are working? Definitely. I wish I had more time to consider the implications there.

More subtly in your post, to me, is the idea that with the right people the problems don't happen. This leads me to this lovely piece.[1]

[1] http://www.ckwop.me.uk/Meditation-driven-development.html

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

#48

Post by taeric »

GrinningFool wrote: post #42

> "The discovery of these “sink states,” and how students > got into them, offers opportunities beyond predicting > grades: They open the door for developing systems to > encourage students to go down more fruitful paths before > they become lost in the programming weeds." In the real world, my most valuable learning experiences have been those dead ends. Because I don't repeat those mistakes - better to make them an…

Relatedly, I have seen plenty of very smart people that were able to bowl over these "sink states" completely unaware of just how unmaintainable their ultimate solution was.

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

#49

Post by partition »

bjwbell wrote: post #12
VMG wrote: post #8

Earlier quoted context omitted.

> What was interesting is that the higher-performing group (Alpha) was stuck less often that the lower-performing group (Gamma). Which may just be correlated with high performance, not necessarily the cause. If you make "don't get stuck" a motto, you can easily imagine people skipping over difficult problems and not thinking about a good solution.

"don't get stuck" reminds me of the feynman method of problem solving: 1. Write down the problem. 2. Think very hard. 3. Write down the answer. Rich Hickey's Hammock Driven Development, https://www.youtube.com/watch?v=f84n5oFoZBc , is IMO very good for actually not getting stuck in a bad place problem solving.

Wow, this was a big wake-up call. It's ironic because I am in research and I always did a lot of theory and problem definition up front for whatever I did, but I am now in this "reckless rapid prototyping" phase where if I get some idea I have to try it out RIGHT NOW, stepping back be damned. Ironically it results in getting stuck more than I would have wanted!

I guess this is the fourth tip?

- Step away from the computer

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

#50

Post by partition »

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

> Hold it in your head! Or you won't have a clue what all your code, together, is doing. Do you mean to say: if you can't hold it all in your head, you're overcomplicating things? Because if so, I agree. I just finished giving an introduction to programming course, using Processing. I tried teaching my students to write structured code from the start, splitting functionality into smaller methods as much as sensible.…

> - "The computer only does what it is literally instructed to do. What do you literally want to do? What are you literally instructing the computer right now?"

I feel like after you really know a system you almost start thinking only in terms of its components. "Hmm I want to do X...somehow I just automatically thought to modify function Y and call it in module Z."

Post reply on HN