If you are a developer and want to go beyond Powerpoint, Tao3D (http://tao3d.sourceforge.net) is a valid open-source option. It takes time to master, but it's a much more effective way to tell a complicated story.

Good idea, done. It was hidden in the middle. Renaming Tao Presentations to Tao3D is similarly an attempt to avoid the misconceptions about "presentations".

Are you sure this has nothing to do with you not being familiar with the language?

Maybe the word you are looking for is not "consistency" then. "Consistent" means there are no exceptions to the rule, which is easier to achieve when there are few rules. In C++, f(x,y) may be a macro invocation, a function call, a constructor, and there are different rules in all three cases. In HTML, the "a" tag refers to its URL as "href", but the "img" tag calls it "src". Consistency with the "real world" also matters. In SmallTalk, 2+3*5 is 25, not 17, so SmallTalk is consistent with itself (everything is an object, etc), but not with the rest of the world.

Something helped me immensely in your last post: you put a few code examples. I think that code examples help me figure out what you really mean or what you care about much better.

Why do you call this "sugaring over" now, and not "building an abstraction" (from your previous posts)?

The abstraction for attributes, used consistently, is: each attribute has a name from the real-world, you set the attribute "attr" with "attr value", you get the value of the attribute with "attr", and attributes apply to things that are evaluated later. Not obscure, and consistent, both internally and externally (e.g. with OpenGL).

Can't agree on that one. It's totally unreadable (ask any 10 years old kid without a deep training in JavaScript). And for productive programmers, it has the following useless characters: "object.set()".

There, you went down three steps down the abstraction ladder. Why not MOV $green.str0, color[object] while you are at it?

I have trouble arguing if you tell me that object.color = "green" is a better abstraction than color "green". It's terribly inefficient when you have multiple shapes and multiple attributes, and I have proven with rotation that it does not work for some complex attributes.

No, I'm talking about the abstraction level, meaning you hide what is irrelevant.

Also in terms of expressive power, in terms of the ability to build abstractions incrementally, in terms of ... well... everything ;-) Imperative can also describe computations, tests, loops, and so on. Remember my question about how you'd represent repeated divs with HTML alone (no JavaScript)?

But behaviour is infinitely more complex than execution. Execution is generally defined as a simple step-by-step sequence of operations. Behaviour, by contrast, is arbitrary. For HTML, is requires understanding how a multi-million lines programs like a browser interprets the data.

Please prove it by showing a well-written declarative language.

Because as the person writing the algorithm, you know when and how to cache data. Fibonacci is an overly simplistic example to decide what to do.

OK, but why doesn't color "red" look like a command to you?

I think that I understand your point. You definitely need to learn what a function definition looks like to understand the language, I'll grant you that.

Not in Tao3D, no. In C++, you have a discontinuity based on the type of the arguments. In XL and Tao3D too, but that type is much finer-grained, i.e. you can have a type that takes only odd integer, or a type that contains only the value 1.

And you really think that it's the way I got a 28x factor? I believe that you are ignoring the core of my argument here. We are comparing well-written code against well-written code, and there is a 20+ times code reduction. I used that to highlight that the improvements I see in Tao3D are not just in my imagination or the result of me being the author of the language.

By the way, I wrote an article with the actual code explained for this specific example.

Yes, and conceptually, that's how you see the code in the DNA example until about 3 minutes into the video, when the abstraction is broken by the use of random numbers that are not identical from draw to draw.

And I really mean there is no existing entity at all, that's the whole point. You don't need to name entities. As a matter of fact, it's only in the second iteration of the Tao3D development that there were any entities at all. In the first prototype, it was direct execution, straight to OpenGL. If there were any entities, they were in the graphic card's memory, inaccessible to the program (at least, at a reasonable cost).

It's more about offering a simpler way to describe things. An entity means you need to name the entity. When I draw on a sheet of paper, I don't need to name everything I'm drawing.

If the programs are similar in what they do, in readability, in naming conventions, and if the LOC factor is 20+, then yes, it does.

Yes, I agree with that. Visualisation is a good application. But deep inside, it's really a programming language. You can do visualisation, virtual reality, image processing, etc. While your data visualisation comment is very true, Tao3D can equally well do batch processing on a number of images.

It's a data-only language. So it's not a true programming language ;-)

And it's important for me that it can do quick mockups, where 99% of the 3D stuff is abstracted. When I write a "slide", I happily forget about the hundreds of 3D objects and animations created by the theme behind my back. Now, I talk about a "slide", and that's what I focus on.

Here is the Hello World in Tao3D. It's not the shorter you can do, though. The shortest one would be text "Hello World". It does abstract quite a bit of 3D stuff in the process, by the way, like creating polygonal outlines and textures to render the characters.

You mean, like in the DNA strand example? Or in the clock tutorial? Some videos start in presentation mode, others don't. Some start with existing code, others don't.

OK. It's called Tao3D now, not Tao Presentations, that's a start ;-)

Really sorry to hear that. But apology gladly accepted ;-)

Now you can. But HTML is not a very good format for dynamic text. How do you represent the following with HTML?

This is true with what Powerpoint can do. With Tao3D, when you discuss a simulation, a lot of time is spent refining the simulation.

Even without the patch above, you can copy-paste HTML into Tao3D.

There is no confusion, there are only series of commands, although with a homoiconic language, they are also data, so you can view them as properties and make them behave like properties if you want to. The fundamental paradigm remains sequential evaluation (using parse tree rewrites in that case).

There is an assignment operator in the language. The theme getter/setter is define as follows:

I may not have made the abstraction exactly like you wanted, but I've made abstraction more practical than in most languages. The theme "variable" could be a function, I would not know. And the theme T "setter" could do some validation or anything else, same thing, you would not know.

The real abstraction is precisely that it is not obvious at the call site. If you have something like do_something theme, it's do_something that decides for example if it evaluates theme or not. If not, it gets the unevaluated name, and it can decide to do something with it, like using it as a prefix for a "function call".

That makes no sense to me. While it's a good thing to be able to fit in an existing environment, when you design from scratch, you have to make choices. And those choices are based on your own taste. Who gets to decide for you if you prefer to write runThing, run_thing(); or (run-thing) or, Knuth forbid, <thing EVALUATION_MODE="run" @ARGS[$nil]>?

In the Tao3D evaluation model, they are all consistent.

This only shows that imperative is superior to declarative. You can make imperative feel like declarative, not the other way round.

And this is actually a problem for rotation, because rotate is not commutative. Doing rotate_x 40; rotate_y 30 is not the same as rotate_y 30; rotate_x 40. Worse yet, if attributes are order independent, the "rotation as attribute" model suffers from gimbal lock. So any Three.js code that sets rotation.x and rotation.y on a mesh is conceptually ambiguous, as the effect is not the same if you rotate along X first or along Y first.

In the real world, I can say "Draw a red rectangle" (property), but also "Take the red pencil. Draw a rectangle, a triangle and a circle". Obviously, the most efficient description depends on the scenario, which is why I'd like ideally to have both at my fingertips.

Even when you have attributes like in HTML, the properties are not with the elements in the source code. They may be accessible in the DOM, but in the source code, the color of an element may come from a variety of sources: attributes in the element, inherited attributes, CSS, JavaScript poking into the element, etc.

What makes the "sequence of instructions" abstraction difficult to use? It's part of all imperative programming languages, you are the first person I hear complaining about it.

You are right. I'll probably change that.

Are you asking me to design a language that makes bugs impossible?

No, it's the first match that fits. Where did you see a later match override? What is true is that an imported file can placed its definitions "in the background" (at lower priority) than the definitions of the users. So a library can have a "catch all", its caller have more specialised patterns, and the caller will win even for calls made from within the module. This is how you can override theme definitions.

How is that different from CSS? How is that different from C? In C, someone can define "malloc" in a different file, and that's a good thing. In JavaScript, code can modify any object, anywhere, override functions, prototypes, anything. And many interesting things have been built with this facility.

"Almost certainly", it will be possible to write buggy programs with Tao3D. No doubt about that. The question is whether Tao3D makes it easier or harder. Since in general, the code is 5 to 20 times shorter than JavaScript or C++, I think it rather helps. See examples below.

The functions (and polymorphism) you describe are a well-define subset of parse tree rewrites. The tree rewrites that cannot be modelled as functions are what makes Tao3D interesting. Even if the implementation is not "up to the task" yet, conceptually, Tao3D is, as far as I know, the first language that unifies the notions of variable, function, macro, array, list, hash table, and type, as well as the first language that unifies the notion of compilation, evaluation and computation.

You said you wanted consistency? Here you have it: you can see sin X as a "function", line_width X as a "setter", locally X as a "high order function", render X as a "macro", style X as accessing a hash-array of functions, and so on. It's all a single construct, with a single set of rules to learn. It then becomes a matter of optimisation how each case is implemented. Something that does not work yet is the type system, but in the theoretical XL, a type is a function used during pattern matching to classify trees, and therefore, a function can return a type, and so C++ "template types" are just "functions returning types" in future-XL.

Then by all means keep it in a single place! But remember, it's often not in a single place today, for good reasons. In C++, the + for int, float or double is in the compiler. The + for complex is in <complex>, the + for text is in <basic_string>, and so on. It makes sense. Yet + is conceptually a "single" function, and you can write a "function template" that uses an addition and will work with all these types.

Furthermore, this whole discussion came from the dna_base_pair function in the DNA demo, and that function is discontinuous, since it returns four different arbitrary values, and is undefined for other values. In C or JavaScript, you can't even express that a function is only defined on values 0, 1, 2 and 3.

Go to any trade show. See how many screens show flash, interactive presentations, and so on. Do you think these things program themselves? Tao3D can do slides, and since I often need slides, I use it for that. But it can also do all these things Powerpoint can't do.

Just visit Chrome Experiments, and ask yourself: how much work went into this or even this or this nice clock? Someone thought it was worth doing.

Now let's consider the last one is this code. It is 603 lines of code. How much time do you think it took? I can do exactly the same thing in Tao3D in under 10 minutes, and 38 lines of code. And then, I can make it much easier to read with 3 more lines. So in that case, we have a factor of over 15 in terms of line of code. In terms of characters (aka "carpal tunnel syndrome elementary units"), it's 26594 for JavaScript, 922 for Tao3D, so that's a cool 28.84 factor.

No, in the example, I was the "user". I was simply explaining that the requests I get as a user of Tao3D are not as you suggested. I can't really speak for other "users" (well, I could, but I don't like to), even if I understand you consider me a rather atypical "user" and may not consider my experience as representative.

It will certainly take some time to become commonplace. But Tao3D is already in use in a few large companies, a few of which actually even talk about it.

All decisions are personal, including the many reactions that are in response to user requests. My recent decision to implement HTML text in Tao3D was personal. But it was your request. I don't see any contradiction.

You have been focusing since the beginning on the "surprise" you had that I had to put a "random seed" in my DNA video to have stable colors. When I do this kind of videos, I try to teach a number of things by example. This was a very good illustration of the fact that in Tao3D, things redraw as necessary. When you move the mouse, it redraws what needs to be redrawn. But if what you draw is not "stable", then it does not look good. The same thing exists in JavaScript or any other language. If I had coded the same example in JavaScript, I would have had to put a random seed for the exact same reason. So I really don't understand why you make such a fuss about it.

Not anything "smarter"? I have a 23-lines program that draws a recognisable DNA strand. A 922 characters program that replicates a Chrome Experiment weighting almost 30 times more. That's not high-level enough for you?

Because there is no existing entity. That's the whole point. No existing entity means I don't need to lookup the entity to set its properties. I don't need to think about what happens in HTML when two entities share a same ID. The HTML way is more verbose, it leads to duplication, it gives several time more opportunities for error. Even simple replication with rotation/translation, like I did for the DNA strand, is complicated in HTML. In HTML or any attribute-based XML language, tell me how you repeat a <div> N times, translating it and changing its color as you go? Compare with the DNA example. What is your conclusion?

The Animate module offers a number of helpers for animation, and more are scheduled.

It does not invalidate objective metrics, like the number of characters in programs doing the same thing. It's not because the guy who wrote the Chrome Experiments are dumb. They are super smart. But now, there's a new tool in town that's more efficient than the one they used.

Well, to me, it expresses things at exactly the right level. It's an optimisation done by making objects persistent internally (at the expense of fluidity). I express it by talking about a "cache". It cannot be expressed implicitly, because only you can tell whether the cache remains valid or not (this is what the "version number" argument is for). Any case where we can cache implicitly, we try to do it.

Programming languages are never general purpose tools. But you happily jump from "not general purpose" (and, I believe, "I don't like the way it's done") to "only useful to its creator". This is remarkably false, both from a logic perspective, and from the conclusion you reach.

This is a fallacy. PowerPoint and Tao3D are two presentation tools. Fighter jets and bicycles are two transportation devices. There are legitimate conclusions you can draw from these observations, but you can't draw the analogies too far, like "there is no market for fighter jets because nobody will spend hours learning how to fly".

It does matter. It's a key design decision.

Have you ever written a Postscript program yourself? Probably not. Many HTML pages are generated. There are several graphical front ends for LaTeX. Tao3D can be programmed directly. But it can also be generated. As I suggested earlier, we have been working on a web-based editor for it. The fact that there is a language does not mean there won't be a GUI some day, but that there can be several GUIs.

I strongly disagree. All graphics APIs on the market use global state. Where are the lots of bug reports "proving" something as vague as "confusing"?

But the "pen" is a Logo metaphor. Tao3D has no pen. So don't ascribe properties (or lack thereof) to a pen Tao3D does not have... So you are mixing metaphors, and then telling me that "my" global state is "inconsistent" with the inadequate metaphore you picked.

Nope. That's long been a tenet of the zealots of "pure functional" languages. But there's very little evidence to back this kind of assertion. In practically all languages, I/Os rely on massive global state. Some languages such as Haskell have used things like "monads" to sort of elude the problem. Now, using monads for I/Os, that's funky.

And there are tons of things you could not do. Like rotating any shape globally in a predictable, non-commutative way.

But your original objection was that it was "opaque". Seems to me it's more like "unknown" and "new", more than "opaque".

This is abstracted out. You never deal with matrices in Tao3D. They are an internal implementation details. As a matter of fact, we have massively refactored all the matrix computations somewhere during the life of the project, and we no longer use OpenGL matrix computations anymore. Yet none of our Tao programs were impacted.

Yes, Tao3D is designed to let you create real-time apps, notably for presentation purpose. And that requires high performance.

The problem is that you wrote you don't want when in reality, all you were entitled to write is I don't want. You can't tell me or others what we want.

It's not implicit lists. Tao3D, like Lisp, is strongly homoiconic. In other words, it's primary data structure is used both for programs and data. In Lisp, that primary structure is the list. In Tao3D, it's the parse tree. Manipulating parse tree structures is fundamental in Tao3D programming.

Now, conceptually, you can correctly think of 1,2,3 as a list. But you could as well have 1;2;3, which is also a "list", except it's built with a different infix operator.

So when I write something like:
foo X,Y -> bar X; blob Y
I'm really describing is a parse tree transform recognising a prefix foo, which matches only if the right is infix with a comma, and will split that infix into its left and right components, and call bar, then blob with the components.

I could similarly do something like that:
[A..B where C] -> A-B
and that would only match a [ ] block with a child that is an infix "where", when the left child of that infix is an infix "..".

So it's very regular. It does what other languages call function calls, operator overloading, or even macros (because that process also lets you precisely control when arguments are evaluated).

While it's only 128 edges (not triangles, I had misinterpreted what I was counting), it was still worth investigating. And I modified the way Tao emits polygons to be more aggressive for small sizes. I also added user-controllable parameters in case the defaults are not suited for a specific use case. Code reviews and comments are welcome.

Thank you for your input.

Then you misinterpreted the information I gave you, because my point was that designer, ideographic or Arabic font have complex outlines. AFAICT, Three.js cannot use such fonts (maybe there's a trick I don't know).

These are all great products. What Tao3D offers is:
1. It's notably cheaper, and now there's also a free software version.
2. It's a programming language. That being said, I know Ventuz can at least be scripted, not sure about the other two.
3. Stereoscopy and auto-stereoscopy are just a mouse click away. Ventuz can do some, but it was convoluted last time I checked.
4. Tao3D automatically checks if media, files, sources changed, and reloads them. Great for remote-controlled updates.
5. No need to import media, Tao3D uses media in place (that used to be an issue in Ventuz and Aurora3D, not sure if that's still true).

In a sense, Tao3D is to these tools what a web browser is to Powerpoint: open, extensible, flexible, but harder to get started with. And in this analogy, we see the web-based interface in Tao3D as the equivalent of Wordpress, i.e. a solution to separate concerns between editors, page designers and media content producers.

Does that make sense?

Ah, I missed your point completely in the GP. Sorry.

The problem it addresses is the complexity of creating the simplest 2D or 3D scripted animation, and how this process does not scale or compose well.

Here are a few random examples:
* Create Christmas card pictures for all my friends that are automatically tailored for each of them.
* Display fragile objects in a museum, photographed in 3D (or scanned), shown in 2D, in 3D or in glasses-free 3D
* Display complex data or simulations for a scientist, in a way that can be explored interactively or shown at conferences.
* Teach about fractals by showing interactive models of various fractals.

I'm conscious that with enough effort, some of these can be done with other tools. The purpose of Tao3D is to reduce the effort manyfold.

Sorry about that. Bug in the packaging script. Should be fixed now.

There was none, indeed. In reality, Tao3D is based on tree rewrites, not lambda calculus.

I'm exploring a bit here what the implications are. Quite frankly, the type system as implemented is totally incomplete and still largely broken at the moment. I understood what needed to be done after 5 years of experimentation, and never got the time to actually implement it. Similarly, the language reference describes a runtime environment for functions, how closures and symbol tables are defined, etc. I prototyped this and got a basic compiler half working, so I know it will work. But the symbol table in Tao3D is a more ancient design, in C++, not visible to the program.

That being said, there are "anonymous tree rewrite" notations very similar to lambda calculus. For example, here is how you can draw an almost convincing Christmas tree:

The with operator here implements a map, i.e. we apply foo with the result of an anonymous rewrite (that's the "lambda") with a list made of values 1 through 8 and then 2 through 4.

The filter operation is implemented with another syntactic form:

There's also a reduce operation, but it crashes the compiler at the moment, need to see why:

I meant: you probably have some code that looks like:
var geom = new THREE.TextGeometry(T, { size : S, height: H, curveSegments: CS, font: F });
I was interested in the parameters to that code.

Unless you are rendering bitmap fonts, at some points, your glyph outlines are first rendered to the texture. It may be 2D, chances are it's still done by the graphic card on modern systems.

Actually, you are right, the code I quickly implemented was counting the array elements, not the polygons. So, roughly, the number of edges, but counting terminating edges in triangle strips multiple times. My bad. I guess I'm getting tired. The point I was trying to make remains valid: some real fonts (as opposed to the toy fonts in Three.js) quickly generate huge amounts of polygons.
As another illustration of my point about WebGL, I can see the Three.js geometry / text example on my iPad, but not on my iPhone 4 or my Android tablet. Maybe you are more lucky with your BlackBerry...

I'm sorry I did not convince you. But Tao3D does offer a lot over existing solutions.

First, Tao3D is the only practical solution I know for delivering interactive 3D animations, simulations or presentations quickly. What you can do with Tao3D in 25 lines of code is nearly impossible today with Three.js: no support for real TruType fonts, no text layout for 3D meshes, no RTL text support, etc. And I'm just talking about text here. We can do full slides in 3D with 25 lines of code when Three.js is barely capable of doing one line of text in 600+ lines of code at the moment, and then only with relatively serious 3D programming. Tao3D requires 24 times less lines of code. And you say we bring nothing new?

That brings me to the second big contribution. Even if you add text layout features to Three.js, you will still be working at the wrong semantic level, talking about meshes and renderers and such. Again, someone might work this out the way Reveal.js attempted to do for slides. But Tao3D does this today. Today, with Tao3D, you talk about "slides" and "paragraphs" and "color", because that's what you care about.

Finally, a third innovation in Tao3D (though not in the libre edition) is transparent support for practically every stereoscopic or auto-stereoscopic screen under the sun. So you can playback 3D movies without glasses, superimpose 3D text and logos, etc. In the digital signage space, Tao3D brings glasses-free 3D screens at feature parity with 2D screens. And that's also a pretty significant contribution.

Not any criticism. Against uninformed criticism, of which there is a lot on Slashdot, unfortunately.

I noticed your "failing" startup comment earlier, don't worry. Like any startup, not enough cash, too many ideas, not enough people, too many things to do, not enough time.

Our current markets include exhibitions, e.g. trade show, museums, etc, high-end presentations, scientific data visualisation and 3D advertising. Others we know we can address include education, point-of-sales, automated image processing and generation, ... And if 4K glasses-free 3D TVs start taking off, we can deliver a 3D GUI for set top boxes today. As far as I know, nobody else is close.

As for where I see the product in the future, please allow me to keep that to myself for the moment.

Just to clarify, the poly counts I gave were actual triangles processed by the card when disabling texture-based rendering in Tao3D. This is the only case that always works, so it's both the fallback scenario and the worst case scenario. Therefore, that's the one I'm most interested in.

Obviously, Tao3D does that when that's possible.

Tao3D also does that when it makes sense.

Hmm, how do you draw a glyph with only one triangle per character? Or do you mean that we can use two triangles for multiple characters? We also can store full words in the glyph cache. But currently, we only use that for languages with ligatures such as Arabic.

May I suggest that you should study how the Tao3D code works a little more before being so dismissive ;-)

Quick test with what? How did you create a text mesh with Three.js to start with?

Furthermore, as soon as you extrude, you need true polygonal rendering. You can't draw on a texture and render quads or two triangles as you suggested. Or if there's a way, I don't know it. So you end up with roughly the number of polygons in the base glyph x N, where N depends on extrusion parameters, e.g. if you create a bezel or not, if you round the bezel, and so on.

Would you please be kind enough to share your experience? That's a hot topic for me.

First, I'd like to point out that even if you can do texture-based rendering, you still need to first render to a texture with polygons or, alternatively, with triangles and a shader doing the Bezier fill.

Let's deal with two cases here. The first case is when texture-based glyph caching applies. In that case, polygon count is rarely a problem for alphabetic languages. For ideographic languages, or languages with ligatures such as Arabic, the chances of finding what you need in the glyph cache are lower, but you can still assume you will draw the same text several frames in a row, so that's still a net win. The animation may skip a bit when the text changes though... So basically, the glyph polygon count defines the worst case "skip" you can get. And westerners don't care, since they use a Latin alphabet with an appropriately low number of glyphs. So in general, we can reuse entries in the glyph cache.

Second case is when you can't use textures. Extruded 3D text is one scenario, that's hardly the only one. Then, you need true polygonal rendering. And the number of basic triangles you had for the front face is multiplied by N, which depends on the shape of the extrusion path (bezel, rounded bezel, etc). Plus this time, you need to render the polygons at every single frame, so polygon counts start playing a big role in performance.

In all cases, even with an curvature-dependent algorithm, you still need a decent number of polygons per glyph or any non-basic font looks like crap. I think the best you can do is something like one triangle per Bezier curve in the glyph (unless you want your shader to become really something). Without a Bezier shader, you need at least 5 or 6 times more (depending on how sharp the curves are). In the extrusion case, you can't use textures, and you can't use Bezier shaders either.

In short, drawing "Hello World" spinning in 3D Arial font is something that anybody can do. Fetching text from an Arabic or Chinese news site and drawing that on the screen continuously, that's a different challenge entirely, and one I reckon a Blackberry won't be able to deal with too happily. At least, that's my opinion today. You may easily prove me wrong by porting Tao3D to a Blackberry :-)

Oh, I got it backwards then. I thought you had been trying to prove me wrong all that time... Sometimes, you were right (e.g. black characters on black background). Sometimes, you've made a good point (e.g. align_vertically). Sometimes, I feel your point is less convincing (glTranslate and glColor). Sometimes, I think you are plain wrong (global state is evil), and I express disagreement. That's how a discussion goes. I enjoyed it, sorry to hear that you did't seem to.

If it felt so valueless to me, do you think I'd still be watching for your answers and typing this in the middle of the night? I don't claim to be perfect. Please reciprocate.

No, that's trying to help you become an early contributor. I would not have spent the time locating the exact line to patch otherwise. Remember, open source is about you and others being able to influence Tao3D. But since you obviously don't want to do it this time, I patched it myself. Your name in lights, tadaaa.

Well, text layout is still done in a 2D text box. So align specifies the horizontal alignment and justification within a line (the frequent case), and align_vertically the alignment and justification of the lines and paragraphs vertically.

It's an interesting point. Tao3D actually went the other way. A setter and a getter for a property typically have the same name. So to adjust the stereoscopic effect, you can say something like eye_distance 20, and that adjusts the property you get with eye_distance. To get the current theme of a slide, you use theme, and to set it theme "Master". I personally see the 'set' and 'get' in that case as noise. But I will admit it's a matter of personal taste. I hope you will understand that Tao3D reflects my tastes and not yours.

At the limit, we began implementing (but never finished) a system of properties named x, y, width, top and so on for coordinates. You could then use any of the following three, to your liking:

rectangle 10, 20, 30, 40
rectangle { x 10; y 20; width 30; height 40; }
rectangle { left -5; y 20; width 30; bottom 0; }
x 10; y 20; width 30; height 40; rectangle

Much like for color, the last one would also set the properties in a persistent way for following shapes to use, much like color or texture today. This means you would then be able to say something like left 20 to left-align a bunch of shapes. It's not done yet, but still in the plans.

I find your use of bold font and "broken" quite antagonistic to your statement that two people can be correct at the same time. You call this a real problem with languages. I just don't see it. Specifically, I don't see color "red" or glColor as broken. In doing so, I'm not saying that you are wrong, but I am not convinced by your attempt at proving me (or OpenGL) wrong either. I see it more as a taste than as a matter of right or wrong.

In Tao3D, there is a global "visibility", a floating point value between 0 and 1, that applies to all drawings. When you use show, you change the visibility. Granted, not the best choice of verb. Find a better one, and I might patch that as well. Or you might submit one if you don't go all ballistic again at the suggestion that the code is open :-)

What happens in that case is well specified by the language. You know which pattern wins. Just like if you have a global variable named 'i' and a local variable named 'i' in C, you know which one is selected by the compiler. It might lead to bugs. And in the case of C, it has.

The FUD is using the might as an argument against the feature. If you read the subtext, "Be afraid of the possible consequences" turns into "That feature is evil" turns into "Don't use that language". That's the very definition of FUD in my book. Which does not mean that the fear is unfounded, by the way. But it's on the same level of risk as naming conflicts in any language. Good naming or pattern usage conventions deal with it quite well. I have yet to run into such a conflict myself.

Powerpoint users are not my user base. Tao3D is to Powerpoint what a fighter jet is to a bicycle. It takes more skills and time, you can't use for your everyday shopping/business talk. But if you know how to use it, you can take advantage of the third dimension. So Tao3D was designed for those users who need the power.

Actually, no. One of our first users actually wrote a C++ module to read some scientific data. A typical commercial use of the software is around 5K to 10K lines of code. So not very big, but not "very, very small" either (especially given what you can do in 10K lines of Tao3D).

Actually, that's not true. One thing my customers appreciate is that I edit stuff while it's showing on a projector, from a text editor in a window on my laptop. And for common tasks that fit well in a standard template, we have the web-based editor, that generates code for you.

I agree. This is why we have the web-based and template-based editor. The idea is that you have samples of code with parameters, and that the web user interface lets you tweak only the parameters that the template designer left open. This is still work in progress, though. Most templates remain to be added.

Did you make the "Powerpoint" argument before? Did I tell you you were wrong, ever? You write "wrong" all over the place, and "broken" in bold, not me.

Just curious, what do you mean by "exceptionally good user to listen to"? I know very little about you, sorry to ask.

Second rule of startups: bring something new. So we don't do a Powerpoint wannabe. For that, there's Keynote, Prezi, and dozens of dead products. And LibreOffice Impress if you want free software.

This is a bit my problem here. You already consider yourself an expert when you have not used Tao3D for one week. You are not an expert at Tao3D, sorry. Yet you insist on telling me everything I did wrong. Not helpful.

So why does the demo redraw the shapes with different colors at every frame? Because that's what my program was requesting, that's why. Now if you want to know more about the execution and drawing model of Tao3D, read this. And you'll see that it's a bit smarter than re-creating everything every frame.

Are you positioning yourself as a user, or as an alternate designer? Apparently, you tell me "this design is not good, you should have done it that way", without even having tried our current design. You think you became an instant expert by watching one video on YouTube? You think you can demand changes in the design because you are a potentialuser?

More to the point, the alternative designs you are referring to are well known. This is the model in WebGL, for example. Why do you think the DNA example would be easier to code in WebGL, Three.js or something similar? Here is a DNA-like structure, without text (that would be harder with WebGL). It's 139 lines of code, not counting the many Javascript libraries required to do it. My DNA example is 42 lines of code, with the text. That's one objective measure of simplicity...

In short, I'm not telling you what you should find easy or not. I'm telling you what I find easy or not, and I don't take at face value your theories when my own experience contradicts them. My experience tells me that Tao3D code is short, easy to write, easy to read, to the point. And that all the alternatives I tried are nowhere as good for the specific things that Tao3D is designed to do.

To me, talking about "frames" or the "creation of shapes" is already pretty confusing. Conceptually, drawing is immediate. The fact that it actually is not is an implementation detail.

But of course, optimising drawings and computations is important. So there are tools like cached or frame_texture to cache 3D or 2D drawings. Here is an example with cached if you are curious.

Hmmm, that does not seem to match the quote line just above that sentence. Not sure where this was supposed to go...

Yes, I agree. Tao3D does something no tool I know ever did before. It enables me to create powerful real-time 3D animations in minutes. That, it does better than what has come before. The rest, I don't care. And even if I generally use Tao3D rather than Powerpoint, that does not mean it's meant to be a replacement. Powerpoint has never been described as a "programming language" that I know of. Yet if you look at the title of that Slashdot story, it says "Programming language". You brought up Powerpoint, not me.

Anyway, the original point in your criticism was that global state was evil (if I understood correctly). I answered: no, it's perfectly fine, and there are tons of industry standards to prove it.

Well, the source is open, there is a lot of documentation, there are many examples. The drawing logic you criticised is modelled after OpenGL, arguably the leading 3D API in the industry. What else can I do to make it less opaque? Or, by "opaque", do you mean that you are not yet familiar enough with it to understand how it works? If that's really the problem, give it a couple of weeks.
To answer the question about what you rotate: it's the objects, or what OpenGL calls the "model/view matrix". So if you say rotate_z 20; rectangle..., it's the rectangle that you rotate. Just like if you say color "red"; rectangle... you apply the color to the rectangle.
As for not using it, you are a free man! I still hope Tao3D will prove itself useful to you someday.

Of course, you realise that it's by design that we don't force our users to type useless zeroes and to write rectangle 10, 20, 0, 30, 40, 0? For the 3D version, there's cube for example. You can also extrude 2D shapes to give them a 3D look.

Again, playing the role of the designer here, not the user. There are dozens of other ways this could have been done. Your idea of consistency is different of mine, and your suggestion does not feel like an improvement to me. But again, the code is open. If Tao3D gives you an idea and you want to fork it to create a high-consistency version with abstract types and n-dimensional vectors, you have my blessing. But suggesting I should have done this your way or else it's broken is not helpful.

My audience here is Slashdot. Which last time I checked was "News for Nerds", not "News for Suits". I'm not looking for Powerpoint slide pushers. If you are a good enough coder to be able to use Tao3D instead of Powerpoint, go ahead. If you want your pointy-haired boss to reuse your slides... don't count on me. I described a programming language for 3D animations. If you really want a 3D Powerpoint, check out Aurora 3D.

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.

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.

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.

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.

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 it. If you write rotate_z 6 * seconds; rectangle 0, 0, 320, 200, it redraws it once per second. If you change the color at every frame, then of course it has to re-create it every frame... That's what makes it dynamic and simple to use.

Ah, funny, I had not noticed that... Well, don't count on me to re-record the video just for that ;-)

Can you cite an example of a drawing API or language that has no opaque drawing state? Windows GDI, Cocoa, OpenGL or X-Window have a drawing context. The more advanced ones have a current drawing context, because passing a hDC to every single function adds strictly zero value to the code...

It doesn't (except if there's a funny bug somewhere). Why would you even imagine that?

The problem I have with the article you linked (which is very interesting, by the way) is that it only focuses on learning something, not on actually using it. Let me just give an example. The article asks (rhetorically):

The reason is simple: the first time I learn about an ellipse, I might prefer
ellipse
        horizontal_position_of_center_in_pixels 202
        vertical_position_of_center_in_pixel 208
        width_in_pixels 300
        heigh_in_pixels 300

But if now I have a small example with 4 shapes like this, I go crazy at the third one. Even more so if all graphic shapes have the same parameters in the same order, i.e. always X, Y, W, H. As is the case in Tao3D.

It's OK for a user interface to put explicit labels on dialog boxes because I don't have to type them every single time I use the f...g dialog box...

So why do we use a keyboard to enter programs? Because it's the fastest way we have found so far. There are graphical programming languages, but they are restricted to toy experiments. As long as we have to type programs in, we might as well type as little as necessary...

Not really. The parsing is defined by xl.syntax, a file that currently contains 62 lines, so it's not complicated. The semantics, on the other hand, comes from libraries, including some that are built-in. In the case of base XL, the library components implemented in XL are in builtin.xl, and the components implemented in C++ are in basics.tbl.

But XL and Tao3D put way more in libraries than regular languages. Remember when we moved from BASIC to C? In BASIC, the 'PRINT' statement was a keyword. In C, 'printf' was a library routine. I argue that the C approach is superior. So of course, an exhaustive catalog of C libraries today is a bit difficult. And there are inconsistencies. But it's still superior.

And XL as a grammar that is just a little bit less tiny, just enough so that you can get rid of the parentheses.

That's already the case in any language today that has libraries provided by more than one person. Where is the consistency between C's printf, C++'s iostream and Qt's logging facilities?

XL helps you create new notations that are well suited to the task at hand. It does help you make these notations consistent or useful, not any more than a C compiler makes the name of your C functions consistent or useful.

Because it lets me define operators such as * ** and *** for bullet points, for example, so now I can write slides like this:

There are more interesting things you can do with custom notations. Here is an example using the Animate module:

For the algorithms, I'll let you look at the code :-) It's mostly in path3d.cpp, text_drawing.cpp and glyph_cache.cpp.

There are several algorithms that are activated separately depending on: whether you draw flat text or extruded 3D text; whether there's a texture or not; the size of the font; and more. The primary ones are: render to textures and draw quads, render polygons for the outline and play that back, or extrude the outline with triangle strips. Then there are some tricks to minimize the number of triangles emitted. I also tried an approach where we rendered triangles and there was a fragment shader doing the bezier curve inside each triangle. That was surprisingly very inefficient on many low-end graphic cards, so I stashed it without going through with it.

That being said, if you want the text to look any good, you have to emit a large number of triangles for even relatively simple text. The text of the previous paragraph is 69475 triangles in Arial, 138950 when extruded, 171298 polygons in font "Amaze" not even extruded, 265636 with the font "Be safe", 561930 with font IthornÎt, and ... a whopping 2171202 with Apple's "Chalkduster" font.

1. Performance (which is getting good on desktop-class devices thanks to improvements in Javascript compilation, but still terrible e.g. on mobile devices).
2. Portability. I gave as an example the fact that using a mere GLSL shader as a background on my tutorial page made it unusable for a good fraction of the readers.
3. At the time we started, Microsoft still had the position that they would never support it. They changed their mind only last year, remember? So anybody using IE before 11 has no WebGL.