I have been developing in Microsoft Dynamics AX 4.0 for about 2 years. 2 years and I still find myself banging my head against my desk trying to get things done. DAX tends to have a tendency to do things without you telling it to do anything, and conversely, you can tell it to do something and it flat out won't carry out your command. A lot of this is the result of DAX trying to make things easier by taking the wheel, but really makes things harder for the developer trying to add functionality.
As a developer, just recently out of college, it is hard to adjust to an environment like this. In college, everything is presented and carried out in a precise and logical fashion, the good old days when the expectations matched the outcomes. I understand there is a learning curve when leaving the books and entering the business world, but my gosh have I seen some very strange and unexplainable behaviors within the MorphX environment in DAX.
Truthfully, I like the theory behind DAX and what it (could/is suppose to) be, it was truly way ahead of its time. I like the AOT and making everything "object-oriented" in a tree structure (to an extent). It is meant to cut down on maintainability by sharing attributes and processes, similar to inheritance in object-oriented classes. But, by doing so, it creates many more dependencies, and with more dependencies you cut into the ease of customization, it really becomes a step backward.
After writing code in IDEs like Visual Studio, Eclipse, NetBeans, BlueJ, etc...you can't help but to think you are in the stone age when moving to a MorphX environment. Inconsistent behaviors is something to expect when working in MorphX; everything from version control to drag and drop seems more like a child and that it chooses when to listen to you.
However, the more and more I work with it, the more I seem to uncover about it. Using various debugging tools like SQL Server Profiler, I am able to see the underpinnings of its quirky-like behavior. I see Dynamics as a great challenge and a great area to grow with and get a better understanding of how it works. I can easily see myself entering into the consulting world with expertise in this software. From a job economic standpoint, there is much more demand for a good AX developer than it is supplied, much less than other developers in .NET or Java.