Chapter 10. Conclusion

Table of Contents
SML/NJ vs Real-World Needs
Related Languages
To Finish

The aim of this book has been to demonstrate that functional languages, in particular SML, can be used to build the kind of real-world projects that you might ordinarily only think of using C or C++ for. In the following I will discuss some of the lessons learned from developing the web server project in SML/NJ. I'll also point you at some related languages to look into.

SML/NJ vs Real-World Needs

To tackle real-world projects a language and its environment needs to:

Large-scale Development

Functional languages certainly scale to the size of real-world projects by nature. The productivity improvement from a functional language allows a programmer to tackle much larger projects. I estimate at least a 10 to 1 improvement in productivity over the C language just from a reduction in the number of lines of code needed. There is a large productivity boost from the absence of memory management bugs and the like that plague C programs. Further the strong static type system often means that sizable pieces of SML code just works first time.

The SML module system goes a long way towards managing large-scale code. (But its inability to handle groups of mutually dependent modules is a minus).

Performance

Over the years computer scientists have developed many "very high level" languages to help solve the "programming crisis" and improve programming productivity. In the early stages of research they are usually interpreted rather than compiled and the implementation is slow. Often they don't progress beyond the research stage. This leaves the impression that advanced languages are by nature slow and not suitable for real-world use. Unfortunately programmers are prone to myths about programming languages and seldom revisit them.[1]

My experiments with the Swerve server in this book show that SML/NJ does perform well. Without much trouble it achieved around 2/3 the speed of Apache, which is written in C. Anecdotal evidence has it that C++ is about 1/2 the speed of C. The speed drop is mainly due to the excessive copying encouraged by copy constructors and the overhead of virtual method calls. Even a good Java implementation is slower again. This suggests that SML/NJ can certainly compete with C++ or Java.

Having said that, there are still some performance issues that need to be noted. In the section called Basic SML/NJ Performance in Chapter 7 I ran some basic speed tests. The performance on inner loops and low-level byte handling could do with some improvement. This speed loss is partially compensated for by the much better heap performance. Other implementations of SML such as the MLton compiler[MLton] work harder at optimisation.

Infrastructure

The big impediment to wider use of SML in the real-world is support for features such as databases, graphics, encryption, native languages (unicode), true concurrency etc.

The standard basis library is looking rather dated. It hasn't progressed in years. A future release of SML/NJ will include a native C-language interface. This will allow your SML program to dynamically link to a shared library and call its C API. It includes a tool that generates SML stubs for all of the API functions found in the library's header files. This will make it possible to call libraries for database access, file encryption and compression etc. But I think that the basis library will need further work to integrate this properly. Personally I would like to see a plug-in mechanism for the SML/NJ run-time to make it easier to extend.

The choice of a web server for this book neatly avoids the issue of database programming. Web servers typically delegate this to CGI scripts which you could write in Perl or PHP. SML/NJ desperately needs an ODBC-like mechanism.

This book has been silent too on the matter of graphics programming. Image handling (e.g. JPEG, PNG) needs access to standard libraries as described above. To develop a GUI with SML/NJ you have a choice of the eXene system, supplied with SML/NJ, or the SML/Tk package[SMLTK]. I haven't used eXene. It's an experiment in designing a concurrent GUI toolkit for CML. But I would prefer a more conventional look and feel such as Tk. But SML/Tk is not written for a concurrent environment. Personally I consider Concurrent ML to be a "killer" feature of SML/NJ. A GUI should be multi-threaded for responsiveness. It's a shame that CML is not built-in to SML/NJ instead of being an add-on.

Notes

[1]

Here are some common ones. Lisp is slow. Optimising compilers have been available for years. Ada is huge and bloated. What, C++ isn't? C must be efficient because you can program down to the bare metal. Nope, its 1970s-vintage machine model no longer fits well with modern computers.