Re: what is the best language for go: Re: [computer-go]Score estimating

[Xavier Combelle <xcombelle@xxxxxxxxxx>]

Don Dailey wrote:

> The two languages are very similar.  I have experimented with both and
> I much  prefer Ruby which  I found a  lot more intuitive  and natural.
> This could  be because  I learned Python  first.  But the  tendancy is
> like  the first  thing more  and the  second thing  has to  be clearly
> better to win you over.  It's interesting that we both did it this way
> and came to different conclusions.
>  
I can only make suppositions.
Learning Python first seems to be the good way,
because it seems to be more close to C/java programming.
(This is a plus for catch C/java programmers)

The language in itself seems more clean in Ruby.
Maybe you learn python quite a long time ago,
and python evolve in a very good way. For exemple in
the future 2.4 version, the syntax of classmethod
will be more clean.

Concerning the standard library, python seems more
"battery included".
http://www.rubycentral.com/ref/index.html
http://docs.python.org/lib/lib.html

So finally, there is nearly no differences between languages
is thin and after comparing the standard library I still consider
Python as better.
However, the languages are so close that if you begin
a go programm in Ruby, I will probably follow you.

> The idea  that is suggested  in these kinds  of languages is  to write
> your software in  them and then convert the time  consuming parts to C
> code when you need performance.  I'm not sure this is all it's cracked
> up to be.  When you design  something in Ruby or Python you will think
> about it a  whole lot differently that if you started  in C.  It's the
> old top down  versus bottom up design philosophy  again.  I've changed
> over many  years to  thinking bottom up  when it comes  to performance
> programming.  Top down seems to "box you  in" in a way I can't seem to
> easily communicate.  In this case it's easy to communicate because you
> build  it  in  the most  convienent  high  level  way supported  by  a
> language, and then you can be  "boxed in" when it comes to making this
> work in C.
I am totally agree, except for the conclusion. I played recently
with gnuGo and it appears that performance is *not* the point.
He played nearly as soon as I played. I think the design of a go
programm should use all the power of a high level language and
not be directed by performance purposes.
To keep the best of both world, maybe the low-level librairies
should be realized in a separated process from the high level.
I am currently thinking about making a wrapper of gnugo for
Python wich could help us to see if the two world could
communicate in a productive way

Xavier

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/