Pith. sign in

REVIEW 3 major objections 6 minor 72 references

Let's Take Esoteric Programming Languages Seriously

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read Esoteric programming languages are inherently useful in significant ways and deserve serious study.

desk verdict Honest, well-sourced essay that makes a plausible case for taking esolangs seriously; the five E's are a useful frame, but the load-bearing transfer claim is asserted, not shown. read the letter →

arxiv 2505.15327 v2 pith:FHEOGHND submitted 2025-05-21 cs.PL

Jeremy Singer , Steve Draper This is my paper · ORCID
classification cs.PL
keywords esotericprogramminglanguagesesolanglanguagedesigneducationvariationtheorymotivationsAIcodegenerationcomputationalmodels
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

Esoteric programming languages (esolangs) are built to be awkward, playful, artistic, or deliberately impractical, and this essay argues that they are nonetheless inherently useful in significant ways. The authors claim that wrestling with esolangs can improve general programming-language awareness: their bizarre syntax forces learners to see syntax as surface, while their stripped-down semantics expose the abstract machine underneath all programs. The essay also turns the esolang phenomenon into a general observation about language design, proposing five recurring motivations—expressivity, efficiency, education, economy, and exploration—and locating most esolangs in the exploration corner. If the authors are right, these apparent jokes are legitimate objects of study with real pedagogical and design value, not guilty pleasures.

What carries the argument

The argument is carried by two organizing devices. The first is a taxonomy of esolang syntax types: natural-language-like syntax (Shakespeare, Chef, Rockstar, LOLCODE), non-textual syntax (Whitespace, Piet), and exotic computational models (Brainf***, Befunge, Malbodge, Fractan), which shows that the genre's common core is low-level semantics wrapped in deliberately alien syntax. The second is the five-E scheme of language-design motivations—expressivity, efficiency, education, economy, exploration—used to locate esolangs within the general space of programming-language design and to argue that exploration, not practicality, is what they optimize. Pedagogically, the load-bearing mechanism is variation theory: encountering the same underlying concept expressed in deliberately different forms deepens learning, so esolangs, which share semantics but not syntax with mainstream languages, force the deep conceptual transfer the essay claims.

What would settle it

A controlled experiment would settle it: give two groups of novices the same introductory programming course, add a short esolang module—one Shakespeare or Brainf*** program, say—to one group only, and then test both groups on an unfamiliar mainstream language. If the esolang group shows no advantage in comprehension, debugging, or concept transfer, the claim that esolangs improve general PL awareness fails.

Watch

Extended reading notes

Core claim

The essay's central contention is that esoteric languages might be inherently useful in some significant ways, and so deserve to be studied in a serious manner. Concretely, it claims that esolangs can improve general PL awareness, both through the experience of writing programs in them and through the experience of designing them. The survey of languages from INTERCAL to Fractan shows a consistent pattern: almost all esolangs have low-level semantics and unconventional syntax, and that combination forces programmers to attend to the underlying computational model and to treat language choice as a design decision rather than a given. The essay's most important contribution, in the authors' own assessment, is to draw attention to the varied and often implicit motivations involved in programming language design, captured in a five-E scheme that makes room for play, parody, constraint, and exploration alongside the usual practical goals.

Load-bearing premise

The essay's argument depends on the premise that the awareness and skill a person gains from struggling with an esolang carries over to mainstream programming, a transfer that is asserted with examples but never measured.

Editorial extensions

If this is right

  • Esolangs deserve a place in programming education; a short esolang exercise can teach novices that syntax is surface and that control flow, state, and an underlying abstract machine are what matter.
  • Designing and implementing an esolang is a tractable student-scale project that teaches language engineering and exposes design trade-offs.
  • The five-E scheme gives language designers a shared vocabulary for design motivation, legitimizing exploration as a primary goal rather than a byproduct.
  • AI code generation that fails on esolangs reveals how much of mainstream code generation is corpus-bound, and correct esolang output would be a more demanding test of programming competence.
  • Educators who work through an esolang can experience the frustration novices feel with mainstream languages, making them more empathetic teachers.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the transfer claim holds, deliberate difficulty itself is a reusable pedagogical resource: code golf, obfuscation contests, and constrained-exercise formats may give mainstream students some of the esolang benefit without a full esolang module.
  • The five-E taxonomy suggests a design heuristic the paper leaves implicit: language creators could declare which E they optimize, and the resulting map might predict which languages attract communities and survive.
  • A testable extension is to benchmark LLM code generators on a corpus of esolang programs; the essay's anecdotal failures suggest esolangs are a hard, low-contamination test of whether a model understands computation rather than pattern-matching patterns from training data.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The paper is an essay arguing that esoteric programming languages (esolangs) deserve serious study because they are 'inherently useful in some significant ways' and can improve general programming language (PL) awareness. It surveys a range of esolangs (INTERCAL, Shakespeare, Chef, Whitespace, Piet, Brainf***, Befunge, Malbodge, Fractran), analyzes their appeal through playfulness, nostalgia, belonging, and artistic expression, and argues for their pedagogical value via variation theory. It then proposes a five-'E' taxonomy of design motivations (Expressivity, Efficiency, Education, Economy, Exploration) and presents preliminary observations on AI-generated esolang code. The paper explicitly frames itself as an essay and acknowledges the absence of formal proofs or controlled studies.

Significance. If the transfer claim were established, the paper would give PL educators and researchers a principled justification for incorporating esolangs into curricula and a framework for understanding language design motivations. The paper's strengths are its broad and well-referenced survey of esolang culture, its connection of esolangs to established work by Perlis, Papert, Hermans, Cox, and Temkin, and its honest signaling of the limits of its own evidence. However, the central pedagogical claim rests on analogy and anecdote, and the paper's own caveats in Sections 5.1.2 and 7.1 indicate that the empirical assertions are not yet supported. The essay is a valuable discussion piece, but its headline claim currently outruns its evidence.

major comments (3)
  1. [Section 4] The variation-theory argument does not support the claimed transfer to mainstream programming. Variation theory requires an invariant target concept expressed in varying contexts; the esolangs surveyed in Section 2 vary the underlying computational model itself (e.g., Brainf***'s Turing-machine-like tape, Piet's direction pointer, Fractran's fraction multiplication, Malbodge's self-modifying semantics). If the semantic model changes, variation theory predicts the learning of a different concept, not the reinforcement of a shared one. The sentence 'deep underlying conceptual transfers are enforced' (Section 4) is asserted without evidence, and no citation is given for the claim that esolang experience improves comprehension of mainstream languages. To make the central claim load-bearing, the authors should either identify specific concepts that remain invariant across esolangs and mainstream languages, or present (or propose) empirical evidence for transfer. Without this, the abstract's promise that esolangs 'can improve general PL awareness' is unsupported.
  2. [Section 7.1] The claim that LLMs fail to synthesize correct esolang code rests on 'initial experiments' with no protocol: no model versions, prompts, sample sizes, or evaluation criteria are reported, and only a single unparseable Piet example is shown. Similarly, Section 7.2 reports 'brief experiments' on AI-generated languages without details. Since the paper argues that esolangs' obscurity limits AI code generation, this observation should be reported as a conjecture or supported by a reproducible methodology, especially given the paper's own acknowledgement that mainstream code generation works well.
  3. [Section 5.1.2] The discussion of gender and esolang designers begins with an explicit caveat that it is 'based on a cursory analysis of designer names' and that 'a more formal analysis would be required,' yet the following paragraph infers a connection to Hermans' work on feminism in programming language design as if the observation were established. Given the sensitivity of the topic and the admitted absence of systematic evidence, this section should be reframed as a set of research questions or hypotheses, rather than presented as a finding. The paper should also avoid the phrase 'it seems that the majority of esolang designers are males' without supporting data.
minor comments (6)
  1. [Section 2.4] The language is usually spelled 'Malbolge'; the paper uses 'Malbodge' throughout. Please correct the spelling (unless intentionally variant) and ensure consistency with references.
  2. [Section 3.1] The quotation from Temkin appears as 'intentionally ununsable, uncomputable or conceptual'; if this reproduces the source, add a [sic] or correct to 'unusable' as appropriate.
  3. [Section 5.2.1] 'essentialy' should be 'essentially'.
  4. [Section 8] 'why programing languages succeed' contains a typo; it should be 'programming'.
  5. [Section 6.6] The INTERCAL manual quotation would benefit from a page number or section reference for verifiability.
  6. [Abstract and Section 1] The central phrase 'improve general PL awareness' is never defined operationally; specifying what 'PL awareness' means would make the paper's claim more testable and help the reader evaluate the evidence.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is an argumentative essay with no derivation chain, fitted parameters, or load-bearing self-citation.

full rationale

The paper makes no formal predictions and derives no quantitative results. Its central claim, that esoteric programming languages can improve general programming-language awareness, is supported by qualitative argument, examples, and citations to external literature (e.g., variation theory, McIver and Conway, Temkin, Papert). No equation, fitted parameter, or construction is reused as an output; the five 'E's taxonomy is offered as an organizing generalization, not as a derived theorem. The variation-theory argument in Section 4 is an application of an external pedagogical framework to esolangs; it may be empirically questionable, but it is not circular because the cited framework does not presuppose that esolangs improve awareness. Self-citations to the authors' own prior work are absent from the load-bearing reasoning; the only in-references are to the paper's own earlier sections, which is ordinary exposition rather than circular reduction. No step reduces by definition to its own inputs, no fitted quantity is renamed as a prediction, and no uniqueness theorem is imported from the authors' prior work. The appropriate finding is therefore no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The essay rests on domain assumptions about transfer of learning and the representativeness of its examples, but introduces no free parameters or invented entities.

assumptions (3)
  • domain assumption Exposure to multiple programming languages improves learning outcomes through variation.
    Section 4 invokes variation theory (Thuné and Eckerdal) as a basis for the pedagogical value of esolangs, without empirical validation in this paper.
  • domain assumption Esolang programming experience transfers to better understanding of mainstream programming concepts.
    The essay claims esolangs 'improve general PL awareness' (Abstract) and reinforce concepts like GOTO harmfulness (Section 4), assuming transfer without measuring it.
  • domain assumption The five E's taxonomy is a representative framework for language design motivations.
    Section 6 proposes expressivity, efficiency, education, economy, and exploration as the overarching themes, based on illustrative examples rather than a systematic survey.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Let's Take Esoteric Programming Languages Seriously." pith.science (2026). https://pith.science/paper/FHEOGHND

@misc{pith2026250515327,
  author       = {Pith},
  title        = {Pith review of: Let's Take Esoteric Programming Languages Seriously},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FHEOGHND}},
  note         = {Machine review of arXiv:2505.15327}
}
read the original abstract

Esoteric programming languages are challenging to learn, but their unusual features and constraints may serve to improve programming ability. From languages designed to be intentionally obtuse (e.g. INTERCAL) to others targeting artistic expression (e.g. Piet) or exploring the nature of computation (e.g. Fractan), there is rich variety in the realm of esoteric programming languages. This essay examines the counterintuitive appeal of esoteric languages and seeks to analyse reasons for this popularity. We will explore why people are attracted to esoteric languages in terms of (a) program comprehension and construction, as well as (b) language design and implementation. Our assertion is that esoteric languages can improve general PL awareness, at the same time as enabling the esoteric programmer to impress their peers with obscure knowledge. We will also consider pedagogic principles and the use of AI, in relation to esoteric languages. Emerging from the specific discussion, we identify a general set of 'good' reasons for designing new programming languages. It may not be possible to be exhaustive on this topic, and it is certain we have not achieved that goal here. However we believe our most important contribution is to draw attention to the varied and often implicit motivations involved in programming language design.

Figures

Figures reproduced from arXiv: 2505.15327 by the authors.

Figure 1
Figure 1. Typical INTERCAL compiler error message We consider INTERCAL to be an archetypal esolang since it demonstrates foundational principles that define the genre, i.e. syntactic absurdity and a satirical stance toward conven￾tional programming language design. Later esolangs share these playful characteristics. INTERCAL sparked amusement and curiosity among the broader software developer com￾munity, which continues to en… view at source ↗
Figure 2
Figure 2. Online Interpreter for Shakespeare programs [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Set of mixing bowls, appropriate for the CHEF esolang 2.3 Non-Textual Syntax While all esolangs feature unconventional syntax, some of them have entirely non-textual syntax. Two such languages are Whitespace and Piet. Both these languages feature relatively straightforward abstract machines. They are stack based with a sensible in￾struction set that has appropriate low-level operations. In [PITH_FULL_IMAGE:figures/… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Visual Studio Code with the LOLCODE plugin in operation the early days of computers, compilation was much more expensive, perhaps an overnight job. The use of esolangs raises the level mental activity required for programming. For instance, no program was written in th…
Figure 5
Figure 5. Figure 5: Hypothetical esolang suggestion from xkcd.com webcomic, number 2309 (CC BY-NC 2.5 Randall Munroe) For esoteric languages, programs need to be written dif￾ferently, in an unconventional syntax and structure. Con￾straints are ever-present, and in some cases programs are …
Figure 6
Figure 6. Figure 6: AI-synthesized Piet Fibonacci program, which contains syntax errors 7.1 Esolang Code Synthesis Could an AI-based large language model (LLM) synthesize correct code to solve a specified problem in a given esolang? On the one hand, LLM-generated code seems to work well f…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

72 extracted references · 55 canonical work pages

  1. [1]

    Harold Abelson and Gerald Jay Sussman. 1996. Structure and interpre- tation of computer programs . MIT Press

    work page 1996

  2. [2]

    Beckwith and M

    L. Beckwith and M. Burnett. 2004. Gender: An Important Factor in End-User Programming Environments?. In 2004 IEEE Symposium on Visual Languages - Human Centric Computing . 107–114. doi:10.1109/ VLHCC.2004.28

    work page 2004

  3. [3]

    Black, Kim B

    Andrew P. Black, Kim B. Bruce, Michael Homer, James Noble, Amy Ruskin, and Richard Yannow. 2013. Seeking grace: a new object- oriented language for novices. In Proceeding of the 44th ACM Technical Symposium on Computer Science Education . 129–134. doi: 10.1145/ 2445196.2445240

    arXiv 2013

  4. [4]

    Alan F Blackwell and Nick Collins. 2005. The Programming Language as a Musical Instrument.. In PPIG. 11. https://www.ppig.org/files/2005- PPIG-17th-blackwell.pdf

    work page 2005

  5. [5]

    Edwin Brady. 2013. Idris, a general-purpose dependently typed pro- gramming language: Design and implementation.Journal of Functional Programming 23, 5 (2013), 552–593. doi:10.1017/S095679681300018X

    doi:10.1017/s095679681300018x 2013

  6. [6]

    Lev Bratishenko. 2009. Technomasochism: Getting spanked by INTER- CAL. Cabinet Magazine 36 (2009). https://www.cabinetmagazine.org/ issues/36/bratishenko.php

    work page 2009

  7. [7]

    Frederick P Brooks Jr. 1995. The mythical man-month (anniversary ed.). Addison-Wesley

    work page 1995

  8. [8]

    Martin Campbell-Kelly. 2012. Alan Turing’s other universal machine. Commun. ACM 55, 7 (July 2012), 31–33. doi:10.1145/2209249.2209277 Let’s Take Esoteric Programming Languages Seriously Onward! ’25, October 12–18, 2025, Singapore, Singapore

    arXiv 2012

Show all 72 references
  1. [9]

    Robert Chatley, Alastair Donaldson, and Alan Mycroft. 2019. The next 7000 programming languages. Computing and software science: State of the art and perspectives (2019), 250–282. doi:10.1007/978-3-319-91908- 9_1

    2019 doi

  2. [10]

    John H Conway. 1987. Fractran: A simple universal programming language for arithmetic. In Open problems in Communication and Computation. Springer, 4–26

    1987

  3. [11]

    Jon Corbett. 2023. Cree Coding. Available from https://pinnguaq.com/ stories/cree-coding/

    2023

  4. [12]

    Geoff Cox and Alex McLean. 2012. Speaking Code: Coding as Aesthetic and Political Expression. MIT Press. doi:10.7551/mitpress/8193.001.0001

    2012 doi

  5. [13]

    Becker, Nigel Bosch, James Prather, Brent Reeves, and Jacqueline Whalley

    Paul Denny, Brett A. Becker, Nigel Bosch, James Prather, Brent Reeves, and Jacqueline Whalley. 2022. Novice Reflections During the Tran- sition to a New Programming Language. In Proceedings of the 53rd ACM Technical Symposium on Computer Science Education - Volume 1 . 948–954....

    2022

  6. [14]

    Edsger W Dijkstra. 1968. Go to statement considered harmful. Com- mun. ACM 11, 3 (1968), 147–148

    1968

  7. [15]

    Antoine Faivre. 1994. Access to Western esotericism. SUNY Press

    1994

  8. [16]

    J.-M. Favre. 2005. Languages evolve too! Changing the software time scale. In Eighth International Workshop on Principles of Software Evolu- tion. 33–42. doi:10.1109/IWPSE.2005.22

    2005 doi

  9. [17]

    Federico Gobbo et al. 2005. The digital way to spread conlangs. Lan- guage at Work: Language Learning, Discourse, and Translation Studies in Internet (2005), 45–53

    2005

  10. [19]

    Tracy Hall, Helen Sharp, Sarah Beecham, Nathan Baddoo, and Hugh Robinson. 2008. What Do We Know about Developer Motivation? IEEE Software 25, 4 (2008), 92–94. doi:10.1109/MS.2008.105

    2008 doi

  11. [21]

    Felienne Hermans and Ari Schlesinger. 2024. A Case for Feminism in Programming Language Design. In Proceedings of the 2024 ACM SIG- PLAN International Symposium on New Ideas, New Paradigms, and Re- flections on Programming and Software . 205–222. doi:10.1145/3689492. 3689809

    2024 doi

  12. [22]

    Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler

  13. [23]

    Capers Jones and Olivier Bonsignour. 2011. The Economics of Software Quality. Addison-Wesley Professional

    2011

  14. [24]

    Eunsuk Kang and Mary Shaw. 2024. tl;dr: Chill, y’all: AI Will Not Devour SE. In Proceedings of the 2024 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Program- ming and Software. 303–315. doi:10.1145/3689492.3689816

    2024

  15. [25]

    Stephen Kell. 2017. Some were meant for C: the endurance of an unmanageable language. In Proceedings of the 2017 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software . 229–245. doi:10.1145/3133850.3133867

    2017

  16. [26]

    Caitlin Kelleher. 2008. Using Storytelling to Introduce Girls to Com- puter Programming. In Beyond Barbie and Mortal Kombat: New Per- spectives on Gender and Gaming. MIT Press. doi:10.7551/mitpress/7477. 003.0022

    2008 doi

  17. [27]

    Ronald Kneusel. 2022. Strange Code: Esoteric Languages That Make Programming Fun Again. No Starch Press

    2022

  18. [28]

    Donald Ervin Knuth. 1984. Literate programming. Comput. J. 27, 2 (1984), 97–111

    1984

  19. [29]

    Donald E. Knuth. 2011. Chapter 7: TPK in INTERCAL. In Selected Papers on Fun and Games . Center for the Study of Language and Infor- mation, Stanford, California

    2011

  20. [30]

    David A Kolb. 2014. Experiential learning: Experience as the source of learning and development. FT press

    2014

  21. [31]

    Michael Kölling. 2024. Principles of Educational Programming Lan- guage Design. Informatics in Education-An International Journal 23, 4 (2024), 823–836. doi:10.15388/infedu.2024.29

    2024 doi

  22. [32]

    Miikka Kuutila, Leevi Rantala, Junhao Li, Simo Hosio, and Mika Mäntylä. 2024. What Makes Programmers Laugh? Exploring the Submissions of the Subreddit r/ProgrammerHumor.. In Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurem...

    2024

  23. [33]

    Peter J Landin. 1966. The next 700 programming languages. Commun. ACM 9, 3 (1966), 157–166

    1966

  24. [34]

    Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrit- twieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al . 2022. Competition-level code generation with alphacode. Science 378, 6624 (2022), 1092–1097. doi: 10.1126/ science.abq1158

    2022

  25. [35]

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang

  26. [36]

    Joseph Lo Bianco. 2004. Invented languages and new worlds. English Today 20, 2 (2004), 8–18. doi:10.1017/S0266078404002032

    2004 doi

  27. [37]

    Violetta Lonati, Andrej Brodnik, Tim Bell, Andrew Paul Csizmadia, Liesbeth De Mol, Henry Hickman, Therese Keane, Claudio Mirolo, and Mattia Monga. 2022. What We Talk About When We Talk About Programs. In Proceedings of the 2022 Working Group Reports on Innovation and Technolog...

    2022

  28. [38]

    John R. Mashey. 2004. Languages, Levels, Libraries, and Longevity: New programming languages are born every day. Why do some suc- ceed and some fail? Queue 2, 9 (Dec. 2004), 32–38. doi:10.1145/1039511. 1039532

    2004 doi

  29. [39]

    Michael Mateas and Nick Montfort. 2005. A Box, Darkly: Obfuscation, Weird Languages, and Code Aesthetics. InProceedings of the 6th Digital Arts and Culture Conference (IT University of Copenhagen). 144–153. https://nickm.com/cis/a_box_darkly.pdf

    2005

  30. [40]

    Sean McDirmid. 2013. Usable live programming. In Proceedings of the 2013 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software . 53–62. doi:10.1145/2509578. 2509585

    2013 doi

  31. [41]

    McIver and D

    L. McIver and D. Conway. 1996. Seven deadly sins of introduc- tory programming language design. In Proceedings 1996 International Conference Software Engineering: Education and Practice . 309–316. doi:10.1109/SEEP.1996.534015

    1996

  32. [42]

    Ed Nather. 1983. The Story of Mel. Available from http://www.catb. org/jargon/html/story-of-mel.html

    1983

  33. [43]

    Graham Nelson. 2006. Natural Language, Semantic Analysis And Inter- active Fiction. 141–188. https://www.ifarchive.org/if-archive/books/ IFTheoryBook.pdf

    2006

  34. [44]

    James Noble and Robert Biddle. 2023. programmingLanguage as Lan- guage. In Proceedings of the 2023 ACM SIGPLAN International Sympo- sium on New Ideas, New Paradigms, and Reflections on Programming and Software. 191–204. doi:10.1145/3622758.3622885

    2023

  35. [45]

    Dominic Orchard. 2011. The four Rs of programming language design. In Proceedings of the 10th SIGPLAN symposium on New Ideas, New Paradigms, and Reflections on Programming and Software . 157–162. doi:10.1145/2089131.2089138

    2011

  36. [46]

    Seymour Papert. 2002. Hard Fun. Available from http://www.papert. org/articles/HardFun.html

    2002

  37. [47]

    Alan J. Perlis. 1982. Special Feature: Epigrams on programming. SIG- PLAN Notices 17, 9 (Sept. 1982), 7–13. doi:10.1145/947955.1083808

    1982

  38. [48]

    Simon Peyton Jones. 2003. Wearing the hair shirt: a retrospective on Haskell. (January 2003). https://www.microsoft.com/en-us/research/ Onward! ’25, October 12–18, 2025, Singapore, Singapore Jeremy Singer and Steve Draper publication/wearing-hair-shirt-retrospective-haskell-20...

    2003

  39. [49]

    Eric Raymond. 2000. Guest Editorial: World Domination.Linux Journal (Jan. 2000). https://www.linuxjournal.com/article/3676

    2000

  40. [50]

    Eric S Raymond. 1990. INTERCAL. https://gitlab.com/esr/intercal

    1990

  41. [51]

    Eric S Raymond. 2010. Risk, Verification, and the INTERCAL Recon- struction Massacree. http://esr.ibiblio.org/?p=2491

    2010

  42. [52]

    Dennis M. Ritchie. 1996. The development of the C programming language. In History of Programming Languages—II . 671–698. doi:10. 1145/234286.1057834

    1996

  43. [53]

    Sammet and David Hemmendinger

    Jean E. Sammet and David Hemmendinger. 2003. Programming lan- guages. John Wiley and Sons Ltd., 1470–1475

    2003

  44. [54]

    Mary Shaw. 2022. Myths and mythconceptions: what does it mean to be a programming language, anyhow? Proc. ACM Program. Lang. 4, HOPL, Article 234 (April 2022). doi:10.1145/3480947

    2022 doi

  45. [55]

    Guy Steele and Richard Gabriel. 2008. 50 in 50. http://lambda-the- ultimate.org/node/3101

    2008

  46. [56]

    Guy L Steele. 1999. Growing a language. Higher-order and symbolic computation 12, 3 (1999), 221–236. doi:10.1023/A:1010085415024

    1999 doi

  47. [57]

    Bjarne Stroustrup. 1998. Generalizing Overloading for C++2000. https: //www.stroustrup.com/whitespace98.pdf

    1998

  48. [58]

    Alaaeddin Swidan and Felienne Hermans. 2023. A Framework for the Localization of Programming Languages. In Proceedings of the 2023 ACM SIGPLAN International Symposium on SPLASH-E . 13–25. doi:10.1145/3622780.3623645

    2023

  49. [59]

    Don Syme. 2020. The early history of F#. Proc. ACM Program. Lang. 4, HOPL, Article 75 (June 2020), 58 pages. doi:10.1145/3386325

    2020 doi

  50. [60]

    Daniel Temkin. 2009. Velato. http://velato.net

    2009

  51. [61]

    Daniel Temkin. 2017. Language without code: intentionally unusable, uncomputable, or conceptual programming languages. Journal of Science and Technology of the Arts 9, 3 (Sep. 2017), 83–91. doi:10.7559/ citarj.v9i3.432

    2017

  52. [62]

    Daniel Temkin. 2023. The Less Humble Programmer. DHQ: Digital Humanities Quarterly 17, 2 (2023)

    2023

  53. [63]

    Daniel Temkin. 2025. Forty-Four Esolangs: The Art of Esoteric Code . MIT Press. (to appear)

    2025

  54. [64]

    Michael Thuné and Anna Eckerdal and. 2009. Variation theory ap- plied to students’ conceptions of computer programming. European Journal of Engineering Education 34, 4 (2009), 339–347. doi: 10.1080/ 03043790902989374

    2009

  55. [65]

    Deepika Tiwari, Tim Toady, Martin Monperrus, and Benoit Baudry

  56. [66]

    Ethel Tshukudu and Quintin Cutts. 2020. Understanding conceptual transfer for students learning new programming languages. InProceed- ings of the 2020 ACM conference on international computing education research. 227–237. doi:10.1145/3372782.3406270

    2020

  57. [67]

    Zhang, Mark Harman, Don Syme, Joost Noppen, and Detlef Nauck

    Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, and Detlef Nauck. 2025. LLMs Love Python: A Study of LLMs’ Bias for Programming Languages and Libraries. arXiv:2503.17181 [cs.SE] https://arxiv.org/abs/2503.17181

    2025 arXiv

  58. [68]

    Chaozheng Wang, Zongjie Li, Cuiyun Gao, Wenxuan Wang, Ting Peng, Hailiang Huang, Yuetang Deng, Shuai Wang, and Michael R. Lyu. 2024. Exploring Multi-Lingual Bias of Large Code Models in Code Generation. arXiv:2404.19368 [cs.SE] https://arxiv.org/abs/2404.19368

    2024 arXiv

  59. [69]

    Jeannette M Wing. 2006. Computational thinking. Commun. ACM 49, 3 (2006), 33–35. doi:10.1145/1118178.1118215

    2006

  60. [70]

    Woods and James M

    Donald R. Woods and James M. Lyon. 1973. The INTERCAL Program- ming Language Reference Manual. https://3e8.org/pub/intercal.pdf

    1973

  61. [71]

    Yicong Yuan, Mingyang Su, and Xiu Li. 2024. What Makes People Say Thanks to AI. In Artificial Intelligence in HCI, Helmut Degen and Stavroula Ntoa (Eds.). Springer Nature Switzerland, Cham, 131–149. doi:10.1007/978-3-031-60606-9_9 Received 2025-04-24; accepted 2025-08-11

    2024 doi

  62. [2007]

    In Proceedings of the Third ACM SIGPLAN Conference on History of Programming Languages

    A history of Haskell: being lazy with class. In Proceedings of the Third ACM SIGPLAN Conference on History of Programming Languages . 12–1–12–55. doi:10.1145/1238844.1238856

  63. [2023]

    Advances in Neural Information Processing Systems 36 (2023), 21558–21572

    Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation. Advances in Neural Information Processing Systems 36 (2023), 21558–21572

    2023

  64. [2024]

    In Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Society

    With Great Humor Comes Great Developer Engagement. In Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Society . 1–11. doi:10.1145/3639475.3640099

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.