Post AwX11oRDAXSLeBnAIK by PeterLudemann@mathstodon.xyz
 (DIR) More posts by PeterLudemann@mathstodon.xyz
 (DIR) Post #AwWyC02sZFP4gGZp4K by shriramk@mastodon.social
       2025-07-26T12:46:11Z
       
       0 likes, 0 repeats
       
       Thought experiment: Most programming languages were designed in an era where mostly one programmer coded in isolation. If you were designing a language for modern collaborative programming/commenting/etc., what would you change? How would you *modify* existing languages?
       
 (DIR) Post #AwWyC1LLk3lwhqE5Uu by cross@discuss.systems
       2025-07-26T14:46:04Z
       
       0 likes, 0 repeats
       
       @shriramk interesting question. I suppose it depends in part on what you mean by "collaborative programming."Supposing that means scaling up development teams to large numbers of programmers working on a project simultaneously, I'd suggest that well-defined module boundaries, and the way that interface information is communicated across those boundaries, is something that deserves some consideration.An anecdote: when Go was starting to gain some traction at Google, I was talking to a very senior engineer who was (at the time) heavily involved in G's C++ infrastructure, and he made an interesting point: Google has O(10^4) C++ programmers working in a codebase with O(10^9) LOC simultaneously. Because of the way that C++ works, with classes often definedi n header files and included in compilation units by the preprocessor (this was pre-C++ modules, which still don't seem like something that's fully baked...), it's very easy for some programmer on one side of the monorepo to "break the build" for someone else on the other side of the mono-repo. In fact, this happened all the time (and likely still does, but I don't really know anymore).Consider the case where I add a data element to some class definition in some header. This may be a data member that is completely internal to that class, not part of the public interface, but since the interface it is still exposed _in the text of the source code_, a consumer of the interface must have access to relevant the definitions of whatever I'm adding. When I'm implementing this new thing, it's trivial to inadvertently end up relying on those definitions being in the namespace of my header indirectly; perhaps because the set of transitive includes for my project causes them to be in scope _for my module_. But it may break for you because you have a _different_ set of transitive includes, and aren't including something I introduced as a requirement.Go is different, in that modules are (or were?) individually compiled, and binary information about the types, interfaces, signatures and so forth, are embedded in the resulting object file, useable by the compiler elsewhere. The internal implementation details needed by the module are truly encapsulated in the module, and while the interface can of course change (and thus break someone), the language's compilation model eliminates this particular class of problem. The upshot was that you could have more programmers working in a language concurrently. And It's faster, since i'm no longer parsing a code from headers just to use a module.I suppose this raises something else, that I don't know has been formally addressed at the language level: versioning interfaces and tracking inter-module dependencies based on version. Usually this feels like something that's punted to the build system, but making a version a first-class property of the language feels like it would be an interesting idea to explore.If, on the other hand, collaborative programming means two or more programmers simultaneously working on the same piece of code, then that feels like more of a social and/or tooling issue, and I'm not sure how language design could help facilitate things.As an aside, I've long suspected (but have no data) that one of the reasons there's so much COBOL in the world is because it can be very difficult, without semantically aware tools, to understand when a procedure is called and from where: COBOL has this weird thing where if procedures A, B and C are written textually adjacent in a source file, one can say, "call A through C". So often when modifying something it's safer to just make a big copy of it and change the copy to suit. This is, perhaps, a great example of an anti-collaborative feature.
       
 (DIR) Post #AwWyC2IuAdPXgY5eKG by shriramk@mastodon.social
       2025-07-26T15:30:23Z
       
       0 likes, 0 repeats
       
       @cross But yes, my question is precisely, CAN language design facilitate the social issues?
       
 (DIR) Post #AwWyC30rXCZZssekqG by ricci@discuss.systems
       2025-07-26T16:29:46Z
       
       0 likes, 0 repeats
       
       @shriramk @cross I've thought for a long time that the way that most languages conflate (lexical) scope with text layout gets in the way of collaborative editing. But I don't have anything better to suggest.
       
 (DIR) Post #AwX11oRDAXSLeBnAIK by PeterLudemann@mathstodon.xyz
       2025-07-26T17:01:33Z
       
       0 likes, 0 repeats
       
       @ricci @shriramk @cross There were attempts in the 80s to make syntax-aware editors and they didn't work out ... sometimes you want to treat code as a structure and sometimes you want to treat it as plain text. (Document mark-up languages suffer from a similar problem, although Framemaker got a lot closer to the solution than the WYSIWYG systems that dominate nowadays [notwithstanding LaTeX and Scribe])