Forking @Marcelle Rusu (they/them)’s thread onto this bit

If so, how does "future of coding" even matter if any form of real adoption feels impossible.

(Making a new thread about this because the other one has become about OO instead of this bit) I feel this deeply. It can often feel as if things don't get adopted. That programming doesn't change for the better. I have so many thoughts on this, it is hard to summarize. First, I do think we can get others to adopt the things we value. It is almost never an education issue, imo and instead a value question. (I am intentionally leaving aside the OO frame here). Think about the impact that Rich Hickey has had on how many people code, not just clojure people, but in the industry broadly. How did he do it? Through Simple Made Easy, a talk largely about values, not techniques. The same is true of Bret Victor's influence on the future of coding community. He communicated values that others adopted. I've found this to be true in practice as well. Trying to convince people to change their coding style requires diligence, communicating values, and showing how code improves because of these values. Conflict often happens when people implicitly hold very different values. I'm going to bet that is the case in the original example given. But I also want to step back and ask, what kind of adoption, by who, by how many people? I'm willing to bet a lot of people in this slack listen to some genre of music that isn't completely mainstream. Have those genres failed because of the lack of becoming mainstream? Would they be better if they became mainstream?

Really appreciate this framing, totally agree & feeling less dread ❤️

This I think is a very common issue, how do we measure success of anything? If a sports team doesn't win the championship is that season a failure? If someone only stays at a workplace for 12 months, is that a failure? If a project only has 1 or 2 adopters was is a failure? As someone who builds ambitiously in my free time, I can honestly say that adoption is not a great metric for success in software. I've spend 6 years working on a single open source suite and so far I know that there is 1 actual user. I learned sooo much along the way though and I choose that as the metric for success here because if I used adoption it would be an unequivocal failure.

I’d add that everything we have now passed through the filter of adoption. These processes are complicated and path dependent, but new things can survive and reach wide enough use to feel like they’ve made a difference in the world.

The way I see it, there is a layer of UX missing from what we call “programming”. What we call “programming” is a way of scripting single-threaded[sic] CPUs in a fairly rigorous and efficient manner. What non-programmers want is not to be bothered with all of that bumph. BASIC and SpreadSheet language are sufficient and don’t involve deep thinking about the actual act of programming. The missing layer of UX is something like a mapping from BASIC to extreme lambda calculus. Example: in the Lisp world, FEXPRs are convenient, while hygienic macros are more rigorous, but, less convenient for non-zealots. How do we provide a method for programming that presents ultra-rigour as a convenient-to-use IDE? Forcing non-programmers to think deeply and rigorously about programming ain’t it. [My bet is on box-and-arrow diagrams using 0D, non-conventional uses of OhmJS, PEG, SVG, HTML, etc., but, YMMV].

For adoption, I see two levels that matter. The first level is "large enough mindshare to survive and prosper". The second level is "large enough to be considered mainstream", meaning among the top contenders. My personal interest is in learning, discovering, improving. Technology in this space should reach the first level of adoption to stay useful in the long run, but stay well below the second level at which the practical needs of lots of users drown any interesting discussion of fundamentals.

I'm still optimistic that adoption barriers/network effects can be eliminated with wasm support and cross-language build systems.(cross-language build systems are currently just nix afaik, not the best, but building another one is not especially hard, you just need more than one compiler toolchain to have wasm versions and then you're basically there) Though I've never seen a wasm gc interface language that was like "yes we're going to make gc and non-gc programs seamlessly interoperable"

I am not convinced yet that enough people in WASM space care enough about language interoperability to make it happen. WASM might just become “C for the browser”, with everyone providing an FFI for WASM binaries but no support for actually dealing with another language’s high-level data structures.

What makes you unconvinced, from my memory working on Rust's wasm-bindgen there was a lot of energy around interop, then it was "host bindings" now it seems to be components

1. I don’t see who would have both the incentive and the means to do the job. 2. I don’t see multilingual WASM apps, nor toolchains to produce them. There is of course promising work, including components, but it’s not yet ready for real-life applications.

TBH you could say that about WASI (if not WASM) in its entirety