Imagine something like Go and APL compile down to the same AST, and imagine two programmers working on the same project with different syntaxes as you describe. The Go user one day finds a function called "life" that contains several hundred lines of code, which is clearly bad style and should be broken up, so he goes to talk to his APL using coworker who wrote the function. His coworker seems confused, "it doesn't seem too long to me" he says as he shows the APL function on his screen:
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
I think what you proposed is a good idea, but it's just an idea. We'd need some new innovation to make it work I think.
Your thought experiment shows how hard it would be. If we could do that, we could translate machine code into readable high-level programs.
To put it the other way around, it reveals something about how choice of programming language affects not only how we write a program, but what we write, and even how we think about the problem.
Rich Hickey had a great comment a long time ago on the Software Engineering Radio podcast [0] that I think speaks to this. He was asked why he didn't just make the ideas in Clojure a library for Java.
Interviewer: "Wouldn't it have been possible or simpler to add this using some kind of library or framework to an existing language? In other words, why does this kind of stuff need language support as opposed to just a library?"
Rich: "In fact it is a library. It's a library written in Java that you can use from Java. The whole thing about a language is, a language is about what does it make idiomatic and easy. So for instance, you can use the same precisely the same reference types, and the STM, and the data structures of Clojure, all from Java... The lack of idioms and language support means using exactly the same constructs, the same underlining code, from Java, is extremely painful compared to Clojure where it is the natural idiom."
I thought about it some more and I think it would go the other way too. APL has a lot of very terse array operations, but in Go you might find a mix of loops and if-statements. Translating those arbitrary combinations of loops and if-statements into APL might be very very ugly, or even impossible.
Consider assembly or basic, which use a lot of goto-statements. It can get very ugly trying to fit some arbitrary goto's into the more structured loops and if-statements we're accustomed to.
Exactly. There's a kind of entropic arrow from higher-level to lower. Moreover the different high-level languages occupy different places in that same space. It isn't just that you can't easily translate between them. It's that they lead to different classes of system being created in the first place.
What should be possible, though, would be to distinguish a surface-syntax from the underlying code: e.g. a language that can transparently convert to/from c-style curly brace blocks, Pascal-style begin/end and s-expressions. possibly implemented as a bunch of git hooks that transforms to a normalized representation (as, e.g. prettier does for JS) on push and transforms to the programmer's preferred representation on pull.
I suspect you'd find that what look like surface differences actually go deeper into the meanings of programs, like a plant whose roots go deeper than one would expect.
There's a special level of Hell that involves streaming xml processing and cobol. Since cobol lacks dynamic memory allocation (speaking of cobol 85 here) and you don't generally build things like linked lists or trees, there's a limited number of things you can conveniently do with streaming xml data. Many cobol programmers are left with a feeling of despair, I wager.
The Sapir-Whorf hypothesis is certainly real in programming languages[1].
Consider assembly or basic, which use a lot of goto-statements. It can get very ugly trying to fit some arbitrary goto's into the more structured loops and if-statements we're accustomed to.
There was a lot of work around equivalance of control flow between goto/conditional branch instructions/unconditional branch instructions and "while programs" in the 70's that showed there's actually a limited variety of control flow patterns, and while programs can be made equivalent. I think the result of this is the nowadays presence of break/continue loop constructs in most languages. Maybe this is a folk theorem, I don't recall really.
I think with a sufficiently advanced compiler pretty much any page of Go code would compile to a few lines of APL albeit in a different style. I have no source for this view though I can't imagine something in Go being more terse.
That sounds like an imaginary non-problem. In such an extreme case, the APL developer would just have to put up with that line broken into 10 lines maybe. Just configure his editor accordingly (maybe to move through text like there are no newlines except some condition or whatever - if you use an "exceptional" syntax waaay different from all the others, it's your problem to hack your Emacs/Atom whatever to handle it for your need!). And btw, you could also have an autoformatter like goftm that will break down that line of APL by a condition like "should not exceed maximum line length in any taxes", whether you like it or not, might even avoid having a conversation altogether.
Even if one of the syntaxes is not text based, maybe even a "syntax that involves arranging blocks in 3D space with a VR headset" or whatever, people could still agree on sensible defaults.
Only issue I'd see might be with open source projects, where you could add a guideline like "please reformat your code so that it looks good in syntax X according to styleguide X-42 or your pull request will not be accepted". Yeah, the conversations might become less democratic, with some "style dictator" needing to push "the right rules" down right every contributors throat to prevent endless bikeshedding, but it could work.
If we'd give of some of this crap "style democracy" and have a few more authoritarian rules, we could instead enjoy multiple syntaxes easily. The ol' "more freedom under tyranny" paradox that people always seem to (like to) forget it actually works, and could work well to code too.
