[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what is the best language for go: Re: [computer-go]Scoreestimating
Ok, it's all a matter of opinion anyway. Ruby is a BIG project
language in my opinion, even though you can whip out little things
almost instantly. Python is the same in this regard. If a large
project can deal with less than the fastest compilers, I just cannot
imagine thinking it will go faster with less errors in c++ than in
Python or Ruby.
> Java and C++ have been proven on countless huge projects, I don't think you
I personally think that's ridiculous, buy only my opinion. C++ has
been USED on countless projects, but being used a lot doesn't mean
it's been "proven." By that definition C has been "proven" as well as
Fortran and Cobol and RPG, all of these languages still being used for
more years than Java. And c++ is one of the cruftiest bug prone
languages I know of (along with C.)
I do agree with you on one thing in particular though. Communication
between programmers is the biggest thing. I don't see how this is a
language issue unless you are talking about being able to read other
peoples code? If that's the case, are you saying c++ is more readable
than Python/Ruby?
I think languages like Python and Ruby are not taken seriously because
of human nature. Most people are extremely conservative about trying
new things when the old things have been "proven" (which means it's
been used for a while, not that it's any good.) The other mentality
is what I call the "sheep" mentality. For instance Microsoft can make
a language almost instantly popular just by announcing it.
I'm not exempt, we all do things for reasons like this, not for
strictly pragmatic reasons. (Probably the biggest reason is that
someone has a "boss" who may not really know what is going on and
dictates this or that language. He makes the "safe" choice because he
has to justify it to HIS supervisor. I know this exists because I've
seen it happen that the supervisor had to suggest the better choice
because the underling (who also wanted to use the better choice) was
afraid to suggest it (sometimes supervisors really are smarter.)
> For example the following Ruby program runs just fine until you enter "b" at
> which time you get a *runtime* error:
> a = gets.chomp
> if a == "b"
> a += 100
> end
That's true enough, but would you rather chase down this bug which is
completely obvious on failure, or find a C bug (like a memory leak)
that may not show itself for months?
In C you get to typecast everything to death. That's a lot of fun and
really makes the program safe. I'm being sarcastic of course.
No language solves every problem, but Ruby makes up for this many
times over. There are way too many things to trip over in C++, very
few in Ruby/Python. The bugs that happen in C tend to live in the
code for a few weeks or months before even noticed.
I've read all the hype about static typing and agree to a point. But
the truth of the matter is that you can't believe too much that you
read. This talk is usually mostly promoted by devotee's of the
languages that do static typing. (But remember I said I agree to a
point.) On the other hand Perl weenies like to brag about perls
dynamic typing and claim it makes you more productive.
- Don
>
>Someone said this:
>
> >>I'm not sure why it wouldn't be OK for bigger programs (ie. a Go
>program)
> >>as long as you're prepared to live with dynamic typing and code up
>plenty
> >>of Unit tests.
>
>Whoever wrote this doesn't quite get it. Ruby and Python are better
I said it and I think I get it just fine thankyou :-)
>for for BIG projects and was designed for this. Much better than
>lower level languages than Java or C++ etc.
Java and C++ have been proven on countless huge projects, I don't think you
can say the same about Ruby or Python. Static typing comes into its own
when you hava a very big codebase (multi million line) with many (say 20+)
programmers working on it. In that situation it is often communication
between programmers that becomes a bottleneck, and static typing definitely
helps solve that problem in a way that dynamic typing can not.
>
>The unit tests is not more necessary in ruby/python than these other
>languages, it's LESS needed, but it should be done. You will always
I disagree. With dynamic typing the compiler catches fewer errors at
compile time, therefore you need more unit tests to catch those things.
>get better results in any language by testing as you go and making
>yourself go slow to be thorough.
>
>Ruby is strict about types which is the more important thing. It's
>not STATICALLY typed but it is strictly typed. You cannot add an
>integer and a string, for instance, like you can in perl.
Ah, but you can write the source code to do it and you must rely on testing
to detect it.
For example the following Ruby program runs just fine until you enter "b" at
which time you get a *runtime* error:
a = gets.chomp
if a == "b"
a += 100
end
>
>Unless python has changed, it doesn't hide data very well. Ruby is
>way ahead unless python has fixed this, but Ruby always had it right.
>
>- Don
>
cheers,
Peter
>
>
>
>
>
>
> I think this computer language discussion is probably stretching the
> patience of people whose main interest here is computer Go so I'll try
>to
> make this my last post on the topic :-)
>
> >>Regarding Mark's question about large scale development: I'm not sure
>how
> >>Ruby would fare there. It has pretty decent OO features (better than
> >>Python IMHO) which should help. My biggest Ruby program to date is
>only
> >>about 500 lines and it is certainly fine for anything of that size.
> >
> >I really go back to read the Ruby OO features, I did not found
>anything
> >that don't exist in python. Maybe you can give me good pointers on
>web.
>
> The things I didn't like about Python's OO were:
> - lack of private and protected instance variables
> - having to use an explicit 'self' parameter in all methods
>
> Note that I'm not saying Python is a bad language, just that I
>personally
> didn't like it much. I'm sure that lots of people do wonderful things
>with
> Python. I'm equally sure that a sizeable bunch of people will prefer
>Ruby.
>
> cheers,
> Peter
>
> >
> >>I'm not sure why it wouldn't be OK for bigger programs (ie. a Go
>program)
> >>as long as you're prepared to live with dynamic typing and code up
>plenty
> >>of Unit tests. I'd still see it as potentially much more productive
>than
> >>C++ or Java. I agree that speed would be an issue - if you do a
>serious
> >>Go program in it I'm guessing you'd want to re-implement the critical
> >>parts in C once they've stablised.
> >
> >I'm sure that Python can manage such programs.
> >For that there is a similar paquages as in java,
> >but the import system is even more powerful than java one.
> >
> >Personnaly I know Python only since six month
> >and I already made a full working application (even if not finish)
> >which has 888 lignes wich is perfectly extensible and stable.
> >It includes: configuration, special ftp client, language source
>detection
> >C code processing, batch compilation (with system ("gcc ") calls)
> >
> >Biggest aplications full works.
> >mailman (mail list manager) 33 000 lignes of code.
> >Zope (web server and web development environemnt) 403 000 lignes of
>code.
> >
> >And the point is to realize the same functionnality,
> >the code is *really* shorter than java or C++.
> >For exemple, in my project, with the help of introspection,
> >I parsed a file, transform it into a full working Python object,
> >add one simple unittest, all in one file of 79 lines.
> >As far as I remember how I worked in java, I would expect
> >that the same job in java would require at least three
> >classes (one file for each) 80 lines each.
> >That's why I rely believe that Python is three times more productive
> >than java (even including the learning stage)
> >
> >So I don't think that big project in Python is an issue
> >The integration with C is easy (but not tested personnally)
> >
> >So I think it meets better the requirements of go application
> >than C or java. Maybe Lisp is even better, but I know very
> >little about lisp, except that it is harder to learn.
> >
> >Xavier
> >
> >
> >_______________________________________________
> >computer-go mailing list
> >computer-go@xxxxxxxxxxxxxxxxx
> >http://www.computer-go.org/mailman/listinfo/computer-go/
>
> _________________________________________________________________
> There’s never been a better time to get Xtra JetStream @
> http://xtra.co.nz/jetstream
>
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>_______________________________________________
>computer-go mailing list
>computer-go@xxxxxxxxxxxxxxxxx
>http://www.computer-go.org/mailman/listinfo/computer-go/
_________________________________________________________________
Check out news, entertainment and more @ http://xtra.co.nz/broadband
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/