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
