Closed marianoguerra closed 1 year ago
π Stop Writing Dead Programs π€ MockMechanics is Turing Complete π Tiny Tile-based Structure Editor ποΈ End User State Machines
π₯ Lisperanto - editor with built in version control via Oleksandr Kryvonos
π¬ Kartik Agaram
Beginnings of an environment for building programs live. Includes some discussion of how the program is represented, including version history.
This is all nothing new compared to Emacs, Lisp, Smalltalk, etc. What draws me to this project is trying to implement these features on a much simpler and so hopefully easier to learn and more self-sufficient stack.
This project has been fermenting in a couple of past threads:
Next step: use the version history to recover from errors. The big epiphany for me has been that I can recover from errors without restarting the entire program -- as long as programs submit to LΓVE's constraints: purely synchronous programming with an event loop, so that no single function can be long-lived. You can write any programs you like as long as they aren't batch programs.
π₯ "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022) via Jack Rusher
My talk from Strange Loop is out. There will soon be a mini-site with a transcript, references, and a few additional notes and corrections.
π¬ Felipe Reigosa
Hey guys, this time I proved that MockMechanics is Turing complete (not a big surprise). I created the smallest universal Turing machine without using any code. Let me know what you think.
π₯ turing2
π¦ Tweet from @pomber via Mariano Guerra
what's a good UI to edit a string representation of a small array of numbers?
π¦ Rodrigo Pombo: what's a good UI to edit a string representation of a small array of numbers?
so far I have this, but I want to see more options
π¬ Breck Yunits
Scenario: GitHub, GitLab and BitBucket decide they're just not that into it anymore and are gonna sunset. What are the other cool online VCS communities?
π We are stuck with egrep and fgrep (unless you like beating people) via Kartik Agaram
One problem in the world today is that if you take a widely used program and add a warning to it in some situation, people get mad at you. No matter how useful the warning is, how insidious the situation it protects you against.
The reason for this seems to be that not everyone who sees a warning is empowered to fix the underlying cause. You might use a library that does something warning-worthy. You can't change the library yourself to fix the warning.
Question for live-program enthusiasts like Jack Rusher[1][2]: I wonder how much this problem is caused by overusing batch-programming and an insufficiently expressive communication channel for warnings. I made up a wishlist at lobste.rs/s/vgnnjt/we_are_stuck_with_egrep_fgrep_unless_you#c_gqhemo that might be interesting to think about together.
On the other hand, I see Common Lisp people get annoyed about similar issues: mailman.common-lisp.net/pipermail/asdf-devel/2022-January/006680.html
π¬ Jim Meyer
Coding tools treat code as static structured text.
UX design tools treat design as static vector-graphics with "noodles for swapping a 1000 static states" on top.
Code is data that needs direct manipulation with instant feedback. That's what creative tools need to achieve.
π¦ Tweet from @guidorosso via Christopher Shank
Finite state machines enabling βend-user programmingβ of complex animations!
π¦ Guido Rosso: Here's how the state machine is set up in @rive_app for this. Without a state machine, all these interactions and logic would need to be written in code.
Btw this is all designed and animated in Rive too.
π¬ Tony Worm
I wonder how much Stable Diffusion, NeRF, and similar techniques will change this?
π emilprogviz.com via Jan Ruzicka
Today, Iβve discovered this year-old but brilliant website and youtube channel by @Emil H: emilprogviz.com
Itβs a series of videos about ideas for improving programming tools. The ones that especially spoke to me were the stretchy code map (episode 2), call graph navigator (episode 4). Iβm personally looking forward to the next episodes, when Emil has the time to record them.
π₯ [TyDe'22] tylr, a tiny tile-based structure editor via Mariano Guerra
tylr, a tiny tile-based structure editor
Abstract: Structure editors designed for keyboard input often struggle to resolve the tension between maintaining hierarchical term structure and offering efficient linear editing affordances. Contemporary designs either compromise structure by deferring to text near the leaves or else maintain structure by permitting only edits that transform the selected term.
However, visually adjacent sequences (e.g. of operators, operands, and individual delimiters) do not always cleave cleanly to term boundaries, so even experienced users report difficulties with selection and code restructuring tasks. We propose a novel approach to structure editing, tile-based editing, that maintains term structure while offering linear selection and modification affordances.
The idea is to allow disassembly of terms into linearly sequenced tiles and shards around user selections, while guiding the user through restructuring actions and automatically inserting holes in a manner that ensures reassembly into a term. This paper introduces tylr, a tiny tile-based editor designed primarily to highlight this uniquely flexible set of affordances.
We evaluated tylr with a lab study where participants performed simple code transcription and modification tasks using tylr as well as a text editor and a structure editor built on JetBrains MPS, a state-of-the-art keyboard-driven structure editor generator.
Our results indicate that participants frequently made use of tylr's selection expressivity, and that this flexibility helped them complete some modification tasks significantly more quickly than with the MPS editor.
We further observed that a few participants completed some tasks more quickly using tylr than with text, but were in general slowed by a number of limitations in our current design and implementation. We discuss these limitations and suggest future research and design directions aiming toward more flexible structure editing interfaces.
π¬ Ivan Reese
[Not moved from anywhere, original post by Ivan Reese]
We're going to record the next episode of the FoC podcast in about a week.
Something new I'd like to do is read questions or other discussion prompts submitted by the audience. Then we'll probably talk about them. Would be weird if we just read them and moved on after a moment's awkward silence.
Kindly DM me any questions or things you'd like us to talk about. Don't β I repeat, do not β send them to Jimmy Miller. You mustn't. He's a real programmer, not an art school dropout. He can't be trusted with information.
Best if the questions / topics are related to the FoC, the show, or Jimmy/myself as "people". But I can't and won't tie your hands.
Thanks, friends!
[x] Change Month and Week Number
[x] focWeekExport "2022-01-19" "2022-01-26"
[x] Update Search Index
[x] Download New Attachments
[x] Update links
[x] Check that comment links work (push weekly dump with channel summaries)
[x] Check to mention right person for moved messages
[x] Summary
[ ] Hashtags
[ ] Set title in newsletter
https://tinyletter.com/
https://tinyletter.com/marianoguerra/letters/
http://localhost:8000/history/
https://marianoguerra.github.io/future-of-coding-weekly/
https://stackedit.io/app#