Stephen asked that I explain my philosophy on declarative programming.
Programming involves a lot of declarative data:
configuration
messages b/w threads/processes/devices
application data
build directives
UI layout
rules for an expert engine
The list goes on forever.
In the Java and C# world this information is typically pulled out into XML. This sucks because there is serious impedance mismatch between Java/C# and XML. What is the standard way to map Java data to XML? Well JAX, Ant, Swing, util.prefs, etc all have a different "mapping". It is completely ad hoc. Quite likely every developer has written several custom mappings. I know I've written a couple dozen myself. If you are working with multiple languages then XML can be a good thing. But within a Java or .NET environment it is a complete waste of mental effort.
So after Java/.NET portability, declarative programming was one of my top priorities. A key requirement was that Fan support a built-in serialization syntax which:
just worked on any object with the appropriate facet tagging
gave you the ability to write atomic serialized types
was text based for humans to read/write
maintains Fan's type system
leveraged the same primitive syntax for ints, floats, strings, etc
was a true subset of the language so that an serialized object could be used as an expression
was flexible enough to be used in another language like Java, C#, JavaScript etc (just like JSON can be used in any other language)
defined a standard tree walking model for generating other formats such as JSON or XML
I designed the serialization syntax first, then figured out how to create the necessarily language constructs to support it as a subset. This is how with-blocks were born. They seemed a natural general purpose mechanism to support "serialization as an expression".
I think these requirements have been achieved quite elegantly. We obviously have run into issues with post-construction validation, but that is to be expected of any declarative solution. I think the FWT code really illustrates how powerful Fan's declarative programming can be:
UI tools can just serialize their state via OutStream.writeObj
the results can be loaded from a text file via InStream.readObj
or the results could just be pasted into code directly
It is pretty cool stuff!
tompalmerSun 20 Jul 2008
I agree it's cool.
On the JSON subject, at least in that case, I actually dislike it being a subset of JavaScript, just from the basis that people use full JavaScript (or at least slight JSON incompatibilities due to using nicer JavaScript syntax) and still call it "JSON". When people are sloppy enough, it adds to security risks. Maybe wouldn't be an issue with Fan, but it might be worth at least keeping in mind.
brianSun 20 Jul 2008
What Fan fixes about JSON is that it there is a very clear separation between a script you can evaluate and a serialized object which is purely declarative.
brian Sat 19 Jul 2008
Stephen asked that I explain my philosophy on declarative programming.
Programming involves a lot of declarative data:
The list goes on forever.
In the Java and C# world this information is typically pulled out into XML. This sucks because there is serious impedance mismatch between Java/C# and XML. What is the standard way to map Java data to XML? Well JAX, Ant, Swing, util.prefs, etc all have a different "mapping". It is completely ad hoc. Quite likely every developer has written several custom mappings. I know I've written a couple dozen myself. If you are working with multiple languages then XML can be a good thing. But within a Java or .NET environment it is a complete waste of mental effort.
So after Java/.NET portability, declarative programming was one of my top priorities. A key requirement was that Fan support a built-in serialization syntax which:
I designed the serialization syntax first, then figured out how to create the necessarily language constructs to support it as a subset. This is how with-blocks were born. They seemed a natural general purpose mechanism to support "serialization as an expression".
I think these requirements have been achieved quite elegantly. We obviously have run into issues with post-construction validation, but that is to be expected of any declarative solution. I think the FWT code really illustrates how powerful Fan's declarative programming can be:
OutStream.writeObjInStream.readObjIt is pretty cool stuff!
tompalmer Sun 20 Jul 2008
I agree it's cool.
On the JSON subject, at least in that case, I actually dislike it being a subset of JavaScript, just from the basis that people use full JavaScript (or at least slight JSON incompatibilities due to using nicer JavaScript syntax) and still call it "JSON". When people are sloppy enough, it adds to security risks. Maybe wouldn't be an issue with Fan, but it might be worth at least keeping in mind.
brian Sun 20 Jul 2008
What Fan fixes about JSON is that it there is a very clear separation between a script you can evaluate and a serialized object which is purely declarative.