Gábor Melis introduces MGL-PAX, an "untangled" literate programming system for Common Lisp. An untangled system takes advantage from the flexibility of code order of a language to rely less on tangling tools.
#literateProgramming
Whether you agree with, hate, or are turbulently navigating the transition of many teams to agent-mediated coding (I am considering the post from @anildash where he talks about #codeless, IE #LiterateProgramming or #LiterateDevelopment), Robert C Martin's book, Clean Code should be the bible in these times.
@anildash I do have a better term than #codeless!
I mean Donald Knuth does: #LiterateProgramming.
AI is new, but everything about what the developer does is, well, let's call it #LiterateDevelopment, just a slight shift into this millennium, reflecting that it really becomes enough to develop a system, still obviously referencing Knuth.
I think the word "literate" emphasizes the care and responsibility a dev should take not to produce slop.
#AppleII #hires #applesoft #basic #literateprogramming #apple2
REM HOW TO CALCULATE THE HIRES ADDRESS
REM GIVEN THE COORDINATE OF A PIXEL
https://mmphosis.netlify.app/hires/
What a curious point about LP:
In part this is because LP is not much practiced, but it is also because, as Christopher Wyk perceptively observed (CACM 33.3, 1990), "no one has yet volunteered to write a program using another's system for literate programming".
Why does it specifically apply to #LiterateProgramming and not, say, programming languages? :blobcatthinking:
I wrote an MMORPG where the README is the executable.
The game world is The Internet Gopher Protocol itself.
The game is written as literate Haskell.
Source: https://github.com/someodd/grpg
🧠📄⚙️🐹
#programming #haskell #literateprogramming #retrocomputing #gopher #gamedev #opensource
Fun idea:
I've found that a lot of times, I've been using #ChatGPT and other LLM assistants to help me research things. I write in my thoughts and questions, and the bot comes up with stuff that, uh, may or may not be helpful. It *might* be useful or accurate. Or it might be badly parsed Reddit horseshit. Or made up.
Thing is, while the LLM is occasionally useful* (*in the Principia Mathematica sense), I find *my* side of the process more interesting here.
Why don't we have interfaces to online research and search engines that would use journaling (or #literateprogramming) as UI metaphor?
Basically, #Jupyter Lab, but for Googling?
"Okay, so today, I searched for A and B. This is the sort of results I got. [Results] Hmm, some of those also talk of C and D. A and C, and B and D seem very related, I wonder if that's so? So this is what I searched next, and this is what I got [More results]..."
And hey, this doesn't even need chatbots to work!
Ah yes, yet another attempt to decrypt the Rosetta Stone of #coding - "literate programming." 📚💻 A literary masterpiece where everyone pretends to understand #Knuth, while secretly just hoping the comments make the code run faster. 🤦♂️ Spoiler alert: It’s like Shakespearean sonnets but for the terminally nerdy.
https://pqnelson.github.io/2024/05/29/literate-programming.html #literateprogramming #humor #techliterature #nerdculture #programmingjokes #HackerNews #ngated
What even is "literate programming"?
https://pqnelson.github.io/2024/05/29/literate-programming.html
#HackerNews #literateprogramming #programming #concepts #tech #education #coding #insights
Ayer presenté en LatinR 2025 un paquete de R llamado taxnames, que sirve para insertar nombres científicos de organismos en documentos de R Markdown o Quarto. Desarrollé este paquete para ampliar las capacidades de taxlist y facilitar la conexión entre bases de datos taxonómicas y documentos taxonómicos o de biodiversidad.
Si te interesa este tema, echa un vistazo a la presentación: https://www.youtube.com/watch?v=Cg27K-hdaQ0&list=PL9-E3cL2KgKnHT6jP17fZozEN-KVTWp_m&index=2
#rstats #LatinR2025 #taxonomy #environment #biodiversity #literateprogramming
My contribution to this month's Emacs Carnival, *An ode to org-babel*, as hosted by @donaldh.
https://www.homepages.ucl.ac.uk/~ucecesf/blog/20251112.html
#Emacs #EmacsCarnival #OdeToOrgBabel #orgmode #DataProcessing #DataAnalysis #LiterateProgramming
Really enjoying this month’s #Emacs Carnival on #orgmode — especially the focus on #orgbabel!
Huge thanks to @donaldh for curating the topics.
For me, #orgbabel is where documentation, data, and computation truly meet — it turns notes into living, reproducible workflows.
I’ve written down why I think org-babel is a *ROOT technology*:
https://lukascbossert.de/posts/org-babel/
@lukascbossert In 2012, I presented a paper at #iKNOW2012 where I demoed the workflow to generate an ACM whitepaper from one single #Orgmode file + Org-babel + raw data files in CSV format.
Template used: https://github.com/novoid/orgmode-ACM-template together with Tom Dye.
This might be irrelevant implementation-wise because it would need an update but the workflow idea is still awesome!
The people at the session back then mostly did not get it. I probably failed to transmit the idea because they asked specific questions about the demo example data which was just lorem ipsum to me. 😉
The meta poster frames the concept: clarity + openness → resilience. It traces the lineage from Knuth’s Literate Programming to Org-mode and NFDI practice, and introduces the ROOT badge as a compact signal for robust, open, ongoing, time-tested tools. It also spotlights resilient stalwarts often hiding in plain sight—find, LaTeX, perl, rsync, SQLite—showing why they remain reliable RDM building blocks.
#ResilientTech #LiterateProgramming #OrgMode #RDM #NFDI #FAIR https://doi.org/10.5281/zenodo.17157588
Main poster maps long-lived tools to the research-data life cycle (Plan → Produce → Analyze → Archive → Access → Re-use). Emacs/Org for provenance, Make for rebuilds, curl/sed/grep/diff for intake & checks, awk for tables, cron for timing, tar/rsync for packaging/sync, plus SQLite/LaTeX/find. Pipelines you can re-run years later. Feedback welcome! #ROOT #ResilientTech #RDM #NFDI #Emacs #orgmode #literateprogramming #OpenScience #tools #researchdatamanagement
https://doi.org/10.5281/zenodo.17157588
Resilient technologies aren’t retro—they’re ROOT: Robust, Open, Ongoing, Time-tested. In RDM, text-first + small, composable tools beat opaque stacks. Emacs/Org(-babel) for literate workflows & provenance; Makefiles declare rebuilds; CLI atoms—curl, sed, awk, grep, diff, tar, rsync, cron, SQLite—keep steps inspectable, portable, rebuildable. DOI: https://doi.org/10.5281/zenodo.17157588 — Feedback welcome!
#ROOT #ResilientTech #Emacs
#OrgMode #RDM #NFDI
#FAIR
#Reproducibility
#literateprogramming
#BoostOK
I wrote a little about "literate programming" used to implement proof assistants, mostly about the "literate programming".
#LiterateProgramming #ProofAssistant #Logic #Mathematics
https://thmprover.wordpress.com/2025/09/16/literate-implementations-of-proof-assistants/
@Eduardo Mercovich (él)
I sort of had it in mind that it might be in chapters (or possibly modules?) with the code relevant for that chapter in there too.
The point of literate programming is that there isn't a distinction between 'code' and 'documentation'. I realise your thesis goes beyond code and documentation about the code, but I wonder whether the same line of thought might still apply: perhaps the discursive thesis, the code, the code's documentation, the data, etc. all belong with one another, on a topic or chapter basis?
As I don't have a very concrete suggestion but just some floating ideas, I think my advice is still the same: keep it as one file for now and work it out later. A division that makes sense may arise as you & your collaborators work with it more — let the cowpaths emerge!
I think one file will leave your mind more open to other alternatives too. Generally speaking if you don't have a good basis to make a decision, and there's no real reason to make it right now, it's better to just defer it.
However, I don't think anything very much will go wrong if you decide you like the idea of splitting it into code and non-code. You can always change your mind later.
#tem25 #literateprogramming
I sort of had it in mind that it might be in chapters (or possibly modules?) with the code relevant for that chapter in there too.
The point of literate programming is that there isn't a distinction between 'code' and 'documentation'. I realise your thesis goes beyond code and documentation about the code, but I wonder whether the same line of thought might still apply: perhaps the discursive thesis, the code, the code's documentation, the data, etc. all belong with one another, on a topic or chapter basis?
As I don't have a very concrete suggestion but just some floating ideas, I think my advice is still the same: keep it as one file for now and work it out later. A division that makes sense may arise as you & your collaborators work with it more — let the cowpaths emerge!
I think one file will leave your mind more open to other alternatives too. Generally speaking if you don't have a good basis to make a decision, and there's no real reason to make it right now, it's better to just defer it.
However, I don't think anything very much will go wrong if you decide you like the idea of splitting it into code and non-code. You can always change your mind later.
#tem25 #literateprogramming
Does this sort of thing count as an intrusive thought?
What else can I share to better describe the thesis? Some parts that are not clear?
While #orgmode does 85% out of the box (#LiterateProgramming, tagging, counting, writing, exporting, even interacting with #gnuplot, etc.) #elisp is needed to do some of this calculations, ordering and grouping... :)
[end] #tem25
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst