Stale Cake - With Frosting!

Funny comments by Microsoft product manager Lawrence Liu on Mike Gotta's blog. Removing some noise between the lines:

"I am asking customers to step back and assess what business problem(s) they’re trying to solve... Jive and IBM are trying to wedge ... themselves into the SharePoint 'pie' by focusing on feature-to-feature comparisons while we’re working hard with our partners to provide the right frosting (or Cool Whip) to solve our customers’ problems."

I'm confused by Lawrence's response here for a couple of reasons:

• Bad metaphor is always difficult to read - Who puts frosting on pie? Who takes a "wedge" of pie? Good pie is best served hot by a knowledgeable baker, not after the original baker has stepped away from the pie and waited for six months to see what other pie makers are selling, then asking some other pie maker to fix the six-month-old, stale pie.
  
• Certainly nobody is asking customers to *not* solve a business problem. That would be equally as insulting - Microsoft does not have a monopoly on fixing business problems. If anything, they have a monopoly for causing business problems (early EOLs for XP, patch practices requiring substantial outages and reboots, Vista protocol design that causes networking headaches all translate into BCP issues in my mind).
• More comical, Lawrence is trying to convince customers that alternatives to *their* products are rash and that buyers are *safer* sticking with the platform and ignoring what other vendors are doing in the space. In my mind, this is akin to "only following orders", but why take orders from the used car salesman at the end of the block? Sure, eventually Microsoft will figure out what is important for their most profitable customers, or alternatively customers can buy a number of flexible solutions today that meet their needs.
  

My translation: "We're Microsoft. You will do what we say is important, when we say it is important. Thank you, your next invoice is in the mail."

The term "Microserf" comes to mind...

Erlang Musings

Completely bogged down buy our 2.0 release push at work, generally not a lot of time to blog these days. That combined with the Twitter micro-blog phenomena and I'm neglecting this blog. Sorry for the two people who read this :)

I did want to capture some thoughts on the recent discussion on the Erlang mailing list around Damien Katz's post about Erlang.

To preface my comments, I've been using a decent bit of Erlang over the past few weeks and have been learning the language for several months now. My current endeavors are in the distributed load-testing arena (Tsung didn't meet my needs). I'm by no means an expert and have nowhere near the experience of Damien or the members of the Erlang mailing list, but I'm beginning to feel like I'm not a total n00b.

Initial thoughts on Damien's post:

• I've also found refactoring a bit difficult. Over time, defining an entirely different function to elicit a slight behavior change generally results in some parameter munging then a call to an existing function. Problem is, in development, the behavior of that existing function often changes thereby affecting all the calling functions.
• I was also intrigued by the response to Damien's post on the Erlang mailing list where I lurk but rarely post. Some highlights:

• "sometimes giving a whining child a lollipop is a rational thing to do." - Richard O'Keefe clarifies this comment in subsequent posts, but the condescending attitude towards other languages continues to discredit him IMO. I generally get this sense from the Erlang community - "we know functional and you don't, so don't bother us with your critique of our superior language." Not sure why early adopters of most languages feel a need to succumb to Napoleonic urges and lash out at successful platforms. Java bashing is so very original these days...

• Robert Raschke also jumps on the Java-bashing bandwagon but with less valuable critique other than that he doesn't want to write Java in Erlang - not sure who asked him to do so.

• As usual, Ulf comes through with solid, valuable feedback.

• My experience has been similar to NAR's and I related to his comments for the life of the thread. In particular, defining dozens of one-line functions has made flow control difficult to follow in some circumstances. Probably my lack of understanding towards the language idioms but building on Damien's points, there aren't consistent examples of those idioms so it's easy to lose your way. I stand by my claim that Wide Finder proved this for file I/O in Erlang. It shouldn't take a committee to help you write good file handling code.

• I found Alpár Jüttner's comment interesting: "I think, the major obstacle for newcomers is not the syntax, but the immutable data structures". As a newcomer, this was not an issue for me at all. In fact, having spent more time than I care to remember worrying about dirty reads of shared memory, this is a welcome addition to my programming routine. Rather, I struggled with multi-byte strings (referring people to ejabberd is not sufficient documentation for an entire language), function proliferation, syntax ( =:= ), and most importantly lack of libraries.

• Robert Raschke's clarifications as line endings was a huge help here.

• The fact that POST'ing a form with http:request remains an enigma (eh, where are my param encoding functions?) really makes me feel like the language is a DSL for networking gear. Yes, Erlang is more expressive and concise than Java, but that doesn't mean much to me when I can write a Scala function to make an HTTP POST in four lines of code and have it run screamingly fast where as the same Erlang takes two dozen lines (and based on the documentation is questionably not process safe). I have the sense that the Erlang community would happily provide me with 10 different functions to solve the parameter encoding issue, but that misses the point - I don't have to worry about such things in most other languages I work with.
  

In summary, I actually agree with most of Damien's original post. Having written a good bit of C/C++/Java/Python/Ruby, his observations are generally representative of how I feel approaching Erlang from that perspective.

Like Damien, I have a lot of issues with Erlang. I kind of hate Erlang. I hate it in the sense that I wish I had a better, more familiar solution to programming with actors. At the same time, it's immensely powerful and expressive. Every time I use it, I think "wow, I love functional programming" and "actors are so important, it will be amazing when the programming public realizes why we all need to do this".

At the same time, the syntactical and idiomatic issues I have with Erlang constantly nag me. I'm sure these will ease over time, but I have yet to reach a point where I've stopped looking/hoping for alternatives. Given some of the attitude displayed on the mailing list, I won't really have a lot of community loyalty if given a comparable option.