First up, can I suggest adding the word "visualisation" to your standard blurb?
Good idea, done. It was hidden in the middle. Renaming Tao Presentations to Tao3D is similarly an attempt to avoid the misconceptions about "presentations".
I'm talking about a visual confusion. The reason I keep using the word "opaque" is that when I look at the code, the intended (semantic) behaviour is obscured.
Are you sure this has nothing to do with you not being familiar with the language?
You've suggested several times that having effectively only one syntactic structure in the language makes it more consistent, but my object with regards to consistency is precisely the contrary: that the syntactic rule is inconsistent because there is no clear mapping of syntax->semantics.
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.
So ":=" is the assignment operator, but in all your examples you've sugared it over, and basically obscured the logic of your code...?
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).
I don't think it's more practical, because it massively less readable.If I use object.setColor("green"), it's easy to read the intended meaning.
I would prefer the abstraction object.color = "green" because getter/setter is usually implemented by convention rather than rule (leaving things open to programmer error).
There, you went down three steps down the abstraction ladder. Why not MOV $green.str0, color[object] while you are at it?
But your solution offers less clarity than either.
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.
You're talking about the computer.
No, I'm talking about the abstraction level, meaning you hide what is irrelevant.
Imperative is superior to declarative only in terms of optimisability
Also in terms of expressive power, in terms of the ability to build abstractions incrementally, in terms of
a declarative language should be easier to code in, because you only have to worry about the behaviour, not the execution.
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.
A well-written declarative language would be quicker to write in than a similarly well-written imperative language.
Please prove it by showing a well-written declarative language.
Why can't I just declare which functions should be memoised over recursive calls, rather than faffing with (set!
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.
As I say, it's only problematic when it doesn't look like a command.
OK, but why doesn't color "red" look like a command to you?
Sorry, I confused the "with" iteration as a pattern over a discontinuous range of values. This is what I mean by opaque -- there is minimal visual distinction between a function definition and a function call, making it difficult to read and reason about code quickly.
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.
My point isn't that the DNA functions aren't discontinuous, it's that a discontinuous function is still a single unit, and not comparable to a polymorphic operator.
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.
If we start down the LoC line, we get to the point where we're declaring obfuscated Perl code as the best thing since sliced bread. If we use characters as our metric, you're penalising explicit variable and function naming. The characters metric also automatically penalises against things like using explicit assignment operators (which really do add to the understandability and maintainability of code), and LoC automatically tends to favour semantic whitespace (as end-block delimiters are often given their own lines to enhance readability).
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.
All I'm saying is that for most practical purposes, the idea that the item persists and that redraws are implicit is a useful abstraction.
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.
Because there is no existing entity.
That's not the answer -- I said "an", not "the". I was questioning the choice, not the consequences. Yes, I know you went on to justify that choice, but starting off the paragraph this way risks confusing things.
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).
But the real explanation here isn't about ID clashes, is it? It's about keeping memory manageable for massive datasets -- no computer on Earth would be able to maintain persistent objects for every star in the known universe in memory.
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.
As above, that's an objective metric, but it doesn't indicate objective superiority.
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.
It's not a fallacy, it's a reality. It's about perception and expectation.
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.
But a PowerPoint file is just an XML document, which means that PowerPoint is a language, even if no-one in their right mind would try to edit the source directly.
It's a data-only language. So it's not a true programming language
I thought this was for quick mockups, and therefore I felt it should abstract away a lot of the 3D stuff.
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.
(Even "Hello World" examples are usually a terrible start for a coder in a new language, because it's easier to just type echo "Hello world!" at the shell prompt.)
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.
Well, for a start, I wouldn't use the slide format in the introductory video. Seriously, that is extremely misleading. Or maybe use it later on, once there's (eg) a rotating model of a simple product (a bicycle wheel, maybe), so that you're clearly showing the presentation tools as an extension
Data visualisation. "Presentation" implies passivity. This is not fallacy, it's a natural consequence of years of death-by-PowerPoint.
I do not see your stargazing app as a "presentation", because a presentation is not typically an end-product.
OK. It's called Tao3D now, not Tao Presentations, that's a start