FWIW, my reaction to something mentioned in the latest FoC podcast (futureofcoding.org/episodes/073):
Computer Science isn’t about programming . Computer Science is about mapping computational thinking into the digital domain and discovering problems in an ad-hoc manner, then fixing the problems to make the mapping work on reprogrammable electronic machines.
programmingsimplicity.substack.com/p/computational-thinking-run-amok?r=1egdky
When I started my law firm, I thought everything I knew about a client matter needed to be in "the file". I wasted a lot of time moving things that were perfectly fine where they were. I realized that "the file" was a naive metaphor I took from law firms pre-cloud. That changed my outlook about data models. I don't want my digital model of things to mimic the real world artifacts involved, and spend a lot of time trying to explain to my colleagues that just because a person files a motion by delivering a real or digital pile of pages with real or digital ink on them doesn't mean that the document and the motion are the same thing. A motion doesn't have a page orientation, and a document isn't potentially vexatious. But when I argue that we should be modeling the domain, not only the artifacts, my colleagues — who are all also former lawyers — don't seem to disagree so much as act as though I'm speaking heavenly script. Does anyone have any tips for persuading people who haven't been converted to the wisdom of domain modeling that maybe our systems should deal with the things we care about, and not only the things we can download or touch?
I'm increasingly trying to focus on specific things that you can do in terms of features and UI/UX that are impossible or very hard without the domain model. Hopefully that will help. But any insights appreciated. Have you persuaded anyone? Has anyone persuaded you?
I would talk about how crime detectives resort to knowledge graphs to identify patterns. Graphs are where it's at. Every other artifact is lossy and should be derived rather than be the source of truth.
These are called "evidence boards". More sophisticated ones would incorporate time and place dimensions into it.
I have the same problem with explaining domain modeling to my colleagues in computational science. What I try, with mixed success, is to say that I want people to interact with computers using the same concepts that they use to communicate with each other. The mixed success is probably due to a change of habits in what I see as the wrong direction: people start to talk to each other in terms of files and programs. It is normal nowadays to see journal articles state "we analyzed the data using the FOOBAR program suite" rather than "we computed a time correlation function".
@Nilesh Trivedi oh wait, what, evidence boards are real and not just an invention by hollywood? TIL!
I wonder if an evidence board is sort of not at all what I want them to be thinking about, because an evidence board is a graph of physical artifacts. I want a graph of abstract entities. You can't pick up and pin someone's lawsuit to a cork board. 😂 I did make a little progress today with drawing pictures. But so far what I have achieved is bemused tolerance, and what I'm looking for is enthusiasm. 😉
If you learn how to get abstraction-averse folks to address boundary objects as signified and not as signifier, let me know. I yearn for this technology too. But I agree that drawing pictures together is our best stop-gap in the meantime.
I would recommend David Ribes' work on this subject of (other) domain logics. Lately I have approached visualization design studies as a method of soliciting (as Konrad has it) discussions with collaborators that are more about 'time correlations' and less about 'FOOBAR program suite'.
(ribes 2019) dl.acm.org/doi/pdf/10.1145/3359140
(otto 2024) osf.io/9f5ub
The theory of boundary objects describes how designed artifacts support coordination between different expert stakeholders. [...] In contexts where technological mediation makes ‘seams’ between domains hard to traverse, visualization artifacts are valuable because they enable experts to share knowledge with other stakeholders.
📝 2024_BELIV_Boundary_Objects_Camera_Ready.pdf
Presented by OSF
Also, I recall that Ian Arwajo recommends Latour's essay on Circulating Reference as well, and has written about the subject at length himself. Sadly these ones are paywalled, let me know if you want the pdfs.
(latour 1999) google.com/books/edition/Pandora_s_Hope/RMu6wbzVrVkC?hl=en&gbpv=1&bsq=circulating%20reference
(arwajo 2020) dl.acm.org/doi/pdf/10.1145/3313831.3376731
Although later work in software would characterize drawing diagrams as purely documentation, extraneous to the practice of coding and “drawn after, not before, writing” programs [29, p. 194], coding in the ENIAC vision was firstly inscribing by disciplined hand.
Could Huawei's triple foldable display phone combined with software like Samsung Dex liberate portable devices from being consumption-oriented devices? 🤔
Apple has kept a strong hold on keeping ipadOS from threatening macOS. But the Android ecosystem does not have that limitation (see Waydroid or BlissOS or PostmarketOS for example)
Projecting in the future, we might even get briefcase size displays/machines that unfold into a full tabletop-style communal computing interface.
My take on this is: It's not a matter of display size, it’s a matter of interaction models. We'd be happily programming on touch-screen smartphones, if someone had figured out how to provide a better interaction model for programming on such devices. Granted, it's even harder for smartphones than it is for tablets, but there's not many projects that explore this space. It seems as if 99% of all “future of coding” projects still assume large display, keyboard, pointing device, and text-based programming. Even visual programming explorations usually start from mouse interaction, instead of touch-first, which is similar but subtly different. There are also many sensors in tablets and phones that could be utilized for such an experience, which you usually won’t find in laptops and certainly not in desktops. But it seems few of us target these device classes, and if so, only as an afterthought porting something that has been designed for keyboard and pointing device, which is just not going to provide a better experience.
Stefan Lesser That's very insightful! I do find swype keyboard very efficient but your post provokes much bolder approaches.
FWIW: I think that there are at least 2 interaction models: (1) end-user (non-programmer), and, (2) developer. When I write code, I use emacs, because I can do just about everything with 10 fingers and without lifting my hand off of the keyboard to fiddle with the mouse or Apple pencil. Mousing and swiping and speaking are operations that are too large-grained for me when I'm "in the zone" writing code. I used to play piano and observe that a QWERTY keyboard is more efficient than a piano keyboard (less arm motion involved). I used to play guitar, but, wonder if the Chapman Stick is a better way to cause audible vibrations (youtube.com/watch?v=78hlYpydv5g). The Yamaha WX7 Wind Controller used 8 fingers and the mouth and lungs. Artists want nuance. Software developers are like code artists, I guess. At one time, we explored building a diagram editor that was like emacs - mostly keyboard, mouse optional.
Periodic self-reminder.
The main ideas behind Hest are:
Are there languages that emphasize the single-datum <=> collection-of-data duality? E.g. making loop-with- if <=> filter -on-the-whole look very similar?
But that's just a programming curiousity; I'm more interested if there are any mind bicycles that help one think about local vs. global rules?
Physics is rich with examples where seeing both perspectives is insightful:
Example task: For a while now I've dreamed of making a model of weather that's simple enough for paper+pen+tokens, or generally something "board game-ish". Lies-to-children are fine, but would like it to demonstrate at least basic mechanics: (A) wind caused by hotter air rising and leaving a vacuum; (B) evaporation over sea => rain over land (C) "rain shadow" beyond a mountain (my country has this).
It's not easy to discretize continuous-quantity equations into something like a cellular automaton... I'm leaning towards representing conserved quantities like water with tokens you can move, rather than per-cell state.
And I don't want some huge "simulation"—I'd love to find rules that can demonstrate these processes in few enough steps to follow by hand.
Hmm say I have air that wants to go up + right, and it holds just 1 water token—which way do I move it? Well I suppose I want a bit larger numbers so quantization won't matter that much... And I probably want alternating horizontal vs. vertical game phases (also dealing with 1D slice at a time can reduce previous-vs-next-state confusions).
Any advice for tools to help think about rules/mechanics and what can emerge from them, beyond "try and see what what happens"?
(But I guess I really should play with large "sand" style models, then try to scale down! try-and-see is more powerful than merely keeping in my head.)
