Great thread. My favorite response: "It turned out, at least 15-20 years ago, that smaller programs were somewhat easier to write, but larger ones took about the same time, and (at least where i worked) people agreed that it was very hard to understand the flow of the program for new people, or if you had to maintain something after an extended period of time." https://news.ycombinator.com/item?id=20476919#20477168

Woooof that thread is painful to read. So much context-ignoring we tried that already and it didn't work.

The comment I quoted above had caveats carefully stated, I thought. I think we can all agree which side the burden of proof is on? Switching people over to a whole new modality is an immense undertaking with several chicken and egg problems. We have to lay the groundwork for an environment that can scale to large programs before the large programs exist. It has to allow people using it to collaborate with people who are still using text. It has to be robust to incomplete or outright wrong metadata. Seems reasonable that people who don't care about building it are skeptical of the enterprise.

The only thing no one on that thread touched on is the mental overhead of keeping the architecture of an entire codebase in your head…

hacker news is like a petri dish for the is-ought fallacy. I wish I could buy up like 20% of the ad display space on the net just to plaster it with "WE LITERALLY DIDN'T HAVE GRAPHS OR CHARTS UNTIL SOMEONE INVENTED THEM" Like, if the only worth you have on the internet is based on successfully arguing you know more than the OP then you're going to be incentivized to misinterpret absence of evidence as evidence of absence: if I haven't thought to work on this, it must be a bad idea to work on it otherwise I'd be an idiot in my own value system

@Kartik Agaram

The comment I quoted above had caveats carefully stated, I thought. I think we can all agree which side the burden of proof is on?

Yes, and yes. I wasn't responding to that comment, I was responding to the entire HN discussion in aggregate — "that thread" — where, sure, there are plenty of good points well made, but there's also a lot of needless dunking.

It has to allow people using it to collaborate with people who are still using text.

This is a stated must-have for a lot of people, but (not-even-contrarian take) I don't think it's a must, and I think you can find examples of communities that get by fine without this. Game devs, for instance, often work in tools & formats that are siloed. Interop is a great benefit, but it doesn't need to be foundational. The absence of it just slows one vector of adoption, but history has shown that lack of interop doesn't always lead to DOA for a new paradigm.

Seems reasonable that people who don't care about building it are skeptical of the enterprise.

That's a fantastic point, and the dual of what I was saying. I'm someone who cares about building it, so it's painful to see people dunk on it. I have a vested interest.

Interop is a great benefit, but it doesn't need to be foundational.

Definitely. One thought after this exchange: perhaps it's counter-productive to start conversations about non-text programming with, "why aren't we already doing this?" That tends to trigger responses that are basically saying, "we aren't already doing this, and I'm scared to switch." Scoping it to a specific community (at least for a time) would lead to more productive conversation, even with those outside the community. It also feels like a classic case of low-end disruption. If people dismiss it as a toy, you may be doing something right!

yeah or even "we aren't already doing this because we use Unix, and Unix loves text"—like: that's not the end of the conversation!!