[Golist] Go: Scary-complicated?

[Patrick Figueroa]

Thanks for clarifying a bit Moses... I also think that a great way for  
some users to start diving into Go is to see it as a comparison to  
Fuse. I know a lot of designers and developers (including me) know  
Fuse inside and out after using it for so long. I think perhaps a  
great way to introduce Go to those veteran Fuse users is with a simple  
fla or tutorial showing what Go is in a Fuse context. A lot of the  
time I learn new techniques through dissection of a fla because things  
are already grouped in a familiar environment (e.g. this is a nav  
button, this is an animated mc, this is what happens after it  
animates, etc...). In this context we all know what each item is  
supposed to do and how we would code that using Fuse, but to show how  
that would be coded with Go would put things into perspective. I hope  
I didn't get too confusing there... I can clarify a bit if things  
don't make sense.

Patrick.



On Mar 4, 2008, at 4:32 PM, Moses Gunesch wrote:

> Thanks for the thoughts Tim..
>>
>> 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.
>
> 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.
>
>> 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.
>
> 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.
>
>> 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 seems more complex.
>
> 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.
>
> 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.
>
> 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  
> not being locked into one narrow way of doing things?
>
> - m
>
>
> _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080304/8cf0c14d/attachment-0001.html