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

161–170 of 171 posts

Re: GitHub Classroom

#161

Post by 3PS »

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

One of my favorite classes had a few simple tests provided by the professor, and the rest of the tests were provided by students. Our grade was based on our score on the overall test suite, combined with the quality of our own provided test case, our code quality as judged by a TA, and an external writeup. This was fun because it encouraged students to create brutally hard tests to cover all sorts of corner cases in a way that was openly available to everyone.

Re: GitHub Classroom

#162

Post by downerending »

kasey_junk wrote: post #102
thomascgalvin wrote: post #100

Earlier quoted context omitted.

> Programs are not designed to be readable, they are designed to solve a problem. This is 100% incorrect. If a developer submits a PR that works and if fast, but cannot be understood by the rest of the team, it can, should, and will be rejected. 80% of software's lifetime is spent in maintenance. That clever hack or ugly patch might work today, but you're going to hate yourself for it in a month. There are exceptions…

The broader theme of that comment was that ‘correct’ is table stakes. A readable incorrect program is worse than an unreadable correct one. That neither is acceptable doesn’t negate that.

Unfortunately, correct is a function of time, and almost all correct programs become incorrect at certain points of their lives. Maintainability is a thing, and I've learned to lean pretty sharply in the direction of just shitcanning unreadable code.

As a corollary, unreadable code almost always seems to have a lot of latent bugs that simply haven't been observed yet.

Re: GitHub Classroom

#163

Post by marcolussetti »

user5994461 wrote: post #78
ShamelessC wrote: post #67

Earlier quoted context omitted.

This is peak hacker news. I'm not entirely certain I'm understanding your concern as I don't see anything in the feature list about how they handle "pure documents". My assumption is that they expect you to use markdown for such submissions (a valid choice for programming-based learning) and you're suggesting this should be more widespread and used for teaching other subjects? > At what age do kids embrace Markdown a…

>> But I know of adults who are barely interested in or capable of using Word/Google Docs correctly. I think markdown would work precisely because of this. Word is too hard to use and too easy to create documents that are impossible to edit by a second person. For context. I've just watched my wife trying for 20 minutes to add one item to a bullet list, with the proper indentation and numbering of course. Mission imp…

I admittedly haven't used it in some time, but Typora felt like it would fit the bill as a solid editor with WYSIWYG live editing/preview, and export to PDF (admittedly that isn't bundled it directly, you have to install pandoc I think?)

Re: GitHub Classroom

#164

Post by OkayPhysicist »

jsinai wrote: post #40
OkayPhysicist wrote: post #37

Earlier quoted context omitted.

Markdown is out of its league for proper typestting. LaTeX is superior in a major way.

Markdown is dead simple, quick and has minimal overhead. Sometimes the power of convenience trumps the power of features. It’s a trade-off. I would hate to have to use LaTeX for every small document I compose, but then I would hate to write anything longer than 3-4 pages in Markdown or that really required formatting (like a thesis). It comes down to flexibility and what the requirements are.

The required LaTeX for simple documents is correspondingly simple. You need less than 10 commands to generate a normal essay, and most are the same in everything. The power of BibTex alone makes it worth it, especially when all academic databases output BibTex entries.

Re: GitHub Classroom

#165

Post by Seirdy »

ShamelessC wrote: post #67
sradman wrote: post #22

This type of system seems obvious for programming courses but I wonder how intuitive it is for pure documents; the classic essay or report style assignments. At what age do kids embrace Markdown as the single source of truth for their documents? Do technical writers within Google use Gerrit, or whatever their Perforce based review process is called, as a core part of their collaborative workflow like coders do?

This is peak hacker news. I'm not entirely certain I'm understanding your concern as I don't see anything in the feature list about how they handle "pure documents". My assumption is that they expect you to use markdown for such submissions (a valid choice for programming-based learning) and you're suggesting this should be more widespread and used for teaching other subjects? > At what age do kids embrace Markdown a…

Plenty of middle schoolers can handle Reddit commenting just fine. I know I wasn't the only person in high school writing essays in Neovim with Pandoc. A friend and I would do our peer reviews in English by diffing our papers.

Markdown is incredibly straightforward. I'm quite sure it's easier to pick up than a word processor; you can explain all basic formatting on half a page instead of making kids watch a series of YouTube videos on now to use [whatever word processor is hip nowadays]. Programs like Pandoc make it easy to incrementally transition to LaTeX by inlining it in Markdown documents.

I'd say that ideally, teachers should "support" a few programs, but allow students to use any program that can conform to a reasonable style. Either that, or just have students paste their essay text into a box.

Re: GitHub Classroom

#166

Post by Seirdy »

saagarjha wrote: post #159
hanniabu wrote: post #91

Earlier quoted context omitted.

You can still submit .txt documents

Try doing that in 11th grade English class when the teacher asks for MLA format.

Solution: replace MLA requirements with an HTML form that accepts plain text. Teach students how to click the BibTeX link on Google Scholar, and how copy/paste works. Now they can submit their papers and citations.

Re: GitHub Classroom

#167

Post by bayindirh »

bpyne wrote: post #128
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.

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.

> Are Computer Science programs supposed to produce software engineers or people grounded in the theory?

I'm a graduate of a program called "Computer Engineering" which infuses a good deal of theory coupled with hardware and programming internals (gates, ALUs, programming language design, theory and implications, etc.)

As a person who absolutely loves coding, I immensely enjoy writing code while being able to visualize/understand how it will execute on the hardware. New CPUs blur the things continuously though.

Re: GitHub Classroom

#168

Post by bpyne »

bayindirh wrote: post #167
bpyne wrote: post #128

Earlier quoted context omitted.

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.

> Are Computer Science programs supposed to produce software engineers or people grounded in the theory? I'm a graduate of a program called "Computer Engineering" which infuses a good deal of theory coupled with hardware and programming internals (gates, ALUs, programming language design, theory and implications, etc.) As a person who absolutely loves coding, I immensely enjoy writing code while being able to visuali…

CE mixes low and high level concepts well. I've never had a hardware class but have a copy of Tanenbaum's hardware book. It gives me hand-wavy notion of how the processor operates. But I'd never apply for a hardware programming job. Eventually I'm going to take a class in computer architecture.

While I used an "or" in my statement the reality is that most CS programs give a smattering of different CS areas including theory, SE, and hardware. SE is often one course in a 4 year program. A developer simply can't develop the skills for SE in one course.

When I was in grad school for CS I had a course with the department chair. I had been in the field for 20+ years at that point. One day she asked me for feedback on how to improve the undergrad program for students who want to go into the field. My response was a separate track that required practical year-long projects requiring SE skills. Each year the project could get progressively more involved. Students in this track would still need courses like data structures, algorithms, and programming language paradigms. But they would apply the knowledge from them to practical projects.

Re: GitHub Classroom

#169

Post by coolreader18 »

ShamelessC wrote: post #67
sradman wrote: post #22

This type of system seems obvious for programming courses but I wonder how intuitive it is for pure documents; the classic essay or report style assignments. At what age do kids embrace Markdown as the single source of truth for their documents? Do technical writers within Google use Gerrit, or whatever their Perforce based review process is called, as a core part of their collaborative workflow like coders do?

This is peak hacker news. I'm not entirely certain I'm understanding your concern as I don't see anything in the feature list about how they handle "pure documents". My assumption is that they expect you to use markdown for such submissions (a valid choice for programming-based learning) and you're suggesting this should be more widespread and used for teaching other subjects? > At what age do kids embrace Markdown a…

I really do agree that this is peak hackernews, but I'm a kid (or legal minor, at least) and I wrote both my AP exam essays in Markdown in vim; it's not really that crazy for kids to learn a plain-text prose format.

Re: GitHub Classroom

#170

Post by divyavaishnavi »

dimxasnewfrozen wrote: post #98

This looks great and really want to give it a try. Unfortunately, I can't add a github organization. It goes through but never shows up in my organization list.

Hi @dimxasnewfrozen, We are working to improve this experience in Classroom. I would love to connect with you and gather your feedback. Do share your details https://forms.gle/Ni9Q8D574EWet5x27 and I shall reach out.
Post reply on HN