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

GitHub Classroom

classroom.github.com

Post reply on HN
Print view View original

121–130 of 171 posts

Re: GitHub Classroom

#121

Post by the_af »

2OEH8eoCRo0 wrote: post #109
bayindirh wrote: post #106

Earlier quoted context omitted.

> A readable incorrect program is worse than an unreadable correct one. That neither is acceptable doesn’t negate that. I will happily fix a readable but non-working code rather than maintain a working but unreadable code any day under the sun.

We are talking about teaching. You guys wonder why students graduate who can't code- professors who passed them because their shit that doesn't work looked nice.

Students who pass who can't code aren't the ones doing the coding (clear or unclear) in my experience. When doing homework, these students focus on higher level concepts and let the people who love coding do the actual coding.

This is based on my actual experience at university, not a random guess. It's never a case of "teachers weren't strict about working code", it's a case of "student didn't focus on coding, let others do it". Note that in proper CS (as opposed to a "coding school" or bootcamp) this is semi-acceptable, since CS is much more than just coding.

I do find it puzzling, because how can you study CS if you don't enjoy coding? But surprisingly enough, a lot of people who study CS don't actually love coding. Some actually love maths.

Re: GitHub Classroom

#122

Post by poplarstand »

maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

I believe that there is a strong argument to be made for the middle ground. Like you, I have been both a teacher and student, often at the same time, and was exposed to the trade-offs that any educational paradigm will have to make.

My current favorite approach is the one taken by Udacity in their "Nanodegree" programs. Much of the coursework is tied to autograders, which offer quick (if not very nuanced) feedback on the work performed. The culmination of each unit is a project evaluated by a human being, allowing for guidance on a more personal level.

In the absence of 1:1 tutoring, a hybrid model like this would be the base for my ideal class structure.

Re: GitHub Classroom

#123

Post by bpyne »

elcomet wrote: post #97
maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

> I saw some student fail to produce a correct program but had a well organized code. I don't necessarily agree with this. Programs are not designed to be readable, they are designed to solve a problem. The first goal is to get the correct program, and only after, it is important to make the code readable. A readable code that doesn't work is not worth much. As a former student, I think automatically graded assignmen…

"Programs are not designed to be readable, they are designed to solve a problem."

Programs are written to solve a problem. They are designed to be understood by others who might have to debug or modify them due to new requirements.

Re: GitHub Classroom

#124

Post by TechBro8615 »

maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

I had one professor who used private (30%) and public (70%) tests. You could iterate on the public tests up until the submission deadline. But you never saw the private tests until the professor ran them on your program after you submitted it.

I think this was a good middle ground that forced you to think beyond the rigid parameters of the public tests, and discouraged things like “switch” statements.

Quality of code was also a component, as determined by a TA.

Re: GitHub Classroom

#125

Post by 2OEH8eoCRo0 »

bayindirh wrote: post #118
2OEH8eoCRo0 wrote: post #109

Earlier quoted context omitted.

We are talking about teaching. You guys wonder why students graduate who can't code- professors who passed them because their shit that doesn't work looked nice.

> We are talking about teaching. I'm heeding the way of my professor. She cut serious points from non-working code as expected but commented on our code in great extent regardless of its state. She one to one explained to all of her students why their code didn't work. She similarly reduced grade of a working but, non-readable code and she clearly told why she did that. Also you got bonus points for informed experime…

Yes, that's good. Nobody is saying that code cleanliness is worth 0 and working code is worth 100. Working code is the most important metric but cleanliness, extensibility, etc are also important but secondary.

Your professor did exactly the same that mine did back when I was in university. Your code works? Good, you've met the minimum requirements, you'll pass. Your code has to be immaculately written and commented if you want a full perfect grade though.

Re: GitHub Classroom

#126

Post by andreareina »

fastball wrote: post #87
reustle wrote: post #42

Earlier quoted context omitted.

Please don't use code blocks for quoting text until HN finally fixes their css on mobile. > Delete repositories > Ability to delete any adminable repository > This application will be able to delete any repository to which you have admin rights.

Seems like it might be better to pressure HN to fix a clear bug by continuing to use this formatting though.

Arguably the bug isn't the rendering of code blocks, but using them to delineate quotes.

Re: GitHub Classroom

#127

Post by IggleSniggle »

dheera wrote: post #55
reustle wrote: post #42

Earlier quoted context omitted.

Please don't use code blocks for quoting text until HN finally fixes their css on mobile. > Delete repositories > Ability to delete any adminable repository > This application will be able to delete any repository to which you have admin rights.

You can inject your own CSS on Firefox mobile. It's also great for getting rid of popups and paywalls.

This does not appear to be true on iOS? If it is...how?

Re: GitHub Classroom

#128

Post by bpyne »

2OEH8eoCRo0 wrote: post #109
bayindirh wrote: post #106

Earlier quoted context omitted.

> A readable incorrect program is worse than an unreadable correct one. That neither is acceptable doesn’t negate that. I will happily fix a readable but non-working code rather than maintain a working but unreadable code any day under the sun.

We are talking about teaching. You guys wonder why students graduate who can't code- professors who passed them because their shit that doesn't work looked nice.

Your comment harks to a much broader concept. Are Computer Science programs supposed to produce software engineers or people grounded in the theory?

My own opinion is that separate tracks should exist.

Grading students more harshly without modifying the focus of their studies simply won't produce better people in the field.

Re: GitHub Classroom

#129

Post by sradman »

ShamelessC wrote: post #119
sradman wrote: post #114

Earlier quoted context omitted.

> I don't see anything in the feature list about how they handle "pure documents". True, but I’m taking the product name “Github Classroom” seriously. Maybe it should have been named “CSLab”. I think that the Scrum-like tools and processes that developers have refined over the last decade can be used in any endeavour that generates digital artifacts from text source files. Github/Gerrit workflows seem ideal for these…

> but I’m taking the product name “Github Classroom” seriously. Maybe it should have been named “CSLab”. I also was confused about the scope they are going for with this. My initial assumption was that since it's GitHub, it's probably mostly for coding lessons. I read your comment though which implied it could be used for more generic lessons and I mistakenly assumed you had used the offering and had more info about…

> Are you suggesting complicated version control could be useful for e.g. some group of teens doing a 6 paragraph research paper in their social studies class?

Yes, kinda. I am suggesting that revision history is a powerful tool. The concept of change control has long been a staple of science and engineering. So yeah, I see a group of teens working on a a three file project, Report.md, TODO.md, and Links.md very useful. The complicated part I could live without but using non-standard tools is not desirable either.

If there is a WebUI then it simply looks like a Wiki with file history.

Re: GitHub Classroom

#130

Post by H1Supreme »

elcomet wrote: post #97
maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

> I saw some student fail to produce a correct program but had a well organized code. I don't necessarily agree with this. Programs are not designed to be readable, they are designed to solve a problem. The first goal is to get the correct program, and only after, it is important to make the code readable. A readable code that doesn't work is not worth much. As a former student, I think automatically graded assignmen…

> Programs are not designed to be readable, they are designed to solve a problem

I assume you've not had much experience with any legacy code where: if statements span hundreds of lines, variables have cryptic names which mean nothing to anyone but the original author (who is gone), and a distinct lack of comments.

I'm in the middle of such a project, and the lack of readability is severely inhibiting my ability to move forward. In fact, I've had to write software to parse this source code, just to follow the flow of logic.

This might be an extreme example, but it highlights how important readability is.

Post reply on HN