Is there a "Grammar of Data Schemas/Constraints" similar to "Grammar of Graphics"? Any schema definition language you find interesting?

Friends, I don't know what to make of developments in AI these days. Having worked on dialog systems in the aughts and having loosely followed developments since (I recall preparing a talk around 2010 which left me pretty enthusiastic about ML applications in contrast to the App-and-Facebookification of "tech" — that was on time horizon of a few years, which ended up being a decade plus), every day I check in on Twitter I see more exciting stuff than I can possibly process. I was just writing someone yesterday about how in six months time, we'll have LLMs acting as the front-end to knowledge bases and rigorous computational systems, and then we'll need to focus on getting the human, AI, and formal model all on the same page. As has already been noted in #linking-together today, my estimate was off by roughly six months. Consider, "I've developed a lot of plugin systems, and the OpenAI ChatGPT plugin interface might be the damn craziest and most impressive approach I've ever seen in computing in my entire life. For those who aren't aware: you write an OpenAPI manifest for your API, use human language descriptions for everything, and that's it. You let the model figure out how to auth, chain calls, process data in between, format it for viewing, etc. There's absolutely zero glue code" https://twitter.com/mitchellh/status/1638967450510458882. If you can tolerate his prose, Stephen Wolfram has a long post https://writings.stephenwolfram.com/2023/03/chatgpt-gets-its-wolfram-superpowers/. The "Wolfram Language as the Language for Human-AI Collaboration" section is most relevant to Future of Coding. What do these developments mean for the Future of Coding? And how are you all holding up? Me? I can hardly process what's happening, let alone what to do about it.

Here's my perspective on LLMs and the future of programming. I don't believe that the introduction of LLMs that can write code is going to obviate programming. And I don't believe that it is now pointless to develop new programming languages. Instead, I think LLMs are going to make programming and FoC research better, by automating one of the least interesting parts of programming: fiddling with the minutiae of syntax, language constructs, and libraries. I think programmers will still have plenty of work to do. The profession is not doomed. But to justify this, we have to take a step back and consider all of the activities involved in programming. Firstly, what is a "program"? A program is nothing more than: • A formal specification of the behaviour of an interactive system • ...that computer hardware can execute (after translating it into machine code). To emphasise this, I will use the term "formal spec" in place of "program" for the remainder of this discussion. GPT-4 can understand formal specs, and also everyday English. Thus, if we can describe the functionality of a system in everyday English, GPT-4 can (attempt to) translate it into a formal spec. But writing the formal spec is just one activity of programming. Altogether, programming (or perhaps "software development") involves several activities: 1. Determining what functionality the system being developed "should" have. This is done either by talking with relevant stakeholders (e.g. the future users), or by directly observing deficiencies with their current practices. 2. Expressing that functionality as a formal specification, i.e. "coding". 3. Verifying that the specification correctly implements all of the functionality of step 1. This includes practices such as reading and reviewing the specification, as well as testing the software. 4. Validating that the implemented functionality addresses the stakeholder's problems. 5. Repeating the first 4 steps until the stakeholders are satisfied with what has been developed. Here's my hypothesis: In the next 10 years, LLMs might radically reduce the amount of work required for step 2, but only step 2. Steps 1 and 4 are very human-centered, and thus can't be automated away — at least until we are at the point where we have an omnipresent AGI that observes all human practices and automatically develops solutions to improve them. Similarly, step 3 will not be automated any time soon, because: • The plain English descriptions that we give to LLMs will often be ambiguous, underspecified, and maybe even inconsistent. Thus the LLMs will have to make educated guesses at what we mean. (Even if they are able to ask clarifying questions, there will always be some choices that are automatically made for us.) • LLMs will occasionally get confused or misinterpret what we say, even if we are clear and careful. We will not have infallible AIs any time soon. So let's assume that LLMs can automate most of step 2. What does this mean for those of us developing tools and technologies to improve programming? Is our work obsolete now? Will the AI researchers and AI startups be taking the reigns? I don't think so! There is still a huge opportunity to develop tools that address step 3, at the very least. (Steps 1 and 4 are harder to address with technology.) In particular, step 3 involves the task of reading source code. When an LLM spits out 1000 lines of JavaScript, how do you know that the code implements the functionality that you wanted? You have to verify that it does, and for large programs, that will be an enormous amount of work! As we all know, no amount of testing can prove that a program is correct. Thus, we cannot verify AI-generated programs just by using them. Maybe the program has a subtle bug, such as a buffer overflow, that might only be triggered 5 years after the program is deployed. Or less insidiously: maybe the program just doesn't handle certain edge-cases in the way you would like it to. Either way, a human should probably read through the entire program with a keen eye, to check that all of the logic makes sense. There's clearly an opportunity for FoC researchers here: we can make languages and tools that make reading and verifying the behaviour of programs easier! Some examples: • We can design programming languages that are vastly easier to read than traditional languages. How might we do that? Well, "higher-level" languages are likely easier to read, since they are likely to be more concise and focus on the end-user functionality. So work on higher-level programming models will continue to be valuable. To complement this, we can (and IMO, we should) invent new syntaxes that are closer to plain English, such that the specifications that LLMs produce are accessible to a wider audience. • We can design programming languages where it is harder to write erroneous programs. For example, we can design programming languages that cannot crash or hang (i.e. Turing-incomplete languages), but which are still general-purpose. This reduces the kinds of errors that a human needs to consider as they verify a program. • We can design better tools for reading and interrogating source code. (For example, better IDE support for navigating and understanding the structure of large codebases.) • We can design better tools for exploring the space of behaviours of a running program. (Perhaps similar to the tools discussed in Bret Victor's "Ladder of Abstraction" essay.) Overall, I think the future is bright! I'm going to continue my own PL research project (a very high-level language) with as much vigor as ever.

On the heels of the "LLMs and the future of programming" discussion (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1679642239661619, https://futureofcoding.slack.com/archives/C5T9GPWFL/p1679892669316079), I'd like to start a more concentrated discussion around their effect on Future of Coding projects. There was already some sentiment that LLMs are going to kill FoC projects. Some yes, but certainly not all. So what kind of FoC projects LLMs will not kill?

Has anyone tried to square “computing is a metamedium” (able to simulate all other mediums) with “medium is the message” school? I can think of a number of places where existing mediums can’t be emulated by a computer. But curious where people might say that’s an inherent limit vs a stage of expression computers have not yet reached (I think probably a mix of both). Is thinking there’s a limit “bad” if you are interested in the Future of Coding or does it help in some way with maximizing on strengths?

Object capabilities represent a shift in the way we think about access control and security in software systems. Rather than relying on traditional user-based or role-based access control mechanisms, object capabilities grant access based on the specific capabilities an object possesses. Object capabilities are first class and can be narrowed down to arbitrary granularity by the programmer. • What are the implications of object capabilities for the design and architecture of software systems? How do they impact the modularity, flexibility, and scalability of these systems, and how do they influence our understanding of software architecture more generally? • How can we best leverage object capabilities to promote the development of more secure and resilient software systems? What are the potential pitfalls and challenges associated with this approach, and how can we address them? • How do object capabilities relate to broader philosophical debates about the nature of objects and their properties? Do these capabilities represent a fundamentally new way of thinking about the relationship between objects and their properties, or are they simply a new instantiation of existing concepts?

Did you see what he said? Did you hear? Listen well! Take it to bed with you. Take it out of sight. Dream of it. https://futureofcoding.slack.com/archives/CEXED56UR/p1680041884022849

I've been thinking about how the state of a running program could be modeled as the definition of a program changing over time. This seems closely related to "image" based programming systems, right? Does anyone have thoughts or reading related to this? (I got there thinking about the branchable/forkable database trend which tries to tie program version to state version.)

Has anyone read Christopher Alexander’s The Timeless Way of Building in light of future of code? He’s the literal architect whose concept of patterns inspired the software patterns movement. In practice, Java enterprise software patterns are a lot of the past-of-code that we want to get away from. I’ve read that Alexander thought that community missed the point, and from Timeless Way I believe it. From the first chapter he gets into the concept that people should be able to build their own buildings, that it doesn’t take extensive planning, and that it resonates with something very natural within us and within the world. I don’t want to say more as I really think you need to read it in context for it to sink in; but I’d recommend picking up a copy.

Brooks said in the Mythical Man Month. Fail. Fail again. Succeed. You want to find a way to fail-fast the first two times. Using type-checked, bloatware languages ain’t the way to fail-fast.

I've been thinking: We might need new languages for describing workflows that involve both humans and bots. Something much nicer than BPMN (which is XML-based): https://twitter.com/nileshtrivedi/status/1645779203210764289

I’ll be leaning a discussion at my work about Elephant 2000 soon, and found this very valuable context to help ground the paper in some common, yet not clearly defined terms. Anyone have thoughts on Elephant 2000?

Anyone planning to read anything interesting and future of code adjacent this weekend?

Befunge, but readable https://github.com/m-ender/hexagony made the rounds of the internet yesterday, and caused me to swap in an old interest of mine that I've flailed ineffectually at in the past (e.g. https://twitter.com/akkartik/status/1238349948074070017): a way to display a program that makes its large-scale structure really obvious (rather than obfuscating it as Befunge does). One problem I have with Befunge (not the one you're thinking of, ha) and other fungeoids [1] is that you have a bunch of static information about a program visible in 2D on screen, but a key piece -- the stack -- is invisible. The question I keep returning to is how one might go about making the stack (or any other run-time state used by the program) visible without just bolting it on on the side. This time around, I got hooked on the following metaphor. Imagine a spaceship that contains some data, sets out on a voyage across an infinite 2D plane, and performs various operations depending on the objects it collides with. Example 1: The space ship contains a row of boxes. Colliding with a number pushes a box on to the nose, colliding with an operator operates on the 1 or 2 front-most boxes in the front. This is a way to display a stack, but a stack in isolation doesn't seem to scale well to larger programs. Example 2: The spaceship contains a number. Colliding with the BF-inspired primitives

+

and

-

[2] causes the number to be incremented and decremented, respectively. Now build addition out of it. Zooming into a number

n

shows it to be a loop of n iterations. When the spaceship collides with

n

it loops through n times, and the number inside it has n added to it. At a high zoom, you see the spaceship loop n times before exiting the "solar system". At a low zoom you see the spaceship exit instantaneously with n added to its value. Now you can imagine a reduce operation as a series of solar systems that the spaceship visits one by one. Example 3: The spaceship contains a binary heap to insert and delete elements from depending on objects it collides with. Zooming into any single collision reveals the tree structure to be the "space" that a smaller spaceship containing a single number bounces among. Two properties that seem important from these examples: • A hierarchical nature where space and spaceship are duals, and zooming in and out causes them to turn into each other. • Rendering the state of a spaceship needs to be extensible[3]. We need to leave Befunge's ASCII behind. At the largest scale, state machines feel like a really powerful way to represent the state within a spaceship. I often find them to be the outermost architecture of a large program. But to actually find the state machine I have to flail around for a long time. If we could use some visual paradigm at the largest scales but zoom into text as needed, programs might be much more comprehensible. [1] https://esolangs.org/wiki/Fungeoid [2] https://en.wikipedia.org/wiki/Brainfuck#Language_design [3] Like in my old Pong demo: https://handmade.network/snippet/1561

One of my recent discoveries is Permacomputing (I had encountered the term before, but never looked at it closely before). And I am wondering if anyone here has explored it more than I did, and if anyone has a view on how it might matter for the future of coding. I suspect that @Kartik Agaram is aware of this because some of his projects are cited as "adjacent". At first sight, the principles and overall objectives of permacomputing resonate with me, but I see a lot of theory and little practice. While I can see how such technology could be valuable in a different universe, which may of course be tomorrow's reality, my impression is that in the real world of today, permacomputing is nerd fiction.

Is there a more modern version of Grouping UI components by "type" and showing examples?

I've just asked this question "Why is bash a popular scripting language" to the wider internet https://news.ycombinator.com/item?id=35744867 I'm interested what do we think a futuristic shell environment looks like. is it a notebook replacing a shell, a different language i.e. more functional? or does a simple text script always exist

I have been creating a graph-based notetaking app; I am curious about the current landscape. I see Roam/Obsidian/Logseq sort of in the same category (with Obsidian Canvas as a feature with a lot of potential), and Tana (which I just learned about) goes one step further by nodifying more things. Are there any other killer features/products in this space?

I don't want to make something that already exists :)

It isn’t pitched as a note taking app, but around work I see tons of teams using mural and miro as communal note taking surfaces. To the extent that a lot of projects are almost wholly documented in some sprawling mural

1. Are games more robust than other kinds of end-user software? Why? 2. Are games in 2023 more robust than games in 1980? Why?

I am going to need to come up with a more robust way to allow my users to edit legislative text in a way that is user friendly, and forces them to stick to a predefined data structure. I'm wondering if anyone has tried to use tools like slate.js or ProseMirror for that sort of thing, or have other suggestions. It's legislation, so I want the editing environment to be as text-like as I can manage.

Software Engineers do not write code. Implementors (coders) write code. Engineers think (deeply) about what code needs to be written, and, what trade-offs need to be made to simply make the system work. Production Engineers think about making trade-offs so that the system is “efficient” along one or more dimensions (speed, space, cost, etc.), but, only after the initial system is working and shown to satisfy end-users’ needs. Current popular programming languages, like Rust, Haskell, Python, etc., conflate all of these issues together, thus, making the code more difficult to design. Conflating issues together like this has a name: “cottage industry”. Then, there’s Software Architecture, Maintenance, Testing, Q/A, Security, etc., etc. The above pattern is visible in other, older professions, such as building construction. Software might re-use these ideas and re-purpose them for creating electronic machines. Note, too, that more-established professions use diagrams to augment the use of written words when communicating designs (blueprints, schematics, molecular diagrams, etc.). Note, too, that more-established professions use elements that are completely isolated and decoupled from one another. This assumption (of inherent non-coupling) is violated by most popular programming languages.

I think we need many different little languages and a substrate “language” (kernel) to bolt them all together. Note that, in electronics, there is/was something called “design rules” which is something more-than-type. In web-site design, one uses “input validation” which is like type-checking but on a very per-project basis. It would be nice to be able to bolt design-rule checkers together using a palette of existing components. Again, it seems that one should want a palette of components to help build up design rule checkers and completely different palette of components to build up actions. I would expect to use different “syntaxes” for each concern and would expect to use IDE layers to deal with each kind of issue separately then let the IDE automagically stitch them together. This is just another way of saying “I would like to use a different language (SCN in my words) to deal with each kind of issue”. Would I use text-based SCNs exclusively? No. But, for text-based SCNs, I would use Ohm-JS and for diagrammatic SCNs I would start by using draw.io. Both kinds of syntaxes are “easy” now, so there is no reason not to build project-specific SCNs. We have been indoctrinated to believe that “one language to rule them all” GPLs is the way to go. I don’t agree. duplicated in https://publish.obsidian.md/programmingsimplicity/2023-05-31-Bolting+Little+Languages+Together

I'm currently thinking about whether Product Managers (or other non-coder end users) can be able to make direct changes to native product without Engineers. In the companies I've been at, there's been paper cuts and requests that engineers make to the product, which are time-consuming, tedious and take away from actual product/infra development. If there are guardrails that Engineers define on certain parts of the product, are there any problems to this idea? Curious what others think and/or have seen

I've been working on a specification for better, networked bookmarks. A problem I'm currently facing: I share a lot of links. I have a channel on my Slack workspace called #walkers-claptrap where I share anything / everything that I find noteworthy. It's a bit like #linking-together. That said, not everyone I share bookmarks with (and short remarks about them) are at work, so I'm frequently duplicating and sharing over multiple lines of communication (texting, social media, slack, etc). Even then, those channels aren't easily traversed and are organized linearly. I don't love sorting things by date when their value isn't directly scoped to time. I'd also prefer to publish some place that I own and syndicate elsewhere, so that rules out Twitter. semi-solution: The claptrap specification. A graph of links / small notes. The edges are based on relationships or membership with some group. A claptrap MUST be hosted plaintext and MAY be accessed with curl or similar tool (sort of like Carmack's .plan files). A claptrap MAY expose an RSS of updates to syndicate to channels etc. A claptrap MAY reference external claptrap nodes to network / branch beyond the local graph. Still very much a work in progress. Does anyone have a similar problem; do you have a solution you like? I want to bridge the gap between "personal knowledge base" and "sharing links into the ether"

I wonder if anyone has tried to use Rosie as a replacement for grep? https://rosie-lang.org/doc/rosie.1.html?hidden=true IMO, the problem with grep is that it based on regular expressions, whereas PEG is more powerful. My favourite PEG is Ohm-JS but I am curious about Rosie...

Hey all! I need a tool / stack suggestion. We'd like to track internal metrics for development like build performance stats, build size, source control size, etc. I'd like to be able to see these trends in a graph by date/commit. • CI tools can do some of this, but they only surface a small, inconfigurable set of metrics. Usually just test failures and build times. • There are monitoring solutions like Grafana Cloud, Datadog, but these all seem geared towards monitoring servers and cloud systems. They also assume you're ingesting massive amounts of data. What I really just want is a POST-able URL that I can spit metrics to, and a dashboard with some basic alerting. Is there something like this that exists?

Attending a conference today and yesterday about Blockly, the visual code editing environment. Big push toward bi-drectionality between code and blocks. For integration with existing code-bases, AI generation, collaboration with people not using visual editors, etc. At least two different approaches being investigated or used, and I would be inclined to use a completely different one. They don't realize it, but some of their problems are solved by some of the tools people here are working on. Like how do you make it so that you can generate blocks when the text is in an invalid state? Much easier to just avoid invalid states, like Blockly does! How can you avoid invalid states if the person isn't finished typing, and there are mandatory subnodes in the AST? Much easier to fill holes by default, like Blockly does. Essentially, they can't get to bidirectionality, because the text editing experience is structurally unaware. It's not possible with VSCode, but it is possible with Tylr, or anything that imposes a structure. Even ProseMirror would work better. But there is no need to stop at two concrete syntaxes, if you can sacrifice interface specific details (e.g. whitespace in text, grid position in Blockly), or keep them where they live (linter settings, a database of block locations outside the AST), you can operate directly on the AST in whatever tool you want. Has anyone played with a "headless" AST that could be used that way? It feels like all structural editors need one, particularly if they hope to facilitate collaborative editing. Has anyone tried putting two different coding interfaces over the same shared AST?

Has anyone seen controlled natural languages implemented in a structure-aware WYSIWYG XML editor? Is there some reason that wouldn't work?