Pinderkent

Yesterday a colleague forwarded me the link to Underscore.js. It's a JavaScript library that provides some functions commonly offered by functional programming language implementations.

Now, I can understand completely why JavaScript programmers would desire to use such techniques. They bring some very clear and powerful benefits, including shortened development time, fewer lines of code, greater flexibility, and improved readability. However, I do hope that JavaScript programmers using such a library don't come to think that they're actually doing functional programming.

One of the most significant areas where JavaScript fails with respect to functional programming is immutability. Current implementations have spotty support for constants, leading to various workarounds. So while it's possible to manually avoid state changes as much as is possible, it becomes difficult to do when performing browser-based JavaScript development. And it's almost always better to have the language implementation strictly enforce const-ness, rather than trying to have developers communicate this intent through all-caps variable names, for instance.

Many functional languages also offer very rich pattern matching functionality, which we just don't get with JavaScript. While some people have tried to implement pattern matching in JavaScript, it is nowhere near as clean or natural as pattern matching in Haskell or pattern matching in Erlang.

Many, but not all, functional programming languages also offer strict, static typing. There has been much debate about the pros and cons of the various typing techniques employed by various languages. In the end, however, experience shows that static typing results in higher-quality software, and static typing saves developer time. Unfortunately, JavaScript as a language, as well as its current widely-used implementations, don't lend themselves to strong, static typing.

It also doesn't help that JavaScript came mainly from the imperative and prototype-based OO world, and is only now trying to adopt features and techniques from the functional paradigm. It's often much cleaner to start with a purely functional language, and then add useful imperative features like for loops and references, as was done with Objective Caml. So the language and standard libraries have a functional feel to them, and naturally encourage the use of functional techniques, yet still allow the use of imperative features where they may prove to be the best option.

In many respects, I see trying to do functional programming in JavaScript much like doing object-oriented programming in C. While it can be done, to some extent, it never feels very natural because it lacks support that should be provided at the language level and by the implementations of said language. GObject is one of the most widely used C object systems, and as anyone who has written even a moderately sized GTK+-based system in C knows, it's not a very pleasant ordeal. Languages like Objective-C and C++ offer a much more developer-friendly experience.

So I see trying to add features and techniques from functional programming to JavaScript as generally being a pointless exercise. It may help in some cases, but ends up just masking the symptoms of a greater problem, namely that we want (and maybe even need) a true functional programming language available in all of the popular Web browsers. I've suggested Haskell in the past, but just about any functional language would be better than JavaScript.

Today I read an article suggesting that 8 GB of RAM is "only just enough" memory for a typical developer's PC running Windows. I'm not here to dispute that claim. Indeed, the RAM usages given in the article are somewhat realistic. Using recent versions of Microsoft's various software and database development tools does require a significant amount of RAM. In many ways, the need for that much RAM is unfortunate and likely quite unnecessary.

In the mid-1990s, I had the pleasure of doing software development on a NeXTstation Color. Unlike the base NeXTstation Color models, which came with 12 MB of RAM, the system I was using had been upgraded at some point to 16 MB of RAM. But by that point, it had been used by several developers before being passed on to me. Yet it was still an extremely powerful development system.

Now, it might be argued that Windows development today isn't much like the software development we did on a NeXT system 15 years ago. In some sense this is true, but for the most part very little has changed. Objective-C is relatively similar to C#. The various NeXTstep kits are fundamentally similar to the .NET standard class library. We had Project Builder for development, as well as Interface Builder for drag-and-drop GUI creation. And although it wasn't available yet when I was developing on that NeXTstation, NeXT would later introduce WebObjects for developing Web applications.

Anyone who has done any Mac OS X development lately has a general idea of what it was like to develop software on a NeXT system. It was an experience quite comparable to software development today, due to how far ahead of its time NeXT and their software offerings were. And although many people today might find it difficult to believe, we actually were able to develop relatively complex business software on a system that had only 16 MB of RAM. To put things into perspective, the article I read today claims that at least 500 times as much RAM is needed today than was needed 15 years ago. But the software we're developing today really isn't much more complex.

It's obvious why this has happened. Since then, the price of RAM has dropped considerably. It has become far cheaper to acquire more RAM than it is to pay a developer to write more efficient software. In fact, we see this reflected throughout the entire software stack. It's no secret that Windows Vista requires a significant amount of memory to run efficiently. The same goes for .NET. Developer tools like Visual Studio are also very memory-intensive. Given the platform and development tool vendor's general disdain towards writing memory-efficient software, it's no surprise that the applications developed by software developers using those tools would also consume more memory than necessary.

One thing to consider is how we now approach a simple task, such as reading and writing data files, versus how it was done 15 years ago. Today, we're likely to see some given data persisted to an XML file on disk. To work with such files, we'll need an XML parser, some way of representing the XML document in memory, custom code to tie everything together, and so forth. Fifteen years ago, we would have used a custom binary format, and written the serialization and deserialization code ourselves. Although it would have taken longer to develop, the overhead in terms of memory usage and CPU usage would have been considerably less with the custom binary format.

But to require over 500 times as much memory today is still quite excessive. I think it just goes to show how little developers today care about minimizing memory usage of their applications. The low cost of RAM no doubt helps our "cause" immensely. Today we can get away with waste that would have been considered intolerable a decade ago. But on the other hand, I think we are shortchanging ourselves to some extent. The memory we consume today, essentially out of waste and carelessness, could no doubt be better used for other purposes. Extra memory put towards even just caching data from disk is typically beneficial to system performance, even in systems with significant amounts of RAM.

Fifteen years ago, I don't think I would have believed it if somebody from now had come and told me that we'd have low-end PCs with 4 GB of RAM, typical development systems with 8 GB, and we'd actually need that much RAM to run contemporary applications. Yet here we are. And I don't even think it'd take that much more care or effort to minimize the amount of RAM we use, or at least bring it down to a more reasonable level. To have any effect, we'd need to see this initiative at all software levels, from the operating system, to any higher-level runtimes like .NET and Java, to our software development tools, and finally to the applications we develop. Unfortunately, I don't see this happening.