"That sounds like a less than sympathetic response to the article." It is, I admit. My ego went off.
"The domain is complicated, but it really shouldn't be hard to create a simple universe with simple shapes, particularly not as hard as it was 16 years ago." It's not hard. Once you know the "mechanics" of it. Geometry, materials, appearance, lights, textures, interpolators, transforms, bounds, behaviors, triggers etc. Just get to know 10-12 general things and their relationships. Not so bad I'd say. It doesn't give you that high(-level) feeling as some other APIs might though :) If you want to point out something counter-intuitive, pick the triggers.
"Yes, but the example would start to become very complex then. Remember, I am not trying to teach anyone anything about Java3D, merely to point out that we are building a hierarchy of somethign complicated and that there is a really nice way of doing this in Groovy, which I post next. I felt the whole thing would be too long and rambling to post in one go. Also, I thought the translation of the 3D data from Blender to Java3D was pretty cool and worth mentioning in a blog." Well, so far, the longest snippet of code was your Blender XML parser/loader. I'm eagerly awaitng how you replace J3D scenegraph (joke).
> "That sounds like a less than sympathetic response to the > article." It is, I admit. My ego went off. > > I'm eagerly awaitng how you replace J3D > scenegraph (joke).
I appreciate comments, and I hate censorship, which is why I haven't removed any comments from this blog. I do think though that you are misunderstanding the thrust of the blog, because you obviously know a lot about the Java3D API and that makes you think that that is the subject of the blog.
It isn't. Showing how one API presents itself at one level of abstraction and how you might use a powerful linguistic construct to change that level of abstraction has very little to do with the actual API in question. In this case, though, the API is of a very low level of abstraction, which is why it makes for a good example. I could have chosen the Java XML API, but that has been done to death, and I couldn't justify cool pictures of skulls.
I get that you are great with Java3D, and thank you for sharing your thoughts, but honestly, this could be any API which involves creating something hierarchical, so by focussing on the intricate details of the API you are drifting off topic.
Thank you for your candour in admitting to your ego. We all have them, but considering the astonishing (and somewhat amusing) hornets' nest my casual mention of right brained vs. left brained activity has stirred, I would prefer to leave them out of the discussion, if we could.
I feel the need to justify my statement, as the author of the blog, I know what I meant, after all.
Medical studies aside, I think it is commonly accepted parlance (even if inaccurate) that right brained activity is artistic, whereas left brained is intellectual.
As someone who has been developing software for 20 years, married to an artist who can create beautiful paintings, I mean to suggest that I can do the former, but not the latter for whatever reason and that by convention I choose to label that as being lacking in right brained control.
When I see a rendering of this quality, for example, http://bit.ly/9nEZ3r I am struck by the need for a good understanding of the rendering tool (and process) which I label as left brained, and a need for an artistic streak, which I call right brained. I am not the only one who uses these conventions, so I don't really mind if they are scientifically inaccurate.
> Medical studies aside, I think it is commonly accepted > parlance (even if inaccurate) that right brained activity > is artistic, whereas left brained is intellectual.
I don't think anyone was contradicting that artistic talents are right-brained. What created the hub-bub was that your statement "it also means being right-brained or creative" was interpreted to mean that creativity is right-brained. Or in other words, only artistic people are creative and all left-brained skills are uncreative.
I'm guessing you didn't really mean that, at least not literally. If you did, then I have to disagree. Creativity is not limited to the arts nor are the arts purely creative.
"It isn't. Showing how one API presents itself at one level of abstraction and how you might use a powerful linguistic construct to change that level of abstraction has very little to do with the actual API in question. In this case, though, the API is of a very low level of abstraction, which is why it makes for a good example. I could have chosen the Java XML API, but that has been done to death, and I couldn't justify cool pictures of skulls." I'm looking forward to your next blog post then :)
> What created the hub-bub was > that your statement "it also means being right-brained or > creative" was interpreted to mean that creativity is > right-brained.
Hmm, I see the problem now, what I meant was ..*and* creative, but I said ..*or* creative. A dangerous slip!
> Jeremy, I do have some feedback for you but I was hoping > to wait for Part 2 of your series on your Groovy 3D coding > (pun intended). > > I've spent a lot of time thinking about good domain > specific languages for graphics applications, and line of > business applications.
> I think this speaks to the caution somebody else provided > in this thread, stating Groovy sugar cannot replace > thorough problem domain analysis. I am very curious to > exactly why you would think a syntactic DSL for a Builder > pattern would be good for a 3D app!
Sorry for the long delay in replying, but I, too wanted to wait until I had posted part two. Have a look, I would be interested to hear your thoughts. I have read your analysis of the suitability of DSLs for the 3d domain. Of course this is not about the Java 3d domain, but more about improving on flat, boiler plate, creational code. The fact that we have a very complex two dimensional model for the representation of a 3d world in Java3d makes it a good example, and a bit of a no-brainer to plug in a builder, the way I see it.
Also, I think "sugar" is an overused term. I consider syntactic sugar in a language to be the "prettification" of something without necessarily adding much power. Groovy builders are certainly not sugar by my definition. They give you all of the power of the Groovy language parser together with a pre-implemented builder pattern. Good value for money.
Have a look at the latest blog with an open mind, it might spark something! I would also be happy to discuss LOB applications too.
Flat View: This topic has 22 replies
on 2 pages
[
«
|
12
]
Previous Topic
