See SyntaxVsSemantics for what is meant by syntax first.

Ideally, syntax would be the incidental decoration to semantics. Many try to come up with syntax following the principle that SyntaxFollowsSemantics. But that's doomed since the line between syntax and semantics is subjective.
* If one follows the tedious low-level definition of syntax and semantics, then the conclusion is that there's a hard and fast line between the two, and it isn't subjective at all. Following your looser "internal vs external" definition still '''sounds''' kind of strict to me; how does it follow that the difference is then subjective?

What's syntax and what's semantics is a subjective quality dependent on the user's frame of mind. Some person may really, really care that writeFoo does something slightly different from writeBar. In fact, they may think that makes them ''radically and fundamentally different''. Another person may simply not give a damn.

This subjectivity of what people wish to pay attention to, what deserves to be decorated by special syntax, shows up most prominently in the field of UserInterface''''''s as DirectManipulationVsScripting.

* Applying my point about definitions from the other page here, what it comes down to is that direct manipulation is a syntax/representation that is precisely in one-to-one mapping with the semantics. That's different than "no syntax/representation".

* ''That's false you know. Direct manipulation is just a different form of syntax. You just don't see it because you assume that the objects being directly manipulated are those things that you care about. But if they weren't, if for example you were task-oriented, then they'd just be an extremely painful syntax. Consider for example having little "letter" objects that you have to directly manipulate onto a label in order to write something. Gee, doesn't that sound more powerful than magically invoking keys by pressing an associated button on a "key"board.''

* ''Even parse trees can be syntax if you don't care about that level of detail, or they don't map one-to-one onto those things that you do care about.''

* Basically when you say "syntax" you mean "details that don't matter to me"? Hmm. Instead of inventing a new meaning for an existing word, why not just call them "trivial details"? It seems to me that that would communicate what you have in mind better. Communication is difficult to start with; misunderstandings over terminology don't help.

*''I'd call them irrelevant implementation details with the appropriate sneer in my voice. But judging from the response, it wouldn't communicate what I have in mind.''

*''But I use syntax vs semantics because these words are subsumed by the concepts I use. Think about it, what is syntax in a programming language except a way to demarcate what matters to a compiler (writer)?''

*''Parse trees are the natural syntax of compiler writers. They're the natural syntax of someone wanting to muck around in the language because they map one to one onto what they care about. But they're still syntax exposing low-level details that most people don't care about.''

*''What people usually call syntax in a programming language is that completely arbitrary shite that nobody ever gives a damn about. To most people, a lot of the lower level details (the form of parse trees and whatnot) is just syntax too.''

* ''I think I've got it though. Semantics is what matters is an interface. Syntax is what doesn't matter to one or the other party on each side of the interface. If I don't care about the distinction between two functions but you force me to distinguish them, then that's evil syntax. If there is no distinction between how I implement two functions but you want me to distinguish them, then that's good syntax. But both are syntax.''

The only way out of the morass is to have no distinctions between anything, to have as few different concepts as possible. And then to distinguish between all of these "same" concepts based on user preference.