Comment Re:Video tutorials (Score 1) 158
Sorry -- I'm tired and angry about various things
Really sorry to hear that. But apology gladly accepted
You'll probably hate me for saying this, but why not just write text elements in an established format... like HTML?
Now you can. But HTML is not a very good format for dynamic text. How do you represent the following with HTML?
paragraph "It is currently " & hours & ":" & zero minutes & ":" & zero seconds
zero N -> if N < 10 then "0" & N else N
I believe that the typical usage of presentations will see a lot of minor adjustment of the most PowerPoint-like elements
This is true with what Powerpoint can do. With Tao3D, when you discuss a simulation, a lot of time is spent refining the simulation.
For one thing, reusing existing collateral would be more of a cut-and-paste affair
Even without the patch above, you can copy-paste HTML into Tao3D.
the language confuses the two metaphors of series-of-commands vs collection-of-properties.
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).
Ah... what I hadn't noticed was the lack of assignment operator in the language.
There is an assignment operator in the language. The theme getter/setter is define as follows:
theme -> "default"
theme T -> theme
If that's what you've done, in theory you have completed the abstraction of objects -- if the caller doesn't need to know how an object works, it shouldn't need to know that it's not changing the properties directly.
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.
But without an operator, how is it obvious the difference between an assignment, a function passed as argument, a function call and a looked-up value?
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".
As a developer, you should be avoiding personal taste.
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]>?
That last one, while I don't like it, at least looks consistent
In the Tao3D evaluation model, they are all consistent.
at other times a bag of object properties.
This only shows that imperative is superior to declarative. You can make imperative feel like declarative, not the other way round.
If I edit the attributes of an HTML tag via javascript, it shouldn't really matter which order I edit them in -- the end result is the same.
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.
So while I'm thinking of the colour as a property of the rectangle, I expect to be able to change the rectangle's colour.
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.
OK, fair enough. I consider Processing at the very least problematic in that the abstraction is difficult to use.
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.
If you're using "color" as a manipulable property, why not just do the same with "visibility"? I'm not sure I like it, but it seems to sit with the language logic.
You are right. I'll probably change that.
Much problematic behaviour in many languages is well specified, and yet bugs occur.
Are you asking me to design a language that makes bugs impossible?
I've been watching your video Introducing the Tao language, and I see later definitions override earlier definitions. Fine. Pattern matching usually works on the first match, you're working on the last match. Both are valid models.
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.
If you allow one of my colleagues to define one case of the pattern two screens after the majority of cases, and I don't know it's there, I can't predict the behaviour of the code.
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.
But statistics says if if can happen, it almost certainly will happen at some point.
"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.
typically polymorphism at the very least conceptually models different functions (adding complex numbers is different from adding non-negative integers)
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.
but pattern-matching with different values of an int (for example) is conceptually a single (possibly discontinuous) function. It is easier to understand someone else's code if that one single thing stays in one place, surely.
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.
I don't know anyone who writes enough presentations to justify learning a new (and quite different) language to proficiency.
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.
OK, make that a vanishingly small userbase. Very few presentations ever require that level of work.
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.
I talked about "users", and you called them "customers". Presumably, then, you originally made the software hoping to sell it, but have found your niche using it as a consultant to build up custom presentations for small businesses/projects.
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.
I don't think your software will ever be accepted in large enterprises. Small companies may be different.
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.
No decisions in a startup should be "personal", they should be a reaction to what users need.
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.
It's not the colours that bug me, but the fact that the programmer has to explicitly deal with redraws.
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.
Your article doesn't show me anything "smarter" -- everything is about explicit redrawing of the item
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?
I don't see the need to do that -- why not just update the properties of an existing entity?
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?
but with all these objects, wouldn't it be much better to treat it like stop-motion, moving physical objects in a 3D space?
The Animate module offers a number of helpers for animation, and more are scheduled.
Didn't you write the language yourself? That means you are intimately acquainted with the logic.
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.
Caching seems a lot less flexible and a lot less intuitive than having a persistent object with manipulable attributes.
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.
There we go -- more personalisation. It enables you to create animations. It's an esoteric tool that fits the workflow that you built for yourself. It's not a general purpose tool.
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.
It was TFS wot did it. Because the text "interactive, data-rich presentations" was a hyperlink, it was underlined, and apparently led quite a few commenters to focus on the presentations side of things. And of course, multiple of your demos focusing on slides doesn't help either. You may not have mentioned PowerPoint, but you have presented the software in such a way as to evoke it.
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".
As for PowerPoint not being a language, I see that as a side issue. Whether something is a graphical application or a text-mode language, it's still a computer-mediated tool aimed at getting an output. When I choose between a visual editor or a code editor to update a webpage, it doesn't matter that one is "language" and the other isn't -- I pick the tool that gets the job done most efficiently.
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.
Global state is often confusing, and there are lots of bug reports to prove it.
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"?
Your global state is also inconsistent, in that your pen (to use a Logo metaphor) has colour and orientation, but lacks the most basic property: position.
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.
Global state leads to funky errors when you refactor and reorder code, and you break dependencies.
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.
Going back to what I was saying earlier about properties vs execution steps -- if your colour was a property of the scope, rather than a state, if you were drawing a flower, then within the (repeated) petal component, the stem component etc, there would be a unique colour property, and that would be far easier to conceptualise.
And there are tons of things you could not do. Like rotating any shape globally in a predictable, non-commutative way.
As I said, OpenGL is low level. Tao3D should be aiming at high-level.
But your original objection was that it was "opaque". Seems to me it's more like "unknown" and "new", more than "opaque".
Ah, matrices... now I see what OpenGL is up to -- storing all cumulative operations in a single matrix to apply to all points, to avoid recomputation. And the persistent state is to prevent passing the same matrix back and forth between all procedures. In a high-level tlanguage, this can (and I would say "should") be abstracted out.
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.
Unless you're trying to make high-performance realtime apps
Yes, Tao3D is designed to let you create real-time apps, notably for presentation purpose. And that requires high performance.
in which case the "presentations" use-case is even more misleading, because you don't write high-performance realtimes apps just for presentations. Either you show the actual application, or you use prerendered video.
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.