rough first impressions

[Miles Egan <miles@xxxxxxxxx>]

(Coming from the perspective of someone that's been a daytime
perl/python/ruby person and nightime lisp/ocaml person for the last
several years.)

LIKES:
* terseness vs common lisp
Code compactness contributes to readability, at least to a point.  I
think goo strikes a good balance here although the d? keywords are a
little bit hard to distinguish.

* pervasive object orientation
One of Ruby's big strengths.  I think this is the right way to do this.

* prefix syntax
Macros or bust.

* multimethods
I was very disappointed to hear that they're leaving these out of Arc.

* property / member function equivalence
Aka the Uniform Access Principle.  Another of Ruby's inspired moves. 
Switching from direct member access to a member accessor function,
especially in a dynamically typed language is a huge PITA.  The only
safe thing to do in Python is to defensively write a lot of boilerplate
getter/setter code for every member.  In Ruby I can do the lazy thing
first and fix it painlessly later.

* collection stuff
Probably my favorite thing about Ruby is the elegance of it's iteration
mechanisms and corresponding syntax.  This feature alone makes me twice
as productive in Ruby as in Python.  Building this in is a smart move. 
Goo's iteration seems to have an even more imperative flavor than
Ruby's, which is a bit ironic given Goo's roots.

* direct module/filename mapping and hierarchical modules
I like (use goo/mail/smtp).

* optional type declarations
I definitely miss this in the big 3 scripting languages and I'm assuming
this will open the door for compiler optimizations that are difficult or
impossible without them.  I'm not sure if I agree with the convention of
adding type annotations to every function.  Seems tedious.

DISLIKES:
* <type> notation
Is it really necessary to so strongly distinguish types syntactically? 
Is this done primarily to help the compiler?  You've already got the |
for type annotations, couldn't you just as easily write:
(dm mygenfunc (a|int b|str => str))
?

* {} for (seq ...)
This is too hard to distinguish from () in deeply nested expressions and
doesn't seem like enough of a win over (seq ...) to justify new syntax. 
I guess if you support reader macros this could just be a simple reader
macro, right?

* simple function vs generic function distinction
It bugs me a bit that there are two completely different kinds of
methods and that I have to make up my mind which one to use pretty early
in my design.  I don't know anything about multi-method implementation
so maybe this is nuts, but it would be cool if all functions were
generic.

Anyway, I think it's a pretty intruiging package.  How serious are you
all about developing this thing?  Is it primarily a research vehicle or
do you really intend to take on Python?