Somewhat augmenting Dries' Why the big architectural changes in Drupal 8 most excellent blog post, let me explain two architecture decisions: annotations and YAML. Both were chosen as the least bad. The decisions are obviously debatable and believe me they were (and still are) but I think it'd be helpful to give some background on the decisions. Also note there might be arguments I have forgotten.
One, annotations. These are used in the plugin system: plugins are much like PHP native interfaces with a little extra: the plugin system can discover every implementation of an interface (the default is magic namespacing), deals with metadata (by default this is provided by annotations) and provides a factory for the plugin classes. These are used for field formatters, widgets, blocks and a lot other things. So, why are we using annotations for this metadata? There are (roughly) three ways to provide metadata: in code (a hook or a static method), in an external file or annotations. We didn't want to use code because it makes static code analysis and any sort of external processing quite a bit harder not to mention that people might get the wrong idea and introduce logic there. An external file, well, that's an external file, there are already enough files or so we thought it's not desirable. It's easier to handle the class and its metadata in one file. So, annotations.
Why YAML, that's also by exclusion. First, we are looking for a file format that is both human editable and computer parsable. We did not want a Drupal-specific format (info files). We did not want XML because then the schema is the Drupalism (and XML has cooties ;) ). JSON doesn't allow comments and non-ASCII characters need escaping, that's not nice for humans. So, YAML.
Commenting on this Story will be automatically closed on October 1, 2013.