I was reading this article on the Experimentia blog and I have to agree with its conclusion: internet applications are turning computing devices from platforms where applications are run into interfaces into various applications deployed remotely. As applications are moved off to the internet it follows that they are accessible to a larger audience as the cost of running those applications shifts from hosting the applications locally (as with desktop applications) to connecting to the applications.

There is one big difference between ordinary desktops and mobile phones, though, the ergonomics. As the feature set of an application increases so increase the demand for a larger interface in order to interact with that richer feature set (which could be deployed remotely, BTW). This would mean that third world consumers will first interact with an application thru a cheap mobile phone, and access a reduced feature set, and as they grow richer they could afford a tool which would allow them to access the same application thru a different, more expensive and graphically more expressive interface (the same application accessed thru a netbook).

The difference in income would drive the difference in access to the very same application. This could allow for identifying customers with higher incomes by the way they access the same free resources…

In a previous post I was saying that some technological issues are simply proxies for organizational issues and that whether one techonology will thrive or fail within an organization is not determined exclusively on the technology itself but it could be influenced by the organization itself. I ended the post saying:
For example, you may find out that DSLs will not work in particular setting not because DSLs are bad, but because the organization within which these DSLs are implemented and used simply doesn’t warrant their success.

I will get into an example where using DSLs is probably not a good fit because of organizational issues rather than inner strengths and weaknesses. Let’s say that you have some distributed teams working on the same application and that these distributed teams are led by a team of architects which need to create an environment in which these distributed teams work together. I find it pretty hard to see how this environment could be constructed using DSLs, particularly iteratively-developed DSLs, because changes in the DSL would have to be propagated across multiple teams in dispersed locations which would need to be re-trained for every iteration. Compare this approach with creating an API that would be released every so often and for which re-training costs are very small.

I have the impression that the main cost of DSLs is the distance between the place where the DSL is produced and the place where the DSL is consumed and that DSLs tend to be either specific to the location where they are produced or widely known and used within a community (in the second case the distance between the DSL producer and the DSL consumer is compensated by “mind-share”). I would say that the main difference between a DSL and an API is that DSLs are more tightly bound to the domain (by definition) and that part of the costs of using a DSL is the cost of transferring the knowledge about that domain between various stake-holders. This would mean that domain experts can adapt to a DSL targetting their domain faster than a typical developer that is new to the domain and that domain experts would be more productive. The difference in productivity between various members of the work-force means that the work-force composition should partly drive the decision to choose a DSL or APIs on a particular project. Regarding the distance between DSL production and DSL consumption this paper discussing how distance affects knowledge transfers is probably a good read.

Other issues wih DSLs such as developer lock-in (a developer working with a DSL can become out of synch with the rest of the IT landscape), the lack of language design skills on the IT job market, the problem of capturing domain knowledge correctly in large or rapidly changing domains are not explored in this post.

I end this post hurriedly…

Later Edit: I was watching this interview with Charles Simonyi and I would say I remained with these impressions:
If the DSL comes from an already existing language, such as domain experts notations, then there are chances that the DSL will be a good language (this addresses the issue of lack of language design skills on the IT job market). The problem of creating a new language is done away with by re-using a currently used language (the domain experts notations) and creating a new way to implement this existing language.
Regarding domains which are changing rapidly Charles Simonyi says that by separating the notation from the actual domain schema it becomes pretty easy to change the notation (the DSL) without affecting the underlying domain schema. Creating a DSL becomes an iterative process.
End-user programming is to remain a pipe-dream because of the difference in skills between what is needed for programming and the difference in skills needed for working within the domain. DSLs seem to engage the domain expert more into the process of software creation rather than turn domain experts into programmers. Domain experts contributions to software creation thru DSLs may be simply to communicate the domain better to a programmer. Language work benches would create a new division of tasks according to skills.

LLE: I watched this presentation by Intentional Software on domain work-benches and I remained with these impressions:
In an environment where domain workbenches are used it looks like the programmer will be involved in creating projections to an operational environment. The developer will focus on the systems while the  domain experts will focus on the business logic. This division of tasks addresses the issues arising from developers’ lack of enthusiasm about the domain.
It looks like domain work-benches should be used in large and rapidly changing domains where the transfer of knowledge from domain experts to developers is very costly due to the size of the domain and the speed at which it moves (this answers one of my questions above).

I think that the argument that I was making above that DSLs will be location-specific still applies even with a domain workbench in the picture because knowledge transfers with high costs will not appear in the creation of the DSL itself (the DSL being just one notation for an underlying domain schema, one notation among many, it can be created and used locally) but rather in the creation of the domain schema itself (which may end up being a collaborative effort carried out among people in various locations).

As I was saying above I have the impression that in the near future domain workbenches and DSLs will be used where the costs of knowledge transfers from domain experts to developers is large. If the costs of creating languages start to drop and these domain work-benches become ubiquitous then it is possible that a complete separation between domain logic (stored in domain code and expressed thru various notations) and its implementation in a system (which appears to be essentially a projection of the domain code into an operational environment) will appear. It would be interesting to work with Intentional Software’s domain workbench too.

We will have to wait and see…

L3E: This is another presentation on the Domain Workbench.

This post on the BW blog echoes some feelings that I had when the web2.0 “revolution” took off and everybody with an internet connection put a blog. I was wondering how long it will last because it was seemed similar to a trend in fashion, a trend that you don’t expect to outlast the season in which it was launched.

One pretty good example of such an application is Technorati, an application feeding off the blog frenzy that characterized the mid 2000’s. For a few years it was the go-to site for everything blog-related, today it is a has-been as interest in blogs was replaced by interest in social networks and Twitter.
I see one small problem with applications which follow and try to satisfy consumer trends: the fact that they require large investments in infrastructure (demanded by the large loads they have to satisfy) as well as the fact that they need to re-coup this investment in a relative short period of time before they become fads. 

I am wondering how volatility in user tastes will affect the funding and the revenue models for applications which are trying to satisfy consumer trends, because the gap between the investments necessary for putting up such applications and returns on these investments grows larger as the volatility increases. VCs will not be able to hedge away risks by investing in multiple applications at the same time (effectively spreading risk across different applications in the same class of applications), because all these applications could suffer large swings in their userbase. VCs will probably have to hedge away the risks of investing in these applications by investing in areas outside social-networks (green technologies, etc…).

User volatility is a pretty new phenomenon for which there is no history from which to infer much. It will be interesting to see how this will un-fold: will this type of application simply disappear because it is economically irrational to invest in them or will the costs of running such an application become so low that the investment required for it can be amortized in a short period of time? Or something else…