Brandon Werner

Over at Lambda The Ultimate, the best academic programming blog on earth, there is a large debate going on regarding what the future of languages will be for 2008. The most important thing to emerge from the discussion is the larger role functional programming will play. It seems like a safe bet. This year has seen the explosion of interest and creation of functional languages such as Apple OS X’s Nu, Java’s JVM using Scala and Microsoft Research’s .Net language F#.

I am ecstatic at this change.

The Failure Of Lisp

It’s hard to understand where it came from. Certainly one can argue the broader academic community had nothing to do with it, the old guard Common Lisp hackers are still as fickle and as judgmental to new comers as ever. Also, the old standards in Lisp languages, Franz and LispWorks have not lowered their prices to anything approachable to the casual developer. There are open source ANSI Lisp implementations without all the supporting engines and functionality, such as SBCL. In fact, my most linked thing I’ve ever written in my career is the installation walk-through I did for installing SBCL and Allegro which includes adding your repository and packages for CLOS and automatically compiling the FASL files, especially dealing with the asdf differences between the implementations. The complexity of this in itself points to problems with portability and configuration in Lisp. However, even that project that targeted Lisp’s Bread and Butter, the parsing of semantic ontologies for the Semantic Web, was met in the message boards with worries on if there would be enough developer participation using such an odd language, and recommendations on moving it to Java.

In reality, Common Lisp showed its failure as a community by sitting out this enthusiasm that has been generated around functional programming languages. It didn’t have to be that way. I recall my first awarenesses of functional programming’s growth was the awesome work of Lemonodor’s blog and Sriram Krishnan posting “Lisp Is Sin“. I was happy at the time that Lisp was getting such attention, as well as functional language architectures in general. I imagined that as OO languages had grown so verbose and feature dense that even the IDEs to develop your applications run in to the tens of gigabytes, a new evolution “Back To The Future” was inevitable. Even more, I believe long suffering Lisp deserves to be back in favor again, it’s certainly spent its time in purgetory. Yet, it didn’t happen. You can blame the old 50 year old men sitting on IRC channels for that. It was the most thorny and un-inspiring community I’ve ever participated in, despite my extreme interest in the language. It’s jaw dropping that a language with such promise has sat out the resurgence, and speaks to what an un-friendly and un-inviting community can do a technology platform. I would be the first to march it off to the grave.

The Rise Of Functional Languages

The interest in functional programming actually grew up around more academic but pure languages like Scheme and Haskell. Although these languages sit within their own island and lack many of the “dirty” aspects of Lisp’s CLOS environment that make it easy to access OS and hardware resources, they are still strikingly useful in learning things that are the staple of functional languages, such as Closures and Lambdas. Indeed, one could argue that the movement to move Closures in to OO languages (first C#, now Java) was in part due to the rise of awareness of functional languages.

Further, it seems to me that functional programming languages answered two prayers of those more ambitious engineers who don’t seem to want to stick with the script and Java worlds they were taught in college. Those two large wins, far more important than the semantic features of functional languages that have gotten all the attention, are architecture foundations of functional languages:

• Referential Transparency / Side Effects
• Concurrency

Referential Transparency

To those coming from a pure OO world, Referential Transparency and the restriction of side-effects can be something hard to get their heads around. The best way I describe this concept is by hitting at the root of their assumptions: Everything they deal with are dead. The objects are dead, the variables are dead, the entire atmosphere is dead, as if something had come along and killed everything in your stack and you have to assemble your program by only what’s been given to you, nothing more. There are no instances, objects do not “come alive” and have state; a state that you have to poke in to and a state that can change at any time. A function will always do what you expect, and nothing can come along and change that behavior.

One of the things that seems to appeal to developers most about the promise of SOA architectures happening in enterprise environments, if you’re smart enough to pry it out of them, is that they get the same referential transparency in services. No one can override a service (besides versioning, which is explicit to the developer) and a service will only return what it did earlier in your code and earlier in the year. This forces developers to design services that have the same relationship to the world as functional programmers write their functions for. This is perhaps the trickiest part of migrating enterprise teams to a services based model, their expectations of the mutableness of the services they are accessing and their inability to anticipate what working in that world will be like. Especially for those who use tools or libraries to convert service interaction in to an object, the interaction can be jarring.

However, the soon find the predictability and the safety of such an environment liberating. In much the same way OO programmers were use to making their objects or variables immutable to maintain their contracts and relationships with other objects, often sacrificing many of the benefits that OO programming promised their stack, now they have immutability and transparency in an environment where functional paradigms are key, they do not expect to be able to “embrace and extend” services. They are what they are. This tends to cascade out to the living instantiated code a developer writes as well, as there is no point in entering the world of the living if what you have to return to is a dead function.

This was hinted at in an article in the ACM Queue magazine by Terry Coatta, entitled “From Here to There, The SOA Way“. He states,

Objects are still a very good way to model systems and they function reasonably efficiently in the local context. But they don’t distribute well, particularly if one tries to use them in a naive way. A service-oriented architecture solves this problem by dealing with the latency issues up front. It does this by looking at the patterns of data access in a system and designing the service-layer interfaces to aggregate data in such a way as to optimize bandwidth, usage, and latency.

Not that SOA limitations are the only thing that is affecting the consciousness of a software engineer, the other issue is the large rise in the complexity of managing a large enterprise library written in an OO language. One of the largest pain points of any application of large size is the management of graphs and graphs of live objects and the living data within them. When software engineers experience the lack of side-effects in functional languages, it’s a breath of fresh air.

Concurrency

A funny thing happened on the way to those multi-core processors. People loaded their applications on them and noticed nothing got much faster, particularly when it came to transaction intensive tasks. Turns out Intel and AMD left out an important fact about their Moore’s Law cheating multi-core environment: you can’t ring as much performance out of it without changing the way you manage concurrency and threads. Sequential programming could always rely on going faster as the single processor speed got faster, but as multicores come in to play that isn’t always the case. You want to farm off transactions to occur on separate processors, and in the living world of mutable objects and variables, breaking out two transactions to work concurrently that operate on the same living data is a bad idea. Add structural programming’s solution to this problem, optimistic and pessimistic locking, and you have dead-locks in short order.

Functional programming has been a natural place to explore parallel processing and new ways of doing atomic transactions because of the reasons above. More important, these atomic structures can be composable which is lost when doing locks in structural programming. A lot of the buzz has been generated around the idea of software transactional memory, where execution blocks can be flagged and managed and built upon. The best introduction to this topic is the paper by Tim Harris entitled Concurrent Programming Without Locks. Although this use to be expressed only in the confines of Concurrent Haskell, others have shown how the same techniques can be used in other functional languages, such as F# using nothing more than PowerList.

This experimentation is one of the large reasons why functional languages have become more important as software engineers wrestle with the problems and promise of multi-core processors in transaction processing. Although not every engineer will be interested in the deeper details of STM or other strategies in concurrent programming, the fact that these libraries will emerge and only be available in the functional realm will force software engineers to learn the core concepts and bring even more visibility to the functional programming space.

Functional Hybrids: Functional Programming Is Now Approachable

The other driver for adoption of functional programming languages, besides the architectural benefits it has to solve current problems, is the fact that languages such as F# and Scala have adopted a more hybrid model in their language design, where a developer isn’t forced completely outside her comfort zone. Scala is a combination of functional and deeper OO methodologies (as in SmallTalk) and has access to the entire Java library, significantly reducing the learning curve. The same can be said for F# and .Net and Nu and Objective-C. This does have draw-backs however, as both F# and Scala have not been able to use more of the STM strategies that Concurrent Haskell allows because the underlying thread architecture of the VMs they run against are built for structural programming languages. It is easy to see how this can be fixed, however, and allow those using hybrid functional languages the same power as those who express their ideas in Haskell or even Lisp.

As I said, I am excited about this new resurgence in functional programming languages, and I am enthusiastic 2008 will have even more to offer those who are just getting their toes wet. I personally know some college freshman who started out using Nu as their first language, and are already contributing to the community. The future of software engineering is bright.

I seem to be visiting a lot of my prior entries from 2005, but a while back I wrote about an experience I had meeting an old IBM programmer at the local Catholic store. She was female, which seemed like a trail-blazing thing to have been working in the heavily male dominated technology industry in the 1950s. Her story, and her eagerness to share with me, led me to write my experiences with gurus in my life, entitled In The Presence of A Guru (On Catholicism, VAX/VMS and Geek Culture). I still feel profoundly stupid for not having spent more time with her, as it was obvious she wanted to share her story. I will regret it for the rest of my life, not just because of what the exchange could have done for my understanding, but more refusing my obligation, the obligation we all have, to listen to and carry on the mythology and history of our elders. I am afraid that mythology may be vanishing, and none of us are listening.

I thought about this again when I stumbled upon a new blog from Dan Weinred as linked from Lemonodor. His career in Computer Science and his contributions certainly qualifies him as a Guru.

His essays so far are a treasure trove of information and computer science archeology. One of my favorites is called The Technology and Business of ObjectStore, where he recounts taking his ObjectStore technology to Microsoft and Bill Gates as well as Steve Jobs. The reaction of both icons demonstrates humorously their approach even now:

When the new Windows technology (which was OS/2 at the time; IBM and Microsoft were still working together on it) came out, it was crucial for us that it be able to support memory mapping. Dave Stryker and Tom Atwood, flew out to meet with Bill Gates in September of 1989. Dave Stryker recalls: “We originally had a 45-minute appointment, but Gates extended the meeting to a couple of hours, and called in Dave Cutler [the architect of OS/2]. At Tom’s urging, we told Gates and Cutler everything they wanted to know about ObjectStore. Gates was complimentary of the Object Design approach, but said, in a nice enough way, that if the Microsoft Empire ever needed such a thing, they would build it themselves. Still, Gates told Cutler to make sure that the OS/2 equivalent to mmap was powerful enough to run ObjectStore, and there were some changes made to make it so.” Later, this OS/2 technology turned into Windows NT. Dave Moon adds that it turned to have a bug: it doesn’t free up disk space when it ought to. For some reason Microsoft hasn’t fixed this, even after many years. We found a way around it.)

Speaking of industry luminaries, we also met with Steve Jobs when he was at NeXT, and Jobs made a big announcement praising our technology, which resulted in a nice press release. There was some discussion that NeXT might buy Object Design, but that never went anywhere.

This type of history is fascinating and important. There have been efforts to capture this knowledge, such as Fokelore.org and ACM’s excellent ACM History Committee trying to archive CS knowledge, but their efforts so far is approaching it the wrong way. It’s getting the stories, while these people are still alive and can tell them, that is important. Much of it will not be academic or well checked, but that is missing the point. It’s the mythology as well as the history of these pioneers in the 1930s - 1970s that we should be after. We’ve already lost Jeff Raskin, Adam Osborne and others.

If we do not do this, their legacy and our history as a profession, one that has changed the world as much as any other in human history, will be lost forever.

Smalltalk was originally developed at Xerox’s legendary Palo Alto Research Center (PARC) in 1972, but came in to it’s own in 1974 when ported to the Alto computer, and was used to build the first GUI. This would later set Steve Jobs ablaze with ambition for the Mac, launching the Personal Computer revolution. Smalltalk-80 was ported to many platforms and many of the pioneers of Smalltalk (Alan Kay and Dan Ingalls) moved over to Apple in the 1980s. Originally designed to be a language a child could use for the Dynabook, it later moved on to a more important role and was eventually released outside of PARC in 1980. Just like the Dynabook, the Alto, the GUI interface and the other technologies PARC invented, Xerox fumbled the ball in releasing these technologies to the public leaving it for others to fill the gap. I sure hope the executives and board members of Xerox in the 1970s and 1980s aren’t collecting any pension, they don’t deserve any.

Although Squeak, which comes from Alan Kay and Dan Ingalls themselves, has taken a lot of the publicity away from the Xerox VisualWorks (a version of SmallTalk released in 1990), the actual VisualWorks and ObjectStudio was bought from Xerox in 1999 by Cincinnati based Cincom and has also been heavily expanded and developed. Cincom has tried to make Smalltalk a major force in application development.

If you visit their website, you’ll find an active community, conferences and seminars (Smalltalk Solutions Conference looks cool), and even a Smalltalk Digest. Their Smalltalk products are available for free for non-commercial use, and can be downloaded here. Amazingly, there are versions of Windows, Mac OSX, Linux, Solaris and other unixes (ObjectView is Windows only, tsk tsk). In fact, the complete system that Cincom has deployed around SmallTalk is breath-taking in it’s completeness.

It includes such 21st century enterprise features like:

• VisualWorks Application Server - with it’s own servlet container and JSP or ASP tags and tag libraries
• Store - Not the best named feature, it’s a complete code management and control application
• VisualWorks itself - with code refactoring and other goodies
• Opentalk - Webservice interoperability with SOAP and UDDI
• Strong Database Integration - table to object integration for all major databases (except MySQL.. a big hole). Hibernate like and powerful.
• Object Engine/Virtual Machine - What it says, a powerful VM that allows for neat immutability that allows for object sharing across VMs as well as better garbage collection algorithms.

Needless to say when I first downloaded it from Cincom’s website after playing with Squeak a great deal, I had no idea I was downloading what amounted to a complete J2EE-like application environment. I didn’t even know it existed. There is a lot to play with, and I’m impressed Cincom has done so much work on the SmallTalk platform.

I highlight this product not only because Smalltalk is a great language and has a nice following (especially with the explosion of Ruby, which uses much of Smalltalk as it’s inspiration) but because I wanted to highlight on this blog what a company like Cincom in Cincinnati is doing. Admittedly, Cincom, even in Cincinnati, has a low profile vs. other large companies headquartered in Cincinnati (Convergys, Kroger, 5/3rd Bank, ect.) , and in an industry where if you’re not where the action is you’re not noticed, this company deserves some more respect for it’s work.

What is the future of Smalltalk?

It’s hard to predict where the product will be going in the future however, especially with Ruby gaining so much momentum. In fact, as oddly highlighted by Cincom’s Smalltalk Digest itself, a Smalltalk User Group in Omaha, Nebraska recently decided to merge with the Ruby Users Group. This is probably a good indication of where Smalltalk programmers will be going in the future, and it might make Cincom’s Smalltalk an even harder sell to the young hacker evangelists that a language needs to rise above the fray.

It’s obvious when Cincom grabbed Smalltalk from Xerox in 1999, it assumed it could be a Java-like alternative to Sun Microsystems in the enterprise space. After all, J2EE was just starting, Microsoft had DCOM and ActiveX and it was anyone’s game at the time. Looking at what happened later, it’s hard to say why Smalltalk didn’t emerge as a good competitor. It could be that other people during the critical 1999 - 2002 timeframe could have more input on the quality of the Smalltalk from Cincom during this time, but I hate to think it was simply because of their location and their budget vs. Sun Microsystems. Remember, IBM wasn’t as Java-centric as they are now in 1999 either. Few people know this, but IBM VisualAge was actually an IBM Smalltalk IDE environment. It was only when they extended it to also be a Java IDE and attached the word Java at the end in 2000 that IBM VisualAge for Java gained visibility with Java developers. Interestingly, people were attracted to VisualAge for Java because of it’s flexibility and power (like Scratch Pad and UML reverse engineering) which were pretty new for the time. However, this flexibility that made it and IBM’s Java famous came from Smalltalk, not from Java.

So, it was a pretty even game. Why did Cincom Smalltalk not emerge with more of a following in the enterprise space?

Now, however, the battle might be over for both Java and Cincom Smalltalk as people move to platforms and frameworks that are more light-weight and open source. Certainly, Java will always be a force in the enterprise market for years to come simply because it is in the back offices of so many companies now, but the evangelist are moving on.

Regardless, I’m proud of Cincom for keeping a language with such an amazing history alive, and extending it in a way that other old legends like Lisp, Fortran and Pascal can only dream of. Whatever their plans are for the platform, I’ll be sure to bring them up more when discussing fun things developers can learn and be productive in.