As it stands, I still place Erlang as next best hope for making development teams more effective at delivering solid products.
I have had doubts now and then about this conclusion, but ultimately it comes down to experience. With an incredibly limited amount of experience I was able to write effective and useful systems with Erlang. No language other than C has ever made that possible for me.
It may be simply that abstractions act more as distractions for me. Their presence calls out to me to incorporate them in my designs and this siren's call drags me aground over and over again when I write Java applications. Given my extensive professional and personal experience with Java I am adept at overcoming this simply by brute force. However, I have found that languages offering more abstractions than Java make this problem far worse for me.
Another big worry I have about highly abstraction-oriented programming languages is the flexibility of expression. This flexibility beckons each developer on a team to choose wildly different ways of expressing the same intent. Certainly, this problem exists in all languages, but room for unusual diversions is narrow in Erlang and the benefits meagre.
Diversity of expression is generally desirable in an artistic medium, but it can also confuse and be misinterpreted by other members of your team. Shouldn't coding conventions cover this? Definitely, they should, but coding conventions are like a small footwall compared to the mountain of abstractions at hand in language like Java. And Java is a lightweight in this arena. The trend is towards even more abstract programming with languages like Scala and Ruby at the vanguard.
However, I believe that discouraging the use of abstractions in a language like Java, Ruby or Scala cripples the developer and defeats the purpose of those languages. However, I also believe that such abstractions are not only inherently unnecessary for building applications, they are actually detrimental to timely delivery. Abstractions encourage upfront design, upfront design encourages future creep, future creep enourages scope creep and scope creep delays delivery. Not exactly scientific, but it's what I feel is going on... at least for me.
Many people burst onto the Erlang scene quickly with compelling open source and commercial products shortly after having just learned the language. Surely this speaks volumes for considering its more direct and concise approach to programming?
I like Erlang... it speaks to me. When it does, it says:
"Stop designing your programs and start freaking writing them!!!"
2 comments:
Interesting, it's not often you hear anyone warn against abstractions in software development. I wonder what exactly you mean by "abstraction", and if you might give some examples of problems you've come across as a result.
Personally, while I've seen a bit of unpleasantness from premature / speculative generalisation, I've found one of the big advantages of abstraction is that I can write programs using concepts closer to the problem domain and further away from the nuts and bolts of the machine implementation.
@Matt:
Speaking of generalisations, I significantly overgeneralized when I said that abstractions are distractions for me :)
By "abstraction" I mean a mechanism provided by a programming language for reusing code and coordinating execution. In my opinion certain abstractions are more useful than distracting. I also believe that a smaller set of more powerful abstractions encourages consistent coding style and consistent problem solving fom developer to developer. Closures and functions are the most powerful abstractions I have come across. Beyond closures and functions I have found it useful to have a abstraction for coordinating concurrency.
After learning Erlang I realized that I like to structure my programs to be more about doing things than being things. In that respect functional and concurrency oriented abstractions are a better match than object-oriented abstractions for the way I program.
Professionally, I apply what I learned from Erlang by using Java's abstractions less for representation and more for structuring algorithmic execution and concurrency. I have found the resulting Java code to be concise and easier to understand than what I used to write.
Realistically, simply being exposed to a less abstraction-oriented programming language forced me to value the abstractions where they were useful rather than simply applying them because they are cool. Joshua Kerievsky's Refactoring to Patterns was another excellent source of insight into how to balance the use and value of abstractions.
Post a Comment