Future of Coding is an online community with a welcoming, cooperative, and revolutionary spirit. We are unified in the belief that the common practice of programming is tragically less humane than it could be.

Future of Coding

"Logic is Algebra" paper suggests Abstraction Logic as foundation of mathematics: <https://arxiv.org/abs/2304.00358>
It's from the creator of Practal proof language: <https://practal.com/>

Interesting... I wonder if this is consistent (considering how much power the metalogic seems to require). I'll need to read this more carefully when I have time.

The Little Typer online reading group starts tonight around 7 PM Toronto time contact me for details

<https://www.cs.cmu.edu/afs/cs/user/bam/www/langbook.html|https://www.cs.cmu.edu/afs/cs/user/bam/www/langbook.html> 1991 workshop proceedings looks interesting but not sure it's worth buying :thinking_face:   But amazon free sample is generous, reading that first...

It's on the libgen shadow library <https://libgen.li/edition.php?id=138574748>

I'm looking at defining a collaboration-centered language that has sound semantics (ie semantics under composition are intentional and generally useful)
My understanding is that you can only verify semantics for a specific model, so trying to define a "good enough" model
Do y'all know of any papers on the tradeoffs of various "computer" models for distributed machines? Bonus points if it has time costs and resource limits built in and supports heterogeneous machines.
My best guesses so far are <https://arxiv.org/abs/2002.02762|guarded petri nets> or <https://arxiv.org/abs/2005.01894|Poly>

IMG_20231012_130106.jpg

I was leafing through my father's old books when this diagram caught me off-guard.
We're so used now to having an OS with apps, that it's weird to think of OS-level transitions (login-&gt;shell), inter-apps transitions (shell-&gt;vi) and inside-app transitions (vi's command&lt;-&gt;append modes) as similar things. :upside_down_face:
But to a user new to computers, yes these are all "modes".

IMG_20231012_130114.jpg

The book was "Unix Made Easy" by(?) "Lurnix"

IMG_20231012_130242.jpg

They had a deeper one with mail(1) spawning off vi(1):

I doubt anybody still composes mail that way, but the practice of semi-interactive unix tools spawning $EDITOR is very much alive e.g. `kubectl edit pod` or `git rebase --interactive`...

Personally I happen to prefer "emacs pinky" to vi kbd efficiency, and I can sympathize in general with "modes considered harmful".
But would I be willing to apply that principle to app switching?? :thinking_face:

• No!  That would mean everything the computer does MUST follow same Interface Guidelines™, which I agree is nice for users, but also implies program authors can't experiment with unusual interfaces. But my computer is a general-purpose device, damn it, and e.g. games should be able to take over hardware for an immersive experience.
• Maybe!  I'd love things to be more <https://alexanderobenauer.com/articles/os/1/|itemized> where most work happens not in isolated "apps" but a shared computational env to which I can apply a global set of commands.  like Emacs, or Boxer, or Jupyter, or even the tty... 
    ◦ Or hey, the browser!   "everything is html + links" with global actions like "go back" was an itemized env that actually succeeded at reaping some benefits of "itemization" and won the world!  It didn't go very far though, got optimized for app devs over user agency + automation and now is pretty much a regular OS (exhibit: Chromebooks).

Great thread with excellent set of questions/challenges/topics for this community - but you hid them further down! The main post is of geeky interest at first sight, but maybe you could, I dunno, repost the juicy post to the channel or something?

Having said that, you mentioned "modes", which normally gets the vi-haters wound up! (I'm a vi user not emacs btw)

I've read Jef Raskin's _The Humane Interface_ and other writings against modes. I generally find them persuasive (even as a vi-keybinding-user). But I still see mode problems _everywhere_ in UIs, and see people stumble with them. The most common is focus — I _think_ focus is on one element or in one window, when it is actually elsewhere, so my input goes to the wrong place. Have "we" generally decided that mode errors aren't as much of a problem after all?

&gt;  That would mean everything the computer does MUST follow same Interface Guidelines™, which I agree is nice for users, but also implies program authors can't experiment with unusual interfaces.
This is more-or-less what made me accept (and still sometimes hate) the web as a platform. There are no (all that useful) UI standards, but there is a *ton* of room for UI innovation.

Hard to tell if it is worth the usability cost, or how much we ought to be making user interface experiments on unwitting users.

&gt;  I'd love things to be more <https://alexanderobenauer.com/articles/os/1/|itemized> where most work happens not in isolated "apps" but a shared computational env to which I can apply a global set of commands.  like Emacs, or Boxer, or Jupyter, or even the tty...
Are you thinking of something similar to <https://en.wikipedia.org/wiki/OpenDoc|OpenDoc>? (I'll have to read through your link in more detail later.)

I don't think "can't experiment with unusual interfaces" is what we should be concerned about, it's more "competition to make a better thing".

But personally I'm in the camp of "give 90% of the users something simple, consistent and effective for 90% of their needs, but allow extension for edge cases and those difficult ones (like me!)" If you don't have apps at all, then you're kinda forced into cross-datatype interaction consistency. Which is good IMHO.

And yes, "itemized" is (part of) the future! There's another thread talking about Obenauer's stuff just now.

And exactly as you say, it's also the past - the TBL Web didn't have "apps" like today's web pages have. Today, each page is not really part of a seamless web any more.

I'm thinking this is too good a thread to drop or have limited visibility, so I'm re-energising it!

I've been digging into Raskin's work this morning; here are some links I found:

<https://www.wired.com/1993/06/1-6-guis/>
<https://web.archive.org/web/20080509155848/http://jef.raskincenter.org/humane_interface/summary_of_thi.html>
<https://wiki.c2.com/?TheHumaneInterface>
<https://en.wikipedia.org/wiki/Archy_(software)>

His son Aza carried on his work for a while, at least (as head of UI at Mozilla, then... I stopped paying attention). I remember that he did some additional work on Archy.

It's been somewhat carried forward with Mercury OS
<https://uxdesign.cc/introducing-mercury-os-f4de45a04289>
<https://www.mercuryos.com/>

I love the idea from Jason Yuan (I think this is what he's saying) that if you design for neuro-atypical folk (like me) who have immense difficulty getting into a flow state and are easily distracted (I have OCD, misophonia, etc, etc), then you benefit everyone. This is a principle I've always espoused: design for those with disabilities and everyone benefits. I often take the ramp not the stairs in honour of this! I have lever-handled taps in preference to grab-and-turn ones. Mind you, I also have a daughter with disabilities.

<@UC2A2ARPT>, in episode 9 of a podcast I can’t tell if I’m supposed to know about or not, you asked, “Where is [data] going when you’re throwing it away, and when you rewind, how does it come back?” And I don’t think it has answers that you’d want to apply directly to your situation, but *Feynman’s Lectures on Computing* comes back to the idea of reversible computing again and again with various playful metaphorical lenses. I think that at the very least it might be a nice way to take a break and think about the problem from a physicist’s perspective now and then, if this is still a problem you’re working on.

An extremely low-power computer needs to run just as easily forward as it does backward, so that the slightest touch can send it in one direction or the other. In fact, it will rock forward and backward just based on random fluctuations, and you try to bias it just enough so that it runs forwards more often than backwards.

To do that, no part of it can ever create or destroy information. Every operation propagates the “waste” information forward so that if it rolls backward, it returns to its initial state. It’s fun. :)

I love reversible computing! Your 2nd message has a lovely description of it, painting it in a way that I'd not quite pictured before. Thank you for sharing that!

Reversible computing is attracting a lot of interest recently because it is the only possible approach to quantum computing. I'd expect the "green computing" people to explore it as well, but I haven't seen any references to it.

Something that ought to be obvious but is rarely said is that "never deleting data" also means "never adding data". A perfectly reversible computing system is useless for information processing. But searching for a good compromise ought to be an interesting engineering challenge.

That’s not obvious to me. Why can’t data be added?

There’s just an energy cost to changing the inputs, AFAIK?

Exactly. Adding data means changing the inputs. That entails the same energetic cost as deleting the prior input values. If you look into reversible computing from an energy-saving point of view, it really matters to look at a complete usable system.

A very interesting podcast talking about *the future of software engineering* :bulb:
• How classic programming differs from ML/AI programming ..
• How to software engineers can adapt to emerging AI technologies ..
• And few other topics related to AI/ML and software engineering ...
<https://stackoverflow.blog/2024/01/16/Kian-Katanforoosh-standford-deep-learning-ai-skills/>


_*If What We Made Were Real: Against Imperialism and Cartesianism in Computer Science, and for a discipline that creates real artifacts for real communities, following the faculties of real cognition*_
Antranig Basman
Abstract: I argue that we have not yet succeeded in constructing any real software, but merely simulations or cardboard prototypes of software…

PPIG 2017 - 28th Annual Workshop
<https://www.ppig.org/papers/2017-ppig-28th-basman/|https://www.ppig.org/papers/2017-ppig-28th-basman/>
Not new, but new to me. Indeed PPIG seems to be a goldmine

An inspiring <https://searchworks.stanford.edu/view/jm095fy2355|video: Mobile Pen-based Computing (1992)>. 1hr 3 min.

In the conference recording, <https://en.wikipedia.org/wiki/Terry_Winograd|Terry Winograd> demos the <https://en.wikipedia.org/wiki/PenPoint_OS|PenPoint OS>, a mobile operating system focused on the "notebook interface". This is around the time PDA's and Apple Newton were on the radar.

image.png

Pete McBreen's _Software Craftsmanship: The New Imperative_ (2002).

Most of the book is about the consequences of distinguishing between "software engineering" (defined as armies of programmers going down a waterfall) and "software craftsmanship" (defined as small teams working incrementally). He runs deep with the craftsman metaphor, taking seriously how to make real the "apprentice" and "journeyman" stages in a software developer's career.

One interesting thread is that he points out how "best practices" are firmly a creation of the software engineering side of his binary, and do not satisfy craftspeople's very different trade-offs. Some by nature will wind around on their own path, custom-fitting each architectural decision to their preferences and the needs of the specific project.

There is overlap with our <https://futureofcoding.slack.com/archives/C5T9GPWFL/p1703941495921419|discussion of a month ago>, exploring <@U013ZLJARC7>'s ontology of [programming, computer science, software engineering]. It seems useful to me to further distinguish the "strong S.E." that Jack and McBreen use as definitional from the "soft S.E." which we all seem to use colloquially to mean all manner of techniques for making an application error-resistant. The work of the latter may not be intellectually engaging or novel but it lacks the qualities which make strong SE distasteful: centralization of power, treating developers interchangeably, the urge towards monoculture, a cultural belief in "training" instead of learning.

This is toward the top of my reading list for new developers on my team.

What book should we read for FoC book club #1? (More info in thread)

<https://futureofcoding.slack.com/archives/C01932BJGE8/p1706564547227609|See initial discussion here>. All are welcome to join!

Feel free to add books to the poll and vote for as many as you'd like. I added a couple to get us started. Once we choose a book we can settle on a time to meet.

I used the free version of Slack's poll app, which has some restrictions: 100 response limit per month, can’t send in thread (only channel), can’t edit a poll, etc. Let's see how it goes, and later we can consider switching to another polling app or simply a message with emoji reactions. These are the poll settings I chose:

• Make responses anonymous: `No`
• Allow others to add options: `Yes`
• Select one option / Select many options / Rank options: `Select many options`
• Show results of the poll: `In real-time to everyone`
• Mentions and reminders: `No`
• Order results by most votes: `No`
• Close poll automatically: `No`
I'd welcome any suggestions on poll settings or other housekeeping items. Excited to read together!

Tagging everyone who liked the original message: <@UCS1K3QTH> <@U05UK5T7LPP> <@UK3LH8CF5> <@U05SU27S1M2> <@U05Q5DXRK5L> <@U06GHD1TJJD> <@USH01JEDQ> <@U06H4766K42>

We can give it a week or so to nominate and vote, then we can start reading and pick a time to meet :slightly_smiling_face:

Just posting resources - <http://worrydream.com/refs/Papert%20-%20Mindstorms%201st%20ed.pdf|http://worrydream.com/refs/Papert%20-%20Mindstorms%201st%20ed.pdf>

Can others see the `Add option` button on the poll? Just want to make sure I'm not the only one who can nominate!

This piece by Prof. A.J.Ko might be of interest for those planning to read mindstorms <https://medium.com/bits-and-behavior/mindstorms-what-did-papert-argue-and-what-does-it-mean-for-learning-and-education-c8324b58aca4|https://medium.com/bits-and-behavior/mindstorms-what-did-papert-argue-and-what-does-it-mean-for-learning-and-education-c8324b58aca4>

I assume we are splitting off based on vote, but starting with what the majority chose, correct?

That's what I was thinking^ (i.e. we all read the top voted book). Then we could automatically roll runner-up books into the poll for the next meeting. Open to other structures, though!

I thought that was the plan too, 

I’ll admit that while I am interested in end user programming, I am not interested in education and can’t really see myself ploughing through mindstorms

(And I find that thing where dads try to get their small children programming a bit off-putting tbh. Play with them ffs. They aren’t small for long & no one ever said they wish they wrote an app when they were 8)

<@UCS1K3QTH> haha, to be fair a lot of Mindstorms is about play. Overall though, it’s much more focused on learning than programming.

Looks like _A Small Matter of Programming_ will be the first book. Before I post a poll for day/time — does anyone have suggestions on accommodating such a wide range of time zones? (Maybe someone with experience working for a global remote company?)

Based on time zones in Slack profiles, we have:
• UTC-8: Jasmine, Justin
• UTC-7: Ivan
• UTC-5: Ben, Jos, Pete, Jacob, Naveen, Jimmy
• UTC+0: Stephen, Alex
• UTC+1: Mariano, Jack
• UTC+5: Prabhanshu
• UTC+11: Mattia 

There is no good way to accommodate that range of timezones 
The best I can suggest is 16:00 utc. - 8am for utc-8, 9pm for utc+5, but is *3am* for utc+11

And that is assuming work and family commitments don’t preclude participation

IMG_7970.jpg

Wow, what an amazingly time-zone distributed set of folks.

I’m just going to jump right in and start a thread for ch1 it is only 11 pages

I’m open to async sharing my thoughts- i kinda prefer over audio - i have a tendency to walk and talk my ideas out. 

~10 page units are really encouraging / approachable

Yes but I forgot to include the preface and introduction :rolling_on_the_floor_laughing: 

This is my first time seeing this book! I’m only five pages into the Introduction and already full of thoughts! I’m also very aware of the bias’ i’m bringing to the pages regarding my personal beliefs about why the problem exists and what could improve it. 

"Programming-in-the-large versus programming-in-the-small" by DeRemer and Kron (1975)

<https://dl.acm.org/doi/pdf/10.1145/800027.808431>

*Chapter 1 Introduction* (11 pages) 
&lt;https://mitpress.mit.edu/9780262140539/a-small-matter-of-programming/|A Small Matter of Programming
Perspectives on End User Computing
By Bonnie A. Nardi&gt;



From the preface: _This book asks why it has been so difficult for end users to command programming power, and explores the critical problems of the end-user application development must be solved to afford end users greater computational power._


_The chief problems to be solved in providing more end user application development environments are_
_(1) To provide highly specialised end user programming environments that leverage users’ existing task related interests and skills, and
(2) […] re-organise work practices to better support end users._

_How are we to do these things? That is the subject of this book, […]_


Grabbed my copy from the shelf, and will do my best to at least follow along here... Is this book really 30 years old?

If anyone would like a digital copy of this book (hard to find), feel free to DM me. :slightly_smiling_face:

The thing that I find most jarring in this chapter is the early 90s framing where computing devices are not yet ubiquitous, and still kind of an alien intrusion in many users' lives (there's a line about 'computers gathering dust' from disuse as people continue to use old manual processes). The thing that I find most relatable is a mention of users preferring to tediously execute repetitive steps to accomplish a goal instead of figuring out how to use the programming/automation tools they have access to.

Everything said so far resonates quite strongly with me, really excited for the next chapter

<@U04717WKH5K> I wasn’t around in the 90s :slightly_smiling_face:, do you think that the resistance to programming was because of bad tools or that the manual alternatives were sufficient? (or really where on this spectrum)

<@U05TJD2V4P2> some people were threatened by the growth of personal computers in the late 80’s/early 90’s 
I spent time in banks and libraries where terminal based system were commonly used by front line staff, but anything pc-based was very new

It is hard to remember what the world was like prior to the explosion of smartphones 

&gt;  the resistance to programming was because of bad tools or that the manual alternatives were sufficient
I think there were a lot of factors that overlapped -- certainly many workplace systems were literal translations of existing paper forms and offered little in the way of opportunity, but I'd think that the novelty was as much of a factor. It's a huge leap to start thinking computationally. I remember my wife taking a required Excel class when getting her Masters' in Education in the 90s and watching her use a pocket calculator on the desk to sum a column instead of using `=SUM(A1..A10)` and (even more) her resistance to approaching the problem in this way.

IMG_6003.jpg

End user = The opposite of a compiler or DSL writer (the "beginning/starting user"? prime mover alpha vs omega)

Another connotation of endpoint is the end of a pipeline, that receives the most finished product

IMG_6004.jpg

Further evidence all that's required is HyperCard buttons + HyperTalk, could prob even recapitulate visual programming 

There have been a lot of HyperCard clones that have got approximately zero uptake and sank without a trace. It is a different world now.

Don't take the bait from the hypertrolls Stephen

I recently saw an upcoming small game making tool called Downpour (<https://downpour.games/>, also shared at the London meetup) where you create cards from photos and link them together with a bit of logic. It reminds me of some of the "magic" HyperCard unlocked.

The "just who are end users?"  passage that <https://futureofcoding.slack.com/archives/C037X8XMFB3/p1708487434608039?thread_ts=1708096398.023089&amp;cid=C037X8XMFB3|Christopher screenshotted> feels timeless. End users want to get work done whereas programmers want to work on interesting problems (and get work done). It reminds me of something I heard Jerome Hardaway say when I was first learning to code (paraphrasing): your users only really care that your website (1) works, (2) is fast, and (3) looks good—in that order.

&gt; If anyone would like a digital copy of this book (hard to find), feel free to DM me. :slightly_smiling_face:
<@UML4ZEKDK> looks like Stripe Press is <https://x.com/_TamaraWinter/status/1757769019669590199?s=20|going to republish it>! Not sure when, but in the meantime someone posted a link in that Twitter thread

Thanks for the reminder. Got distracted by work. Need to read second chapter. 

*Chapter 2: Conversation and Computers* (pages 13-25)
<https://mitpress.mit.edu/9780262140539/a-small-matter-of-programming/|A Small Matter of Programming by Bonnie A. Nardi>

<https://futureofcoding.slack.com/archives/C037X8XMFB3/p1708096398023089|Chapter 1 discussion>

It's pretty neat how current this book reads being published in 1993. I like Nardi's counter examples of driving cars and playing music as alternatives to natural language ("mundane conversation") as the default medium of human machine communication.

Reminds me of something I read recently in <https://www.goodreads.com/book/show/18770267-make-it-stick|Make It Stick>—that there is no empirical support for the claim that instruction in one’s preferred learning style (e.g. "I'm a visual learner") improves learning outcomes. It's the subject matter that dictates the best medium, e.g. diagrams for geometry, words for poetry

Definitely an interesting chapter, though I struggled a bit with some of the linguistics analysis. We know now that computers are capable of mundane conversation, so I feel like there are some follow up questions worth asking

Nardi seems to suggest that programs require too much precision to be described without formal semantics. But we often talk to each other about how code works (e.g. specifications aren’t written in code, but are an informal means of meta-programming).

I there agree that code is a good direct interface with the computer, but for many of the computer users who want to program but don’t know how to code, I feel that conversational model in the AI era has a lot more promise than this chapter foresaw.

Yeah, the chapter felt like the AI chapter with Nardi as the AI skeptic. I am craving a blog post or something with her thoughts 30 years later on how the chapter aged (looks like she hasn't blogged in over a decade though, so I'm not getting my hopes up haha).

Make it stick was pretty focused on learning/retention rather than communicating/understanding.
In teaching/communicating, understanding the shared context is needed to maximize efficiency (which is why tutoring/sales generally has better outcomes than class/marketing)

Related, I think we can talk about how code works with lower precision because we have a lot of shared context, which she stressed in other parts of that chapter. We'd have very different conversations with someone non technical (different shared context and probably a different model).

I believe the lack of blog posts can be explained by her retirement in 2018

If anyone else wants to keep going, I’ll mention that I’m still reading and enjoying Small Matter of Programming

^I finished the book a while back and just got around to jotting down <https://www.petemillspaugh.com/a-small-matter-of-programming|some wandering notes>.

Would anyone be interested in doing a zoom book club discussion? Slack threads per chapter are nice for participation across time zones, but I prefer the format of reading then chatting about the whole book in one sitting

Having a deadline is also good motivation (for me at least) to read the book. We could do a book+meeting every 2 months maybe

I’m sorry I fell off track, I’d love to finish it though and join this. Are there any chapters in particular that you think are a must read or could be skipped?

I am out of town without my marked up book, so I'll get back to you on this^ <@U05TJD2V4P2>!

My biased answer to your question re must-read/skip (tldr - I enjoyed the first half more than the second half):

*Chapter 1* :+1: 
• Must-read because it sets the stage for the whole book
*Chapter 2* :+1: :thinking_face:
• Interesting chapter — reads very current (LLMs)
*Chapter 3* :+1: :slightly_smiling_face:
• I thought the beginning of chapter 3 was fascinating as a casual baseball fan
• I also appreciated the spreadsheet analysis as someone who used to spend most of my workday in Excel
*Chapter 4* :+1:
• Feels a bit outdated, but I liked thinking about modern examples of the different end-user programming approaches as I read it
*Chapter 5* :man-shrugging: 
• I'm not super into visual programming (scared to admit that here lol), but worth reading if you are
*Chapter 6* :man-shrugging: 
• Similar take as chapter 5. If you're particularly interested in collaborative multi-player software it'd be more worthwhile
*Chapter 7* :man-shrugging: 
• Examples felt outdated, but it's short and wraps up the book
All that said, the book isn't long, so you could just skim through the parts that don't grab you. Sorry for taking so long to respond here!

I just finished ch4 but meanwhile wanted to bring up a conundrum from ch3.

> It seems that the only way to know how specific a set of program constructs should be is to study the domain very carefully to ascertain how tasks are broken down and performed. A guiding principle is that users will want to be able to create their applications with only a few basic operations, as the experience of UNIX users (Greenberg and Witten, 1988), spreadsheet users (Nardi and Miller, 1990) and CAD users (Tee, 1992) shows.

1. You have to provide primitives that are high-level enough to correspond to concepts & tasks users have.
2. Users want to learn & use _few_ primitives.  Sometimes they are happier with lower level yet more composable primitives.
3. Striking a good balance requires interviewing users a lot - which requires not just programmer skills but sociology skills (how to interview, "activity theory", etc.)
 :worried: 

• The book hopes for advances on the last point (3). So, has there been?  Are there simple & proven interview techniques? "ask these questions and you'll design a good EUP system" :ballot_box_with_check: ?
• Frame challenge: are there ways for users themselves to design for their domain :thinking_face:?
• Challenge on _few_ requirement (2): were there advances on giving users both composite & lower-level primitives so they can inspect the relation ("A flange, for example, can be created out of a cut and a protrusion") and pick for themselves - something users do anyway - without overwhelming them :face_with_head_bandage: ?

Has anyone worked through “Software Foundations”, and did you find it valuable?

Is it <https://softwarefoundations.cis.upenn.edu/|this one>? I read it years ago when it was still one single book and only contained the first two volumes. While I don't think it has much relevance to the main topic of FoC I'd say it's a really good one for what it aims to do and I would definitely recommend it to undergraduate or even high school students (kids could get seriously advanced these days...) who are ambitious enough.

Beautiful study on a visual representation of abstract types (Haskell in this case but generalizable). Conclusion: intuitive and helpful for beginners, but distracting <https://arxiv.org/pdf/2405.12699|https://arxiv.org/pdf/2405.12699>

I've just learned about Alternate Reality Kit. I've searched through the archive and it was mentioned in passing a couple of times but I don't think this article was ever posted: <https://worrydream.com/refs/Smith_R_1987_-_Experiences_With_The_Alternate_Reality_Kit,_An_Example_of_the_Tension_Between_Literalism_and_Magic.pdf> . There is also a relatively recent video upload (video comes from 87 but it was uploaded only three years ago) which shows a more mature version in action: <https://www.youtube.com/watch?v=w1HhPE0zV6g> .

Its similarity to the system that I'm developing is just uncanny! I'm very interested in learning more about it. I tried to follow its history to figure out why it was abandoned but I've only been able to track that its development eventually led to the Self language (<https://www.youtube.com/watch?v=3ka4KY7TMTU>) which honestly seems like a step back from the original. I have my theories about why it might have been abandoned (which is that educational software is hard to sell) but would love to learn more about it from the people who might know more. Or maybe there are other systems that might have been derived from it?

The Alternate Reality Kit video - just wow! ...also loving the ending :sweat_smile:

I don't know, but I have my hypothesis as well as for why this and other user-empowering approaches were abandoned: the rise of PCs. In the late 80s and early 90s, the first PCs appeared and were seen as the obvious road to computing for everyone. But they were not powerful enough to run environments like Smalltalk. It's Basic we got instead. In parallel, professional high-end computing grew as well and that's where the money was. Academia followed the money.

I've been kinda obsessed with this paper, "Weird Machines, Exploitability, and Provable Unexploitability" since October last year.
<https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&amp;arnumber=8226852>
<https://www.youtube.com/watch?v=1ynkWcfiwOk>
(I think starting with the talk is a good idea)

After hearing about robust first computing I've been pondering the connection for a bit. I'm not really sure what to make of it, but there has to be some connection. In <https://www.youtube.com/watch?v=Dmlm6mtnSZs|this talk> by Dave Ackley he specifically mentions that "flipping one bit" (paraphrasing) can be enough to destroy a lot of software, which is the exact attack model that Dullien uses. It would be nice if software could maintain security invariants despite memory corruption (which Dullien proves for a small piece of software that he writes) so in that sense the two concepts allign. But I find that "continuing despite an error" or "return a best-effort answer" is the source of many security vulnerabilities, (mid example: database lookup fails, code is written in a way that forgot to handle that case, code continues anyway and returns admin data that shouldn't be shown). I wonder if any of y'all have read this or have thoughts about it. :))

I'm still thinking about this one, but want to share something I wrote a few years that starts out from a similar framing: <https://akkartik.name/post/modularity>

OP is much cleaner. What I refer to fuzzily as "territories of programs", OP makes precise as the distinction between the intended finite state machine and its _emulation_ on a (fixed-memory, so you end up padding a bunch of don't-care bits in the address space) real computer.

Ah, I see the connection! And I see how tests are a good aid for this. My take on tests is that everyone who cares about their software being correct should do them, because I don't believe anyone can make and maintain correct software, so tests will be useful to show how and where you fail. But also they don't give correctness under typical use and definitely not security (read: correctness) under adversarial conditions. And and they don't give robustness, but also i'm not quite sure what robustness is really but i think my software should have it

>  OP is much cleaner
More formal at least, your writing is very clear.

I feel like there's a tension between formal correctness and robustness. The whole "correctness and efficiency only" goal of current software methods means we don't think about what happens after faults or memory vulnerabilities. I think I'd like to have correctness despite faults, which is different from what Robust-first computing seems to do? I'm not sure

All I know about robust computing comes from the Future of Coding episode on it, so this response is probably steeped in ignorance. One thing not mentioned in the episode is probabilistic algorithms. The usual setup is to assume a deterministic computer, and then introduce imperfect information (often via a hash function) giving a small probability of error but achieving a large reduction in time or space requirements. Perhaps the most used algorithm is [HyperLogLog](<https://en.wikipedia.org/wiki/HyperLogLog>), but I think [MinHash](<https://en.wikipedia.org/wiki/MinHash>) is particularly easy to understand. This isn't the same as assuming any part of the algorithm can fail, but it might provide a pathway to that model.

screenshot_2024-07-31_12-07-34.png

The future of programming is data-parallel?

<https://www.youtube.com/watch?v=vU3ryvZYlkk>

LLMs are forcing me to think about non-deterministic yet rational "computation".

Agents are beyond what traditionally computation has been. When an agent starts performing a task, and the environment changes, they need to find the balance between too much rethinking (classical decision theory) and not enough rethinking (computation).

<https://web.archive.org/web/20110604050051/https://www.aaai.org/Papers/ICMAS/1995/ICMAS95-042.pdf>

Yes! Thank you for the link - bookmarking to read later

through the visualization literacy working group, an extensive discussion of end-user development models &amp; overlap with computational thinking. the two design axes alone are worth the price of admission::
• component-based / rule-based / programming-by-demonstration
• direct manipulation / conversational interface
<https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4129683>

suggested pairing: from the world of knowledge management, a reading of paper tools in the workplace
*Making sense of visual management through affordance theory*
<https://www.tandfonline.com/doi/full/10.1080/09537287.2016.1243267>

experiment: I uploaded the EUDability paper to google's notebookLM and generated an audio (sounds like a podcast to me). I'm going to listen to it on my morning walk tomorrow morning. <https://notebooklm.google.com/notebook/c8ef3a30-2dc6-4224-a623-9f0c32c70010/audio>

Image from iOS.jpg

Learnable and Expressive Visualization Authoring Through Blended Interfaces
L'Yi et al. 2024
<https://osf.io/preprints/osf/pjcn4>
&gt; we explore the design space of blending multiple visualization authoring interfaces for supporting authoring tasks in a complementary and flexible manner. To evaluate the effectiveness of blending interfaces, we implemented a proof-of-concept system, Blace, that combines four common visualization authoring interfaces—template-based, shelf configuration, natural language, and code editor—that are tightly linked to one another to help users easily relate unfamiliar interfaces to more familiar ones. Using the system, we conducted a user study with 12 domain experts who regularly visualize genomics data as part of their analysis workflow.

cool study on multimodal authoring in a plotting grammar DSL. no direct manipulation unfortunately!

Screenshare - 2024-10-13 6:05:59 AM.webm

Is there any research about 3d user interface? Right now we use the windows from Xerox popularized by Macbooks. But I am considering to make it as a game scene, where everything is represented as a 3d objects. I couldn't find anything related to this, or attempts before. The only close thing for this is the holograms from the sci-fi.
As a reference, I am making a social network, but I want it to be a 3d. As a reference here is the prototype:

<https://www.youtube.com/watch?v=suOaUQmMSGo&amp;t=144s>

I also recorded the new form of interface for the crypto wallets. How the transferring tokens from your address to another is done. If there are any systematic explanation of 3d objects, I would appreciate it. :)

There have been a bunch of 3d computing UI experiments. <https://en.wikipedia.org/wiki/Croquet_Project|Croquet> is one of the most famous, but I’m sure others here can point to more.

<https://en.wikipedia.org/wiki/BumpTop|BumpTop> was another fun one. There were a handful back in the Flash era, but their names escape me.

Pinging <@UE6EFEPTQ> who has been writing about similar ideas.

Ah thanks, <@UJBAJNFLK>, much appreciated :hugging_face: ! <https://duncancragg.substack.com/p/smashing-the-boundaries-of-spatial|Here's my most recent article> on the topic, but my whole Substack site is about this, <@U06FCGNJL4A>

Also there's <https://www.anarchyarcade.com/|Anarchy Arcade> to look at, plus <https://stardustxr.org/|StardustXR> for a Linux 3D Display Server. And <https://en.wikipedia.org/wiki/Magic_Cap|General Magic> and <https://en.wikipedia.org/wiki/Project_Looking_Glass|Looking Glass> for history!

<@UE6EFEPTQ> I checked your reality computer. Do you work on the prototype yourself. Is that a startup with the closed source, or you plan to make it open source?

I was thinking how about potential team forming to work together. Maybe I can schedule a call with you if you don't mint?

Hi <@U06FCGNJL4A> I just finished watching your videos - they're very well produced and the ideas are very interesting of course. My "Reality Computer" is fully open, yes, in every way! I don't have the mental wiring to do commercial stuff or marketing and so-on! So it's just me on my own writing C code! :smile: Now, I don't see any strong overlap between my stuff and your ideas of AI- and "<https://www.mturk.com/|Mechanical Turk>"-assisted End-User customisation or programming! The 3D stuff is very nice, but it's obviously not really your core offering: you could do the whole thing in 2D I should imagine. There are many folk on FoC here that will be interested in talking to you about your project for sure.

<@UE6EFEPTQ> You are right. Can you also look at the most recent update?

<https://youtu.be/RrE_NkExyiw?si=1RSmSpjh4NWCHRhW>

As for the 3d, I decided to add it slowly. for now prioritizing the core. The thing that overlaps is the augmentation of data. That messages from messaging apps can be moved, linked to let's say to the tasks on project management software.

For the upcoming month I will push the new update. Where instead reinventing all the apps, I decided to make it as the interface for the services. For messaging I will use Telegram. For project management I will use the Trello. Both have the API. And we can build the custom interface for them. As the Ara as the interface, it will allow messages, tasks to be shared across different services. The AI is the cherry on the cake that can automate the stuff. It's in the long run. I want this web operating system to be as <https://rem.ing/> and AI learns from the all user's behaviour to find common patterns and help automate the stuff so user will interact with the computer less. Interested now? :slightly_smiling_face:

Ha ! :smile: I was researching "intelligent user interfaces" in 1989 in my first job, so I've got some form, and the idea was that the UI would learn from you and become part of you in some way, thinking ahead to what you may want next. Didn't get very far due to lack of money and time! (We also tried applying neural networks to predicting the stock market, but again didn't get too far due to lack of resources.)

But ... I don't do AI any more and blockchain tech isn't part of my vision in any way, so I don't think there's a match between our work, but I'm sure there are many FoCcers (:upside_down_face:!) who will be more synergistic with all this!

getting some lovely blue-sky Realtalk energy from this piece on 'infrastructuring'
*Design Things and Design Thinking: Contemporary Participatory Design Challenges*
Erling Bjögvinsson, Pelle Ehn, Per-Anders Hillgren 2012
<http://www.gobigcreativelab.com/wp-content/uploads/2019/01/Contemporary-Design-Thinking-Challenges.pdf>
&gt; An infrastructure (e.g., railroad tracks, cables, or the Internet) reaches beyond the single event (temporal) and the site event (spatial); it does not need to be reinvented every time; and it is embedded into other socio-material structures. However, the infrastructure also is accessible only by participation in specific practices. [...] it is relational and becomes infrastructure in the relationships between design Things at project time and (multiple, potentially controversial) design Things in use.

Maybe I should have posted this here at the beginning. But I did an advent of papers. All of them are papers we haven't done on Future of Coding. And most of them will probably never be papers we do

<https://jimmyhmiller.github.io/advent-of-papers>

Thanks <@UK3LH8CF5>, I enjoyed your posts in this series!

My first time reading a classic: [Naur on programming as theory building](<https://pages.cs.wisc.edu/~remzi/Naur.pdf>).

Loved the article and disagreed with almost everything. Sharing my private thoughts without polish or much justification, in case someone's interested in a dissenting opinion :sweat_smile:
- I think Naur is not quite right. It's not theory building. It's the building of a representation of reality, that in itself can be a part of reality.
- My take: if programs are much more readable, and we have a set of universal constructs for thinking programs, then reading and modifying a program doesn't require an external entity. There needn't be a private theory of the program except for the program itself (and any documentation in natural language). The theory should be readable from the constraints and the words/calls used in the system.
- Simplicity can be evaluated as relative length of two solutions that do the same thing.
- "Theory" can be rediscovered by studying both the problem domain and the solution.
- Naur's concept of the theory of a program is downright <https://en.wikipedia.org/wiki/Animism|animist>. The theory is an entity living in the programmers that created the program, and can only be communicated by them while they are working in the program. When the program stops being worked up, the theory quickly fades and dies. No amount of program or documentation reading is going to revive it.
- I think a more accurate and constructive view of programming considers it akin to an intellectual or scientific discipline, where a thread can be maintained over time through language, even if the chain is not transmitted orally.

have you heard this podcast episode? <https://futureofcoding.org/episodes/061>

We had <https://akkartik.name/archives/foc/linking-together/1661296709.406409.html|this discussion> about it in Aug '22, which perhaps led to this paper being chosen for the podcast episode above in Jan '23. Or perhaps it was recorded earlier and the thread was coincidental.

I still tend to be closer to <@U0887QU9G2V> than <@UK3LH8CF5> here: I don't think there's any essential reason it's impossible to communicate a theory of a codebase. Yes, it won't be identical to the original author's theory, but it'll be close enough that others can make the same decisions as the original author. Yes, not always the _exact_ same decisions, but close enough that if y'all talked you may not care too much about the differences.

There's a lot here, so let me just tackle the communication bit. You can't communicate a theory because it isn't linguistic at all. A theory is knowing-how, not knowing-that. Imagine I can juggle. I might be able to juggle without explaining how. Just like I know how to identify people by their faces, but if you asked me how I do it, I have no idea. If I can teach you how to juggle, what I gave you was not my know-how of juggling. I gave you facts about how to juggle and you built up your know how.

So it isn't that theories can't taught. It's that theories can't be written down because they aren't the kinds of things to be written down (or talked about or drawn etc). In order to write things down about a codebase one has to have a theory. Writing is just one way of presenting ones theory.

Yeah, I agree with that narrow definition of communication. You can't describe it directly in prose and recreate what about knowing it makes you effective at using it.

I also want to add that I disagree with the point above about Naur being animist, to the extent the term seems to have a negative connotation for you, <@U0887QU9G2V>. Programs are complex, and they require special tacit knowledge to navigate, that is impossible to write down directly and a lot of work to write down indirectly (using exercises and so on to help build "muscle memory" in others). While you can view this phenomenon as a spirit animating the body, there are equivalent ways to view it that carry a more positive connotation for us moderns.

Yeah the whole motivation for the theory is actually to be a thorough going materialist. Ryle didn’t think we had anything in our head. We just had dispositions and behavior. So he reduced theory to dispositions. 

>  - "Theory" can be rediscovered by studying both the problem domain and the solution.
I would also add the history of each. As an extremely simple example, I just had a discussion this morning about why do we (at my work) use `<input type="button">` instead of `<button>`. I actually don't know — and it doesn't matter at all in this instance — but I suspect it has to do when the `<button>` HTML tag was added. (Our code base started _early_ in the life cycle of the web.) It's a technical decision that might not have any rationale now, but once did. Without knowing the history, that couldn't be rediscovered.

First of all, I'm really happy to be having this discussion with you all! Normally, I'd keep these thoughts to myself and move on. But now you're making me consider your viewpoints!

<@UK3LH8CF5>, if I may quote what to me is your main point:

>  You can't communicate a theory because it isn't linguistic at all.
I strongly feel it does, because even if the theory itself is not language, it can be represented/conveyed by language. Moreover, by *written language*. Rather than try to convince you of this point (and honestly I don't think I have enough data for even trying), I'm going to keep this hypothesis in mind as an open question.

The other idea I posted above that I still consider interesting is that programming can be seen as an exercise in representing reality. Our program, rather than the theory itself, can be the representation of reality.

As for animism, I think I went too far :joy: I'd actually even side with an animist theory of programming that allows for its conveyance through the written word, separated by space and time. I chose that adjective as a way to highlight the lack of preservability of the theory in Naur's view, like meat that won't last long in time or space, not even if you have a freezer handy.

To me, the most beautiful example of resurrecting the theory behind a program is Petzold's Annotated Turing, where he revives the code of Turing's 1936 paper, including a full reconstruction of the Turing Machine. I always assumed that he did this through texts (directly from Turing's paper and from other papers written about it), rather than by an unbroken chain of human-to-human communication.

Hopefully I didn't go to hard on the idea, apologies if I raised any hackles!

PS: I didn't know about the podcast episode, I just had found the link earlier today while reviewing <@UCUSW7WVD>’s Mu :D

&gt; I strongly feel it does, because even if the theory itself is not language, it can be represented/conveyed by language. Moreover, by written language. Rather than try to convince you of this point (and honestly I don't think I have enough data for even trying), I'm going to keep this hypothesis in mind as an open question.
Ryle (and I assume Naur along with him) would say this is a category error.

&gt; Ryle: To have a theory or a plan is not itself to be doing or saying anything, any more than to have a pen is to be writing with it. To have a pen is to be in a position to write with it, if occasion arises to do so; and to have a theory or plan is to be prepared either to tell it or to apply it, if occasion arises to do so. The work of building a theory or plan is the work of getting oneself so prepared.
&gt; Also Ryle: Having a theory or plan is not merely being able to tell what one’s theory or plan is. Being able to tell a theory is, in fact, being able to make just one, namely the didactic exploitation of it. Mastery of Euclid’s theorems is not merely ability to cite them; it is also ability to solve riders to them, meet objections to them and find out the dimensions of fields with their aid.
The theory is our ability. We can use our abilities to write things down. But that isn't a theory. So yes, we can explain our theory. We can help others build a theory. But they don't thereby get our abilities. They learn their own abilities.

Thanks for the counterpoint!  It's indeed likely I'm confusing the categories.

Maybe then, my objection to Naur is that, while recognizing that theory of a program/system is something that one must build for oneself, certain textual representations of the program (both code &amp; natural language) can effectively let someone construct a theory of the program/system with relative ease, and that that theory converges (even if it's never equal to) the original theory of the program. The entire power of the objection lies in the possibility of doing this 1) in writing separated by time/space; 2) effectively in terms of time spent by the "resurrecting agent"; 3) in a way that can be considered (by whom? Perhaps by the original holders of the theory?) that the reconstructed theory has a level of convergence to the original similar to that that would have been experienced by the shared theory of a team building a system in a single point in time/space.

I just re-read that paragraph and I feel that my positivism might have gone a bit too far.

Awesome! Now we have the real disagreement. And you are in good company with that one. Knuth thought that using literate programming you could write a program in such a way that others gain the theory. 

I think along the lines of what <@U04E5QAD6DD>   If you want the theory you need to also know the history. But not just the actual history. You need to know the counter-factual history. Why X and not Y? If I wanted to make this program do Z from the beginning, how would I have written it differently? 

I personally buy the claim that you can’t resurrect. But I definitely think that is more debatable for sure. 

Ah, beautiful! Now we have it, indeed. Whether resurrection of the theory of the program is possible or not. I'm not that sure either!

My first "serious" hobby programming project was to build a literate programming tool. I didn't know about parsers so I figured I could just do it with regexes. Incredibly, it kinda worked, but because I used triple angle brackets to delimit parts of the code.

I wonder if programmers should have a right to put a Do Not Resuscitate command in their own software :sweat_smile:

If theory is the disposition to behave and program is a description that produces behavior...

Yeah I think Ryle was very wrong that theory is just a disposition. He wanted to reduce all of thought feelings beliefs and desires to dispositions. But in my opinion that is a failed research project. 

But even if it weren’t, the programs dispositions and our dispositions are two different things. So the program wouldn’t be its own theory. And since <https://jimmyhmiller.github.io/advent-of-papers/2024/dec-4-brain-computer|the brain ><https://jimmyhmiller.github.io/advent-of-papers/2024/dec-4-brain-computer|isn’t><https://jimmyhmiller.github.io/advent-of-papers/2024/dec-4-brain-computer| a computer>, our mind isn’t a program 

Anyone wanna work through SICP with me? I tried a few years ago when I was picking up programming, but I was in over my head.

I think I could swing it now. It'd be cool to learn Clojure after as well.

I'd be more than happy to do that :slightly_smiling_face: (Disclaimer, I've definitely already read it, but happy to revisit)

If you find Scheme a barrier, and/or want to use your web background, there is also a JS edition nowdays: <https://github.com/source-academy/sicp>.
It uses small subsets of JS, and ends up implementing them, in same JS subset.  And it lets you run code fragments interactively right inside the online book.
They also have a "comparison" edition where you'll see both original Scheme and new JS, and any diffs in explanations + some commentary on the conversion.  That might be overwhelming, or insightful, or both :wink:

<https://akovantsev.github.io/corpus/sicp>