From my perspective, the most important thing for the
mobile department is
to have a tool that is easy to use, very easy for us to develop
generally requires the little overhead for us to work with and interact
with the data we care about. I'd be surprised if anyone on the mobile team
is particularly married to Limn. While I haven't interface with it much
(aside from perusing graphs), it seems like Limn has been fairly trivial
for us to use to generate our data visualizations, and as such has been
great for us. Perhaps folks from the mobile dept who have spent development
time with Limn ought to weigh in on this - Juliusz, Jon, Yuvi (anyone else)?
On Sat, Aug 10, 2013 at 7:45 AM, Dan Andreescu <dandreescu(a)wikimedia.org>wrote;wrote:
Some quick background, important for what follows.
Coco is a language
Perl and Ruby and Python. We don't use the vast majority of them in Limn.
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
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
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
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
> 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
> 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
> 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.
> 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
> 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
Software Engineer, Mobile