5 ms·

i've coded a lot of perl, and i hate "there's more than one way to do it". not that there is more than one way, but the idea that it's a good idea. when there

i've coded a lot of perl, and i hate "there's more than one way to do it". not that there is more than one way, but the idea that it's a good idea. when there is only one way to do it, then you and i will write identical code and it will be therefore easy to maintain, an idea put forward by Charles Simonyi before you were born. perl's hodgepodge semantics do make sense if you had already lived on the cli in a perl-less world and already knew grep, sed, awk, etc. because that's where perl grabbed its ideas from and you would already be familiar with them and it would not seem like more of a hodgepodge than what you already knew. there is more than one way to do it (semantically) is not there is more than one way to write it (syntactically) The boolean algebra of sets and the boolean algebra of logic are isomorphic (which in a strong sense is "same syntax"), but they are not semantically the same at all, is what I mean by semantics. the point I was making has nothing to do with perl's hodge podge of semantics, i simply want to know what the semantics of Q are, and the syntax presentation in the examples hardly distinguishes its semantics from any other post algol language. I'm not saying the language should support multiple/lax syntaxes, I'm saying that when I edit a file I should see what I like, and when you edit the file you should see what you like; I should never see what you like unless we agree to share. Same semantics, not same syntax. The syntax would not be part of the language. The fact that syntax is part of our languages is how noobs get syntax confused with semantics and then never learn that semantics are the only important thing.

K0balt 1y ago
How would one separate syntax from the language? Some kind of syntax.conf where syntax would be defined? I guess that would mean a syntax compiler stage to an intermediate language- kind of like the way many “languages” compile down to js? Or perhaps a shallower version of that idea, with a “plain” syntax and the syntax wrapper lives in a pre-render in the IDE? How would you choose to accomplish this?
- fsckboy 1y ago
  depends how quickly the "conversions" or "expressions" of syntax can be altered, and how each of us likes to work. when we load code into an editor, we get colored syntax highlighting that's done on the fly according to rules which have a syntax of their own. So, perhaps it could be done at that level. I would prefer if I ran "make syntax" on my repository, and you ran "make syntax" on yours, and we both ran "git semantics" to update the hub. The reason I prefer that is then I could use cli tools I'm used to, like grep, and only have to keep in mind "my syntax" which I would use for all the languages I code in. Then I could write my own helper tools... or, I could also write helper tools that worked on the semantic version and would not need complex parsers of braces, quotes, backslashes, etc. these ideas are not orginal to me, the language CGOL https://en.wikipedia.org/wiki/CGOL https://en.wikipedia.org/wiki/CGOL was lisp that looked C or algol style. The language CLU https://en.wikipedia.org/wiki/CLU_(programming_language) https://en.wikipedia.org/wiki/CLU_(programming_language) was OOP that was implemented all as calls to member functions, but then there was a layer of syntactic sugar on the surface so you could write x+y and it would turn into .add(x,y), they had identical semantics.
  - K0balt 1y ago
    It’s a very interesting idea to separate syntax from language mechanics. In a way, that’s what all programming languages do, with bytecode or machine instructions under the hood, but the idea of segregating syntax from function seems distinct in an intriguing way. I wonder how much, exactly, of the comparative benefits of various languages stem from their syntax rather than the way it is compiled?
dolmen 1y ago
> when you edit the file you should see what you like; I should never see what you like unless we agree to share. Tools beyond compilers are based on a text representation of code. I'm thinking to VCS and code review tools. So a whole suite of user (developer) facing tools would be needed beyond the compiler.
- dolmen 1y ago
  Many coding environments that provide the editing experience along with the compiler/runtime are in this class. I'm thinking to: - graphical "languages" like Scratch - MS Excel: a French version of Excel has different names for functions than English Excel. - bytecode based languages

K0balt 1y ago

How would one separate syntax from the language? Some kind of syntax.conf where syntax would be defined? I guess that would mean a syntax compiler stage to an intermediate language- kind of like the way many “languages” compile down to js? Or perhaps a shallower version of that idea, with a “plain” syntax and the syntax wrapper lives in a pre-render in the IDE? How would you choose to accomplish this?

fsckboy 1y ago
depends how quickly the "conversions" or "expressions" of syntax can be altered, and how each of us likes to work. when we load code into an editor, we get colored syntax highlighting that's done on the fly according to rules which have a syntax of their own. So, perhaps it could be done at that level. I would prefer if I ran "make syntax" on my repository, and you ran "make syntax" on yours, and we both ran "git semantics" to update the hub. The reason I prefer that is then I could use cli tools I'm used to, like grep, and only have to keep in mind "my syntax" which I would use for all the languages I code in. Then I could write my own helper tools... or, I could also write helper tools that worked on the semantic version and would not need complex parsers of braces, quotes, backslashes, etc. these ideas are not orginal to me, the language CGOL https://en.wikipedia.org/wiki/CGOL https://en.wikipedia.org/wiki/CGOL was lisp that looked C or algol style. The language CLU https://en.wikipedia.org/wiki/CLU_(programming_language) https://en.wikipedia.org/wiki/CLU_(programming_language) was OOP that was implemented all as calls to member functions, but then there was a layer of syntactic sugar on the surface so you could write x+y and it would turn into .add(x,y), they had identical semantics.
- K0balt 1y ago
  It’s a very interesting idea to separate syntax from language mechanics. In a way, that’s what all programming languages do, with bytecode or machine instructions under the hood, but the idea of segregating syntax from function seems distinct in an intriguing way. I wonder how much, exactly, of the comparative benefits of various languages stem from their syntax rather than the way it is compiled?

dolmen 1y ago

> when you edit the file you should see what you like; I should never see what you like unless we agree to share. Tools beyond compilers are based on a text representation of code. I'm thinking to VCS and code review tools. So a whole suite of user (developer) facing tools would be needed beyond the compiler.

dolmen 1y ago
Many coding environments that provide the editing experience along with the compiler/runtime are in this class. I'm thinking to: - graphical "languages" like Scratch - MS Excel: a French version of Excel has different names for functions than English Excel. - bytecode based languages