Stephen Kell during Convivial Computing Salon Q&am...
# thinking-togethera
alltom
05/07/2020, 5:44 PMStephen Kell during Convivial Computing Salon Q&A: "[C's] concept of memory is bigger than the process… avoiding the denigration of the outside."
👌 3
c
Chris Knott
05/07/2020, 5:46 PMIs it on Youtube? Annoyed I missed it
a
alltom
05/07/2020, 5:48 PMI heard Jonathan Edwards saying that he was updating the agenda spreadsheet to replace the Zoom links with recording links as they go along.
s
S.M Mukarram Nainar
05/07/2020, 5:56 PMAny chance we could get them uploaded to youtube or some other video site?
k
Kartik Agaram
05/07/2020, 5:56 PM
@Chris Knott I missed the first talk today because I transferred the time wrong to my calendar 😭 Extremely disheartening after spending much of my week thinking about this schedule.
😔 2
s
shalabh
05/07/2020, 6:06 PMI have a counterpoint to Stephen's. Is the C memory model not an imposition of the C paradigm to anyone who wishes to interoperate?
shalabh
05/07/2020, 6:08 PMBTW, Kartik's talk coming up soon, right? I have 12pm Pacific.
👍 2
a
alltom
05/07/2020, 6:14 PMI think it's the other way around. Memory exists, so we have "systems" programming languages that use it directly. But your point feeds into a thought I was composing…
Memory extending beyond a single process enables mostly just low-level bit munging. It seems to me that one mechanism for "connection over containment" (also from Stephen Kell's talk) would be rethinking what's "outside."
Standard "outside" today has std streams, the filesystem, the clock. But your language's objects probably don't extend beyond a single process. Your types probably don't (unless you're targeting a Lisp machine). BeOS's rich file attributes encourage you to put most of your program on the "outside."
💯 3
❤️ 1
alltom
05/07/2020, 6:17 PMMaybe everyone already knows this, and it's just that nobody wants to make an OS. 🙂
s
shalabh
05/07/2020, 6:36 PMDifferent. Here's the abstract. I think the slides and recording will be posted at some point: https://2020.programming-conference.org/details/salon-2020-papers/9/Convivial-design-heuristics-for-software-systems
shalabh
05/07/2020, 6:37 PMThe C comment was in the discussion, afair.
➕ 1
shalabh
05/07/2020, 6:38 PMTo follow @alltom's thread - yes inside vs outside is very important. All interplay is within some homogenous and agreed upon model. You can say this is 'bytes' but really that's also an imposition.
c
Chris G
05/07/2020, 6:50 PMLove this conversation - keep adding relevant materials on inside/outside as you can think of them
a
alltom
05/07/2020, 7:13 PMI agree, but I feel like being agreed-upon is still just part of the picture. C denigrates memory less than, say, filesystems, because everything's in memory: every variable is in memory, and even the code itself is in memory, so nearly the whole program is on the "outside," and it just happens to be an annoying outside for interplay. Filesystems extend beyond a single process, but the boundary between one process and another, by way of the filesystem, is nearly absolute.
alltom
05/07/2020, 7:18 PMI keep coming back to "connection over containment" too. Via memory, you can connect to any process, whereas a filesystem interface or network protocol or whatever is clearly containment.
s
shalabh
05/07/2020, 7:37 PMCould you elaborate connection over containment? Is about emphasizing composition?
a
alltom
05/07/2020, 7:42 PMIIRC, yes, as a design heuristic for convivial computing.
s
shalabh
05/07/2020, 8:02 PMYeah I agree with that idea in general. I didn't see the whole talk, but did follow the questions so I missed some of the context.
shalabh
05/07/2020, 8:03 PMI think composition one of the main issues and very poorly solved. We have composition via byte formats, APIs and other higher level models. But it all seems too brittle.
🤔 1
shalabh
05/07/2020, 8:33 PMI would like to make a disctintion between 'can connect' and the 'domain of connection'. At the lowest level we have electricity flying over connected wires and various interconnected micro devices which are compatible because they use the same voltage, etc. Just because we can connect two micro devices doesn't mean it will do any useful. Once we implement 'bytes' it becomes totally irrelevant what voltage and shape of wires is used to represent 'bytes as ram'. So you can switch out the voltage and entire circuitry with something very different and as long as you can simulate 'bytes', its still all good - because your program is dealing with 'bytes' and not 'voltage'. (In fact we have gone through many iterations in hardware from vacuum tubes). But what about bytes and byte formats? To me they are just like voltage - not very important to the real goal. Just because one program can 'see the bytes' of another program (analogous to just wiring up random micro devices) doesn't mean its useful. They have to agree on the byte formats. What do bytes transmit? data structures which represent information. So for composition between two entities, they must agree, at least partly, on the shape of the information. If this is possible, they could negotiate and converge on one of many possible byte representations (or perhaps forgo bytes altogether in some other future computer). Basically I'm arguing that byte formats are irrelevant and information models are where it's at, however most of our composition models are deeply coupled with irrelevant details. The entrenched bytearray orientation via Unix/C is one culprit here.
💯 3
a
alltom
05/07/2020, 11:53 PMI think it's important for conviviality, though, that if I want to make a debugger for your program (one of Stephen's examples), that it not be required for your program to implement a Debugging Communications Protocol. The convenient thing about the "memory" concept is that your program and all its state is in memory no matter how you write it. I don't mean to minimize the importance of information design; I'm just ruminating on how it's irrelevant without access.
Anyway, I guess this is why people like Smalltalk images so much. 😆 It's been dawning on me today that, while my usual gripe is how awful most desktop software APIs are relative to Acme's 9P interface, uniform access to all internal state by putting all internal state "outside" may be more important in the long run—with or without (ideally with!) your representation negotiation tech. Barely any web sites are extension-friendly, but they gotta use the DOM and that's where we get 'em!
💯 1
s
shalabh
05/08/2020, 12:35 AMI think Basman asked about how it is possible to have a universal debugger and the answer points to having pre-shared the concepts and formats (e.g. what a call stack is and how debugging symbols are encoded). I would go further and ask what does debugging even look like if you don't use call/return functions, but use constraint connectors (like Marcel's talk, not sure if you watched it)? Could GDB or a universal debugger even hope to make sense of bits arranged according to completely different paradigm?
shalabh
05/08/2020, 12:39 AMThat said, I strongly agree that if something maps to bits, those must be visible for convivality and transparency. Further, even appropriate lenses to view those bits more meaningfully must be readily available.
👍🏼 1
a
alltom
05/08/2020, 3:32 PMNo, I'm so bummed I missed it and that the recording's not up yet.