graphic formats, social aspects of how langs are



On Jan 23, 12:32 pm, Thant Tessman wrote:
> I've been thinking about graphics file formats on and off for many years
> now. Somewhere along the way I figured out that people were thinking
> about the problem from the wrong point of view.
> The problem is that graphics file formats invariably have to let the
> semantics of the data they represent drive the syntax of the format. For
> example, geometric vertex position data usually--but not
> necessarily--takes the form of homogeneous arrays of 3-dimensional
> coordinates. Applications are forced to work within the semantic
> confines of the data structures the format can faithfully represent. If
> the format hopes to allow for the efficient parsing of data directly
> into memory, its design is forced to anticipate every kind of data its
> designers think might need to be stored.
> Invariably, designers are forced to create complex formats that never
> quite transcend an overly-specific approach to the development of
> computer graphics applications.
> What we need is not a file format, but a programming language--or at
> least something like a programming language. This programming language's
> job is merely to read in a 'program' and build the data structures
> described. It doesn't need to evaluate anything. It doesn't need control
> structures. It doesn't need functions. But it does need a type system.
> The end goal was always to provide the services of this 'language' as a
> highly-optimized C++ library, but on my third or fourth attempt to
> create just such a 'language' I decided to do a 'reference'
> implementation in Standard ML. What this bought me was a huge amount of
> confidence that there were no holes in the semantics or un-accounted-for
> corner cases in the design.
> The language is described here:
> http://www.thant.com/projects/dl/dl090117.pdf
> The SML 'reference' implementation is available here:
> http://www.thant.com/projects/dl/dl_sml_090122.tar.gz
> It builds for both SML/NJ and MLton.
> Data Language can be thought of as playing the role that XML plays in
> the Collada standard, only it's more efficient, easier to implement,
> safer, and can be described in a dozen pages instead of a hundred. And I
> can't help but think that even my SML implementation is far more
> efficient than any XML library written in C. The Collada standard
> explicitly states that it is not a "run-time delivery format" or
> "streaming-friendly." But my C++ implementation of my "Data Language" is
> already serving as exactly that.
> Although I do have some experience with XML, I'm no expert. What am I
> missing? What is the use of XML for these kinds of things buying people?
> -thant

I scanned your doc and read your message, but i don't quite understand your idea clearly. It appears to me, you Data Language (DL) is just a lean version of XML. (as one way to put it)

here's some thought about this topic ...

things that happen in the industry or academia has a strong, not neglect-able social causes. It might be obvious, that some language X, protocols Y, etc, is clearly technically superior, yet nobody seems to thought of it, invented it, or use it, while the industry and everyone is using or talking about Z and its variants. If one puts social aspects into this equation, many such mystery dissolves.

if i understand your case correctly... note that the concept of XML was due to the popularity of HTML, and was born as a effort to cleaned up HTML, when HTML hit the world big time with once known as World Wide Web in the 1990s. (HTML itself is borne out of SGML, which is quite complex) Once XML with its regularity of syntax came into broad awareness among tech people, large number of ideas and movement happened... you have a bunch of XML related technologies (RSS, XSLT, the whole Ajax related protocols, too many to list)

few years ago, it was popularly thought among lisp fanatics, that the world finally got the sexp idea and copied lisp to have XML. But lisp syntax is not regular. XML is. (and Mathematica is) Once you have a pure uniform syntax that can trivially parsed, the ideas of the its power spread and lots of tech based on it comes into being, as we see with the case of XML. (note that the many tech development derived from XML happened similarly to Mathematica since 1996 with Mathematica 3)

For details on this, the implication and consequences of a regular syntax, see:

• Fundamental Problems of Lisp

Now, given XML, we notice that it is EXTREMELY verbose. Verbose to the point that in puts significant burden to even machines. One wonders, that XML could simply have a lisp like syntax. For example:

<link rel="alternate" href="xyz"/>

could simply be:

(title a)
(id b)
(updated 2009-01-24T20:39:02-08:00)
(summary c...)
(link rel:alternate href:xyz)

this would be clearly superior. (any tech problem, such as easy conflict of data string with the demilitor, can be easily mended by several ways. (e.g. JSON, due to javascript and xml influence, is a format similar to the above))

However, consider the social and historical factor, things just happened the way they happened. In retrospect, one can always spot lots flaws that seems obvious.

In regard to your idea, i think similar reason apply. Sure, your DL may be superior. The world doesn't know about it, and probably doesn't need it. Unless, perhaps you started a movement, and if successful, than perhaps all future graphics data will be in DL, and you write a page of history.

On the subject of graphics format... here's some of my grievances. I always hated OpenGL. The incomprehensible, low level, hardware based, speed oriented, C unix style type of shit. I wanted a high level graphics lang.

Around 1995, Apple tried to do something about it. The result is

and subsequently, SGI, HP, Microsoft followed with
Fahrenheit graphics API

for complex social reasons (Apple was in the verge of bankruptcy; fighting among the corporations) history be what it is, these fall off the planet earth. We are stuck with the fucking “free & OpenSoure” OpenGL garbage, and DirectX low level fuck.

• Graphics Programing Pains

You might also be interested in:

• Requirements For A Visualization Software System For 2020

∑ http://xahlee.org/