October 4, 2013
I see two challenges: 1. There is not feature pari…
Craig Martin - Oct 3, 2013
I see two challenges:
1. There is not feature parity between the two types of sync rules
2. The imperative support (VBA) in the new sync rules is limited and difficult to debug
My wish is that we had better extensibility in the new sync rules (scrap VBA, or figure out how to improve the extensibility and debugging).
Also, choosing between declarative or imperative is a bad choice because you’ll always need bits of both. PowerShell is a good example, in the new Desired State Configuration feature:
http://www.powershellmagazine.com/2013/07/05/imperative-versus-declarative-syntax-in-powershell/
This is a very technical comparison. Let’s look at other arguments.
• Skilled people for declarative are easier to find. Software writers are scares.
• The portal knows the sync, but not vice versa. So Understanding the whole logic is much easier when using Declarative.
• Are we integrators or a software house? We don’t write our own virus scanner, do we?
• Reporting over Declarative is OOTB. Reporting over Classic is not available.
• Clients dislike these DLLs where all the “secret stuff” is.
• While it’s true that classic can do anything, that’s also the problem. If you look at the code you will often find some very creative stuff… I would lough if it wasn’t me.
• Judging by the development since ILM 2007, the future is Declarative. Who wants to be left behind?
I think I get your perspective, Guy; you prefer a system that is easier to build and operate, and your priority is not extensibility. That sounds reasonable, but I think the goals are not exclusive. Maybe someday we’ll have both, but in the interim Microsoft agrees with you ;-)