I think FOSI was ahead of its time. In the early 90s, its declarative nature was unfamiliar, and its structured markup foundation was unappreciated.If FOSI had come on the scene later as an XML application called Document Formatting Markup Language, it would have been better understood. Think SVG.
I think declarative languages are the future. They can be standardized, open source, and vendor neutral.Describing the problem and letting the software handle the solution increases productivity and provides a significant cost-saving advantage over imperative languages becauseoptimization is handled by the software, not the developer. So whether the developer is a newbie or an expert, the application always runs at maximum speed, with no need for expert consulting to try to speed it up.
Don't get me wrong -- expert consulting has its place. But not in lieu of business-friendly built-in efficiencies, such as those offered by declarative languages.
Consider the sample APP Styler source edit for boxing. It is about 30 lines of JavaScript, including comments, that tells the software how to draw a box step by step. The FOSI equivalent is one line of code that describes what is wanted:<boxing toffset="3pt" boffset="4pt" loffset="2pt" roffset="2pt"thick="1pt" inclr="#F0F0F0"/">.That is all that is needed because the TeX-based software already knows how to draw a box.
Doesn't it seem like a giant step backward to have to code 30 lines instead of one to produce the same output?
Some people, however,have a strong preference for imperative languages andhave a real problem with declarative languages. Following are excerpts fromImperative vs Declarative, byJavaScript developerPhilip Roberts,related to this. [emphasis mine]
Let's generalize and say that there are two ways in which we can write code: imperative and declarative.
We could define the difference as follows:
- Imperative programming: telling the "machine"(computer/database/programming language/etc)how to do something, and as a result what you want to happen will happen.
- Declarative programming: telling the "machine" what you would like to happen, and let the computer figure out how to do it.
...
A great example of a declarative abstraction isd3.js. D3 is a library that helps you build interactive and animated visualisations of data using JavaScript and (typically) SVG.
The first time (and fifth time, and possibly even the tenth time) you see or try and write d3 code your head will hurt. Like SQL, d3 is an incredibly powerful abstraction over visualising data that deals with almost all of thehowfor you, and lets you just say what you want to happen.
...
Look through the code again and think about whether we are describing what we want our visualisation to look like, or how to draw it? You'll see that there is almost no how code at all. We are just describing at quite a high level what we want:
I want this data drawn as circles, centered on the point specified in the data, and if there are any new circles you should add them and animate their radius.
This is awesome, we haven't written a single loop, there is no state management here. Coding graphics is often hard, confusing and ugly, but here d3 has abstracted away most of the crap and left us to just specify what we want.
Now, is d3.js easy to understand? Nope, it definitely takes a while to learn. And most of that learning is in giving up your desire to specify how things should happen and instead learning how to specify what you want.
Initially this is hard work, but after a few hours something magical happens - you become really, really productive. By abstracting away the how d3.js really lets you focus on what you want to see, which frankly is the only thing you should care about when designing something like a visualisation. It frees you from the fiddly details of the how and lets you interact with the problem at a much higher level, opening up the possibilities for creativity.
...
Declarative programming allows us to describe what we want, and let the underlying software/computer/etc deal with how it should happen.
In many areas, as we have seen, this can lead to some real improvements in how we write code, not just in terms of fewer lines of code, or (potentially) performance, but by writing code at a higher level of abstraction we can focus much more on what we want, which ultimately is all we should really care about as problem solvers.
The problem is, as programmers we are very used to describing the how. It makes us feel good and comfortable - powerful, even - to be able to control what is happening, and not leave it to some magic process we can't see or understand.
...
But frequently we can, and I'd argue should, look for declarative approaches to writing code, and if we can't find them, we should be building them. Will it be hard at first? Yes, almost certainly! But as we've seen with SQL and D3.js the long term benefits can be huge!
Suzanne Napoleon
www.FOSIexpert.com"WYSIWYG is last-century technology!"
