IMO

I've been following for quite some time now the various blogs and articles regarding Erlang. In general, the ones by David Welton I've found the most enjoyable. But one thing I've noticed whenever new languages are discussed are that one tends to bring out of the woodwork language bigots instead of language aficionados. The bigots are those who refuse to see anything good in any language other than "theirs"; that their language is suitable for any and all projects; that it is both general and yet specialized. I much prefer listening to the aficiandos, since they can inform me about the reality of their language. When programming, I tend to worry about the reality of programming languages. As anyone who knows me, or regularly reads this blog knows, I have an affinity for scripting languages. Some mistakenly interpret that as being "anti-Java" when nothing could be further than the truth. The reality is, of course, that Java does not need my help in the least in making a name for itself. The huge marketing forces behind Java have done their job incredibly well, almost too well, since now there is this misconception that Java is the only language that matters, especially in enterprise application development. And that is something that I do hope to clear up. In fact, I'm actually co-presenting with Rod Cope a webinar on this very topic. I think that languages always have a basic design premise behind them; there is one area which they want to shine. The trick is, of course, whether that is a focus of the language or the focus. Consider FORTRAN; its focus was on engineering and mathmatical calculations. That focus was so intense, however, that it made it extremely unsuited for almost any other application. Now compare that with C that was designed from the onset to be a "general purpose" language, but ideally suited to systems programming. In this case, the specialization did not destroy the generality. Which brings us back to Erlang... for me, the measure of success for a language is how well it does what it was designed to do; And Erlang appears to do that very well. The fact that it doesn't do such a good job on things it wasn't really designed for does not strike me as a fault or failure at all. After all, would I complain that I can't use my hammer to saw wood well? Or that my saw sucks at driving nails? Of course, if I had some fancy hammer-saw in my toolbox, and it does an awful job at both sawing and hammering, then the generalization is useless no matter what. Languages, all languages, have warts; As a programmer, I want to know, heck, I need to know, what they are. But only if they are real, honest and true warts. PS: Regarding the webinar mentioned above. A few days ago someone emailed us back saying:

Haha what a joke this is. No one wants to use a scripting language over java for web applications. This is a sad old Unix guy's last attempt to save perl or something. Give me a break.

I kind of liked the "sad old Unix guy" phrase... And I kind of feel sad for those "young Java guys" who feel so threatened... and are so out of touch.

Many people are buzzing about Amazon's Dynamo, and for good reason. But the buzz is almost dual in nature, because not only is it very cool technology, but also because of the real and perceived impacts on other architectural designs. After all, as noted by others as well, what we're really seeing is a RESTful DB, and how it maps to a RESTful web architecture as well. The key is the URI and the data is the resource; it is a very natural fit. And when the "DB" is better, faster and more scalable due to its simplicity, we see a mutual self-validation between the two. The success of REST implies that Dynamo is the right approach, and the power and capability of Dynamo indicate that RESTful architectures should, of course, continue to be taken seriously (if not more seriously). Of course, one can pretty much claim that the web itself is a key/value distributed DB implementation, and they'd be right. I don't agree that RDBMs are going away anytime soon, but mostly it's because that I don't believe in one-size-fits-all solutions. I like having a wide range of tools in my utility belt, so I can use the technology that works, instead of shoe-horning something in, which is the real danger, IMO, with tunnel vision technology.

Well, although 2 points define a line, it doesn't really describe a "trend", but I like the title anyway. I offer this to compliment this.

Now that Ben and Rod's blog-oriented discussion regarding open source support is over, it's a perfect opportunity for me to add my 2 cents. This isn't in response to either of their PoVs, or their companies, but rather my take on the whole topic. First of all, I agree with the point that one can be an an expert on a software package without being a committer on that project (although it certainly does help). What is a danger, of course, is when someone or some company claims to be "expert" in a codebase, when they are no such thing, basing their claim on the assumption that, well, since they have access to the source code, they can suss through the code and find and fix any bugs, which is what you need an "expert" for anyone. Access to the source does not create expertise, nor does expertise in one codebase automatically imply expertise in others.The best way to illustrate that, I think, is via Ben's auto mechanic anology. Certainly, if I have a Toyota and it's having trouble, going to a verified Toyota mechanic is a safe course of action. But even if I have a Ford, I'd still feel pretty comfortable doing that, since, when all is said and done, the similarities between the designs of the cars are so close that expertise in one pretty much translates well to expertise in the other. But this is not the case in software. The differences between software codebases are staggering. It would be like calling your auto mechanic when your refrigerator or dishwater went on the blink. After all, they are both mechanical devices, right? I can only think of a small number of cases where that would even remotely be acceptable. I guess if you had time to wait, you could handle the downtime involved with someone reading the code and getting at least somewhat up to speed on it before they can even start debugging the issue at hand. But certainly not in production environments. And enterprise customers, with production environments, need agressive SLAs and require and deserve that demonstrated expertise. In open source support, it's depth which is critical and key, not breadth.