Author: Vincent Diepeveen
Date: 15:07:52 11/15/02
Go up one level in this thread
On November 14, 2002 at 23:35:14, Dan Andersson wrote: >What are you trying to prove? Lazy evaluation, in the CS sense, can be >optimized. As can most anything. Using well known transformations. A language >implementation can have some implementation detail that makes it slow. Like >making assignments immutable for example. That makes it neccessary to destroy >and recreate all data at certain points. That is slow. But then you use a tree >representation of large data and you go from N to log N. Or list access may be >by traversion. Then you use a good data representation. Slowness usually stems >from poor comprehension on the programmers part. Using lists as arrays an such. > >MvH Dan Anderssond Theoretically you can use years 50 technology with very old computers to fly to Mars too. However a possible mars mission will use the latest technology. So if you manage to optimize your years 70 functional languages very well for a compiler for a certain cpu, then we have a new generation of CPUs already. The compilers for the imperative languages will be ready by then. The functional language compilers will only look like years 70s. Everyone abandons them therefore. There are other practical problems with languages like Gofer. I wrote a checkers program in it. That's not a simple 10 line program. That's a few thousands of lines of code. That's hundreds of functions. It's complete chaos. Imperative programming is completely superb to that. Any serious program is not possible to get written in a functional language. It's chaos. It's idiocy to optimize such code to working code. Now you try to explain to me that you can write an even bigger compiler than all other imperative compilers combined yourself, which also is doing the same job, and you can do it while they move on to newer and newer cpu's? Please be realistic. Those languages will *never* be optimized as well as the current imperative languages are. It's too much code to let it optimize well. I challenge you to write an efficient move generator in a functional language and then tell me what speed it produces semi-legal moves. then we can compare it with the speeds the C programs get. 0 bytes of inline assembly. Let's compare with DIEP, Yace and some others. No theoretic nonsense please. I wrote thousands of lines of functional language and after that i realized better than the professor who had to look after all that code, how impossible functional languages are from practical and realistic viewpoint! It's *impossible* to optimize that very well. Best regards, Vincent
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.