Slashdot Mirror

While Go and Swift are interesting incremental improvements, they are not taking into account what we learned about programming languages. In many ways, these two languages seem firmly stuck in the 1980s. For example, Go has no generics, and as far as I can tell, Swift still does not have the kind of true generic types I introduced in XL in 2000, i.e. the possibility to call "ordered" all types that have a less than, and then define functions with "ordered" instead of having to use <T> all over the place just like in C++ (and please, could we stop using angle brackets?)

More generally, there was a lot to be learned from more dynamic languages deriving from Lisp. Being able to treat code as data (homoiconicity) completely changes things. It means your language can be extended in itself, just like Lisp integrated object-oriented capabilities effortlessly. It means you can do metaprogramming, introspection, reflection, dynamic code generation, in a natural way rather than with specialised ad-hoc features. All things that Go or Swift spectacularly fail to do.

A real language redesign does not bring you incremental benefits, it should bring orders of magnitude on many tasks. I speak from experience. In XL, I can do complex arithmetic in 11 lines of code. What about Swift or Go? Ask yourself why Go can't offer complex arithmetic as a library package? Similarly, in Tao3D, I can do things HTML5 just can't, in a much less verbose, much higher-level language, and simple animations take 30 times less code than in JavaScript. The 30x factor tells me that I invented something new. Many others can demonstrate similar innovation.

I fail to see benefits of a similar order of magnitude with Swift or Go, and it annoys me. Companies like Apple and Google have the means, if only the financial ones, to make bigger things happen, in particular when smaller teams like ours already did a lot of investigative work.

While Go and Swift are interesting incremental improvements, they are not taking into account what we learned about programming languages. In many ways, these two languages seem firmly stuck in the 1980s. For example, Go has no generics, and as far as I can tell, Swift still does not have the kind of true generic types I introduced in XL in 2000, i.e. the possibility to call "ordered" all types that have a less than, and then define functions with "ordered" instead of having to use <T> all over the place just like in C++ (and please, could we stop using angle brackets?)

More generally, there was a lot to be learned from more dynamic languages deriving from Lisp. Being able to treat code as data (homoiconicity) completely changes things. It means your language can be extended in itself, just like Lisp integrated object-oriented capabilities effortlessly. It means you can do metaprogramming, introspection, reflection, dynamic code generation, in a natural way rather than with specialised ad-hoc features. All things that Go or Swift spectacularly fail to do.

A real language redesign does not bring you incremental benefits, it should bring orders of magnitude on many tasks. I speak from experience. In XL, I can do complex arithmetic in 11 lines of code. What about Swift or Go? Ask yourself why Go can't offer complex arithmetic as a library package? Similarly, in Tao3D, I can do things HTML5 just can't, in a much less verbose, much higher-level language, and simple animations take 30 times less code than in JavaScript. The 30x factor tells me that I invented something new. Many others can demonstrate similar innovation.

I fail to see benefits of a similar order of magnitude with Swift or Go, and it annoys me. Companies like Apple and Google have the means, if only the financial ones, to make bigger things happen, in particular when smaller teams like ours already did a lot of investigative work.

While Go and Swift are interesting incremental improvements, they are not taking into account what we learned about programming languages. In many ways, these two languages seem firmly stuck in the 1980s. For example, Go has no generics, and as far as I can tell, Swift still does not have the kind of true generic types I introduced in XL in 2000, i.e. the possibility to call "ordered" all types that have a less than, and then define functions with "ordered" instead of having to use <T> all over the place just like in C++ (and please, could we stop using angle brackets?)

More generally, there was a lot to be learned from more dynamic languages deriving from Lisp. Being able to treat code as data (homoiconicity) completely changes things. It means your language can be extended in itself, just like Lisp integrated object-oriented capabilities effortlessly. It means you can do metaprogramming, introspection, reflection, dynamic code generation, in a natural way rather than with specialised ad-hoc features. All things that Go or Swift spectacularly fail to do.

A real language redesign does not bring you incremental benefits, it should bring orders of magnitude on many tasks. I speak from experience. In XL, I can do complex arithmetic in 11 lines of code. What about Swift or Go? Ask yourself why Go can't offer complex arithmetic as a library package? Similarly, in Tao3D, I can do things HTML5 just can't, in a much less verbose, much higher-level language, and simple animations take 30 times less code than in JavaScript. The 30x factor tells me that I invented something new. Many others can demonstrate similar innovation.

I fail to see benefits of a similar order of magnitude with Swift or Go, and it annoys me. Companies like Apple and Google have the means, if only the financial ones, to make bigger things happen, in particular when smaller teams like ours already did a lot of investigative work.

Thought for the day: whenever designing something for other people to use, you should take all feedback from your potential users and prove to yourself why the feedback is correct before attempting to show the giver why it's wrong.

Why? Firstly, because nobody will give you any feedback at all if your default response is to prove to everyone that their feedback is so valueless to you (and if you don't want feedback, then this whole thread is just self-promotion, which isn't popular here).

Secondly, because we all make mistakes, so there are bound to be things in our work that are suboptimal. Admitting to yourself that there is a mistake doesn't necessarily mean having to change it -- if you honestly assess the impact of the mistake and say it's something your happy to live with, great. But it has to be a conscious decision, not denial of the problem.

Thirdly, both sides can be right, and often are. If our disagreement comes from different assumptions and use cases, you might find that if you open the dialogue (rather than shouting "FUD"), you might hear of a problem you hadn't thought of. You need to see it from not only the angle you choose to follow, but also the angle you have already rejected.

Now...

I don't like subroutine names that include something that looks like a parameter, so things like rotatex and rotatey set me on edge a bit.

If you prefer, you can use the plain rotate. But rotating along X, Y or Z is frequent enough to deserve a shortcut. Not different from CSS transform, by the way.

It gets worse when this is inconsistent, and you see a subroutine called vertical_align for vertical alignment, where the seeming parameter (vertical) is now before the generic (align), and separated by an underscore instead of run together. Not only is this an internal inconsistency, but it's inconsistent with English, as "align" is a verb, and we would put in an adverb "vertically" after the verb normally. And then it gets worse again, as the command for horizontal alignment is... "align".

You are right, align_vertically would be more sensible. Exercise for you: fix it ;-)

Exercise for you: go **** yourself. That's just patronising. I'm giving you feedback, and the implication of your statement -- regardless of the smiley -- is that my feedback is valueless if I'm not willing to code it up myself. I'll say it again: if you want feedback, don't tell people you don't care about their feedback.

As for align, that's the common case, so I'd rather keep it that way.

[Citation needed] If we were just talking about text flow in a 2D page, I would agree with you, but there's so much geometry in here, I personally don't see any default.

The grammatical inconsistency continues with other commands/subroutines taking on names with no verb component at all (eg the command color, with no verb or assignment operator.

That derives from OpenGL, which has glRotate and glTranslate, but glColor and not glColorize. BUT it's not inconsistent. It's actually fairly smart. The color is an attribute, and glColor just sets it. So the name is the name of the attribute you set. glRotate and glTranslate modify an attribute (the current model/view matrix), so they are verbs.

I understand that, but it's wrong. I know a lot of people laugh at the idea of using setColor and getColor as per so many OO style guides, but really, you either need to use assignments or use verb-based names, or the syntax is broken from a human cognitive perspective. It is very difficult to reason about a grammar

I don't like subroutine names that include something that looks like a parameter, so things like rotatex and rotatey set me on edge a bit.

If you prefer, you can use the plain rotate. But rotating along X, Y or Z is frequent enough to deserve a shortcut. Not different from CSS transform, by the way.

It gets worse when this is inconsistent, and you see a subroutine called vertical_align for vertical alignment, where the seeming parameter (vertical) is now before the generic (align), and separated by an underscore instead of run together. Not only is this an internal inconsistency, but it's inconsistent with English, as "align" is a verb, and we would put in an adverb "vertically" after the verb normally. And then it gets worse again, as the command for horizontal alignment is... "align".

You are right, align_vertically would be more sensible. Exercise for you: fix it ;-) As for align, that's the common case, so I'd rather keep it that way.

The grammatical inconsistency continues with other commands/subroutines taking on names with no verb component at all (eg the command color, with no verb or assignment operator.

That derives from OpenGL, which has glRotate and glTranslate, but glColor and not glColorize. BUT it's not inconsistent. It's actually fairly smart. The color is an attribute, and glColor just sets it. So the name is the name of the attribute you set. glRotate and glTranslate modify an attribute (the current model/view matrix), so they are verbs. Unwittingly, I applied the same logic for things that change the color state, e.g. show. Since show changes the color state, it is a verb.

I'm really not happy with the way pattern matching is used as overloading ...because you can get yourself in a mess if you split it up into different parts of the code and accidentally overwrite stuff.

How is this different from overloading? That's a FUD argument. In reality, its distributed nature is exactly what makes the construct powerful. It offers a very flexible dynamic dispatch mechanism.

For example, the Slides module draws a background for slides using theme_background. That function is provided by the default theme. But most themes will override it.

In general, this override happens only on part of the pattern. For example, most slide elements are defined by (theme, master), sometimes (theme, master, style). The "master" is the equivalent of the Powerpoint "slide master", i.e. it defines the layout, etc. If you define a new theme, you'll typically define overrides that catch everything for a given theme (e.g. for "BrightRectangles" in the last link). But you may also want to override for a specific combination.

I'm completely baffled why the whole demo recreates the shapes for every single redraw frame rather than keeping them as persistent objects (which necessitates adding a random seed in order to fake them being persistent by pulling up the same colours each time.

The Tao3D drawing model is a feature, not a bug. If you write rectangle 0, 0, 320, 200, it draws the rectangle once, and that's

I don't like subroutine names that include something that looks like a parameter, so things like rotatex and rotatey set me on edge a bit.

If you prefer, you can use the plain rotate. But rotating along X, Y or Z is frequent enough to deserve a shortcut. Not different from CSS transform, by the way.

It gets worse when this is inconsistent, and you see a subroutine called vertical_align for vertical alignment, where the seeming parameter (vertical) is now before the generic (align), and separated by an underscore instead of run together. Not only is this an internal inconsistency, but it's inconsistent with English, as "align" is a verb, and we would put in an adverb "vertically" after the verb normally. And then it gets worse again, as the command for horizontal alignment is... "align".

You are right, align_vertically would be more sensible. Exercise for you: fix it ;-) As for align, that's the common case, so I'd rather keep it that way.

The grammatical inconsistency continues with other commands/subroutines taking on names with no verb component at all (eg the command color, with no verb or assignment operator.

That derives from OpenGL, which has glRotate and glTranslate, but glColor and not glColorize. BUT it's not inconsistent. It's actually fairly smart. The color is an attribute, and glColor just sets it. So the name is the name of the attribute you set. glRotate and glTranslate modify an attribute (the current model/view matrix), so they are verbs. Unwittingly, I applied the same logic for things that change the color state, e.g. show. Since show changes the color state, it is a verb.

I'm really not happy with the way pattern matching is used as overloading ...because you can get yourself in a mess if you split it up into different parts of the code and accidentally overwrite stuff.

How is this different from overloading? That's a FUD argument. In reality, its distributed nature is exactly what makes the construct powerful. It offers a very flexible dynamic dispatch mechanism.

For example, the Slides module draws a background for slides using theme_background. That function is provided by the default theme. But most themes will override it.

In general, this override happens only on part of the pattern. For example, most slide elements are defined by (theme, master), sometimes (theme, master, style). The "master" is the equivalent of the Powerpoint "slide master", i.e. it defines the layout, etc. If you define a new theme, you'll typically define overrides that catch everything for a given theme (e.g. for "BrightRectangles" in the last link). But you may also want to override for a specific combination.

I'm completely baffled why the whole demo recreates the shapes for every single redraw frame rather than keeping them as persistent objects (which necessitates adding a random seed in order to fake them being persistent by pulling up the same colours each time.

The Tao3D drawing model is a feature, not a bug. If you write rectangle 0, 0, 320, 200, it draws the rectangle once, and that's

I looked at the link you mentioned in another post: http://www.taodyne.com/shop/de...
"Taodyne's current technology is written in C++. It uses Qt for the user interface, and OpenGL for the drawing code. It also uses other components that might be a bit difficult to adapt to a web environment, notably LLVM. We can think of a few possible strategies to adapt this technology to the web: ..."

For a port to the web, you could try asm.js and emscriptem:
http://en.wikipedia.org/wiki/A...
http://en.wikipedia.org/wiki/E...

Here is an example:
https://blog.mozilla.org/blog/...
"Mozilla and Epic Games have showed the power of the Web as a platform for gaming by porting Unreal Engine 3 to the Web and showcasing Epic Citadel, using asm.js, a supercharged subset of JavaScript pioneered by Mozilla. In less than 12 months, optimizations have increased the performance of Web applications using asm.js from 40% to within 67% of native, and we expect it to get even faster. This performance opens up new opportunities for giving users an astonishing and delightful experience, from within their choice of Web browser. Any modern browser can run asm.js content, but specific optimizations currently present only in Firefox, ensure the most consistent and smooth experience. "This technology has reached a point where games users can jump into via a Web link are now almost indistinguishable from ones they might have had to wait to download and install," said Brendan Eich, CTO and SVP of Engineering at Mozilla. "Using Emscripten to cross-compile C and C++ into asm.js, developers can run their games at near-native speeds, so they can approach the Web as they would any other platform.""

You could also help Chrome improve its asm.js speed and get at least two major browser to have better 3D support, which would help everyone. Why not ask Google for some funding to do that, building on what you have so far? Good luck!!!

Where did you see an example of the language? The links went to sourceforge (I didn't want to install the package just to see the language) and a marketing video.

There are a few code examples in the marketing video. There are several additional examples on the Taodyne web site, but I'm pretty sure it can't take a slashdotting.

I'm curious how anyone thought that if/then/else was a difficult enough construct in popular languages such that it needed improving. I mean, it's a couple of lines of code in *any* language, isn't it? Anyone know how this language supposedly improved on the concept?

The idea is that in other languages, if-then-else is a built-in construct. You can't do something similar yourself without hacking the compiler. In Tao3D, if-then-else is a library element like printf in C. So you can change it.

Let's say you often use a specific kind of for loop. In Tao3D, you simply add the notation you need, and now your code is shorter and more concise. Once you decide that one of the language objectives is that you can extend it yourself and create your own domain-specific languages, it's obvious that a good test for that feature is to use the basic programming language constructs found in other languages, like if-then-else or for loops.

So, functions are first class data members? Is it weakly typed then, like Lua? In that language, defining a function is just syntactic sugar for assigning a chunk of code to a variable of the assigned name, so you can use it just like any other variable.

The part that is always verbose in existing functional languages (except maybe Lisp) is how you pass code to another function. For example, in Javascript, you'd pass a callback with 'function() { ... }'. In Tao3D, I got rid of everything but ..., and the language is smart enough to figure things out. This means that you can define a slide by passing bullet points, and it almost looks like Markdown, whereas if I was in JavaScript, I would need layers and layers of code. This particular aspect is detailed in an article called "Storytelling, the web is doing it wrong"

In Tao3D, you define the notations you want first, you design the (domain-specific) language around your notations second. In existing languages, it's the other way round, the notation is imposed by the language you chose.

I'm also curious what this particular brings to the table that a library couldn't have accomplished. Learning a new language is a fairly big hurdle for someone to take to develop for a particular platform. Part of the reason I think we have so many computer languages is that programmers simply love writing new languages, not that it really solved any new problem. Nothing wrong with that, but then again, don't expect us to care unless there was a good reason for the new language.

That's a very good point. The reason for XLR (the language underlying Tao3D) was that we have to invent new languages all the time, not because we like to, but because existing languages are very bad at accepting something that is not already in their DNA. You could not get lambda functions in C++ until the language committee sat around a table, standardized it, and then all compiler vendors had to implement it. But if what you need is for example a notation for symbolic derivative, or a notation for slides, or a notation for a specific kind of for-loop, you are stuck. So progress in programming languages is very slow, because each language adds its own little features, but drops tons of other features that already exist in other languages.

The idea with XLR was to create a language where the fundamental process was extending the language. And Tao3D is an example of a relatively large scale domain-specific language (specifically around 3D and animations). Most of it is precisely in a library. But you wouldn't know from using it. It feels "native".

Where did you see an example of the language? The links went to sourceforge (I didn't want to install the package just to see the language) and a marketing video.

There are a few code examples in the marketing video. There are several additional examples on the Taodyne web site, but I'm pretty sure it can't take a slashdotting.

I'm curious how anyone thought that if/then/else was a difficult enough construct in popular languages such that it needed improving. I mean, it's a couple of lines of code in *any* language, isn't it? Anyone know how this language supposedly improved on the concept?

The idea is that in other languages, if-then-else is a built-in construct. You can't do something similar yourself without hacking the compiler. In Tao3D, if-then-else is a library element like printf in C. So you can change it.

Let's say you often use a specific kind of for loop. In Tao3D, you simply add the notation you need, and now your code is shorter and more concise. Once you decide that one of the language objectives is that you can extend it yourself and create your own domain-specific languages, it's obvious that a good test for that feature is to use the basic programming language constructs found in other languages, like if-then-else or for loops.

So, functions are first class data members? Is it weakly typed then, like Lua? In that language, defining a function is just syntactic sugar for assigning a chunk of code to a variable of the assigned name, so you can use it just like any other variable.

The part that is always verbose in existing functional languages (except maybe Lisp) is how you pass code to another function. For example, in Javascript, you'd pass a callback with 'function() { ... }'. In Tao3D, I got rid of everything but ..., and the language is smart enough to figure things out. This means that you can define a slide by passing bullet points, and it almost looks like Markdown, whereas if I was in JavaScript, I would need layers and layers of code. This particular aspect is detailed in an article called "Storytelling, the web is doing it wrong"

In Tao3D, you define the notations you want first, you design the (domain-specific) language around your notations second. In existing languages, it's the other way round, the notation is imposed by the language you chose.

I'm also curious what this particular brings to the table that a library couldn't have accomplished. Learning a new language is a fairly big hurdle for someone to take to develop for a particular platform. Part of the reason I think we have so many computer languages is that programmers simply love writing new languages, not that it really solved any new problem. Nothing wrong with that, but then again, don't expect us to care unless there was a good reason for the new language.

That's a very good point. The reason for XLR (the language underlying Tao3D) was that we have to invent new languages all the time, not because we like to, but because existing languages are very bad at accepting something that is not already in their DNA. You could not get lambda functions in C++ until the language committee sat around a table, standardized it, and then all compiler vendors had to implement it. But if what you need is for example a notation for symbolic derivative, or a notation for slides, or a notation for a specific kind of for-loop, you are stuck. So progress in programming languages is very slow, because each language adds its own little features, but drops tons of other features that already exist in other languages.

The idea with XLR was to create a language where the fundamental process was extending the language. And Tao3D is an example of a relatively large scale domain-specific language (specifically around 3D and animations). Most of it is precisely in a library. But you wouldn't know from using it. It feels "native".

Here are a few links:

Tao3D documents on Gitorious

Taodyne tutorials usually have the code corresponding to the videos. But I'm pretty sure our small server won't take a slashdotting. Use it while it lasts.

There are also a few examples in the source tree itself.

Well, as the author of the blog post, I did not intend this post to go on Slashdot. It was just a note-to-self about the various commands and build steps involved. Because they are, well, complicated.

In the grand scheme of things, the significance behind this is that I plan to open-source Tao, the 3D document description language invented by Taodyne, with the intent to be able to integrate it into at least one web browser. More details about why Tao would make a difference for the web here: http://www.taodyne.com/shop/de... (and in the follow up article). More details about how it works for a developer here: https://www.youtube.com/watch?....

Charles Simonyi, one of the creators of Microsoft Word, went on a crusade to enable "intentional programming", which is to programming what the WYSIWYG word processor was to LaTeX. You can see what he does here. This is a VERY hard problem to solve. Simonyi is a good programmer, has tons of money, yet this is not a battle that he has clearly won yet.

I once received a phone call at work from a Forbes journalist, saying that Simonyi had described my own pet project, XL (http://xlr.sf.net), and the associated "Concept Programming" ideas as one of the only competitors to Intentional Programming. That was interesting, because it shows that Simonyi had "groked" what I wanted to do, despite the total lack of polish of this little project. (As an aside, if you are curious, you can see XL in action in Taodyne's software to create interactive 3D documents)

But what Simonyi saw (I believe) is that the general questioning was similar. How do we transform ideas into code. For Simonyi, this can be done with graphical tools. For XL, this can be done with simple transformations on text (more precisely, on a Lisp-like parse tree generated from the text). For example, with XL, you can implement the "if-then-else" concept using the "->" (transforms into) operator as follows:

if true then X else Y -> X
if false then X else Y -> Y

With this approach, it is possible to use nice notations for arbitrary concepts. In Taodyne's products, for example, a slide is described by something like:

slide "Hello world",
        * "This is a bullet point"
        * "This is another one"

This pseudo-markup language is then rewritten recursively until we reach "primitive" operations, e.g. 3D graphics rendering or basic computations.

XL is based on text because a) it's easier to do than Simonyi's approach, and b) I think it is generally easier to read and write "globally". If you have a "picture" in a document, of course showing the picture tells you more than just its name. But knowing that there is a picture in a document is easy with something like image "Woman.jpg" or (in HTML) a img tag.

As the experience with HTML or Postscript demonstrated, text or graphical does not matter much anyway. It's possible to have a text-based representation of the code that most people manipulate graphically and never need to be aware of. You can generate your HTML with Word, never need to know anything about it. It's likely the same thing is slowly happening with code as well: IDEs tend to give you more and more meta-data which is "behind" the text and helps you navigate it or code faster.

Yes, it's possible to do better. But inventing new models is not easy, and it's an uphill battle.

Taodyne delivers Tao, a 3D dynamic document description language which is quite a departure from HTML + WebGL for building 3D contents.

Based on our experience, here are some of the key attributes you need for good 3D to take off on the web:

* Device independence, like PDF or HTML. 3D does not just mean 3D models, but also depth, stereoscopy. You don't want to have to care about the many 3D technologies out there, active, passive, auto-stereoscopic, holographic, whatever. Tao contents adapts transparently, and will look exactly the same on a 2D or 3D display, including 3D without glasses from Alioscopy, Tridelity or Dimenco/Philips. Of course, it degrades gracefully on a 2D screen just like PDF degrades gracefully on a black-and-white printer.

* Integration of text, 2D graphics, images, movies and 3D objects in the same 3D scene. We are very far from that in HTML + WebGL, where there is practically zero integration between 2D and 3D contents. In Tao, 2D graphics and text obey the same rotations, translation or scaling as 3D objects.

* Being able to mix pre-rendered / filmed 3D movies with real-time 3D contents. In Tao, you can have 3D movie appear on the screen of 3D model of a TV, with text on top of it, all rendered in real-time. And that scene will show correctly even on an Alioscopy screen in glasses-free 3D...

* The ability to directly read 3D assets and not just 2D assets. This is almost there for WebGL with Three.js, but still very far from the ease of use of the video tag. By contrast, in Tao, displaying a model that moves with my mouse is nothing more than:

import ObjectLoader
light 0
light_position 1000, 1000, 1000
rotatey 0.1 * mouse_x
object "MyModel.3ds"

Right now, Chrome Experiments are proud to announce "Not your morther's Javascript". We should not collectively take pride in having a web that's for experts only. We want to make things easier to create.

While the Taodyne 3D dynamic document description language is not available in browsers yet, we clearly see what we did as something that could be part of HTML6. We built it with that in mind. It's text based, and you can reference an URL in images, movies, etc. Actually, we would like nothing better than open-source the whole thing and integrate it with the WebKit, we just don't have the resources to do that at the moment. But if a good soul at Google or Apple is reading this, we can talk.

Taodyne delivers Tao, a 3D dynamic document description language which is quite a departure from HTML + WebGL for building 3D contents.

Based on our experience, here are some of the key attributes you need for good 3D to take off on the web:

* Device independence, like PDF or HTML. 3D does not just mean 3D models, but also depth, stereoscopy. You don't want to have to care about the many 3D technologies out there, active, passive, auto-stereoscopic, holographic, whatever. Tao contents adapts transparently, and will look exactly the same on a 2D or 3D display, including 3D without glasses from Alioscopy, Tridelity or Dimenco/Philips. Of course, it degrades gracefully on a 2D screen just like PDF degrades gracefully on a black-and-white printer.

* Integration of text, 2D graphics, images, movies and 3D objects in the same 3D scene. We are very far from that in HTML + WebGL, where there is practically zero integration between 2D and 3D contents. In Tao, 2D graphics and text obey the same rotations, translation or scaling as 3D objects.

* Being able to mix pre-rendered / filmed 3D movies with real-time 3D contents. In Tao, you can have 3D movie appear on the screen of 3D model of a TV, with text on top of it, all rendered in real-time. And that scene will show correctly even on an Alioscopy screen in glasses-free 3D...

* The ability to directly read 3D assets and not just 2D assets. This is almost there for WebGL with Three.js, but still very far from the ease of use of the video tag. By contrast, in Tao, displaying a model that moves with my mouse is nothing more than:

import ObjectLoader
light 0
light_position 1000, 1000, 1000
rotatey 0.1 * mouse_x
object "MyModel.3ds"

Right now, Chrome Experiments are proud to announce "Not your morther's Javascript". We should not collectively take pride in having a web that's for experts only. We want to make things easier to create.

While the Taodyne 3D dynamic document description language is not available in browsers yet, we clearly see what we did as something that could be part of HTML6. We built it with that in mind. It's text based, and you can reference an URL in images, movies, etc. Actually, we would like nothing better than open-source the whole thing and integrate it with the WebKit, we just don't have the resources to do that at the moment. But if a good soul at Google or Apple is reading this, we can talk.

We created a Gitorious project to share sample code. The first sample shows the location of earthquakes in real-time.

I must confess that I also missed the point. The headline of the submission focuses on the RSS feed in 3D, making me believe that it really is the "RSS feed" that is important. Perhaps you should frame this demo differently to convey your intent to the reader. "Create Dynamic 3D documents easily" sounds quite diffferent from "3D RSS reader" as a headline.

You are right I guess. I'll take that into account for my next Slashdot submission :-)

I looked as this tool as I would be interested in displaying my computer network / sysadmin type stuff dynamically in 3D. Stock market performance. That sort of stuff. But I can't see that this tool makes that easier.

Let's try making something like that together. Here's one way to do it:

1) Create a small web server somewhere that returns the stuff you are interested it, for example in CSV format. Say you get lines with X,Y,Z,"label".

2) Read that web server with Tao Presentations, using code that looks like this:

get_url_csv "http://myserver/data.csv", "drawit"
drawit X,Y,Z,Label ->
    locally
        translate X,Y,Z
        text Label
drawit MalformedInput -> false

Of course, your server could also send color, or a sphere diameter, so you could have something like:

drawit X,Y,Z,Color,Radius,Label ->
    locally
        translate X,Y,Z
        color Color
        sphere Radius
        translate Radius, 0, 0
        text Label

If you don't want to access the network to get your data, you can also read that from a local file. For example, you can have a Perl script that munches your input data and writes it to a given local file. Then, your Tao Presentations document does something similar to the above, but with load_csv instead of get_url_csv.

You could obviously send data in other formats and parse it with regexps (XML and JSON are coming soon, hopefully). But at the moment, CSV is by far the fastest way to read relatively big amounts of data for Tao Presentations. In this 3D star map example, we use that very technique to show about 15000 stars from the Hipparcos catalog, and it runs smoothly on a modern laptop.

I am pretty sure we have moved on from individual content viewers. If they were to process https://github.com/mrdoob/three.js/ designed applications and use some tagging to define a distance relocating the perspective then this might have a value.

There are frameworks such as Reveal.js or Impress.js that try to present things nicely using CSS3, HTML5, etc. Taodyne didn't use markup languages on purpose. From that article:

Standard markup, yes, but still a new language
On the surface, this structure is well known, so that you can leverage what you already know about HTML.

But notice how the two examples above don't use exactly the same syntax. There's a reason for that: in both cases, the power of that code really lies in additional definitions using Javascript and CSS 3D. We no longer use a really standard language, but some kind of dialect. We still need to learn this dialect before creating presentations.

It's not like the required code is extraordinarily big. For Impress.js, we are talking about 700 lines of CSS and 800 lines of Javascript. Reveal.js is slightly more extensive, with 1238 lines of CSS and 1039 lines of Javascript, not counting a few libraries.

However, that still means that you need to learn new semantics on how to build animations. The benefits of using a "standard" language are somewhat mitigated. More importantly, it means that what makes the presentation really different, the interesting 3D animations and transitions, are not in the document description itself.

A new kind of programming language designed specifically for real-time, interactive documents has a number of benefits. For example, we don't have a linear execution model. Parts of the document execute in response to events, transparently. That way, if you have a document that refreshes only once per second, we use practically no CPU. And if only this or that part of the document executes. See Execution and Drawing Model on this description of Tao documents.

I am pretty sure we have moved on from individual content viewers. If they were to process https://github.com/mrdoob/three.js/ designed applications and use some tagging to define a distance relocating the perspective then this might have a value.

There are frameworks such as Reveal.js or Impress.js that try to present things nicely using CSS3, HTML5, etc. Taodyne didn't use markup languages on purpose. From that article:

Standard markup, yes, but still a new language
On the surface, this structure is well known, so that you can leverage what you already know about HTML.

But notice how the two examples above don't use exactly the same syntax. There's a reason for that: in both cases, the power of that code really lies in additional definitions using Javascript and CSS 3D. We no longer use a really standard language, but some kind of dialect. We still need to learn this dialect before creating presentations.

It's not like the required code is extraordinarily big. For Impress.js, we are talking about 700 lines of CSS and 800 lines of Javascript. Reveal.js is slightly more extensive, with 1238 lines of CSS and 1039 lines of Javascript, not counting a few libraries.

However, that still means that you need to learn new semantics on how to build animations. The benefits of using a "standard" language are somewhat mitigated. More importantly, it means that what makes the presentation really different, the interesting 3D animations and transitions, are not in the document description itself.

A new kind of programming language designed specifically for real-time, interactive documents has a number of benefits. For example, we don't have a linear execution model. Parts of the document execute in response to events, transparently. That way, if you have a document that refreshes only once per second, we use practically no CPU. And if only this or that part of the document executes. See Execution and Drawing Model on this description of Tao documents.

These guys cannot even figure out how to reinstall display drivers on a Win 7 box and they want to sell me a rendering package? Not gonna happen.

RTFA. We did reinstall the display drivers, and they just don't work. Unless you think that having full screen rendering blinks unless the screen is upside down is not a bug in the driver. Seriously. And the problem only exists on this particular ATI driver, never had that with the original driver or with nVidia...

These guys cannot even figure out how to reinstall display drivers on a Win 7 box and they want to sell me a rendering package? Not gonna happen.

For the slashdotter with more experience: Can 3d Stereo be achieved with regular commodity LCD monitors?

Given their current prices, you should go for 3D-enabled LCD monitors, e.g. the HP 2311 gt. Look for reviews like this one. I personally strongly recommend passive displays (less expensive, and way more comfortable e.g. under fluorescent light).

And if you want to show stuff in 3D easily, why don't you give Tao Presentations a spin?

3D, colour, surround sound, CGI, all of it are just tools for the storytellers to use to tell their story. We don't even think about colour in film, but it was a huge technical milestone for a lot more than just 'improving a character or story'.

This is very true. 3D is a tool that has been abused initially (the "shrapnel flying towards you" another poster referred to). But 3D is also the normal way for us to see the world, so when done right, it enhances the suspension of disbelief. However, it matters that you do it right. Just like color could be distracting when you had over saturated hues or bizarre skin tones, 3D can break the immersion spell if not done right. On the other hand, if you do it right, it is transparent on the conscious level but ads realism and makes the story more believable.

It's not just for movies either. At Taodyne, we brought 3D to interactive presentations. We have a kind of 3D interactive multimedia LaTeX called Tao Presentations. In our experience, 3D presentations are something that people still remember one year after having seen them. Most people don't necessarily remember movies better when they are in 3D, but ask any kid in France about the 3D Haribo ad, and chances are they remember it. The same is true for presentations. Showing models or charts in 3D gives them more impact.

Another interesting effect of 3D for storytelling is that you can put more data on a screen without causing confusion. You can put things in front to draw attention, or in the background for things that are less important. You can create true 3D charts, where the depth ads another useful axis. And the Star Wars effect in real 3D is an interesting way to show data (it's a built-in demo of Tao Presentations).

In short, 3D can be a gimmick. Or it can be used well and make a difference. It's all a matter of how you use it.

I wonder what the precise computational cost is of rendering complex 3D objects and scenes on this kind of technology.

I can't wait to have one of these babies to run Taodyne's 3D presentations software on it! One of the things which is tricky with current multiscopic displays is how to convert existing 2D movies. Ideally, you want to do that in real time, something that Tao Presentations can do for Alioscopy or Tridelity displays, but which is more computationally expensive for Philips/Dimenco displays.

Tao Presentations is a 3D presentation software that runs on Linux as well as on Windows and MacOSX. We had mixed experience with nVidia support. Sometimes, it just works. In other cases, major functionality is missing (e.g. a laptop where the HDMI port is simply not detected). That being said, except when we hit a major bug, OpenGL performance is overall rather close to what we get on the same machine on Windows, which indicates that nVidia takes Linux somewhat seriously.
Actually, I don't think nVidia has any kind of anti-Linux strategy in place. It's rather that their portfolio is big and their overall strategy is sometimes confusing as a result. Consider stereoscopy for example, which matters a lot for Tao Presentations. Both nVidia and ATI have this puzzling idea that only "pro" customers can have stereoscopic support for OpenGL. This leads to situations where a machine with an nVidia chipset will connect to a 3D projector perfectly... as long as it runs MacOSX. The exact same hardware won't offer quad-buffer OpenGL support when running Windows or Linux. Why not?
So it's not about Linux, it's about lining up so many little pieces that sometimes, one of them is missing and the whole thing collapses. Linux is probably at the bottom of the list of things to fix, so that's where you see more problems.

I invite you to install Tao Presentations. Start with the free Discovery editions, http://www.taodyne.com/shop/fr/licences/20-tao-presentations-discovery.html. Once this is done, use the link tao://git.taodyne.com/examples/TEDx and load TEDx.ddd.

This is best viewed with a stereoscopic screen, but it works well on a regular 2D screen as well. This may give you ideas on how to tell your story.