Michael Sherwin wrote: I have been thinking of trying a new language, so I have been reading about various ones and downloading interpreters and compliers for them. Have not found a Windows Haskell compiler yet, do you know of any?
By far the most popular Haskell compiler is GHC (the Glasgow Haskell Compiler), which exists for all major platforms. You should be able to find it easily from http://www.haskell.org.
And what is haskell and why would one wish to use it?
Haskell is a pure, statically typed, lazy functional language. Rather than trying to give a detailed description myself, I'll just provide links to the Introduction from the Haskell web site, and to the Preamble of the excellent "Yet another Haskell tutorial".
I am still not a very experienced Haskell programmer, but here are my opinions so far:
Haskell makes it possible to express many algorithms in a remarkably compact and elegant way. I am not yet sure how well it works for ordinary humans working on large real-world apps (for wizard programmers, it clearly works well, as proved by the Darcs version control system and the Pugs interpreter for Perl 6, among other examples). I also don't know whether I will ever want to use it for anything serious myself, but trying to learn it is great fun and probably beneficial for my general programming skills.
Haskell is pedagogically useful because of its purity. In multi-paradigm languages like Common Lisp (and, to a lesser extent, OCaml), you can continue to use the techniques you know from imperative languages. Haskell forces you to do everything with functional programming.
For chess programming, Haskell is probably a poor choice. The current Haskell compilers don't generate very fast code.
Lisp/Scheme seem like extreamly expressive languages at the cost of a little speed and can make doing hard things a little easier. However, as you stated before, chess code is rather straight forwad and there is no benifit to using lisp/scheme.
Lisp and Scheme, despite their superficial similarities, are actually very different languages. I would say that they are at least as different as C and Java.
O'caml is very interesting and does not seem very difficult to learn. Almost lisp like with out the parenthsis. Very C like with very high level features. To tell you the truth I do not know what O'cml is. Description and documentaition is sparse and terse. It looks like a very concise language that is designed so the compiler can do a good job optimizing and so the programmer can approach each task using a consistant methodology.
I am far from fluent in OCaml, but I don't think it is very similar to Lisp, except that they both support (but don't enforce) functional programming. Lisp is dynamically typed, OCaml is statically typed. The object systems are entirely different. Lisp allows you to manipulate programs as data, while OCaml does not.
OCaml seems like a nice language (although the syntax hurts my eyes), and has the advantage of a good optimizing compiler.
Any or all of what I have said can be wrong and any comments or corrections are welcome. Keep in mind that I am a speed freak and am not interested in a slow language.
Whether a complicated program is fast or slow depends mainly on the efficiency of the algorithms used, and not on the compiler or programming language. In practice, it is therefore not at all unusual that a program written in some high-level language can outperform a C/C++ program, because high-level languages make it easier to discover and implement good algorithms.
An interesting comparison of the practical performance of C/C++, Java and Lisp for a simple programming problem can be found here. The programming problem itself can be found here. It is interesting to note that even for this relatively simple programming exercise, the Lisp solutions are on average much faster than the C/C++ and Java solutions.
Also, in many real-world situations (at least in my life), what matters isn't the total runtime of the program, but the total time spent from the moment I start working on the program until I have a solution. As an extreme example, assume that you want a list of the first 100 Fibonacci numbers (the Fibonacci numbers are the sequence 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ..., where each number is the sum of the two previous numbers). In Haskell, I would spend about 30 seconds writing the following simple program:
- Code: Select all
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
main = mapM_ print (take 100 fibs)
In Lisp, I would spend about 60 seconds writing the following code:
- Code: Select all
(defun print-fibs (n)
(iter (repeat n)
(for a previous b initially 1 back 2)
(for b first 0 then (+ a b))
(print b)))
In both cases, the program would finish in a fraction of a second. In C/C++, I might first try something similar to the Lisp solution, but find that it doesn't work because of integer overflow. I would then have to either find, download and install some sort of multiprecision arithmetic library, read the documentation, and try to use it in my program, or spend several hours (or days, depending on how sophisticated algorithms I want to use) implementing my own. In the end, the C/C++ program would, if I were lucky, be twice as fast as the Haskell/Lisp program. But even this is far from sure; it depends on how the efficiency of whatever multiprecision arithmetic library I found compares to the built-in arithmetics in Haskell and Lisp.
When you talk about "fast" and "slow" languages above, what you really mean is probably the speed of arithmetic and bitwise operations with 32-bit and 64-bit machine integers. For this, C and C++ are hard to beat (some other languages could in principle be equally fast, but in practise the optimizing compilers for C and C++ are the best). OCaml and Lisp are probably better than Haskell in this respect, but will still be a bit slower than C in most cases.
Also Shogi is very chess like, so wouldn't your criticism about using lisp for chess also apply to Shogi?
Absolutely - that was precisely what I was trying to say. I meant that this was a reason for me to program Go rather than Shogi.
Tord
