Slashdot Mirror

That's an interestingly nonsensical restriction.

http://www.defmacro.org/ramblings/lisp.html

This is an excellent article about functional programming.

Ocaml has a very good reputation. It compiles to native code, and has performance comparable to C. It's agnostic about programming style. You can use it as if it was C with garbage collection, or you can us it in an fp style, or you can mix the two. There are good libraries. Because of the way the garbage collector is designed, it doesn't support SMP to the extent that erlang does. The design of ocaml includes some conscious trade-offs of elegance for performance. In particular, strings are not lists.

Erlang's claim to fame is that any code you write will automagically take advantage of SMP.

Haskell's design focuses on elegance, sometimes at the expense of performance. It's strongly focused on the functional style.

TFA is a fun read. Too bad XML sucks. As Jerome and Philip Wadler write, "[T]he essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."

Lisp had the same problem solved 40 years earlier. While a lot of people find S-expressions verbose, XML is quite a bit more verbose. Slava Akhmechet has a nice essay on the relationship between the two notations.

Wrong, wrong, wrong. :)

Well, Lisp doesn't look like XML. But its s-expressions are able to deal with tree like structures just as easily. If you have some free time, I suggest reading http://www.defmacro.org/ramblings/lisp.html.

I've been programming(not professionally) for 10 years.
Mostly in C, Python, ECMAscript and Java. I've been recently trying to get in to functional programming after reading a really interesting article: http://www.defmacro.org/ramblings/fp.html. I really liked the concepts.

I started by looking at Erlang and Haskell, but I just don't like their syntax which made it really difficult to stay motivated in learning. Thinking functionally was pretty easy, but thinking functionally to do something that involves state is confusing.

I've recently been looking at scheme and using ECMAscript functionally, which I like the syntax of more.

The other issue with FP is that they tend to treat all problems as a collection of simultaneous equations -- things that can be evaluated at any time in any order. There's a huge class of computing problems that can't be described that way. You can't unprint a page on the line printer.

This is what lazy evaluation is for. You actually can describe printing a page functionally. What'll happen, internally, is that the topmost print function won't terminate until it has satisfied all its "dependencies". Just like a procedural language, where a function returns when every function it called returns, recursively. But a functional language is just a little slicker.

Let's consider a plain old mathematics problem. Let's say we want to find the area under the line y = x on (0,1).

Now, obviously, we have to evaluate the integral $\integral x dx$. Note that this is an operator on functions. Given a function (of real numbers) f, we can find the anti-derivative $I(f) = \integral f(x) dx$.

To compute the area under the line, you have to evaluate a function A(f,a,b) defined by (I(f))(b) - (I(f))(a). (The value of the anti-derivative of f at b minus the value of the anti-derivative of f at a).

Here's the slick part. The definition of the function is in some sense the computation. I described the functions I and A in one order, but I could have described them in the other, just by using the same notation and implying that the other definition would come soon. And even if I defied A but didn't define I, you would still know that A(x^2, 0, 1) was (I(x^2))(1) - (I(x^2))(0). In a parallel system, that computation can be done at the same time as I(f), I(f)(0), and (I(f))(1), although all three have to be done before you know the actual area.

Also, check out: http://www.defmacro.org/ramblings/lisp.html

Still not short enough for me though. [...] Furthermore, I'm not sure it makes ANY sense to have commands in XML.

I bet you'll find this article at least a little bit interesting; http://www.defmacro.org/ramblings/lisp.html

Actually, the very first thought I had after the first sentence of the summary was that Lisp would be a much better match than XML for something like this. The moment you try to treat code as data, you can be sure Lisp is what you want, although I believe Rebol (http://www.rebol.com/) tries to do something similar.

They handle state in a scoped manner that is hard to describe without lots of example code. The best example I can think of is Erlang. If you look at the link I posted above (re-posted for your convenience: http://www.defmacro.org/ramblings/fp.html ) they mention Ericsson inventing the functional language Erlang to handle concurrency.

As for how state functional languages handle state; state is held in the parameters a function is called with. The simplest example is recursion; in an imperative program using a for loop or a while loop or something like that, state is stored in a counter variable that gets incremented or decremented or somehow changed each time the loop is run. In recursion, if the ending condition is not met, the function calls itself with slightly differing parameters; the parameters keep track of the state, but unlike imperative programming, since the parameter is not a variable that can be changed once a call is made, it is impossible to have bugs caused by unexpected or unintentional changes to a variable in the scope of other operations that might change it. FP doesn't permit any declared values to change, so there are no "variables", just constants.

If this makes no sense at all, you'll just have to program a few loops in an imperative language, and a few in a functional language using recursion, and see the difference. It's a lot easier to show interactively than to explain.

<copy>
    <todir>../new/dir</todir>
    <fileset>
        <dir>src_dir</dir>
    </fileset>
</copy>
 
(copy
  (todir "../new/dir")
  (fileset (dir "src_dir")))