From my perspective, the most important thing for the mobile department is

Some quick background, important for what follows. Coco is a language that compiles to Javascript. It has tons of fancy features inspired by Perl and Ruby and Python. We don't use the vast majority of them in Limn. We use Coco because it's more productive than Javascript once you get comfortable with it. This took about two weeks for me and personally I think it was worth it. I'm happy to address specific points that others like Terry and Ori raised about Coco. Not all my answers will favor Coco but overall I like it. The second important thing is that Coffeescript is strictly worse than Coco. That's pretty easy to show and I point you to the satyr github page for examples. Diederik, you estimate that the choice of language for Limn should be done before a new resource is hired to work on it and before we resume development of fixes/features. I am not so sure this is true. I think once we hire a talented Javascript developer and we decide as an organization what we want out of our visualization solution (read: not just Limn), we can make a much more informed decision. And there are other things to consider. For example Livescript is pretty popular. WebStorm *could* make Javascript development much more productive than it has been historically. Pure D3 might have become mature enough for us to rethink using it outright. And so on. I think at the moment we'd be giving an answer without a question. Christian, as for historical reasons David used Coco. It's honestly mostly because it's a better more productive language and partly because David is a hardcore aesthete who seriously dislikes meaningless characters like brackets, etc. Ori, I think your point about Limn not being the answer forever is great. We really do need to talk about what we want out of visualization and why we can't use the many, increasingly sophisticated frameworks being developed. Like pure D3 with a few templates or plugins via Rickshaw, Vega, etc. But, as to what's valuable in the non-library 250k or so of Limn code. The purpose of Limn was to make it fun to play with data in real time. We had to stop working on Limn before we could show progress towards that goal. The one unique thing in that 250k is the marriage of D3 with Knockout. This establishes a novel way of writing visualization components that are compatible with the end goal by design, out of the box. In other words, we now have only to write the UI via which people would actually play with the data. We know of no other work in this space and it's very exciting. It's the kind of stuff that Brett Victor was playing with in Tangle JS, and we would really further that kind of deep, intuitive understanding of data if we went forward. So my suggestion is to figure out what we want first, and who's going to work on it. Then if we want pure Javascript, it would take a half hour to compile the Coco down and change some parts of the dev and build processes. On Aug 9, 2013 2:18 AM, "Ori Livneh" &lt;ori(a)wikimedia.org&gt; wrote: > > On Fri, Aug 9, 2013 at 4:18 PM, Diederik van Liere < > dvanliere(a)wikimedia.org&gt; wrote: > >> I have been talking with a lot of you in the past months and at >> Wikimania about Limn and how to move forward. One of the recurring themes >> has been that currently Limn is written in Coca and that significantly >> hinders adoption as there are very few Coco developers (Coco is a fork of >> Coffeescript). >> > > Limn needs two things to survive: users that like using it and developers > that like developing it. You have the users. You need developers. Limn is > not realistically going to attract substantial contributions from > volunteers in the open source community, so you need to hire someone for > the role. The job market for Coco developers is comparable in size and > ontic status to the job market for tooth fairies, so you will need to hire > a JavaScript developer, and you need to find a way to keep her or him > motivated. The best way to do that is to tell this developer that you > respect her intuitions and judgments and are trusting her to make the right > call re: Coco vs. JavaScript and other matters related to software > architecture. The specifications you provide should be expressed in terms > of user requirements. > > I would not attach too much significance to the choice of Coco vs. > JavaScript. The choice of Coco drew so much ire not by dint of any feature > of the language itself, but because the choice epitomized an approach to > development that focused on self-gratification and posturing rather than > simplicity and practicality. Dan's heroic efforts to clean it up have > improved things considerably, but in my estimation Limn is not going to > survive, because there are very few talented developers out there who are > enticed by the prospect of cleaning up other people's mistakes as a > full-time job. > > It is important to realize that most of the functionality that users > attribute to Limn is actually provided by external libraries (point in > fact: vendor-bundle.min.js is 411k, limn.no-deps.min.js is 254k). I don't > think that there is enough in that 254k to justify a substantial investment > of resources. > > In my opinion, the most sensible course forward is to feature-freeze > Limn, hire a good, creative JavaScript developer with experience in data > visualization, and commit 20% of this developer's time to Coco maintenance. > The primarily purpose of this 20% time is to provide a context for the > developer to interact with users and to understand what they like and what > their wishes are. Anything beyond this 20% should decidedly not be > encumbered by an indefensible a priori decision that Limn will be the > visualization framework of the future. > > _______________________________________________ > Analytics mailing list > Analytics(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/analytics > >