Chess programming language

[Don]

I am a fan of new programming languages and I'm constantly taking a peek at anything that comes along - in the hopes that someday something might come along that is better than C for writing chess programs. I don't really expect this to happen, but it doesn't hurt to dream.

Recently I ran across something pretty interesting. It's a language called "Go" and my very impression was, "yeah right", another programming language that claims it is great. However, when I saw the name "Ken Thompson" and "Rob Pike" attached to it, I got excited.

There have been a few close calls, but so far nothing has enticed me away from C. The VAST majority of languages are interpreted and slow - at least for the needs of a world class chess program.

The close calls have been D by digital mars, Lisaac and Vala. What these languages have in common is that they are compiled to fast native code and they are system languages, in the sense that you can have good low level control over your hardware. And they are much more modern than C, which is a wonderful language, but was designed 2 million years ago and despite much modernization still feels like driving a model T.

Languages like Java and their derivatives are reasonably fast, but seem to give up too much control - I cannot imagine writing a super high performance chess program in java or scala.

This of course may prove to another disappointment, but it certainly deserves a look. With Ken Thompson involved I feel like there is someone there who gets it. And even if it doesn't replace C for chess it might replace the high level languages I use.

Here is a blurb from the web page:

Go was born out of frustration with existing languages and environments for systems programming. Programming had become too difficult and the choice of languages was partly to blame. One had to choose either efficient compilation, efficient execution, or ease of programming; all three were not available in the same mainstream language. Programmers who could were choosing ease over safety and efficiency by moving to dynamically typed languages such as Python and JavaScript rather than C++ or, to a lesser extent, Java.

[Dan Andersson]

Go feels interesting and at first more than a bit familiar. When I read who were involved the pieces fell in to place especially after reading the primes example. There are lots of Limbo and Modula ideas as well as an OCaml like type system.

MvH Dan

[Dann Corbit]

Do you have a link for Go language?

[Dan Andersson]

http://golang.org/
http://groups.google.com/group/golang-nuts

MvH Dan Andersson

[michiguel]

http://golang.org/
http://groups.google.com/group/golang-nuts

MvH Dan Andersson

I was getting excited until I found a huge turn off:

"Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue operation after non-fatal errors instead of crashing..."

....We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

It bothers me when the designer of a language does not give me a tool because he/she thinks I may use it in the wrong way. This is the same silliness of not having goto and break in the traditional pascal. Good for a pedagogical language (the original intention) but... but... one of the reasons C was so successful, IMHO, is because it was never dogmatic.

Still, building your own assert is easy...

Miguel

[Don]

http://golang.org/
http://groups.google.com/group/golang-nuts

MvH Dan Andersson

I was getting excited until I found a huge turn off:

"Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue operation after non-fatal errors instead of crashing..."

....We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

It bothers me when the designer of a language does not give me a tool because he/she thinks I may use it in the wrong way. This is the same silliness of not having goto and break in the traditional pascal. Good for a pedagogical language (the original intention) but... but... one of the reasons C was so successful, IMHO, is because it was never dogmatic.

Still, building your own assert is easy...

Miguel

I'll bet some oppressive government bureaucracy was behind this decision. Well I for one am not going to take it! I never noticed this before, but now I'm mad. Fighting mad! They can just keep their silly little language!

[Dann Corbit]

http://golang.org/
http://groups.google.com/group/golang-nuts

MvH Dan Andersson

I was getting excited until I found a huge turn off:

"Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue operation after non-fatal errors instead of crashing..."

....We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

It bothers me when the designer of a language does not give me a tool because he/she thinks I may use it in the wrong way. This is the same silliness of not having goto and break in the traditional pascal. Good for a pedagogical language (the original intention) but... but... one of the reasons C was so successful, IMHO, is because it was never dogmatic.

Still, building your own assert is easy...

Miguel

I'll bet some oppressive government bureaucracy was behind this decision. Well I for one am not going to take it! I never noticed this before, but now I'm mad. Fighting mad! They can just keep their silly little language!

It's enough to make me bag it.
I use asserts() like Fabian does.

[Don]

http://golang.org/
http://groups.google.com/group/golang-nuts

MvH Dan Andersson

I was getting excited until I found a huge turn off:

"Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue operation after non-fatal errors instead of crashing..."

....We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

It bothers me when the designer of a language does not give me a tool because he/she thinks I may use it in the wrong way. This is the same silliness of not having goto and break in the traditional pascal. Good for a pedagogical language (the original intention) but... but... one of the reasons C was so successful, IMHO, is because it was never dogmatic.

Still, building your own assert is easy...

Miguel

I'll bet some oppressive government bureaucracy was behind this decision. Well I for one am not going to take it! I never noticed this before, but now I'm mad. Fighting mad! They can just keep their silly little language!

It's enough to make me bag it.
I use asserts() like Fabian does.

Maybe we can petition them to put assert in the language. Picket lines, the whole works. We can think of clever slogans such as, "stop asserting that we don't know how to use assertions." or "We assert that nobody will want to use your stinking language."

Or how about this one: assert( !assert == broken_code )

I have an issue with the semi-colons too. They are so wishy washy about it. They tell you can use them if you want, but that you don't have to most of the time. I sense an underlying insinuation that they think we are stupid if we use them. They must not trust anybody to make good decisions but themselves!

[Dan Andersson]

I'm not too upset about assertions myself.
I'm thinking that a strongly typed language with minuscule compilation times is a prime candidate for a superior tool like QuickCheck. Originally a combinator library for (semi-) automatic testing of Haskell code it has been reimplemented for many imperative and functional languages.
There are impressive demonstrations of the commercial Erlang QuicQ tool finding race conditions in multi threaded programs.

MvH Dan Andersson

[Dan Andersson]

Posted on the golang-nuts and there is a QuickCheck package so the lack of assert isn't even a problem. Missed it myself. Smacks forehead. Blames flu. Reaches for ibuprofen ...

MvH Dan Andersson