SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for September 19th, 2007

And Now For Something Completely Different: Visual Programming Cracks the Multicore Barrier

Posted by Bob Warfield on September 19, 2007

I’ve been admiring LabView, a visual programming language created by a company called National Instruments.  To be precise, the language is actually called “G”.  These guys didn’t set out to solve the multicore problem, in fact LabView was introduced way back in 1986 before anyone was worried about multicore.  It’s used in data acquisition, instrument control, and industrial automation tasks. 

Jim Kring called my attention to LabView in a couple of different ways.  First, I came across his great book, LabView for Everyone, in a Borders Books.  It’s a wonderful introduction to the potential for this language, but you won’t find the book in the programming section–it’s over by the Engineering books.  Second, Jim and I have corresponded about the Multicore Crisis for a little while and he recently posted on his great blog about how LabView is one potential answer to the problem.

Why is LabView able to scale more easily than conventional curly braced languages?  The answer is simple, and perhaps surprising: because the language says very little about the sequence of execution.  It is what’s called a Dataflow Language.  You’re almost certainly familiar with the world’s most common dataflow language already: spreadsheets.  Like spreadsheets, LabView has a very simple way of specifying sequence of execution.  An object in LabView executes whenever all of its inputs are ready.  This corresponds to a spreadsheet where a formula may be recalculated as soon as any other cells it depends on have been recalculated.  So, in theory, every single cell in the spreadsheet that creates an input for a certain cell may be computed in parallel.  Likewise with the objects in LabView.  Conventional languages, by contrast, consist of lists of steps that must be evaluated strictly in order.

Here is the other amazing thing about these two.  People may complain about how hard it is to learn parallel languages like Erlang, but who complains about learning spreadsheets?  They’re easy.  LabView is so easy that National Instruments has managed to build an almost $700M a year business around it.  Their EBITDA income was a little over $100M on that, and they are growing at about 20% a year.  Now Sun won’t break out Java’s revenues, but this company is nearly 10% of Sun’s size.  I have to figure that if Java were close to $700M they’d want to talk about it.  How’s that for the biggest language company you’ve never heard of?

When we compare LabView to something like Erlang, it shows up pretty well.  Recursion is a fundamental construct in many parallel languages like Erlang, but it isn’t necessarily a fundamental construct for many human minds.  Yet the idea of delegation, which is one form of parallelism, and of an assembly line, another form of parallelism often called pipelining, is very natural for people, and is inherent in dataflow languages such as spreadsheets and LabView.

There are other languages like this floating around too.  Yahoo’s Pipes is one designed for doing mashups that’s very cool.  The ease of use seems to carry over into this domain too as I read various examples:

The list goes on, but there seems to be a lot of potential unleashed when you quit thinking about things as a linear list to be solved strictly in order and break loose a bit more parallelism.  Like I said, it’s something completely different to think about.

Posted in multicore, platforms, ria, software development, Web 2.0 | Leave a Comment »

The Ugly Truth About the Force Platform: Salesforce’s is no better than SAP’s or Oracle’s

Posted by Bob Warfield on September 19, 2007

Phil Wainewright’s Digging Beneath Salesforce.com’s Platform Hype is all about how there didn’t seem to be much beef involved in the long series of keynotes about Force, the new name for the Salesforce platform.  Phil concludes that this had to be done because Salesforce needs to convince the Thought Leaders out there that it is more than just a CRM company.  I take away a different conclusion about the lack of substance.

As LucidEra’s CEO Ken Rudin says:

Trying to move from on-premise to on-demand is not just an exercise in relocation of software. On-demand is much more than that. It’s about making a solution that is easy to set up and easy to use.

The italics are mine.  For “easy to set up”, let’s substitue “easy to customize”.  Rudin waxes eloquent about how hard conventional software like Business Objects and SAP is to customize and how this difficulty is not a function of which data center the software is located in.  If you take a product that’s hard to customize and host it, you do not have SaaS, you have SoSaaS (Same Old Software As A Service).  That ain’t all bad, and it is better than conventional software for a variety of reasons, but it isn’t what we really wanted which is to radically improve the platform concept by making it a lot easier.

My problem with Salesforce is I am having a terrific amount of trouble seeing Force as any easier a customization mechanism than what the SAP’s and Oracle’s have to offer today.  Come to that, it’s hard to see it as an easier platform for creating new applications either.  Don’t take my word for it, have a look at the AppEx Language Reference.  That book gives the following description of the advantage offered by using AppEx versus conventional languages:

These client-side programs, typically written in Java, JavaScript, or .NET, grant organizations more flexibility in their customizations. However, because the controlling logic for these client-side programs is not located on Apex platform servers, the clients are restricted by:

• The performance costs of making multiple round-trips to the salesforce.com site to accomplish common business transactions

• The lack of transactional control across API requests

It goes on to say:

Using syntax that looks like Java and acts like database stored procedures, Apex Code allows developers to add business logic to most system events, including button clicks, related record updates, and custom s-control displays.

So, we get a bit better performance and we can make multiple API requests within a single transaction. All this is done using a language that looks like Java.  Folks, I have to tell you, that isn’t revolutionary and the esteemed On-premise Big Boys will tell you their platforms do the same.

VisualForce offers very little new as well.  First of all, it isn’t a visual tool, it’s a tool for creating visual changes.  It uses a tagging language not unlike ASP or JSP to make those changes.  It is cool that you can open a little source window below your app when working on it, and it’s great that the look and feel of Salesforce can finally be customized, but once again, this has all been available for the other players for a long time.

Force confirms what a lot of folks in Silicon Valley have been saying for a long time: the tremendous success of Salesforce.com is part their own stupendous efforts, and part that their domain is tailor-made for SaaS.  It is tailor-made because it requires little customization.  SFDC got to 900,000 seats without much of a platform, and they’ll get much further as well.  Their platform is assured a certain amount of success for those who wish to use it as a way to build more components to tie to Salesforce or as a way to extract sales leads from the vibrant Salesforce ecosystem.

Delivering an order of magnitude simplification for customization is extremely difficult to do.  Lots of innovation is required.  Most SaaS vendors opt for just not letting their users perform much customization.  It’s surprising how often this works.  It gives customers a reason to accept “no” and keep their project simpler.  This gets them value that much sooner and often the customizations are never missed.

Whether the Force platform becomes a major strategic driver by being the foundation for many applications that have nothing to do with Salesforce will be a function of how well the hype works and how quickly they are able to add functionality to give that platform the advantages it lacks today.  What they won’t have going for them is the natural domain:  platforms are all about customization and just hosting them isn’t enough to make them compelling.  That’s not a bad thing at all.  Owning a platform that works around CRM and adjacent spaces is still extremely valuable.  It just doesn’t catapult Salesforce into the position of radical expansion beyond CRM.

Posted in platforms, saas, software development | 3 Comments »