今天终于写了一篇烂东西交上去了，内容空洞，语言乏味~~

This
is not really a research proposal about specific area of functional
programming, but a short essay to show my understanding of functional
programming, Haskell, and some preliminary thinking.

The understanding of functional
programming


Functional
programming is considered as a no assignment statements, no side effects, and
referentially transparent programming paradigm. [1]
Its special
characters and advantages distinguish itself from other programming paradigms,
such as imperative programming languages like C.

In
reality, modular top-to-bottom design can not only reduce the difficulty of
programming and testing, but also improve efficiency by re-use modules. The
most powerful tools in functional programming should be higher-order function
and lazy evaluation, which can improve program modularization greatly. [1]
Higher-order function provides the tool of high degree abstraction, which could
combine existed small modules to build a complex larger module. The lazy
programming style helps to improve the separation of the definition and the use
of computations.

The understanding of Haskell


Haskell
is widely known as a purely functional programming language, which obeys almost
all principles of functional programming paradigm but for side effects in IO
monad. Moreover, it is a very high level language that really close to human
thinking. Although lots of programmers think that their knowledge of lower
level languages are what make them very different from normal computer user, it
is hardly to deny the power and efficiency of abstract thinking, which could be
achieved much easier in humanlike higher level languages, such as Haskell.

Haskell,
as a functional programming language, is more mathematic traceable than other
languages in different programming paradigms. In another word, it is more
suitable to represent mathematical models. This advantage could easily be seen
in the abstract syntax representation in Haskell, which is simpler and clearer
than representations in other languages, such as JAVA. From this point, Haskell
naturally is an efficiently creator of domain-specific embedded languages. Moreover,
considering its mathematical nature, Haskell could also be a great tool for some
other applications, such as image processing.

Why Haskell is not that popular


There
is no doubt that Haskell is such a powerful programming language with unique characters.
However, it is also true that Haskell is not as widely known and used as some other
languages, such as C or JAVA. In my opinion, the reason for this might be
complicated.

There
was a quite interesting question pop up in the class of programming language
technology. Considering Haskell as a very high level language, which should be
very close to human languages, why is it so difficult to manage compare to
other programming languages? The answer from the lecturer was that it takes
time to learn, just like human languages. That is very true; at least I cannot
see anything special when I start with Haskell. In the opposite, some features,
such as the strict type checker, were really annoyed and made me felt tied. It
takes time to see the beauty of Haskell and consume even more time to get
control of them.

Moreover,
compare with other popular programming languages, such as Java, the platform of
Haskell is not that strong, which means programmer might need to do lots of
work all by themselves. The good thing of this is that each time they can pick
and combine very small size modules to achieve their purpose with more
independence and less redundancy. In the other side, this also means lots of
programmers might be doing similar work in different projects, which is another
form of repetition.

What could we do for improvement


There
are at least two things that I think might be helpful for the development of
Haskell.

One
thing is that platform should be continuing completed. More libraries might be
help for reducing the difficulty of programming, especially for people who are
not experts. In additional, a friendly relationship between different
components might be appreciated. For example, I am having a problem with using
ghci and wxHaskell together at the moment. Last but not least, a more
comfortable UI might be very helpful to attract people to use. This could be
very easily ignored by programmers because they already get used to the existed
interface and it does not really matter for them. However, generally speaking,
the more people contribute their efforts in the language, the faster it grows.
I truly believe a better UI could help people to keep developing their
knowledge about this language until they can see its beauty inside.

Another
part that might be optimized is the compiler. In recursive program, even a tiny
ineffective part exists, might reduce the whole program efficiency
dramatically. This amplification forces programmers spent more time on code
optimization. However, their optimization is heavily depended on their
knowledge and experiences, which is not always reliable. In the same time,
similar work is also done by compilers. In a normal compiler, there is a code
optimizer between the intermediated code generator and the code generator,
which makes compilers very different from each other. It takes intermediated
representation as input and sends them out after optimized follow their special
algorithms. [2]
For instance, the worker/ wrapper transformation is
used in compiler optimization. [3]
Considering the optimization work
done by compilers generally has better design and test in advance, it should
have a very stable performance in a certain level. Therefore, the more work
done by compiler automatically, the less that programmers need to worry about.

There
are other problems still leaved open. As I have mentioned above, higher-order
function and lazy evaluation are the most powerful tools in functional
programming, which is also true for Haskell. However, everything is a
double-edged sword. For example, one “side effect” could be caused by lazy evaluation
is running out of memory. As far as I know, no compilers or interpreters could
pop up warning messages for this kind of situations in advance and programmers
need to always keep an eye on their code. There might be some solutions for
this kind of problem, which could be very useful in the improvement of user
experiences and program performances.

References:


[1]
John Hughes, Why Functional Programming
Matters

[2]
Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman, Compilers Principles, Techniques, & Tool
s,
Second Edition, Chapter 1, Chapter 4

[3]
Andy Gill and Graham Hutton,
The worker/wrapper transformation