Y-combinator in Erlang

[Joe Armstrong]

> >   Now  how the  average  Håkan might  have  written it  is a  entirely
> > different matter :-)
> 
> As a named function. Whatever you gain in expressive power with funs 
> you risk losing by people using them in a way that is hard to 
> understand.
>

Almost anything can be abused if you try hard enough.

What does:

	foo() -> 
	    Z = make_ref(),
	    bar(self() ! {Z, left}, self() ! {Z, right}),
	    receive
		{Z, I} ->
		    receive
			{Z, J} ->
			    I
		    end
	    end.

	bar(_, _) -> void.

do?

> Classic example. Consider the higher-order function (standard math 
> notation):
> 
> twice(F)(X) = F(F(X))
> 
> Let double(X)=X+X and figure out what F(1) is, where 
> F=twice(twice(twice(twice(double)))).
> 
> I'm just arguing that sometimes power tools are not good things.
> 

  I  agree  entirely  -  you  must constantly  strive  to  write  "mind
boggling simple code"

  One good way to to this is to mentally repeat the phrase:

  "I must write  as inefficient code as possible"  one thousand times
before breakfast ever day :-)
 
  K & P still applies: (I paraphrase)

	1) make it right
	2) make it fast once you've got it right
	3) keep it right as you make it faster

  IMHO the fast majority of programmers (myself included) don't get past 1)

  The well tried method used by many large industrial concerns is:

	1a) Ship it first
	1b) Make it fast 
	2)  Debug it
	3a) Understand the problem
	3b) Discontinue the product

  1a and 1b are done concurrently as are 3a and 3b

  Often they never get to 3a - sometimes they use the accelerated design
method of 1b followed 3b.

  This method is not recommended.

	/Joe



> -- Hakan
>