Slam them hard

Someone said your language sucks? Slam them back!

• C/C++/Java
  switch control structure is terrible because of one small issue: fall-through by default. Making break the default behavior and using continue to fall-through would make it perfect. But, not to be...
• C
  1. Where are the simple data structures like list?
  2. Working with strings?
• C++
  1. Changed widely used header by accident?
  2. Oops, forgot the copy constructor again?
  3. Great new compiler, now template error messages are only two pages long!
• C#
  1. Works on every platform as long as it's Windows. Mono? Have you at least tried it?
  2. When invoking delegate, you have to check if it's not null! Why?!
• Java
  1. Need to return two values from method again?
  2. When compiling Java became faster than C++, then Maven was invented...
  3. Java <=1.4: who needs templates, store plain objects in collections, Java >=1.5: generics!
  4. Java <=1.7: interfaces are absolutely abstract, anything else would be insane! Java 1.7: great news, you can now provide default implementation in the interface!
  5. Terrible slowness on a large scale and you can scale it even further!
• Python, JavaScript, Perl, Ruby
  1. Mistyped variable again when assigning?
  2. Added extra argument to widely used function?
• JavaScript
  1. Forgot to write var... in two places...
  2. Object is function and function is object, but you can't call this function, because it's not a function
  3. Fragility of C + the power of C++ + extra ammunition

9 reasons not to use XML

When I have to write code that deals with XML, at some point I wish it did not exist...

NOTE: I don't say "don't use XML", I say "think twice before doing so", because simple things should be simple (and XML is unlikely to keep them simple).

Reason for writing this: I've been working with Windows 8 tiles for over two weeks, I need to release some steam...

1. XML is for storing data, not writing code
Yes, this one is dedicated for Spring, Struts, Ant, Maven and co. You can call it "declarative", "configuration" or anything else, I say "it's code". And XML is terrible for writing code: difficult to read, a lot of extra characters to write... Maybe it's easier to parse, but since when do we design language for compiler/interpreter programmers?
BTW, you can step through the code using debugger...
2. It's very difficult to manipulate without dedicated library
Libraries exists, more than enough of them. But quite often modifications you have to make are so trivial, that simple text find&replace seems to be the best solution. But you can't do that, because you have to make sure the string you put to XML does not have characters <, >, ", /, &,... Simply to many of them and who can tell them all without looking somewhere? So, no tools like sed or string methods like replace() for you, use fully featured library to change those two attributes...
3. It's hard to work with even using dedicated library
Marshaling objects to XML or unmarshaling from is fairly easy, full-featured frameworks are available for this. But it gets more interesting, when you only want to change a couple of nodes and XML document is not made by you. Doing full marshaling is not reasonable: a lot of code and bad performance. To add/remove node or set attribute is not as trivial as you'd wish. Simply string find&replace is out of question, while searching for nodes is either fragile or requires quite a lot of checking. Debugging such code is never fun.
The only simple way I've seen is manipulating dom in JavaScript, but you're not always lucky to use such dynamic language. With C++, C# or Java this is much more messy...
4. Slow to read, slow to write
Complex syntax make XML parsers slow compared to the ones for other formats. Formats like JSON or YAML are faster in this respect as well as they are more human-readable. Not to mention simple key-file or INI file formats, which are enough way more often, than they are used. And they are easier to parse by hand than it is to read XML using library...
5. It's only suited for tree-like data
If data is of simpler structure than tree, say, list of records, XML is too complicated for it. Record-Jar format is more suited for this. The same applies for data, that is more complicated than tree, like graph.
6. Too powerful for most use-cases
What is the difference between child node and attribute, when to use one or another? Do you need entity reference? Do you need schema validation? Do you need XSLT?
When you look at what you need and answer "no" to almost every advanced feature, why mess with this format at all?
7. Difficult to embed into program code
Most C-based programming languages use double-quotes for strings, which are also used for attributes in XML. Happy escaping!
8. But everyone knows it
That's a valid argument. But you can also say that everyone goes to dentist, so it should be something everyone likes... The fact that XML is industry standard does not make it good, it only means that industry chose this format because they though it was better than alternatives at the time. It does not mean that it still is and it does not mean it is good for the problem you are solving ATM.
9. XML for UI: from nice to ugly
UI is one place where XML has proven to work well. No surprise, UI is tree-like, so XML just fits right here. More - widgets have properties and children, so attributes and child nodes do the right thing. Application supports plugins? Several XMLs can be merged, Firefox is a good example. Web pages are XML (well, almost), etc.
Now about the ugly part. Do you manipulate raw XML in the code? Tiles in Windows Store Apps require XML for notifications and badges. The first is ugly - you get predefined template and manipulate it using XML manipulation classes to insert necessary attributes. With badges it's much, much worse. They only support numbers and predefined glyphs (identified by string constants!), but to put a badge you have to prepare the full XML document! F*** you very much.

And now the enterprise hell falls onto my head...