Thursday, December 8, 2011

In this post, I'll respond to the comments and feedback to my recent blog on 2 misconcepts about functional programming.

I write the original blog because I found it funny that languages like
XQuery and XSLT, which I feel so 'functional', is not actually
referentially transparent. Yet monadic I/O as implemented in Haskell,
which I feel so 'procedural' is referentially transparent. So my
intension in the blog was to come up with something that can better
depict the computation model of XQuery and XSLT. My approach was to
keep the concept of RT, but stretch the concept of functional
programming. From the feedback, I can see that people think that's not
acceptable.

Tuesday, December 6, 2011

In the previous blog, I've shared my thoughts about functional
programming. Sometimes it looks like to me that procedural programmers
are side-effect addicted, whereas functional
programmers tend to have side-effect phobia. Hard-core functional
programmers
tend to spread the feelings that side-effects are evil. Yes, if the
side-effects are unnecessary, then they should be eliminated by all
means. But if the side-effects are desirable (by requirements), then
there's nothing evil about them. There's no impurity in a program if it
allows desirable side-effects.

Everyone agrees that side-effects should be controlled and carried out
in a structured manner. The question is how. I think the Holy Grail of
current programming language design is to find the best way to mix
procedural programming with functional programming. In the following
blog, I'm going to talk about the procedural design in Candle, and how
it compares to similar designs in languages, like Haskell, Erlang and
Clojure.

Monday, December 5, 2011

It's interesting that almost every old and new language that claims to
have some functional support has to go through the trial of its purity,
like Perl, Scala,
Erlang,
Ruby,
JavaScript and Python.
Candle is no
exception. Candle's last release announcement to
LtU triggered some interesting discussion about whether the functional
features in Candle are pure. I finally have sometime to share more
about my thoughts on this issue. I'd like to talk about 2 misconcepts
about functional programming. The first misconcept is that dynamic scope variables are not functional.
The second misconcept is that monads
are functional. I know the following writing is going to
kick up the dust, but it is better than we settle without thorough
thinking.