Re: rough first impressions

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

miles,

On Sunday, April 13, 2003, at 12:37 PM, Miles Egan wrote:

> (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.

yeah i've thought about at least adding synonyms such as defclass.  a 
lot of people grumble at the beginning but then seem to like the 
terseness and the saved columns.

> * 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.

yeah i've thought about more declarative ways of specifying an 
iteration protocol, perhaps with a macro that expands into the various 
methods.  i definitely wasn't ready though to add coroutine support.

> DISLIKES:
> * <type> notation
> Is it really necessary to so strongly distinguish types syntactically?

it's just a naming convention.  you can name your types whatever you 
want.  you can even alias the builtin ones if you like.

> 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))
> ?

actually what i was thinking was changing goo over to using case 
sensitivity and having all caps be the convention for types.  this 
saves characters and is pretty standard and lets you name the 
constructors by lowercasing the type name.  lots of lispers object to 
case sensitivity and using the shift key (except to type parentheses).

> * {} 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?

it is.  i agree that the curly notation is very experimental.  i really 
wanted to use curlies for a terse closure notation (as is done with 
smalltalk blocks).  the seq abbreviation just fell out of that.  i do 
like arc's use of do for seq.  it seems worth saving one more character 
for something so used.  the other option is to just favor using 
closures for control structures (ala smalltalk) and then not really 
needing seq that often.  this is where the terse closure notation wins 
big.  that's a big makeover though.  not sure.  i'm on the fence.

> * 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.

you can pretty much do this.  the only exception is local functions.  
these could be done as generic functions as well and allow users to 
have multiple methods on a given local generic.  in general, i think it 
is a mistake for users to use raw methods as this precludes future 
extension (of course this might be what the user wants but this is 
meant to be a very dynamic language).

of course, internally i need to have non generic functions to bootstrap 
the system.  it's open for debate.

> 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?

i'm not planning on taking on python.  i'm interested in a number of 
research directions and application areas.  i've got a pretty good base 
and now plan to push it.  i will continue to make it available and 
respond to suggestions but i don't have world domination in mind.

jonathan