Thoughts on software.

I have been thinking about programming in general and all the buzz in our sotware engineering field. I've been influenced by Paul Graham's articles on the importance of thinking in the functional way, and ever since then, a lot of those things that seemed unrelated, now look like they have a common thread running through them, which is:

"Functional languages are more important than what we give them credit for. All of the buzz is really stuff we would take for granted if more of us were using functional languages. And functional languages are more accommodating of what the best practices recommend we do."

I'm still working my way through "On LISP" from Paul Graham, so my opinions may change once I finish it and have a better idea about what it means to program in LISP. The universal acclaim that the most powerful language "LISP" seems to be getting is only fuelling my desire to learn it quickly.

Domain Driven Design:

Using the "domain specific language" is a widely acknowledged virtue. When I ask myself if Java or .NET truly support the ability to write code that can be readily understood by a domain expert, the answer is no. All we can do is choose the function names to reflect the domain task, there is no possibility to change the language's syntax to help deal with domain complexity.

True DDD will only be achieved when some sort of macro support is allowed, something that allows you to refine the language's syntax to better represent the domain. At least, people would not get too excited about for-each loops. I understand quite well that DDD has got more to it than code, it is also about analysis, but surely ease of representation in code is an important factor.

Domain Specific Languages:

Again, people who frequent the DDD conferences seem to have been talking about domain specific languages a lot lately. As we try to solve problems within a domain, we'll see lots of new frameworks come up, each dealing with some aspects of that domain. To give an example, Spring has Acegi security that tries to ease the task of web application security. There are specific frameworks for e-commerce. Some investment banks maintain their own languages that perhaps help them deal beter with the finance domain.

The power of domain specific terminologies is only set to increase as software engineers mount an offensive on domain complexity. So, it is important for a programming language to be malleable, and adapt to the domain, and functional languages do just that.

Object Oriented Design and Design Patterns:

Moving on to object oriented design and design patterns. I was a pattern freak for about one and a half years. I have to admit that, at heart, design patterns are only about code organization. I accept the significance of design patterns, but now it seems to me that "object oriented gymnastics" might be a better phrase used to describe all that. Yes, they help in writing code that is maintainable and easing code extension, and a developer who understands design patterns is less likely to write shitty code, but are design patterns all that important?

To take an example, we can now use Dependency injection containers to just declare that a class is a singleton (Make sure you know why singletons are evil.) or prototype, for example in Spring core.

There should be inbuild support in a language for repetitive thigs, and we should not wait for frameworks to provide what is lacking in the language. Most progress, if you really break it down, is being able to remove duplication. The present languages do not provide anything that can make design patterns easier to use, which is why sometimes we depend on  frameoworks to provide design pattern support, but they too can help us only to an extent.

If only functions were first class objects in the mainstream languages, many of the patterns would just vanish into thin air.
There are articles which argue that design patterns might be a "language smell", indicating that the language lacks something it should have had support for.

Another interesting comment (read it somewhere on c2 wiki) was that some people find the UML as lacking enough representational power. I wouldn't be surprised if an alternative to UML comes up within the next 10 years. It does make me wonder about what techniques people in the functional world use to design their applications. So far, it seems that they favour "bottom up" design/development together with "top down". The language evolves to provide you building blocks for "bottom up", as compared to "top down" where we build elaborate designs and then set about creating them.

Other functional features:

When we notice the evolution of the current languages: the introduction of lambda functions in .NET or at least lame attempts to recreate them with complier tricks and the "coming soon" inclusion of closures in java, it is clear that we are migrating towards functional languages.

Test Driven Development:

Since functions are the focus of development in functional languages, writing simple functions and testing them should come easy and naturally in the functional world.

Another statement that struck me was the LISP world advice to program by wishful thinking. The SICP (Structure and Interpretation of computer programs) book mentions that you should first write the function call API as you would wish it to look. This exact statement is the first step in test driven development.

Other factors:

What I discussed above are purely technical factors, but economical advantages of using a less powerful language and techniques is something that cannot be underestimated. Most code shops will drag their feet, and not accept change unless the change is standardised. The service industry in India and other developing countries is never going to embrace change unless the client recommends it, so I'm not hopeful of the functional languages gaining even a toehold in this corner of the world.

Conclusion?

For now, this post should ideally stay without any conclusion, because with time I will gain more insight into where all of this is headed. Still, for the java world if I had to pick, the winner will be some language that has functional features and can also run on the JVM, since languages that run on JVMs do not freak managers out. With time, all the development techniques and best practices, that are headers in this article, will be taken for granted, and maybe we'll improve on all that as well. But it is clear to me now, that languages have a role to play in helping you embrace and move towards better development. And choosing the most powerful languages is important if we are to get there.