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" <ori(a)wikimedia.org> wrote:
On Fri, Aug 9, 2013 at 4:18 PM, Diederik van Liere <
dvanliere(a)wikimedia.org> 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