[Golist] Go: Scary-complicated?

[Moses Gunesch]

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


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