5 ms·

"The only real strengths of XML are that 1) it's declarative, 2) it's hierarchical, and 3) it's diffable. But code can be too, without all of these other drawba

by astine 7y ago

"The only real strengths of XML are that 1) it's declarative, 2) it's hierarchical, and 3) it's diffable. But code can be too, without all of these other drawbacks." Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather a an XML implementation that can be verified and processed with tools. "- For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated." I frequently write WPF code these days and don't find it any more verbose than attempting the same thing in C# statements. If anything, it's less verbose and it has the added benefit that it's all organized in the same group of files. "At some point you will need to access your user interface from your application code. Which means you end up with silly stuff like findViewById() to bridge the gap, adding even more boilerplate to your code." I don't know about Android, but in WPF, you just add a name attribute to your ui element and reference it by name. "Editing XML kind of sucks. You're more at risk of making silly typos that won't be caught at compile time." Hasn't really been my experience. Syntax errors are caught by the editor typically and further errors do get caught at compile time for XAML at least. Some errors don't get caught, but these are the same errors that would get missed if I attempted the same thing in C# code.

nodamage 7y ago
> Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather a an XML implementation that can be verified and processed with tools. I should clarify and say code can be declarative with the correct language support. I agree that it's probably not well suited to C# in its current state. > I frequently write WPF code these days and don't find it any more verbose than attempting the same thing in C# statements. If anything, it's less verbose and it has the added benefit that it's all organized in the same group of files. Here are two examples I would consider overly verbose in XAML: 1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why? 2. Anything having to do with overriding ControlTemplates. > Hasn't really been my experience. Syntax errors are caught by the editor typically and further errors do get caught at compile time for XAML at least. Some errors don't get caught, but these are the same errors that would get missed if I attempted the same thing in C# code. Ever make a typo in a binding? I agree that Visual Studio is really good at helping you out where it can, but at the end of the day we're still trying to shoehorn programming constructs (objects, properties, enums, etc) into a document language format by shoving everything into XML attributes (where everything is a string) and there is a fundamental impedance mismatch between the two. Good tooling only goes so far.
- astine 7y ago
  "I should clarify and say code can be declarative with the correct language support. I agree that it's probably not well suited to C# in its current state." Ok, but which language do you think would work? Lisp? I like the things you can do with macros and s-expressions as much as the next guy, but you're still left with the question of what should people using C# (which has neither of those things) use to make GUIs. "1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why?" Correct, all the different sorts of trigger are verbose. But, to answer your question as to 'why?' the reason is because we need a deterministic way to express conditional formatting. If we attempted to accomplish the same tasks with hooks we'd have the problem of intermixing imperative, state-full, code with logic that is supposed to be more deterministic. I've written code like that for WinForms like that and it's ugly and hard to debug. If you were to try to implement triggers with code behind C#, it would still be very verbose because you wouldn't be writing actual C# logic. You'd be doing something like declaring an object with trigger conditions and results and it would be at least as verbose as the XAML triggers, that is, if you wanted to accomplish the same thing with the same guarantees as with XAML triggers. The problem here isn't really the XML, but the fact that there isn't really an available language that solves the relevant problem. It's not like you could use an `if` statement. "Ever make a typo in a binding?" I have. I've also made typos when writing viewmodel objects that implement the `INotifyPropertyChanged` interface to similar effect.
  - nodamage 7y ago
    You're clearly coming from a very C# centric viewpoint and reacting to my statements from a perspective of: "well, if I don't do it in XML then I'd have to do it in C# and that would be even worse". Which I don't necessarily disagree with. But just because doing it in C# would be worse doesn't make doing it in XML good either. My underlying point is with platforms like iOS and Android adopting declarative UIs, combined with languages like Swift and Kotlin evolving in parallel to better support them, I think we will eventually be able to move on from being stuck with XML.

by astine 7y ago

nodamage 7y ago

> Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather a an XML implementation that can be verified and processed with tools. I should clarify and say code can be declarative with the correct language support. I agree that it's probably not well suited to C# in its current state. > I frequently write WPF code these days and don't find it any more verbose than attempting the same thing in C# statements. If anything, it's less verbose and it has the added benefit that it's all organized in the same group of files. Here are two examples I would consider overly verbose in XAML: 1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why? 2. Anything having to do with overriding ControlTemplates. > Hasn't really been my experience. Syntax errors are caught by the editor typically and further errors do get caught at compile time for XAML at least. Some errors don't get caught, but these are the same errors that would get missed if I attempted the same thing in C# code. Ever make a typo in a binding? I agree that Visual Studio is really good at helping you out where it can, but at the end of the day we're still trying to shoehorn programming constructs (objects, properties, enums, etc) into a document language format by shoving everything into XML attributes (where everything is a string) and there is a fundamental impedance mismatch between the two. Good tooling only goes so far.

astine 7y ago
"I should clarify and say code can be declarative with the correct language support. I agree that it's probably not well suited to C# in its current state." Ok, but which language do you think would work? Lisp? I like the things you can do with macros and s-expressions as much as the next guy, but you're still left with the question of what should people using C# (which has neither of those things) use to make GUIs. "1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why?" Correct, all the different sorts of trigger are verbose. But, to answer your question as to 'why?' the reason is because we need a deterministic way to express conditional formatting. If we attempted to accomplish the same tasks with hooks we'd have the problem of intermixing imperative, state-full, code with logic that is supposed to be more deterministic. I've written code like that for WinForms like that and it's ugly and hard to debug. If you were to try to implement triggers with code behind C#, it would still be very verbose because you wouldn't be writing actual C# logic. You'd be doing something like declaring an object with trigger conditions and results and it would be at least as verbose as the XAML triggers, that is, if you wanted to accomplish the same thing with the same guarantees as with XAML triggers. The problem here isn't really the XML, but the fact that there isn't really an available language that solves the relevant problem. It's not like you could use an `if` statement. "Ever make a typo in a binding?" I have. I've also made typos when writing viewmodel objects that implement the `INotifyPropertyChanged` interface to similar effect.
- nodamage 7y ago
  You're clearly coming from a very C# centric viewpoint and reacting to my statements from a perspective of: "well, if I don't do it in XML then I'd have to do it in C# and that would be even worse". Which I don't necessarily disagree with. But just because doing it in C# would be worse doesn't make doing it in XML good either. My underlying point is with platforms like iOS and Android adopting declarative UIs, combined with languages like Swift and Kotlin evolving in parallel to better support them, I think we will eventually be able to move on from being stuck with XML.