Pith. sign in

REVIEW 4 major objections 5 minor 131 references

This paper argues that no data serialization format holds a consistent cross-task usability advantage, and that perceived usability is driven mainly by tooling, conventions, and community practice rather than syntax.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 00:27 UTC pith:UCMP4RWK

load-bearing objection A genuinely useful first large comparison of DSF usability, but the central null result leans on a post-hoc resampling that the authors themselves compare to pruning an outlier. the 4 major comments →

arxiv 2607.26211 v1 pith:UCMP4RWK submitted 2026-07-28 cs.HC

Reading Between the Curly Braces: On Textual Data Serialization Format Usability

Shiyi He , Zach Cutler , Andrew M. McNutt This is my paper
classification cs.HC
keywords data serialization formatsJSONYAMLXMLTOMLHJSONusabilitysociotechnical factors
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper asks whether the syntax of data formats—curly braces, indentation, tags—makes a real difference in how easily people can read and write data files. Across a 215-person crowd experiment comparing seven formats on reading, authoring, and modification tasks, it finds no format that is consistently best. Minor advantages for permissive formats such as HJSON and YAML appear only in certain editing steps, and those advantages fade at both very easy and very demanding tasks. Interviews with nine practitioners point the explanation away from syntax: users choose formats by convention, tooling support, and ecosystem fit. The paper's central claim is that notational design is a weak lever, while sociotechnical context is the main driver of data format usability.

Core claim

The central discovery is a null result with a positive explanation. After measuring performance and perceived difficulty across seven textual data formats—JSON, JSONC, JSON5, HJSON, YAML, XML, and TOML—in two realistic data contexts, the authors found no robust cross-task advantage for any format. Statistically significant differences did appear in one modification subtask, where TOML, YAML, and HJSON outperformed XML, and parse rates tracked grammar flexibility, but these effects were narrow and context-bound. The explanation offered is that task difficulty, data familiarity, and tool-mediated workflows dominate outcomes; format effects attenuate when tasks are trivially easy or overwhelmin

What carries the argument

The load-bearing apparatus is a between-subjects experimental comparison of seven data serialization formats across two data contexts (configuration files and tabular data) and three task types (reading, authoring, modifying), paired with a nine-participant semi-structured interview study. The decisive comparison is not any single metric but the pattern across a task-difficulty gradient: notation-related differences appear only in an intermediate band of editing tasks and shrink at both extremes, which is what supports the claim that notation is not the primary usability lever.

Load-bearing premise

The argument's load-bearing premise is that the unusually poor JSONC/configuration results were a sampling irregularity, not a real format effect; the paper itself flags this in its resampling section, and if the original anomaly was genuine, the cross-format null result loses a counterexample and the reported comparison is biased by the replacement.

What would settle it

Re-run the JSONC/configuration condition with a larger sample and a pre-registered analysis that keeps the original anomalous data in the primary comparison. If the poor performance replicates, or if the original anomalous distribution differs from the resampled one beyond sampling variation, then the 'sampling irregularity' explanation fails and a genuine format-specific effect exists that the cross-format null claim must accommodate.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • If no format is task-general best, then new syntax variants are a weak investment; improving tooling, documentation, and migration support should yield larger usability gains.
  • Permissive syntax helps in specific editing steps, so design choices about comments, quotes, and trailing commas matter mainly for modification tasks, not for reading or authoring.
  • Format effects concentrate at intermediate task difficulty; evaluations that use only trivial or only hard tasks may miss or overstate notation effects.
  • Because adoption follows convention and ecosystem, a format's fate depends on defaults and inertia more than on its syntactic merits.
  • The absence of consistent empirical differences helps explain why community debates stay polarized: personal aesthetic preferences fill the evidence gap.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the null result generalizes beyond this participant pool, then proposals for new 'human-friendly' formats are aiming at a marginal lever; their success will ride on tooling and default status, not syntax.
  • A clean extension would hold tooling identical across formats—same linter, formatter, autocomplete, and validator—and re-measure; the paper's logic predicts even smaller residual differences, isolating pure notation.
  • The difficulty-attenuation finding suggests an interaction worth testing: format effects should peak for medium-complexity edits and vanish for reading or large restructuring; future studies could deliberately target that band.
  • Interview themes imply interventions like shared migration tooling and team documentation may beat format redesign; a testable comparison would give one team stronger tooling and another a 'better' syntax and observe long-term maintenance outcomes.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. This paper reports two studies on the usability of textual data serialization formats (DSFs): a crowd-sourced experiment (N=215) comparing seven formats across reading, authoring, and modifying tasks in two data contexts, and a semi-structured interview study (N=9) with practitioners. The central claim is that notational differences among DSFs do not produce robust or consistent effects on usability across common tasks; instead, sociotechnical factors—conventions, preferences, and tooling ecosystems—dominate. The authors find no overall cross-format advantage, with only isolated gains for permissive formats (HJSON, YAML, TOML) over XML in a specific modifying subtask. The interview study supports the sociotechnical interpretation.

Significance. If the central null result holds, the paper makes a valuable empirical contribution to an area dominated by anecdote and intuition. The crowd-work design is unusually large for this problem, the materials are open, and the qualitative study is thoughtfully analyzed. The authors are appropriately careful to distinguish 'no robust advantage' from 'no differences.' The paper also connects to prior PL adoption literature and offers a concrete, falsifiable claim about the limited role of syntax in DSF usability. However, the strength of this contribution depends critically on the treatment of the anomalous JSONC/CONFIG condition and on the reliability of the manual grading used for the writing tasks; these issues currently weaken the evidential base for the central null result.

major comments (4)
  1. [§IV-B, Fig. 7] The central null claim—'no robust cross-task advantage for any format'—rests on excluding the original JSONC/CONFIG data. The authors saw an extreme performance difference, found no procedural explanation, manually regraded and replicated the anomaly, and then resampled the condition because the new distribution was 'more appropriate.' This is a post-hoc data-dependent decision with no pre-specified criterion for what would trigger resampling, how 'appropriate' is judged, or how the replacement sample was selected. If the original anomaly was a genuine format-by-context interaction (e.g., JSONC's comment syntax combined with CONFIG tasks), the reported null result removes the strongest counterexample. The paper must either (a) provide a sensitivity analysis showing the main conclusions are unchanged when the original or resampled data are used, (b) report both versions of the results and
  2. [§IV-A, Evaluation] The writing and modifying tasks were scored by manual grading. The paper states that two authors developed a rubric, graded 20 trials together, 'resolved the differences,' and then the first author graded the rest. It explicitly says 'inter-rater reliability was not calculated.' For a study whose main negative result depends on comparing scores across formats, the absence of any formal reliability check is a serious gap. The authors acknowledge this in Limitations, but it is not merely a limitation: it means the reported null effect could be an artifact of grading inconsistency, especially if the first author's later grading drifted. I ask for either independent grading of a substantial subsample with computed IRR, or a clear argument that grading bias cannot favor one format, with supporting evidence.
  3. [§IV-C, Results] The paper repeatedly interprets non-significant ANOVA results as evidence that formats do not matter. With sample sizes of 15–17 per cell, the design is underpowered for detecting small-to-moderate effects, and a null p-value does not license the strong claim that 'format differences are attenuated' at task extremes. The authors should include equivalence tests, Bayes factors, or at least effect sizes and confidence intervals for the main comparisons, and should calibrate their language to 'no evidence of a difference' rather than 'no difference.' This is particularly important because the paper's broader conclusion is a claim about the absence of effects.
  4. [§III, §IV-A] The study uses deliberately simplified tasks and a novice-leaning participant pool (66% with ≤2 years of programming experience, 30% with 0 years). The authors acknowledge this, but the abstract and conclusion generalize to 'common data tasks' and 'practitioners.' The simplified tasks may compress format differences, and novices may not exhibit the same format sensitivities as experienced developers who work with DSFs daily. To support the central claim, the paper should either narrow the scope of the claims or provide evidence that the task simplification and participant experience do not drive the null result. The current Fig. 5 analysis of experience is correlational and underpowered.
minor comments (5)
  1. [§V-B, Preferences] Typo: 'oncrete' should be 'concrete' in the sentence 'not something more oncrete such as linguistic background.'
  2. [§IV-B and Appendix] The resampling description is spread between §IV-B and Fig. 7; the appendix reference is vague. Please consolidate the full resampling protocol (how many participants, how selected, exclusion criteria) in one place.
  3. [§II and §IV-A] The text uses inconsistent capitalization and spacing for format names, e.g., 'Y AML', 'JSONC', 'HJSON', 'TOML', and 'XML'. This is distracting in a paper about notations; please use consistent formatting throughout.
  4. [Fig. 3 and Fig. 4] Figure 3's stacked bar charts are difficult to read, especially the small numeric labels. Figure 4's multiple panels would benefit from explicit annotations of which task each panel corresponds to; currently the reader must cross-reference the caption and text.
  5. [References] Some references are incomplete or missing access dates, e.g., [99] has no access date, and [101] and [102] have inconsistent years. Please ensure all entries follow the journal style.

Circularity Check

0 steps flagged

No circularity: the conclusions are empirical comparisons; self-citations are background references and the resampling concern is a validity issue, not a circular derivation.

full rationale

The paper's central claim—that format distinctions do not consistently affect usability—is inferred directly from crowd-work task performance (reading/authoring/modifying scores, completion times, parse rates, NASA-TLX) and from semi-structured interviews, not from any equation, fitted parameter, or author-derived theorem. There is no derivation chain in which an output quantity is defined in terms of an input quantity, no fitted parameter renamed as a prediction, and no uniqueness or ansatz imported from the authors' prior work. The post-hoc resampling of the JSONC/CONFIG condition (Section IV-B, Fig. 7) is a serious methodological concern about selective data handling and could threaten the empirical conclusion if the original anomaly was a real format effect, but it is not circular reasoning: the resampled data are not constructed from the conclusion, and the paper openly reports the original anomaly and includes all data in materials. Self-citations ([1], [70], [106]) are background or tooling references and do not carry the argument; the sociotechnical conclusion is independently supported by interview themes and is explicitly framed as echoing Meyerovich and Rabkin rather than as a novel derivation from those works. Therefore no circular step is exhibited; the paper is self-contained as an empirical study, and the resampling issue belongs to data-integrity/validity rather than circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

No numeric parameters were fitted to data; the study is observational. The 'moderate effect size f=0.3' in the power analysis is a design target, not a fitted value. The main load-bearing assumptions are the validity of the simplified task battery and the post-hoc resampling of one anomalous condition.

axioms (4)
  • domain assumption Prolific participants without programming experience are valid proxies for DSF users in reading/writing tasks.
    Crowd study recruited from a general pool, no programming experience required; 66% had ≤2 years of experience (Sec. IV-A, Fig. 5). If format effects are expertise-dependent, the null result may not generalize.
  • domain assumption Simplified versions of real files preserve ecologically relevant task difficulty.
    Task stimuli were simplified to limit experiment scope; the authors note tasks 'might not capture all real-world scenarios (e.g., debugging or learnability)' (Sec. IV-A Limitations).
  • ad hoc to paper The resampled JSONC/CONFIG condition is representative; the original anomaly was a sampling irregularity.
    Load-bearing post hoc assumption that replaces a condition contradicting expectations (Sec. IV-B, Fig. 7). If false, the central null result is biased.
  • domain assumption Nine self-selected interviewees and online commentary are representative of practitioner experience.
    The interview sample is small and mostly male with CS degrees; the authors caution findings are 'indicative rather than comprehensive' (Sec. V-A).

pith-pipeline@v1.3.0-alltime-deepseek · 26931 in / 8115 out tokens · 73841 ms · 2026-08-01T00:27:23.965209+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of Reading Between the Curly Braces: On Textual Data Serialization Format Usability." pith.science (2026). https://pith.science/paper/UCMP4RWK

@misc{pith2026260726211,
  author       = {Pith},
  title        = {Pith review of: Reading Between the Curly Braces: On Textual Data Serialization Format Usability},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UCMP4RWK}},
  note         = {Machine review of arXiv:2607.26211}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Textual data serialization formats, such as JSON or XML, are ubiquitous, supporting tasks like software configuration and data tabularization. Despite their prominence, little is known about their usability. What makes one good or bad? Is there a best one for cognitive efficiency? We explore these questions via a (N=215) crowd work study and a (N=9) semi-structured interview study. We find that format distinctions (like indentation versus curly braces) do not consistently translate into substantial usability differences. While HJSON and YAML performed better than other formats in certain modification tasks, these advantages disappeared in more realistic settings where task complexity was either trivial or highly demanding. Instead, usability appears driven by sociotechnical ecosystems: the tooling, documentation, and community practices surrounding a format matter more than syntax.

Figures

Figures reproduced from arXiv: 2607.26211 by Andrew M. McNutt, Shiyi He, Zach Cutler.

Figure 1
Figure 1. Figure 1: Stimuli used in crowd-work experiment for JSONC in the [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Tasks used in the crowd-work study (with JSONC as an example). The data used were adapted from publicly available datasets. These simplified [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: While there was variance in performance across formats, no one format stood out as best. We note that [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Across all tasks there is not a single dominant format, shown here by condition (format [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Self-reported experience distribution across participants. Although [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: We assessed format popularity using two sources. For community engagement, we used the Hacker News Search API to retrieve the top 500 stories [PITH_FULL_IMAGE:figures/full_fig_p014_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: In the initial run of our crowd work study, we found an extreme performance difference between JSON and JSONC for [PITH_FULL_IMAGE:figures/full_fig_p014_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Format flexibility is approximated by the size of each Tree-sitter grammar, measured here by its numbers of states, symbols, and tokens. Although [PITH_FULL_IMAGE:figures/full_fig_p015_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: The studies in this work, JSON, JSONC, JSON5, HJSON, YAML, TOML, and XML—as well as CSVs where appropriate. Beyond these basic syntactic [PITH_FULL_IMAGE:figures/full_fig_p016_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: After the completion of the main part of the crowd work study, participants filled out a NASA TLX. The average across all formats was [PITH_FULL_IMAGE:figures/full_fig_p017_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Themes resulting from our analysis of our semi-structured interview study. We employed affinity diagramming [ [PITH_FULL_IMAGE:figures/full_fig_p018_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Grading rubric used to evaluate responses of [PITH_FULL_IMAGE:figures/full_fig_p019_12.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

131 extracted references · 1 linked inside Pith

  1. [1]

    No Grammar to Rule Them All: A Survey of JSON- Style Dsls for Visualization,

    A. M. McNutt, “No Grammar to Rule Them All: A Survey of JSON- Style Dsls for Visualization,”IEEE Transactions on Visualization and Computer Graphics, pp. 1–11, 2022

    2022

  2. [2]

    Can someone please explain JSON to me?

    Cizhu, “Can someone please explain JSON to me?” https://www.reddit.com/r/learnjavascript/comments/182qx7o/can someone please explain json to me/, 2023, accessed: 2026-07-22

    2023

  3. [3]

    Why JSON doesn’t support comments (Douglas Crockford),

    deleted, “Why JSON doesn’t support comments (Douglas Crockford),” https://www.reddit.com/r/programming/comments/4v6chu/why json doesnt support comments douglas crockford/, 2021, accessed: 2026-07-22

    2021

  4. [4]

    From FOSS to Profit: Digital Spatial Technologies and the Mode of Production,

    D. Mahmoudi, J. Thatcher, L. Imaoka, and D. O’Sullivan, “From FOSS to Profit: Digital Spatial Technologies and the Mode of Production,” Digital Geography and Society, vol. 7, p. 100101, 2024

    2024

  5. [5]

    Coffeescript-Object-Notation,

    B. Lupton, “Coffeescript-Object-Notation,” https://github.com/bevry/cson, 2011, accessed: 2026-03-16

    2011

  6. [6]

    Configure Unify Execute,

    M. van Lohuizen and Contributors, “Configure Unify Execute,” cue- lang.org/, 2018

    2018

  7. [7]

    DMS — Data Meta Syntax,

    Omega-Tree, “DMS — Data Meta Syntax,” https: //dms-webpage-69537d.gitlab.io/, 2026

    2026

  8. [8]

    Extensible Data Notation,

    E. contributors, “Extensible Data Notation,” https://github.com/edn- format/edn, 2012, accessed: 2026-03-09

    2012

  9. [9]

    The KDL Document Language,

    K. Community, “The KDL Document Language,” https://kdl.dev/spec/, 2021, accessed: 2026-03-09

    2021

  10. [10]

    LEAN (LLM-Efficient Adaptive Notation) — Token- Optimized Serialization Format for Structured Data in LLM Context Windows Resource,

    fiialkod, “LEAN (LLM-Efficient Adaptive Notation) — Token- Optimized Serialization Format for Structured Data in LLM Context Windows Resource,” https://github.com/fiialkod/lean-format, 2026

    2026

  11. [11]

    MAML: Minimal Configuration Language,

    A. Medvedev, “MAML: Minimal Configuration Language,” https: //maml.dev/, 2025, accessed: 2026-04-21

    2025

  12. [12]

    Configuration That Is Programmable, Scalable, and Safe,

    Apple, “Configuration That Is Programmable, Scalable, and Safe,” https://pkl-lang.org/, 2024, accessed: 2026-03-16

    2024

  13. [13]

    KSON: A Love Letter to the Humans Maintaining Computer Configurations,

    T. K. P. Team, “KSON: A Love Letter to the Humans Maintaining Computer Configurations,” https://kson.org/, 2025, accessed: 2026-03- 16

    2025

  14. [14]

    Rusty Object Notation,

    R. contributors, “Rusty Object Notation,” https://docs.rs/ron/latest/ron/, 2021, accessed: 2026-03-09

    2021

  15. [15]

    Token-Oriented Object Notation,

    T. contributors, “Token-Oriented Object Notation,” https://github.com/toon-format/toon, 2025, accessed: 2026-03-16

    2025

  16. [16]

    Token Reduced Object Notation,

    T. Huang, “Token Reduced Object Notation,” https://tron- format.github.io/, 2025, accessed: 2026-03-09

    2025

  17. [17]

    Zero Overhead Notation,

    R. Bhakta, “Zero Overhead Notation,” https://zonformat.org/, 2025, accessed: 2026-03-09

    2025

  18. [18]

    Empirical Analysis of Program- ming Language Adoption,

    L. A. Meyerovich and A. S. Rabkin, “Empirical Analysis of Program- ming Language Adoption,” inACM SIGPLAN OOPSLA, 2013, pp. 1–18

    2013

  19. [19]

    Socio-PLT: Principles for Programming Language Adoption,

    ——, “Socio-PLT: Principles for Programming Language Adoption,” inSIGPLAN Onward!, 2012, pp. 39–54

    2012

  20. [20]

    Comparison of JSON and XML Data Interchange Formats: A Case Study,

    N. Nurseitov, M. Paulson, R. Reynolds, and C. Izurieta, “Comparison of JSON and XML Data Interchange Formats: A Case Study,”Caine, vol. 9, pp. 157–162, 2009

    2009

  21. [21]

    A Comparison of Data Serialization Formats for Optimal Efficiency on a Mobile Platform,

    A. Sumaray and S. K. Makki, “A Comparison of Data Serialization Formats for Optimal Efficiency on a Mobile Platform,” inUbiquitous Information Management and Communication. USA: IEEE, 2012, pp. 1–6

    2012

  22. [22]

    Performance Evaluation of Object Serialization Libraries in XML, JSON and Binary Formats,

    K. Maeda, “Performance Evaluation of Object Serialization Libraries in XML, JSON and Binary Formats,” inInternational Conference on Digital Information and Communication Technology and it’s Applica- tions. USA: IEEE, 2012, pp. 177–182

    2012

  23. [23]

    Data Formats in Analytical Dbmss: Performance Trade-Offs and Future Directions,

    C. Liu, A. Pavlenko, M. Interlandi, and B. Haynes, “Data Formats in Analytical Dbmss: Performance Trade-Offs and Future Directions,” The VLDB Journal, vol. 34, no. 3, p. 30, 2025

    2025

  24. [24]

    Y AML: It’s Time to Move On,

    diob, “Y AML: It’s Time to Move On,” https://news.ycombinator.com/ item?id=29220518, 2016, accessed: 2026-07-22

    2016

  25. [25]

    Apache Avro,

    Apache Software Foundation, “Apache Avro,” avro.apache.org, 2011, accessed: 2025-07-08

    2011

  26. [26]

    Apache Thrift,

    ——, “Apache Thrift,” thrift.apache.org, 2007, accessed: 2025-07-08

    2007

  27. [27]

    Apache Arrow,

    ——, “Apache Arrow,” arrow.apache.org, 2016, accessed: 2025-07-08

    2016

  28. [28]

    Common Format and MIME Type for Comma-Separated Values (CSV) Files,

    RFC 4180, “Common Format and MIME Type for Comma-Separated Values (CSV) Files,” tools.ietf.org/html/rfc4180, 2005, accessed: 2025- 06-10

    2005

  29. [29]

    Tab-Separated Values,

    Wikipedia contributors, “Tab-Separated Values,” en.wikipedia.org/wiki/Tab-separated values, 2025, accessed: 2025-06- 10

    2025

  30. [30]

    INI File,

    ——, “INI File,” en.wikipedia.org/wiki/INI file, 2025, accessed: 2025- 06-10

    2025

  31. [31]

    Gillies and R

    J. Gillies and R. Cailliau,How the Web Was Born: The Story of the World Wide Web. USA: Oxford University Press, 2000

    2000

  32. [32]

    Extensible Markup Language (XML) 1.0 (Fifth Edition),

    W3C, “Extensible Markup Language (XML) 1.0 (Fifth Edition),” w3.org/TR/xml/, 2008

    2008

  33. [33]

    HTML Living Standard — Last Updated 15 August 2025,

    ——, “HTML Living Standard — Last Updated 15 August 2025,” html.spec.whatwg.org/multipage/, 2025

    2025

  34. [34]

    XSL Transformations (XSLT) Version 1.0,

    J. Clark, “XSL Transformations (XSLT) Version 1.0,” W3C Recommendation, 1999. [Online]. Available: www.w3.org/TR/xslt/

    1999

  35. [35]

    XML Schema Part 1: Structures,

    H. S. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, “XML Schema Part 1: Structures,” w3.org/TR/xmlschema-1/, 2001

    2001

  36. [36]

    The JSON Data Interchange Format,

    D. Crockford, “The JSON Data Interchange Format,” Online resource, 2001, accessed: 2025-08-16. [Online]. Available: www.json.org/ json-en.html

    2001

  37. [37]

    Discovering Javascript Object Notation,

    C. Severance, “Discovering Javascript Object Notation,”Computer, vol. 45, no. 4, pp. 6–8, 2012

    2012

  38. [38]

    Crockford,Javascript: The Good Parts: The Good Parts

    D. Crockford,Javascript: The Good Parts: The Good Parts. USA: O’Reilly Media, 2008

    2008

  39. [39]

    Y AML Ain’t Markup Language Version 1.2,

    Y AML Language Development Team, “Y AML Ain’t Markup Language Version 1.2,” yaml.org/spec/1.2.2/, 2009, accessed: 2025-06-10

    2009

  40. [40]

    TOML v1.0.0,

    T. Preston-Werner, “TOML v1.0.0,” toml.io/en/v1.0.0, 2021, accessed: 2025-06-10

    2021

  41. [41]

    JSON with Comments (JSONC) Specification,

    Microsoft, “JSON with Comments (JSONC) Specification,” github.com/microsoft/node-jsonc-parser, 2023, accessed: 2025-06-10

    2023

  42. [42]

    HJSON: A User Interface for JSON,

    HJSON Team, “HJSON: A User Interface for JSON,” hjson.github.io/, 2014, accessed: 2025-06-10

    2014

  43. [43]

    Json5 - JSON for Humans,

    JSON5 Authors, “Json5 - JSON for Humans,” json5.org/, 2023, ac- cessed: 2025-06-10

    2023

  44. [44]

    RDF 1.1 Concepts and Abstract Syntax,

    R. Cyganiak, D. Wood, and M. Lanthaler, “RDF 1.1 Concepts and Abstract Syntax,” w3.org/TR/rdf11-concepts/, 2014

    2014

  45. [45]

    HOCON (Human-Optimized Config Object Nota- tion),

    H. contributors, “HOCON (Human-Optimized Config Object Nota- tion),” github.com/lightbend/config/blob/main/HOCON.md, 2011

    2011

  46. [46]

    Sdlang: Simple Declarative Language,

    D. C. hub, “Sdlang: Simple Declarative Language,” sdlang.org/, 2015

    2015

  47. [47]

    Human Readability of Data Files,

    M. R. Gryk, “Human Readability of Data Files,”Balisage Series on Markup Technologies, vol. 27, pp. 10–4242, 2022

    2022

  48. [48]

    Derivation of New Readability Formulas (Automated Readability Index, Fog Count and Flesch Reading Ease Formula) for Navy Enlisted Personnel,

    J. P. Kincaid, R. P. Fishburne Jr, R. L. Rogers, and B. S. Chissom, “Derivation of New Readability Formulas (Automated Readability Index, Fog Count and Flesch Reading Ease Formula) for Navy Enlisted Personnel,” Naval Technical Training Command, Tech. Rep., 1975

    1975

  49. [49]

    Comparison of Two XML Query Languages from the Perspective of Learners,

    M. Lassila, M. Junkkari, and J. Kek ¨al¨ainen, “Comparison of Two XML Query Languages from the Perspective of Learners,”Journal of Information Science, vol. 41, 2015

    2015

  50. [50]

    A Qualitative Study to the Usability of Three XML Query Languages,

    J. Graaumans, “A Qualitative Study to the Usability of Three XML Query Languages,” inConference on Dutch Directions in HCI. New York: ACM, 2004, p. 6

    2004

  51. [51]

    PL and HCI: Better Together,

    S. E. Chasins, E. L. Glassman, and J. Sunshine, “PL and HCI: Better Together,”Communications of the ACM, pp. 98–106, 2021

    2021

  52. [52]

    Usability of Programming Languages: Special Interest Group,

    B. A. Myers, A. Stefik, S. Hanenberg, A.-J. Kaijanaho, M. Burnett, F. Turbak, and P. Wadler, “Usability of Programming Languages: Special Interest Group,” inSIGCHI Conference on Human Factors in Computing Systems. New York, NY , USA: ACM, 2016, pp. 1104– 1107

    2016

  53. [53]

    A Brief History of the Human Centric Study of Programming Languages,

    L. Church and A. F. Blackwell, “A Brief History of the Human Centric Study of Programming Languages,” inPsychology of Programming Interest Group, 2023

    2023

  54. [54]

    Evaluating Code Readability and Legibility: An Examination of Human-Centric Stud- ies,

    D. Oliveira, R. Bruno, F. Madeiral, and F. Castor, “Evaluating Code Readability and Legibility: An Examination of Human-Centric Stud- ies,” inInternational Conference on Software Maintenance and Evo- lution. USA: IEEE, 2020, pp. 348–359

    2020

  55. [55]

    Readability and Understandability Scores for Snippet Assessment: An Exploratory Study,

    C. E. C. Dantas and M. A. Maia, “Readability and Understandability Scores for Snippet Assessment: An Exploratory Study,”arXiv, 2021

    2021

  56. [56]

    User-Driven Design and Evaluation of Liquid Types in Java,

    C. Gamboa, P. A. Santos, C. S. Timperley, and A. Fonseca, “User-Driven Design and Evaluation of Liquid Types in Java,” 2021. [Online]. Available: https://arxiv.org/abs/2110.05444

    Pith/arXiv arXiv 2021

  57. [57]

    Debugging Database Queries: A Survey of Tools, Techniques, and Users,

    S. Gathani, P. Lim, and L. Battle, “Debugging Database Queries: A Survey of Tools, Techniques, and Users,” inSIGCHI Conference on Human Factors in Computing Systems. New York, NY , USA: ACM, 2020, pp. 1–16

    2020

  58. [58]

    Usability Evaluation of Domain-Specific Languages: A Systematic Literature Review,

    I. Poltronieri Rodrigues, M. de Borba Campos, and A. F. Zorzo, “Usability Evaluation of Domain-Specific Languages: A Systematic Literature Review,” inInternational Conference on Human-Computer Interaction. Germany: Springer, 2017, pp. 522–534

    2017

  59. [59]

    Quantifying Usability of Domain-Specific Languages: An Empirical Study on Software Maintenance,

    D. Albuquerque, B. Cafeo, A. Garcia, S. Barbosa, S. Abrah ˜ao, and A. Ribeiro, “Quantifying Usability of Domain-Specific Languages: An Empirical Study on Software Maintenance,”Journal of Systems and Software, vol. 101, pp. 245–259, 2015

    2015

  60. [60]

    Usability Evaluation Framework for Domain-Specific Language: A Focus Group Study,

    I. Poltronieri, A. F. Zorzo, M. Bernardino, and M. de Borba Campos, “Usability Evaluation Framework for Domain-Specific Language: A Focus Group Study,”SIGAPP Applied Computing Review, vol. 18, no. 3, pp. 5–18, 2018

    2018

  61. [61]

    An Empirical Investigation into Program- ming Language Syntax,

    A. Stefik and S. Siebert, “An Empirical Investigation into Program- ming Language Syntax,”ACM Transactions on Computing Education, vol. 13, no. 4, pp. 1–40, 2013

    2013

  62. [62]

    B2t2: Bringing Back the Tables – ExampleTa- bles.md,

    Brown PLT Group, “B2t2: Bringing Back the Tables – ExampleTa- bles.md,” https://github.com/brownplt/B2T2/blob/main/ExampleTables. md, 2025

    2025

  63. [63]

    D3: Data-Driven Documents — package.json,

    D3 Contributors, “D3: Data-Driven Documents — package.json,” https: //github.com/d3/d3/blob/main/package.json, 2025

    2025

  64. [64]

    Mongodb CRUD Operations Example — Hospital and Patients Mongodb CRUD,

    H. ˙Ibrahim Tas ¸, “Mongodb CRUD Operations Example — Hospital and Patients Mongodb CRUD,” https://medium.com/@halilibrhimtas/ mongodb-crud-operations-example-hospital-and-patients-756556723605, 2025

    2025

  65. [65]

    Chart.js – package.json,

    Chart.js Group, “Chart.js – package.json,” https://github.com/chartjs/ Chart.js/blob/master/package.json, 2025

    2025

  66. [66]

    Wikipedia Movie Data,

    P. Prust, “Wikipedia Movie Data,” https://github.com/prust/ wikipedia-movie-data, 2025

    2025

  67. [67]

    Vega-Lite: A Grammar of Interactive Graphics – package.json,

    Vega-Lite Contributors, “Vega-Lite: A Grammar of Interactive Graphics – package.json,” https://github.com/vega/vega-lite/blob/main/package. json, 2025

    2025

  68. [68]

    Vega- Lite: A Grammar of Interactive Graphics,

    A. Satyanarayan, D. Moritz, K. Wongsuphasawat, and J. Heer, “Vega- Lite: A Grammar of Interactive Graphics,”IEEE Transactions on Visualization and Computer Graphics, vol. 23, no. 1, pp. 341–350, 2016

    2016

  69. [69]

    Ace - the High Performance Code Editor for the Web,

    Ajax.org, “Ace - the High Performance Code Editor for the Web,” github.com/ajaxorg/ace, 2025, gitHub repository

    2025

  70. [70]

    Revisit 2: A Full Experiment Life Cycle User Study Framework,

    Z. Cutler, J. Wilburn, H. Shrestha, Y . Ding, B. C. Bollen, K. A. Nadib, T. He, A. M. McNutt, L. Harrison, and A. Lex, “Revisit 2: A Full Experiment Life Cycle User Study Framework,”IEEE Transactions on Visualization and Computer Graphics, 2025

    2025

  71. [71]

    Prolific,

    Prolific, “Prolific,” https://www.prolific.com, 2026, accessed: 2026-06- 30

    2026

  72. [72]

    Testing of Detection Tools for AI-Generated Text,

    D. Weber-Wulff, A. Anohina-Naumeca, S. Bjelobaba, T. Folt `ynek, J. Guerrero-Dib, O. Popoola, P. ˇSigut, and L. Waddington, “Testing of Detection Tools for AI-Generated Text,”International Journal for Educational Integrity, vol. 19, no. 1, pp. 1–39, 2023

    2023

  73. [73]

    Reviewer Critiques (Qualitative Methods) and How to Respond to Them,

    J. Vitak, “Reviewer Critiques (Qualitative Methods) and How to Respond to Them,” Self-published online document, 2024, collaborative community resource; accessed March 15,

    2024

  74. [74]

    I Heart Hacker News: Expanding Qualitative Research Findings by Analyzing Social News Websites,

    T. Barik, B. Johnson, and E. Murphy-Hill, “I Heart Hacker News: Expanding Qualitative Research Findings by Analyzing Social News Websites,” inFoundations of Software Engineering. New York: ACM, 2015, pp. 882–885

    2015

  75. [75]

    Hanington and B

    B. Hanington and B. Martin,Universal Methods of Design. MA: Rockport Publishers, 2012

    2012

  76. [76]

    Why is JSON so popular? Developers want out of the syntax business

    vplatt, “Why is JSON so popular? Developers want out of the syntax business.” https://www.reddit.com/r/programming/comments/ i6xdr/why is json so popular developers want out of the/, 2011, accessed: 2026-07-22

    2011

  77. [77]

    What is XML for?

    AnimaLepton, “What is XML for?” https://www.reddit.com/ r/learnprogramming/comments/1gqxrtl/what is xml for/, 2024, accessed: 2026-07-22

    2024

  78. [78]

    Reigniting the fire of HJSON.135,

    Joy-less, “Reigniting the fire of HJSON.135,” https://github.com/hjson/ hjson/issues/135, 2025, accessed: 2026-07-22

    2025

  79. [79]

    What is XML for?

    ——, “What is XML for?” https://www.reddit.com/r/ learnprogramming/comments/1gqxrtl/what is xml for/, 2024, accessed: 2026-07-22

    2024

  80. [80]

    Can Comments Be Used in JSON?

    M. Gundlach, “Can Comments Be Used in JSON?” stackoverflow.com/questions/244777/can-comments-be-used-in-json, 2008

    2008

Showing first 80 references.