I’ve been obsessed with the question of how the future of coding might look like for a while, and I’m at the point where I have to ask myself if I’m actually progressing or just jumping from idea to idea. I was initially motivated by the vague feeling that something about software development today is wrong and that there has to be a better way. My working hypothesis was that programming is too complicated. If we made it more accessible, everyone could create precisely the tools they need to solve their problems. Is this true? If we gave everyone the ability to program overnight, very little would change. People still couldn’t quickly build tools to solve problems. I know this because I currently don’t use any tool I’ve created for myself. Most of the time, it’s just not worth it to build a tool for myself. Making programming easier isn’t sufficient to create an ecosystem of DIY tools. The shape of the artifact that we produce when we program has to change as well. The next question is: Do people even want to create their own tools? The answer is most people probably don’t. B Nardi [1] surveyed how people use applications that support end-user programming like spreadsheets or CAD software. What she discovered is that most people only used basic features. If they wanted to do something more advanced, they relied on the few people on their team (10 - 20%) that had an intrinsic interest to tinker with computers and read manuals. She called these expert users local developers because they helped raise the technical sophistication of everyone by supporting their colleagues with questions and by sharing macros or formulas that they’ve created. We can see the emergence of local developers also in the no-code movement. There are now dedicated agencies that focus purely on creating no-code applications [2]. My initial hypothesis that we have to make programming easier was naive and too focused on the creation process. In the future, I want to focus more on the shape that applications should have once they are built. So, for example, I’m less interested in finding more user-friendly abstractions than the EXCEL formula language. Instead, I want applications that you can take apart into recombinable parts. How could a tangible building material of information software look like? • structured search • drag and drop of data objects How to address the different classes of users of the system? • A base material that is useful without programming • A framework for developers to create domain-specific components • A glue language for local developers to recombine the components [1] https://mitpress.mit.edu/books/small-matter-programming [2] https://nocodeagencies.com/

I know this because I currently don’t use any tool I’ve created for myself.

A reason that the people who can program often don't feel the need to program is that many of their software needs have already been met by the mountain of past work from people similar to them — programmers. But people who can't currently program will have needs they face in their work that are less likely to have been met by software, because "people similar to them" are also presumably not able to program. But that's just a quibble with this one supporting argument. I still agree with the conclusions you draw.

If we gave everyone the ability to program overnight, very little would change. People still couldn’t quickly build tools to solve problems.

I strongly disagree with this assertion, assuming I'm interpreting it correctly. I think we can make it practical for end users with technical aptitude to make apps.

My working hypothesis was that programming is too complicated. If we made it more accessible, everyone could create precisely the tools they need to solve their problems.

What do you mean by "make it more accessible"? There are many ways you could interpret that goal. Oftentimes when people say this, they mean making programming easier to learn. Other times, they mean making the programming community more friendly and diverse. Personally, I'm focused on re-inventing the very foundations of programming to make it simpler.

There are 2 relevant threads starting at https://marianoguerra.github.io/future-of-coding-weekly/history/?fromDate=2020-09-08&toDate=2020-09-14&channel=thinking-together#2020-09-08T18:06:34.135Z

I think discovery and distribution is a difficult problem more than creation, hence I orbit a coding community I think might achieve criticality (i.e. observablehq.com) that also supports what I think the future of coding should look like: personal customization of other people's software.

I strongly disagree with this assertion, assuming I’m interpreting it correctly. I think we can make it practical for end users with technical aptitude to make apps.

I should have been more clear. I think it is possible to provide end-users with an environment that allows them to build custom tools. I was trying to argue that the main problem isn’t that people cannot program because it’s too hard. The main problem I see is that most of our programming environments are made for building professional software that will be used by thousands to millions of users. I think programming should be easier, but first I want to focus on a better shape for software that enables casual remixes and recombination of tools. Boxer [1] is a good example for such an environment. @Kartik Agaram Thanks for linking back to previous conversations. I think the future of coding history tool is a great example of the kind of tools I’m talking about. In my dream world, something like this wouldn’t require writing any code at all, and you could just take apart the slack interface to create a custom view. [1] https://boxer-project.github.io/

It's a dream shared by many, and I am in the minority in considering it obviously unrealistic. Slack has its own incentives, and has to compete with the abstractions above and below it [1]. You're never going to be in a situation where you can forget about incommensurable incentives. [1] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v

I don't think Slack would ever provide something like that. What I aspire to is an environment that would make it feasible for a community like ours to build our own communication tool.

The main problem I see is that most of our programming environments are made for building professional software that will be used by thousands to millions of users.

1000% agreed! However, I believe your metaphor of "A glue language to recombine the components" [like Legos] is fundamentally ill-posed. We programmers have a long history of over-estimating how composable software is. I believe that no matter what components you come up with, anybody putting them together will still have to reason about a wide variety of cases, scenarios, error conditions. That is to me the essence of programming, and it takes some minimum effort to learn no matter how easy it is to compose the final program out of primitives. Given that fundamental uncomposability, I think you'll always have disagreements within the community. People and subgroups who can navigate disagreements are more empowered than people and subgroups who can't. And so you'll never be able to stop thinking about how the components are implemented.

I am wondering how observable does not fit this want, here is someone building a data summary tool in userspace with other members contributing opinions and suggestions https://observablehq.com/@observablehq/summary-table

I think there is nothing wrong per se with Observable's approach, but if the stuff I need to glue together is not in Observable, it won't work for me. I suspect that the uncomposability that @Kartik Agaram describes is mostly due to different conventions used by different software tools/environments and different communities. Software components can be assembled together only if the interfaces fit perfectly, and given the enormous amount of detail that can go into software, that's a big constraint. My current view (likely to change, as it has changed in the past) is that the main culprit is the widespread approach of "my language is the entire universe, except that I interface to C or JavaScript for practical reasons". If we want software components to interface easily to components written by someone else far way in time and space, the first thing we need is languages and runtimes designed for being one among many.

if the stuff I need to glue together is not in Observable, it won't work for me.

But Observablehq consumes ES6 modules, and emits ES6 modules. It has standard connector and can directly depend on NPM hosted code. The code is vanilla javascript. You can flip on your DevTools and debug it. You can use javascript's dynamic imports to load ES6 code from any URL on the internet. So it couldn't be more composable and compatible with of one of the largest software ecosystems on the planet.

my language is the entire universe

Javascript call APIs, which is where cross language composability lives.

the first thing we need is languages and runtimes designed for being one among many.

This is what REST HTTP/gRPC is for, we have that at the network layer. I maybe don't understand your points properly but I don't think Observable is a "my way of the highway" approach that I have seen many other tools do (Darklang, ELM), its vanilla Javascript (and SQL, TEX, Markdown and HTML). Maybe the fact you are forced a certain IDE is a problem but I think hosting on the browser is actually a huge win for accessibility (no installation).

Observablehq consumes ES6 modules

Fine, but what if the components I need are in Python, or R? Not a made-up example, that's my daily work environment. I'd love to be able to use Observablehq, but none of the ingredients I need (pretty specialized stuff for molecular simulations) exist in the JS ecosystem. For the same reason, I can't use Clerk (the recently published notebook for Clojure), which looks neat as well.

I totally agree that the python and R ecosystem each has a lot of unique software that is unavailable elsewhere. But this is not the fault of the javascript ecosystem, which is more or less available everywhere. Javascript is running in a sandbox expressly to make it portable, and it is a wild success because we hardly worry about whether your JS is running on a Mac or PC. These same cannot be said for Python, where a numpy installation is a pain on pretty much every platform, and python 2 does not work with python 3. JS has a remarkably strong backwards compatibility story in comparison.

And configuring all port numbers by hand to avoid conflicts doesn't scale either.

this is what docker-compose solves. It gives you a way of wiring a bunch of different binaries written differently together . It's not a great solution but its best we have at the moment. I do think cross language composability is more or less solved at the network layer, we have pretty good standards for networks.

@Paul Sonnentag “Instead, I want applications that you can take apart into recombinable parts.” @Nick Smith “Personally, I’m focused on re-inventing the very foundations of programming to make it simpler.” [ disclaimer: the following is a hunch and I definitely do not have links to research backing up any of it, etc ] I strongly believe that much more is possible than is currently considered. I feel that (1) we, as computer scientists, developers, or just users of PL’s / digital artifacts are blinded by our own tradition; that we are flattening our comprehension of our own human cognitive/linguistic capacities by subconsciously projecting them onto the plane of known PL’s and traditional formalisms. And (2) that each of the two quotes above, minus overlap, embodies at least one prospective magnitude of improvement in accessibility/usability/metrics of cognitive complexity growth. And that’s a huge part of why I appreciate the general openness of FoC! We need to enter a state of playfulness on all levels; inviting our minds to free play outside of our schooling and current experiences. We also need to consciously seek out other points of reference than the current focal points in CS/PLT and find more reference points that can span a broader PL design space. We need to find ways to let go of our discomfort with human cognition/perception/language capacity, accepting… no, embracing, first-principles thinking; immersing ourselves in a decent level first-principles playfulness.

That is exactly what I am doing 🦄

But this is not the fault of the javascript ecosystem

Lack of communication is never the fault of any (potential) participant. It's the shared attitude of everyone. JavaScript is just like Python, R, Java, etc.: there is a wall around the ecosystem, and most of the computing world is outside of it. Which means that you have to choose the most suitable walled ecosystem for your projects, and live without the good stuff from the others. Note that "success" (meaning adoption) is not really a good criterion. Software is everywhere, each application has different needs. Being good in a large niche is no better than being good in a small one.