you can't see the code above or below the cutoffs of the window

I'm confused — don't most node-wire tools also do this?

Can you give an example of what you mean by "auto-hide systems"?

Hamish Todd I've never found a node-based programming environment that I like. Ivan Reese is a much better person to ask about this, as he is very focused on that area. 🙂

One approach (perhaps equivalent to subroutines in textual code) is to be able to manually nest sub-graphs within a node. Useful when there are different levels of abstraction perhaps. I have seen this work quite effectively.

It may be interesting to try to partition the graph in this way automatically (using graph theory) to place highly connected components into sub-graphs.

Ivan Reese a simple example of what I mean by auto-hide: you have nodes A,B,C,D. The connections are A->B, B->C, C->D, A->D (last one is not a typo)

You are zoomed in on B and C and cannot see their other connections. But the wire from A->D could be going over that, creating visual clutter. Auto hide might involve hiding that connection while you are zoomed in, only showing when you zoom out or pan over to D

Ah, okay!

I haven't seen anything that does this exactly. I have seen some VPLs play with hiding wires in other ways:

• fading out the middle parts of wires when they aren't selected, so you just see the beginning & end
• making wires sort to the back, so at the very least they won't be covering other nodes
• forcing nodes to be on a grid, forcing connected nodes to have some degree of adjacency, so that wires can't cross other unrelated nodes and tend to be short stubby things that might not even need to be rendered in the first place

I don't really like any of these sorts of approaches, personally.

My pet "solution" to the issue of the wiry mess in visual programming is that graph layout should be conceived as a first-class concern of the programmer, and the tools for working with wires should be fantastic , such that it's actually pleasing to have wires. The whole point of a visual programming system is to have wires (IMO), and the point of the wires is to convey uniquely valuable information to the programmer. So rather than hiding the wires, I'd like to see VP systems that let you wield the wires to great effect (which may, in fact, include hiding them sometimes — but that should be a thing you're fully in control of, akin to—say—code folding)

Graph homeomorphisms for the win! I'll second Ivan Reese that serious layout support should be a focus. Is one factor simply that wire programs are more hacked together than carefully factored. I mean hacked together text code is a horror, and often can be perfectly cleanly formatted yet semantically tangled. One quality (a feature perhaps?) of functional programming is that a big ball of mud tends to look like one.

Does Scratch feel like a structural repl? If so, there's also this unreleased project for Python:

💬 #linking-together@2022-04-21T22:34:56.430Z

I don't follow your last sentence, though.

Paredit is a structural editor for lisp-like languages in Emacs, which combines well with support for scheme, clojure, &c, to give you this experience. There are a couple of in-progress projects using treesitter to give similar superpowers for infix languages...

Oh hey, I came here to mention what we’re doing with splootcode but it’s already mentioned! The goal is to get all the benefit of a REPL without the downsides.

I'd say Scratch feels REPLy since you can click on a stack of blocks to execute them.

Including unused ones in the tray.

@Katie Bell what are the downsides of a REPL you are trying to avoid with your approach

Where did the name splootcode come from

@Katie Bell have joined the waitlist, are there any video etc in the meantime

The downside of a repl is mostly that you need to type whole statements every time - a typo is mildly irritating to fix in one line of code but if you write a loop or a function, then re-building it is annoying. You can't just go back and edit the code, you might have to hit the up arrow keys many times to find it.

Then once you've iterated on the code you want to write, you need to copy paste it back into your code.

I'm not saying repls are bad - I just want the code editor to have that level of insight into the code all the time without having to switch into a repl at all. :)

And as a not-so-proud user of a readline implemented REPL, each line is separately remembered. So if I make the mistake of trying to enter four lines and line three is incorrect, then the fix is: up arrow, up arrow, up arrow, up arrow, return, up arrow, up arrow, up arrow, up arrow, return, up arrow, up arrow, up arrow, up arrow, fix the mispelling, return, up arrow, up arrow, up arrow, up arrow, return. Of course this always happens when I'm in the thick of something and not at all interested in improving my tools.

Teletype REPLs were fine back when we had teletype hardware. Using one today — when we can have in-place evaluation in our editors — is, IMO, completely mad.

Quicker, easier, more seductive.

This video has 4 short demos from such projects: youtu.be/Q61dh87WGrE

(Lamdu, Dark, Hazel, Lisperanto)

my project is Lisperanto uprun.github.io/lisperanto , but as soon as you create any structural editor you can keep track of changes in the code and refresh function calls whenever there is a change, propagating it to the root calls for me it is a special Sandbox function

really love the idea of the shape of the blocks preventing errors. Would be super interesting to see if it also encourages exploration / curiosity. Maybe there’s a block you’ve never used before but it shares the shape with a block you’re familiar with, maybe you’d try it!

I haven’t used this myself, but this product appears to use the same shapes as the physical blocks you’ve shared above — thunkable.com/#

blawx.com is doing a domain specific version of it for legal

String diagrams come to mind ncatlab.org/nlab/show/string+diagram.

Sorin Lerner has a blocks-kind-of prototype for proofs in natural deduction. It's called "Polymorphic Blocks". Here is a link to a site where he talks about it: cseweb.ucsd.edu/~lerner/pg.html .

@Robin Allison Polymorphic blocks was a fantastic share. I can't find the actual game but Sorin's talk was super-interesting. Thanks for sharing!

@William Taysom I'll have to find a less technical treatment of string diagrams to understand them. 😁

That is oh so fair! Here's the least technical introduction I know. graphicallinearalgebra.net

"Willing into the world" is a rich vein

As a writer (er, writing type, as I am not a productive writer), words come immediately to mind – I know many of us take private notes, and feel in those a power that coalesces energies – words themselves have a summoning power – they build a trail, sometimes in front of us, sometimes breadcrumbs, of what we intended and might actually still do

Related tangent – I've wondered if there should be a much wider notion of "two-minute-week" – for instance, I'm not ready to post videos and show+tell – but would I post a little microblog update? No, because I'll just end up talking in a private sort of language that no one understands. But should I do that anyway?

Think about the original twitter status update, how it was a still-undefined format. Lunch and what's on tv and headed out and reading X, all became the first announcements. There weren't pictures of peoples' lunches back then!

Would it be bad to post something here in one's own private sort of language? Could it still bear fruit? "I'm adding [complex whatsit] to the [no idea] area of [unannounced project]. Feeling stuck with [phrase you might actually be able to parse and mention something for]."

For me, personally, one of my biggest obstacles is the general lack of guaranteed proper tail calls in most programming language implementations.

There's work on getting them added to WebAssembly, but I cannot grasp why they weren't there to begin with.

They were added to JavaScript, but they are not widely implemented.

And the languages that otherwise might function as portable assembly, such as C and Rust, have no intention of adding them.

I cannot grasp why anyone would ever want to create a new language without tail calls, and yet following the programming news one constantly sees people announcing new languages that they somehow believe are better than what already exists even though they have the same limitations around flow control as most other languages since Algol 60.

The biggest thing I would ask of the community is to join me in lobbying every single language creator to PUT PROPER TAIL CALLS INTO THEIR LANGUAGES RIGHT FROM THE BEGINNING!

And yes, it needs to be right from the beginning, because if you don't plan for it you will create a design that makes it very difficult to add later.

Jimmy Miller For me, a good first step would be to put together a "design team" that can butt heads and figure out the right design for a future programming system. The team would consist of people who are willing and able to work full-time (or thereabouts) on building the FoC, whilst being self-funded (i.e. unpaid) and perhaps eventually crowdfunded.

This is the only format (apart from a company) in which I can see a collaborative effort succeeding. We need to bring people who have the time to work deeply on the problem into the same room (or at least, the same Zoom).

completely agree re: needing people who are able to work deeply

in a post-capitalist world, this would in theory be pretty straight-forward (depending on where we land post-capitalism). but here in capitalist-land, we do have the crowdfunding route as an option. not a great one, but it has occasionally worked.

I don’t think that not succeeding is bad. It has the potential to start an experimental creative cycle:

• Choose or create a “cybernetic environment” (environment capable of running programs).
• Make some (even small) experiments inside it －first, define their ideal form, then implement them. Involving wider spectrum of people is encouraged.
• Analyze the shortcomings of the implementations w.r.t. the idealized versions. What aspects of the environment were limiting?
• Create a better environment. Repeat.

Smalltalk was meant to be such an environment, but as Alan Kay reported (regretfully): “Smalltalk stopped changing” －meaning that people continued to do “experiments” (in this case, production-level programs), but stopped analyzing them w.r.t. the environment.

A place like Recurse Center with a stipend. 2 - 6 months of solo work would be enough time to prototype virtually anything. I think everyone here just needs more time to work and it's difficult to do that with a day job/family/financial obligations.

2 - 6 months is enough time to develop a prototype if you already know what needs to be built. But that's not the problem I (and many others) have. The problem is figuring out what needs to be built — design work, rather than "coding" work. Finding the right design for a programming environment could take years (evidence: I've already spent several years on this, and Jonathan Edwards has spent several decades). A small fraction of that time would be coding, but most of it would be designing. IMO design work is the main thing our community should aim to support.

Nick Smith I think that it's not necessary to get stuck on environment design right away (perfect is one of the enemies of WIAN). It's better to just get started with a suboptimal environment, then identify it's (concrete) limitations and fix those. After a while, some of the design will fall out for free out of the experience - at which point, one can rethink the environment to increase its cohesion.

something my art/tech friends and I do that helps us move from idea -> prototype -> more has been a pretty banal but powerful ritual we call story club. At the basis, a weekly zoom share out of a story (read: really anything, big or small, that exists in a sharable state) from everyone there that the only requirement for is that it was worked on inside that week. Then everyone goes around and shares an inspiratory item/idea that they found that week, with the goal being to spark discussion and to bring ideas to the front of mind for the following weeks work. Recently we have been making every other weeks meeting a working meeting, gathering in my apartment a few hours before the call for breakfast and to work in tandem.

That’s all to say, I’d love to see something similar in this space, and I understand that FoC projects do require a good bit of thought/execution time, maybe such a club could put people into a place where they could then go to recurse and run up a pretty legit prototype

@yeT which changes would be required to #two-minute-week to be closer to what you describe?

I think an element of synchronicity, maybe a sort of historic sharing log, some sort of template of [shared thing: thing, inspiring object: thing]. Maybe a record of projects shared with their entries, allowing folks to see what other people are working on and the progress made. Maybe an associated gather/zoom setup could be helpful for working days

@Jan Ruzicka FWIW, because I've mostly been designing a language, and not an app, I've not actually needed to build any working prototypes to complete my design iterations. It's always been sufficient for me to simply write down a small program that embodies a design idea, and manually evaluate its syntax and semantics. That saves 100+ hours building a parser, interpreter, and/or IDE.

Once I've settled on a complete set of language constructs (and a syntax) that can be used to build complex programs, I’m sure I will need to build an interpreter. But that would be at a very late stage in the design process. So it's really not coding that has been slowing me down. I've almost never gotten “stuck” during my design work such that I've needed to write an interpreter to proceed.

People who are doing interaction design, e.g. designing structured editors, would obviously need to write code more frequently so that they can test out the interactions they have in mind.

Maybe this essay is loosely related? dzone.com/articles/abstraction-tiers-of-notations

It's difficult to pin down the meaning of 'object' in a digital sense because in many ways it is used as a term of art, and it doesn't seem like the philosophers are in agreement in any case. Objects can be best defined by differentiating them from data, where objects are behavioral while data must be altered by external procedures, as elaborated in On understanding data abstraction, revisited, The power of interoperability: why objects are inevitable, and "Object Thinking" by David West. OOP muddies the waters with notions like inheritance and classes, but is still centered around objects as the fundamental unit of computing. You can have objects like this in a language that isn't OOP (as many do, however clumsily), but the origins of OOP were centered around the philosophical notion of object as Dan Ingalls puts it in Design Principles Behind Smalltalk:

The mind observes a vast universe of experience, both immediate and recorded. One can derive a sense of oneness with the universe simply by letting this experience be, just as it is. However, if one wishes to participate, literally to take a part , in the universe, one must draw distinctions. In so doing one identifies an object in the universe, and simultaneously all the rest becomes not-that-object. Distinction by itself is a start, but the process of distinguishing does not get any easier. Every time you want to talk about "that chair over there", you must repeat the entire processes of distinguishing that chair. This is where the act of reference comes in: we can associate a unique identifier with an object, and, from that time on, only the mention of that identifier is necessary to refer to the original object.

So perhaps the goal of OOP is to facilitate the primordial meaningless goo of bits and bytes into well-behaved and understandable objects. Brad Cox writes in Planning the software industrial revolution:

What does any adjective mean in this murky swamp we call software? No one is confused when adjectives like small' or fast' mean entirely different things in nuclear physics, gardening, and geology. But in this murky domain of intangible abstractions, it is all too easy to lose your bearings, to misunderstand the context, to confuse the very small with the extremely large.[...]

Such confusion is not surprising. The denizens of the software domain, from the tiniest expression to the largest application, are as intangible as any ghost. And because we invent them all from first principles, everything we encounter there is unique and unfamiliar, composed of components that have never been seen before and will never be seen again, and that obey laws that don't generalize to future encounters. Software is a place where dreams are planted and nightmares harvested, an abstract, mystical swamp where terrible demons compete with magical panaceas, a world of werewolves and silver bullets. As long all we can know for certain is the code we ourselves wrote during the last week or so, mystical belief will reign over quantifiable reason. Terms like computer science' and software engineering' will remain oxymorons -- at best, content-free twaddle spawned of wishful thinking and, at worst, a cruel and selfish fraud on the consumers who pay our salaries.

In the broadest sense, object-oriented refers to an objective, not a technology for achieving it. It means wielding all the tools we can muster, from well-proven antiques like Cobol to missing ones like specification languages, to enable our consumers by letting them reason about our products via the common-sense skills we all use to understand tangible objects.

So, what is an object in a computer, a digital thing? It is philosophy come to life in a metaphysical tool, a structure of consciousness reproduced as a model, which can be understood as an object to other object-speaking agents through what it does.

The notion of an “object” has received surprisingly few treatments in the context of computing

IMO the software industry's blindness to what it means to be an "object" (in our everyday lives) is a major contributor to the stagnation in PLs that we are experiencing.

From my perspective, objects are immortal once they appear, i.e. they can never be destroyed. The rationale: we can still talk about Alan Turing, or the 2001 World Trade Center, even though neither of those things have a physical body anymore. Thus, they still exist as objects in our minds. The fact that they continue to have an influence in the world — associations continue to be made between them and other things — means that they are not really "gone".

Whilst such objects can't be destroyed, they can be forgotten . Computers should be able to model this phenomenon. Object-oriented languages kind of do this, in that objects are garbage-collected only when all references to them are released, i.e. you can't destroy an object that somebody else is still "thinking about". But they conflate something important: objects are given "attributes", and those attributes cannot be forgotten (cleared from memory) until the object itself is forgotten. Crucially, attributes are the only thing that actually consumes memory! Thus, what OOP seems to really be garbage-collecting is attributes, not object themselves. But it's really weird to manage the lifetimes of attributes (i.e. the lifetimes of relationships between things) by bundling them into a "group" that we call an object. After all, they make no contribution to the object's identity — in an OO language, the identity of an object is given by its location in memory.

In conclusion: I think "objects" should be considered immortal (once they appear), and not "contain" any relationships. Instead, relationships should be a separate construct, similar to how "relational languages" (SQL, Datalog...) do it. The open question is: what is the right way to model the lifetimes of relationships, such that relationships can become invalid and be "garbage-collected"? Neither SQL nor Datalog offer a compelling model.

The notion of an “object” is one of the most basic and fundamental ideas in philosophy and it has received surprisingly few treatments in the context of computing given its importance.

The philosophical notion of an object as applied to the context of computing casts quite a wide net. The notions of a “digital object” or similar terms as treated in the links you and Riley provided mostly seem considerably narrower. Do you think your tentative theory will start with a narrower category as a premise and then go from there? Or is the goal to apply the philosophical notion to the context of computing in order to discover the category?

(Unfortunately I don’t think I have any more reference points to contribute.)

Gilbert Simondon's " Du mode d'existence des objets techniques" is probably relevant, but I don't know if it has been translated. It's about "technical objects" and their role in modern societies, so it's a bit wider than "digital objects". Your second link mentions Simondon BTW.

Konrad Hinsen Yeah that’s one of the main influences that Yuk Hui pulls from in his book. I found the idea of “technical objects” really useful in clarifying the relationship between digital objects and broader society, but still need to dig into some of Simondons original work. I just haven't found a good english copy of that work yet.

@Luke Persola the goal is to discover the category, though I would say I’m doing something more like synthesis than pure application of philosophy. And yes, it’s a very wide net, and I agree that some of those references are far too constrained (even if they are useful to some).

@Riley Stewart thanks for the links! Some really great thoughts here! Love that Ingalls quote, and it maintains some clarity (which is often lost nowadays) that the object and the ways we refer to that object may be conceptually distinct. You can refer to the same object in a number of ways, and it isn’t guaranteed that you’ll be referring to the same object with the same reference. I’d like to push back on the distinction between objects and data though, as that would mean that things like files are not objects, and the computational distinction can be blurry when the data might be source code or something ‘computational’ in nature.

Nick Smith interesting stuff! You raise a couple of important points:

• A conception of objects as defined by relations, which as you point out can persist beyond the existence of the original object. This also points to the ontological status of digital objects, and wether an object can be ontologically independent (imho they probably can't be). It also raises the question of the kinds of relations relevant to objects, e.g. do objects have a meronomy (part-whole relation) where their attributes or properties are contained “within” the object. In my view, this question doesn't have a single answer and it comes down to context/perspective. A property may be “part of” an object from one view, and an external relation from another view.
• The question of identity ! This is actually what prompted me to write the paper, as I think this is a much harder question, and one that I think naturally follows from a conception of ‘digital object’. Identity is essentially the question of “sameness” over time/place/context/etc. In your OOP language example, I think it’s not exactly the location in memory that gives an object its identity, but is instead the interaction between the addressing system (often a location in memory) and the mutability system (which is conceptually related to identity). This is only true at the language level though, and doesn't entirely track to broader systems.

In the paper I introduce and build on two related notions: “Objects as addressability” and “Identity as governance” which roughly correspond to the points you made (though I take a systems-theoretic view, not a language one). I think its only when viewing these together that we get a more complete picture. I think the mutability-as-default of our systems may have contributed to the conflation between these two notions. I’m also aware that “addresssability” and “governance” are undefined here, but I’ll leave that for the future for now.

Orion Reed There is indeed a translation: gilbert.simondon.fr/content/mode-existence-technical-objects, upress.umn.edu/book-division/books/on-the-mode-of-existence-of-technical-objects

My first thought when reading "digital objects" was, how might NFTs, Metaverse, AR/VR fit into this conversation... I'm a big proponent of "merge reality" or the idea that smart glasses will merge our physical and digital worlds. All of those "digital objects" are going to come out of the proverbial pandoras' box and live next to our physical objects. How is an object classified once, in example, our toaster has an AR based menu?

Orion Reed Another maybe interesting site is fairdo.org, if only for the fact that it tries very hard to talk about digital objects without ever providing a definition. Put differently: the people behind that site need to read your paper 😉