Why Fudgets are Good

Features of Fudgets

• Easy to get started. Many library components have default values for parameters. This makes library components easy to learn and use in the common case but still flexible and customisable.

• Code size. Fudgets program are usually shorter than the corresponding program written in an imperative language. Because of this they take less time to write and contain fewer bugs.

• Rapid prototyping [1]. The fudgets system features an automatic, adaptive layout system which allows you to write a working first version of a program without having to worry about layout at all. The opposite is also possible: you can start by designing a user interface with a specific layout and later add functionality to it.

• Hierarchical design. There is no conceptual difference between basic building blocks and complete applications. This means that you can easily replace simple things like buttons with composed objects, or reuse existing applications as parts of new ones.

• Extensibility. Library components can easily be bundled with code provided by the application programmer to form new components, which can then be used like any other library component. You can thus create extension libraries for particular application areas.

• Declarative flavour. While it is possible to enable GUI programming in a functional language by providing an interface to an imperative GUI toolkit and, in effect, using an imperative sub-language within the functional language, Fudgets provide a declarative style of programming also for the construction of GUIs.

• State encapsulation. Robustness. Fudget programming is like Object Oriented Programming in that state information is encapsulated and hidden from arbitrary use/misuse. The components that corresponds to objects are called fudgets. State information can be accessed/changed only by sending messages to the fudget maintaining it.

• Concurrency. Fudgets also remind of processes in concurrent programming. A fudget is a process that runs in parallel with other fudgets and interact with its environment by message passing. Fudgets are still easy to compose, like functions in functional languages.

• Client/server programming & networking. The library provides fudgets for Internet communication. Creating a connection to another process (on the same or another computer) is as easy as creating a button in a graphical user interface.

Features of Functional Programming Languages

• Higher order functions and parametric polymorphism. These two together provide an excellent tool for modular programming and software reuse which for many purposes is more flexible and powerful than subtyping and class hierarchies used in Object Oriented Programming.

• Lazy evaluation ensures that computations are not performed needlessly. This too supports modularity [2], e.g. by making library components more powerful. A simple example: a function that takes a list and returns all items that satisfies some search criterion can be used even if you only want to find the first matching item. The list of matching items will be computed only to the extent it is used. Thus, there is no need to learn about two different library functions for searching lists.

• Automatic memory management. A functional programmer does not have to worry about allocating and freeing memory. The inherent support for dynamic data structures in functional languages makes it very easy to work with lists and tree-like data structures.

• Type safety and Memory safety. The type system used in modern functional languages is powerful enough to allow most things to be statically type checked. This allow many bugs to be detected at compile time. In contrast, when programming in C you often need to escape the type system by using things like type casts and void * pointers. Since this precludes the compiler from assisting in bug detection, you often don't know about a bug until the program crashes with "Segmentation fault". The situation is similar in untyped languages like Tcl/Tk, Perl, LISP, Scheme, PHP, Python, JavaScript, etc.

• Brief notation. Introducing a new function in Haskell has a very low notational overhead compared to most imperative languages. This makes programmers more inclined to write small and readable functions rather than big monolithic chunks of code.

References

1. Paul Hudak & Mark Jones: "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity" (1994)
2. John Hughes: "Why Functional Programming Matters". (1984)