I have no idea what the results will look like, but I keep pondering a question that Brett Victor asked in one of his talks. I won't put it in quotes because I don't remember it perfectly, but it was something like: what would it mean to directly manipulate behavior?

I think a related question would be: how can we represent behavior so that it can be visualized and manipulated?

SSL. Oauth. Talking to APIs in general. Also crypto in general, since we're not supposed to roll our own.

Local, syncable storage from browser

Reactive data flow, 3D renderer + camera, computable reals with bounded perf... all in the browser and with an emphasis on minimal code size

A portable assembly language with guaranteed tail calls, not the "we may optimize them if the planets align" sort from gcc and llvm. Explicitly having to label tail calls would be fine.

A programming language that natively supports declarative/reactive GUIs. Similar to Svelte, but less ad-hoc.

But really, the hard part of The Future of Coding is discovering it, not implementing it.

A way to store code structures (like an ast tree).

I want version control as a history of tree edits, including support for branching, diffing and merging.

Essentially I want git but it works for non-text code tree structures. I know of other visual/structured editor projects that got bogged down in this too.

I really don't want to have to reinvent version control but text files are terrible for what I'm doing.

^ Yeah, I want that! But it's gotta work at 60fps for thousands of elements in the tree, and millions of tiny edits, with faster-than-linear-search access to random spots in the edit history, in the browser :$ (I am okay with this using GB of RAM)

@Katie Bell Have you seen https://difftastic.wilfred.me.uk ?

I had not seen this Jack Rusher! Thanks! 🙂

It doesn’t solve the whole problem, but it could help with the tree diffing part of it.

@Nick Santos "But really, the hard part of The Future of Coding is discovering it, not implementing it."

How do you know how hard it is to build if you don't know what it is? How do you know the right idea would be well recognized without first being constructed and experienced? How do you know the person with the right idea is also the person who can easily implement all the missing software layers to build it, or to convince others to do so? How do you know if the right idea is something that pops into one's head completely formed, or is instead discovered through an evolutionary process of building, testing, and seeing what feels right and where it leads them?

@Katie Bell Totally! I don't mind if the on-disk format is text (vs in a DB or whatever else), so long as the tools on top can treat it like something richer, which is where things like this can be so helpful 🙂

Steve Dekorte Conversely, how can The Future of Coding (which I'm assuming takes the form of a "programming environment" of some kind) be hard to build if you know exactly what needs to be built? To "know" what to build is to know what code needs to be written. If you know what code needs to be written, you can simply press all of the correct letters on your keyboard, in the correct sequence, and then you're done.

What I mean to say is: programming is entirely about figuring out what code needs to be written (or modified). That's what I was implying in my last message.

As you say, oftentimes you have to experiment (many, many times) to figure out what code needs to be written. One hardly ever writes the right code on the first try. But writing code (which forces you to deliberate every little detail) is the last step in the design & discovery process.

But also — changing the UI? Because the UI is always the hardest part?

But also — changing user/stakeholder expectations?

I said data model, but I think the best way to make it hurt less that I know of so far is the Parnas approach. https://dl.acm.org/doi/10.1145/361598.361623

[moved from top level, original post by @David Brooks]

changing the data model is always more challenging, imho, since data comes first. for challenge 3, just use NixOS: problem solved 😉

I went 😭 . An algorithm is relatively self-contained. The implications of changing a data model can be impossible to even enumerate.

😮 Understanding all the code, including code not in my codebase, to know if the change I want to make is okay. Actually making the changes to an algorithm or a data model is not too hard, in isolation.

I think data models in practice are typically harder because other code depends on it in a way that I have to understand that other code too. That other code may not even be accessible to me. (A customers codebase for example). Algorithms can have that implication, but not as often.

Since I’m guessing this question is asked partially to motivate which problems to solve, I do think there are ways to tackle this.

First, since others code in my scenario is a blackbox, we can’t just make tools for actually understanding that code, it isn’t accessible. But what we could do is make it easy to explore implications of changes.

Take an algorithm change. Instead of sending a request for every one message, I aggregate every 10 messages and send them. What are the implications of this? What if I never get 10 messages? What if I overflow some bounds? What about retries? Would my accuracy decrees if my failure rate increased? Would this change be effective? Would it reduce my downstream costs?

Consider a data model change. I have data structure A and I want to have data structure B. Is there a bidirectional mapping between them? What will the increase in my storage be? If I need to convert between the two, at what do I need to support? I know that I need X,Y, and Z access patterns. Are those efficient with the new data structure?

All of these things are questions we have to ask ourselves as we are making changes in systems. But we have no way to watch them play out. No way to tweak the parameters.

Really there are two tools trying to help us 1) Whiteboards 2) Formal models.Surely there is a nicer middle ground here.

😮 I spend inordinate amounts of time fighting with libraries and frameworks that I use without completely understanding. E.g., I recently migrated the backend of a web app from .NET Core to .NET Framework, because I needed a specific feature. It took a week to fix all the things that broke.

I don't think it's a trend I've noticed. I would say the programmability of almost everything has stayed consistently low.

Things did feel more programmable 20 years ago. I spent more of my computer time on a Unix server that encouraged more scripting. Now I do more on devices (phones) that I can't program. I've made changes to my mail client when it used to be Pine. I can no longer do that now that it's a webmail client.

Even on programmable devices the picture feels worse. Every single open source project has gotten larger and more complex and harder to build over the last 20 years. Pine is defunct, but observe:

mutt mail client: 41kLoC in 1998 -> 95kLoC now. required perl in 1998, now also requires python.

tmux window manager: 24kLoC in 2009 -> 64kLoC now. Required perl in 1998, now also requires awk and yacc.

One confounding factor: I wonder how much of things seeming worse has to do with me just burning out on this sort of hacking activity over the years.

My experience is much the same as Kartik Agaram's. The one environment that feels as programmable today as it did 15 years ago is Emacs. I suspect Emacs itself also grew bigger, if only for GUI improvements such as better rendering. But from the point of view of add-ons and customization, it's constant.

That was tantalizing enough that I did some more digging.

Emacs in 1997 (v20.1): 152kLoC C, 386kLoC lisp, 1010 lisp DEFUNs defined in C, 15k defuns defined in lisp

Emacs in 2022: 405kLoC C, 1.25MLoC lisp, 1780 lisp DEFUNs defined in C, 42k defuns defined in lisp

This is pretty blunt, of course. I'm just counting DEFUN in the src/ directory and ^(defun in the lisp/ directory. Let me know if there's a more accurate approach. But my impression is that Emacs pays so much attention to backwards compatibility that you are able to ignore new affordances for add-ons and customization until you need to go find something.

For completeness:

Vim: 275kLoC in 2006 (v7.0) -> 390kLoC now

Neovim: 167kLoC in 2015 (v0.1.0) -> 238kLoC now

Very interesting that Neovim is smaller now than Vim was in 2006.

tl;dr - sloccount is a useful tool!

Another potential metric that occurs to me here is "build difficulty index". Not really covered at all by my stats above.

My point is that I don't really care about the size of Emacs. I do look at Emacs source code (the Lisp part) quite often, but I get there by navigating from my own code to layers below. As long as the number of layers I have to go through doesn't increase, the size of the Lisp code is irrelevant for me.

As you note, Emacs values backwards compatibility highly, which is something I do care about. Perhaps even more importantly, Emacs values programmability, and therefore offers good support for exploring its own source code.

So a good metric would perhaps be "number of navigation steps until you hit a primitive" (which for Emacs would be a function implemented in C)>

I'm kinda handwaving that the amount of elisp growing at the same pace as C above suggests there's no difference between C and Lisp once you start poking at the internals of the elisp. But if you're just using the elisp primitives, the surface area of names (which I'm estimating by counting defuns) does seem to grow a bit slower than the total volume of Emacs code.

Surface matters more than volume, indeed, but any simple metric misses the importance of modularity. I suppose Emacs' size made a jump when org-mode was adopted into the core distribution, but this had no impact on people not using org-mode. They could (still can) simply ignore it.

the rabbitmq simulator sounds like it http://tryrabbitmq.com/

https://vimeo.com/51363470