3 ms·

When students send in homework through our e-learning platform, we receive all the submissions in a large-ish xml file. We read the submissions, pass it on to s

by maweki 3y ago

When students send in homework through our e-learning platform, we receive all the submissions in a large-ish xml file. We read the submissions, pass it on to some (static) analysis and example execution, and write out (per exercise) a yaml-file with all the submissions, grading hints, and fields for our comments and grading, etc.. We then generate reports/statistics/feedback pdfs from the yaml files via markdown+pandoc. For us yaml works great, as it's easy to add further feedback in markdown syntax (just correctly indented "- you missed a `NOT` here"). Via the different escape methods for block text, we can print the SQL submission nicely formatted without escape characters, etc., even when the students uses all the different SQL-delimiters. It is all plaintext, so we just use a text editor and we store that all in git and have accountability over grading. We have everything archived machine readable, so that we may test new static analysis stuff on past submissions. But also having to write CI-pipelines and home-automation configurations in yaml, I understand the struggle.

unscaled 3y ago
Stripping indentation for embedded text is probably the nicest feature YAML has. In TOML you either just forget about indenting multi-line strings (which makes them less readable) or you have to remember to putting a backslash at the end of each line. Neither option is ideal. This makes YAML pretty nice for DSLs or configurations that need to embed markdown or other textual format and give it an edge over something like TOML. But I won't put the entire blame for "YAML fatigue" on all the CI and DevOps tools that chose to use it as the carrier format for their DSLs. YAML has major issues which the OP site outlined very well: - The famous "Norway issue" (solved in YAML 1.2) - Leading zero parse as octal (solved in YAML 1.2) - Overeager type-coercion for numbers, dates, times etc. can be confusing. - Different modes for processing multi-line strings can be quite confusing. - Unsafe serialization (not an issue for modern parsers, but you need to be careful when using YAML on a veteran language with dynamic features like Ruby, Python or Java). All of these are issues with the YAML spec itself.

by maweki 3y ago

unscaled 3y ago

Stripping indentation for embedded text is probably the nicest feature YAML has. In TOML you either just forget about indenting multi-line strings (which makes them less readable) or you have to remember to putting a backslash at the end of each line. Neither option is ideal. This makes YAML pretty nice for DSLs or configurations that need to embed markdown or other textual format and give it an edge over something like TOML. But I won't put the entire blame for "YAML fatigue" on all the CI and DevOps tools that chose to use it as the carrier format for their DSLs. YAML has major issues which the OP site outlined very well: - The famous "Norway issue" (solved in YAML 1.2) - Leading zero parse as octal (solved in YAML 1.2) - Overeager type-coercion for numbers, dates, times etc. can be confusing. - Different modes for processing multi-line strings can be quite confusing. - Unsafe serialization (not an issue for modern parsers, but you need to be careful when using YAML on a veteran language with dynamic features like Ruby, Python or Java). All of these are issues with the YAML spec itself.