the future of F#

The very interesting session from PDC10 related to the future of F# - Microsoft functional-object-imperative variance of OCAML.

They are extending application with "type providers", which allow to extend static type system of F# with dynamically generated types withoun explicit code generation - by implementation of a very simple interface.

I think it can be useful techique to implement business platforms such as LightSwitch (when it come to C#) - LightSwitch authors can just implement type provider for entities and do not generate very much intermediate code.

PS. I think there is aplso enteresting how easy Don manipulates various data in F# interactive

DLR & X++

About a week ago Microsoft has announced the new technology named DLR. As far as I know, this is a layer for dynamic languages support on top of .NET framework. I watched the very interesting video where integration of Python, Ruby and JScript is shown.

But what can it give to Dynamics Ax?

I think X++ have some features of dynamic languages.

For example, method identification is being done via method names, not some kinds of method ids (i.e. virtual methiod table indexes like C++). If you write code like

MyClass x;
;
x.myMethod();

compiler checks that class MyClass have method myMethod, runtime checks, that object x has method myMethod, but run time does not check whether x is instance of MyClass.

So you can write something like

MyOtherClass y=...;
Object o=y;
MyClass x=o;
;
x.myMethod();

the code will be executed successfully if MyOtherClass have method myMethod, even if MyOtherClass and MyClass have no common superclass.

Such tricks are used with forms (for example ; Tabax plugin SDK is using it also to provide compiler checks for tabax service methods usage).

So if Microsoft is planning to move Dynamics Ax to .NET platform, they should provide support for such behaviour for the backward comapatibility.

I think the work being done on DLR can be used in such case. Jim Hugunin, architect of DLR and and the author of IronPython says (see video mentioned above), that this implementation of the Python language outperform original C implementation (CPython) and runs 2 times faster on standard benchmarks. He also pays extremely high attention on backwards compatibility (for example, you can not use .NET object methods in IronPython code until you place "import clr" statement in your code).

I think when this job will be done and authors of DLR will find and mitigate dynamic languages problems in DLR and SilverLight, the result of the job can be used in the future dynamics products.

PS. I played some time with IronPython and found though it have pretty good perormance in requires a lot of time to initialize an engine and load a script.

customization: do it smarter

If you haven't watched the video Dynamics AX 4.0 - Smart customizations - watch it! (especally if you are novice Dynamics Ax developer).

I can just add few thoughts:

First of all - this sceencast recommends to subclass existing class, but i thing there asre some cases when it is better to tweak existing class. The most often case - when existing class has bad structure (for example LedgerJournalCheckPost in 3.0 - i don't know about 4.0 so much). If you have one large method which does all you can not just overide it to add some functionality - you often have to copy all it's body to the child and tweak it. I you do so you will have more problems when upgrading to the next version: you have not only to upgrade method of existing parent, but to modify all copied parts of the child and there is no obvious clues to find what parts to modify.

Second, what can be done to make upgrades less painful:

• Interfaces - there havte to be more documented interfaces - so Ax devs will know what they can change and what cannot to make Ax backward compatible.
  
• Unit tests as part of Ax package - all unit tests developed by Ax team have to be shipped with Ax to enable partner or customer developers ensure they haven't breaked anything
  
• Events - SAP R/3, as i know, have concept of events - you have not to modify existing code to be informed about some thing ocuured in system - you just subscribe, say, to journal posting and can make extra transaction if you want. So your customisation code isn't mixed with the existing code.
  
• Better code structure - i think there is no excure for very big methods for example. Better code structure can be easy reused by customer programmers and can be seft documented and testable.