So I like to ask myself that question explicitly... and a lot. The answer changes both from project to project as well as over time. I used to play music for other people to listen to, but these days I play it just for myself. (I'm pretty sure the world is a happier place for it, too. ;) Plasma, however, it meant as a public participation project and we have only bigger plans for it down the line. As such, it's always interesting to see other people's take on it, such as in this article by Brian Proffitt the other week. I can't tell anyone what Plasma is for them, really, and given that people have a variety of thoughts on that matter is pretty cool.
We talked about target audience a fair bit at Tokamak I. When it came to scripting, it was no exception. It turned out that I had a mildly different idea of the target audience for the scripting compared to others who are involved. This is probably in part due to the fact that I'm not an "interpreted languages guy". Don't get me wrong: I looove the ruby .. but I code mostly still in C++. So instead of coming at it from a "interpreted languages (IL) are awesome and a reason in and of themselves" I perhaps come at it from a slightly more cautious position that asks first and foremost: who is the audience?
With Plasma scripting, I see three audiences: libplasma, ninjas and myspacers. Ok, I'm sure none of that made any sense to most of you, so let me explain.
First off, I know that libplasma isn't a sentient being. Yet. ;) So when I say that libplasma is one of the audiences, I mean that libplasma itself needs to have a way to work with the scripting that isn't an afterthought or some transparent magical loading of scripts. The scripting interface needs to be purposeful, manageable, integrated with other parts of libplasma and possible to be made safe. I have been surprised at how the relationship to libplasma is often not even talked about when discussing scripting; perhaps the IL people are just too used to fending for themselves and not being considered seriously during the design phase.
The result of this awareness is a set of well defined interfaces between libplasma and the IL support. This allows for uniform and extremely flexible possibilities (in terms of language and exposed API) when it comes to IL support. It also means that we are designing whole areas of libplasma around the eventual use cases for interpreted languages in Plasma; in fact, the new widget API for 4.1 was designed 100% for the foundation of sane IL API exporting. In fact, it was designed by Richard Moore, the IL guy at Tokamak. This was not an accident: he was tasked with this specifically because he could design it from that perspective better than someone like poor old C++ me.
What about the other two audiences I mentioned: ninjas and myspacers? Well, now we're talking about real people again, at least in abstract terms.
Ninjas are people who are awesome at what they do. Unfortunately, most people aren't good at a given topic (though a lot of people, perhaps even most, are good at some topic). That means that if you pick a certain endeavor, there will be few ninjas of that sort. So it is that there are likely to be few widget making ninjas out there, relative to the size of the audience. Fortunately, they make awesome stuff that most of the user audience will want to pick up on.
By opening up Plasma to other widget systems such as SuperKaramba and MacOS Dashboard we widen our ninja audience. This is one reason having "libplasma" as an audience is so important.
However, we want Plasma Ninjas too. In fact, it would be great if there were evntually more Plasma Ninjas than other kinds of widget ninjas. (Yes, I know that will require market share to achieve. We're working on it ;) What do Plasma Ninjas need? More than anything else, they need a powerful API. I think they also will probably want a design studio, something we'll eventually get to working on. First comes the API, however. So we want to give these ninjas the ability to do much of what you could in C++, only faster, slicker and with fewer stupid details.
Now quickly move to the next audience: myspacers. That's my pet term for the kind of people who glom onto sites that let you easily modify an interface with a little bit of work. They looooove tinkering but their skill level is pretty low. They also tend not to create things very often that many other people would want to use. However, there are a lot of them.
What do the myspacers need? A stupidly simple API, and certainly a point and clicky designy thingy. Making a simple clicky designy thingy (a toy level design studio) requires a really simple API; Macromedia's flash studio tools are beyond this kind of person, generally. That gives you an idea of the simplicity required.
I don't think there's anything wrong with this either: there's nobody who stops you from buying paint and paintbrushes from the art supply store just because your painting skills are questionable. So there shouldn't be any reason to do similarly to people whose aesthetic or coding skills are similar (so long as we don't inflict their work on you, right? ;)
The value in the myspacer crowd is that they make products popular. More and more participation means winning when it comes to concepts such as these. I want to let the myspacers of the world make and share their probably pointless-in-the-big-picture but extremely personally satisfying (to them and their friends) things. Excuse the buzzwordy nature of this, but: democratizing creativity.
If you think that audience doesn't exist, I would ask you to go visit myspace for a moment. Or go hang out at a local hobby shop; check out how many hobbyist painters, fly tiers, sportsmen, etc there are out there. People are creative and put effort into things .. they just tend to be pretty mediocre at it. This audience is not only large but, from a human perspective, deserves the chance to play too.
Now we have a dilemma: we have two groups, both of whom it would be nice to service, but who have very different needs. Both are valuable, however, in terms of "audience" which is an aggregate of number of users of widgets and number of creators of widgets. Perhaps a picture sums it up best:
To optimize a widget system for one group will cut out the other one due to skill differences; either you'll get something too complex for the myspacers or too limiting and toy-like for the ninjas. Or worse, the API will cater to a group somewhere in the middle and instead of maximizing the audience the API will guarantee a minimizing.
Of course, API is just on part of the equation: support tools is another, but market share is probably the biggest. Myspacers are flockers and ninjas go for audience reach. But those are ingredients that must come after having the right scripting API.
The solution? Well, I don't know if there is just one solution per say, but here's mine: we're going to have two different kinds of APIs. One for ninjas. One for myspacers. Plasma's design allows for that, even using the same programming language for both since we differentiate based on target API not implementation language. As a neat side effect, it turns out that the myspacer style API is also a hell of a lot easier to secure.
So there you have it: my very long winded explanation for why there will be multiple scripting APIs in plasma. It all starts with the question of who our audience is and the moves on to how to stand a chance of capturing them.
Now I have to go to the airport to pick up Zack. *hugs*
