On 11/17/2012 12:26 PM, Kevin Kofler wrote:
Przemek Klosowski wrote:
Remember also that data is code: any config files could be seen as tiny
specialized interpreted languages, so it's not like you can avoid
interpretation anyway.
That's a bad view of things, it leads to WTFs like PolicyKit using rules
written in JavaScript. A simple key-value store is not and should not be
Turing-complete, or even anywhere near Turing-complete. The logic needs to
be in the native code, not in the configuration.
You say it yourself---if you need Turing, you have to put him in
somewhere. You argue that the complex logic HAS to go in the native
code, but that is inflexible. PolicyKit needed flexibility so they used
weird data; they combined inflexibility of native code with
inscrutability of complex logic in interpreted input. Plus they still
have a run-time and maintenance overhead of the interpreter, which they
were trying to avoid by designing a native code implementation.
Interpreters do not preclude simple data: they just scale better, from
simple linear declarative data to complex, Turing-cranking swamp. The
only argument against it is runtime overhead, which isn't a problem in
many, if not most, cases.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
