On Thu, 29 Nov 2012 10:57:48 -0500 Ted Trask <ttrask01_at_yahoo.com> wrote:
> The proposed ACF2 seems to be a complete redesign to move from
> functional to data-driven design. Unfortunately, the doc does not
> give any reasons why this change is desired. What is the benefit?
> This change does not address any of the goals listed below. Just as a
> style preference, I've always been a C/functional design guy, rather
> than C++/object-oriented guy. I find object-oriented design more
> difficult to read and debug.
I would recommend you trying one declarative language before condemning
the programming paradigm.
Curiously - all new GUI languages are declarative by nature. QT has QML,
Microsoft did XAML, etc. Having tried both before mentioned languages along
with the traditional imperative GUI toolkits (e.g. MFC, GTK, wxWidgets,
Qt/classes). I have to admit that I see the benefit of declarative
paradigm for UI use.
Though, ACF is ultimately about configuration management, which to my
first impression is pure data modelling problem. And as such, I would
be tempted at least see how the data-driven model looks like.
All problems are solveable with any programming paradigm. But if you
choose the correct programming paradigm for your problem, you end up
writing less code, less bugs, and have less maintenance overhead.
One practical example: there was recent changes in ACF on 2.4->2.5 - and
I actually had to spend 8 hours fixing my two simple ACF modules because
the core libraries got changed in ways that appear only imperative
programming - problem which would not have appeared if ACF was
There are valid reasons for both ways. But they are not just "style
issues". Please try some declaritive language to see how they work.
Received on Thu Nov 29 2012 - 22:02:45 UTC