The simplicity cliche

[Henk]

The Zen of Python
..
Flat is better than nested.
..

This is a dangerous one.

For instance if you expand( (a1 + b1 .... z1) * (a2 + b2 ...z2 )) readability and efficiency may get worse.

Of course substitute groups of one element back in the parent group. Also groups that are not referenced now may be referenced in the future.

[nionita]

But complex things can be combined from simpler ones (composition). When we will have even better optimizing compilers, this will be the way.

Problem is, I am 65 years old now. I won't be programming long enough to see a compiler basically "rewrite" a program like that.

The solution may be not so far as you think

When you have a few days for fun, take a look at Haskell and its main compiler GHC. Keywords: deforestation, program transformation.

Interesting enough, one of the optimisation method used there (which is also open to the end user, i.e. programmer) is "rewriting rules".

[bob]

But complex things can be combined from simpler ones (composition). When we will have even better optimizing compilers, this will be the way.

Problem is, I am 65 years old now. I won't be programming long enough to see a compiler basically "rewrite" a program like that.

The solution may be not so far as you think

When you have a few days for fun, take a look at Haskell and its main compiler GHC. Keywords: deforestation, program transformation.

Interesting enough, one of the optimisation method used there (which is also open to the end user, i.e. programmer) is "rewriting rules".

That is a Looonnnnnngggg way away from what was being discussed. And the "rewriting rules" are pointless, we were talking about the compiler front-end doing this, not the human via rules...

[nionita]

But complex things can be combined from simpler ones (composition). When we will have even better optimizing compilers, this will be the way.

Problem is, I am 65 years old now. I won't be programming long enough to see a compiler basically "rewrite" a program like that.

The solution may be not so far as you think

When you have a few days for fun, take a look at Haskell and its main compiler GHC. Keywords: deforestation, program transformation.

Interesting enough, one of the optimisation method used there (which is also open to the end user, i.e. programmer) is "rewriting rules".

That is a Looonnnnnngggg way away from what was being discussed.

If you mean the current performance of Haskell programs: it is still a way but not so long anymore (LLVM backend). But I was talking about expressing complex algorithms by composing simpler parts (functions) - and this is already in the language, NOW.

And the "rewriting rules" are pointless, we were talking about the compiler front-end doing this, not the human via rules...

No, they are not at all pointless: you can write a library of general combinators (aka EDSL) and use rewriting rules to express general simplification laws. Then the programmer can use those combinators and the resulting program is: a) simpler (and easier to read) and b) optimized by the compiler.

[Henk]

[quote="nionita"][quote="bob"][quote="nionita"][quote="bob"][quote="nionita"]But complex things can be combined from simpler ones (composition). When we will have even better optimizing compilers, this will be the way.[/quote]

Problem is, I am 65 years old now. I won't be programming long enough to see a compiler basically "rewrite" a program like that.[/quote]

The solution may be not so far as you think

When you have a few days for fun, take a look at Haskell and its main compiler GHC. Keywords: deforestation, program transformation.

Interesting enough, one of the optimisation method used there (which is also open to the end user, i.e. programmer) is "rewriting rules".[/quote]

That is a Looonnnnnngggg way away from what was being discussed.[/quote]

If you mean the current performance of Haskell programs: it is still a way but not so long anymore (LLVM backend). But I was talking about expressing complex algorithms by composing simpler parts (functions) - and this is already in the language, NOW.

[quote="bob"]And the "rewriting rules" are pointless, we were talking about the compiler front-end doing this, not the human via rules...[/quote]

No, they are not at all pointless: you can write a library of general combinators (aka EDSL) and use rewriting rules to express general simplification laws. Then the programmer can use those combinators and the resulting program is: a) simpler (and easier to read) and b) optimized by the compiler.[/quote]

Chess programming is all about performance. Simplicity, clarity might be a way to achieve this. Performance is crucial here. Or are we writing quasi mathematical poems. Possible too.

[nionita]

Chess programming is all about performance. Simplicity, clarity might be a way to achieve this. Performance is crucial here. Or are we writing quasi mathematical poems. Possible too.

Sorry, I thought we talk about programming in general. At least this is what I understood from the topic here.

[Henk]

Chess programming is all about performance. Simplicity, clarity might be a way to achieve this. Performance is crucial here. Or are we writing quasi mathematical poems. Possible too.

Sorry, I thought we talk about programming in general. At least this is what I understood from the topic here.

Maybe you can use these functional languages for prototyping.
Maybe it will be possible to translate into efficient machine language.
Also no one writes chess programs in machine language nowadays.
Pure functional languages are very suitable for parallel execution.

[jdart]

A number of these do not apply to chess:

In the face of ambiguity, refuse the temptation to guess.

Computer chess is full of heuristics that work "most of the time" or "well enough" but are technically not sound in all positions.

Now is better than never.

Not when you're exploring a huge search tree - you want most of it be be "never" visited.

--Jon