<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Thanks for the thoughts Tim..</div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><font class="Apple-style-span" color="#000000"><br class="webkit-block-placeholder"></font></div><div>I think the perception of Go being complicated also comes from people's familiarity with Fuse. Fuse was easy to use, but went pretty deep by comparison, which could be throwing people. </div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>I think for projects, the drive is to find something that works and is already built because you need it immediately and don't have extra time to mess around thinking about the mechanics of it. Fuse was geared toward prepackaging everything in that way and hiding its complexity. So, yeah.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>The idea of building Fuse with Go sounds daunting, and there could be a sense that you are required to roll all that functionality yourself, even though it might not be required for the code you're writing. People hate losing options, even when it costs them.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>I can't wait to get time to show you guys this tutorial on how you can build a parser in just a few minutes. It is really, super easy. It doesn't have too many complex features in it, true, but I think as time goes on people will start building those out again.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Also, it's possible that people are confused by the methodology change. Instead of controlling everything through the Fuse class, you create individual tween objects, which <i>seems</i> more complex.</span></div></div></blockquote><br></div><div>Actually that's a misconception right there – the Fuse style parser I wrote worked with static methods, where you never see any tween classes at all. So, yes the tween objects are exposed for OO-style extensibility, but that does not limit you to that style as your final end product at all. For example let's say you write a tween class like HydroTween.. simply add a static method HydroTween.go() that generates and starts a tween, and you have a totally clean usage. </div><div><br class="webkit-block-placeholder"></div><div>I like that it gives you both options – you can still make a new tween and store it in your code for reuse, which is far more efficient than generating one every time, or use the static call to avoid having to bother making the instance and then starting it. Even a third usage would be new CustomTween(...).start() which is pretty much the same as the static call would be, unless the static method does something special to it. </div><div><br class="webkit-block-placeholder"></div><div>Go not about offering "features" that you have to learn, like an API does. The options that it leaves open are just normal AS3 coding options that are always there... maybe people are just uncomfortable <i>not</i> being locked into one narrow way of doing things?</div><div><br class="webkit-block-placeholder"></div><div>- m</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div></body></html>