[skrebbel]

This problem isn't about funny employee names. It's about thick, untransparent software stacks that make simple problems difficult.

SOAP is maybe the most popular example and this is really why it's lost popularity against REST. However, similar "It works with values W, X, Y, but not Z" situations are found in any stack or standard that has too much magic going on. Rails certainly comes to mind.

This is the biggest argument in favour of using many small, isolated components rather than one big all-encompasing framework, in my opinion. If every piece of third party functionality you import into your project can be easily understood, problems like these shrink in size, because there's a limit to how deep the magic can go.

I'm very fond of the Node.js ecosystem for particularly this aspect (even though I dislike the language). There's a big bucketload of tiny components there, rather than 90% of the community relying on a single humongous framework, like is common for e.g. Ruby or C#.

[macspoofing]

>It's about thick, untransparent software stacks that make simple problems difficult.

In this case, the flex framework is handling the marshaling/unmarshaling process incorrectly, but these are not simple problems. Handling things like names, or dates is deceptively difficult.

>There's a big bucketload of tiny components there...

Are you sure that's a good thing? First, anything works when you have a small code-base, and a significant portion of JavaScript ecosystem involves building fairly small self-contained applications. I have a strong feeling micro-frameworks fail hard when the line count gets over a certain threshold.