How does it relate to this discovery: https://news.virginia.edu/content/uva-smashes-barrier-growin...
("By manipulating the appropriate signaling, the U.Va. researchers have turned embryonic stem cells into a fish embryo, essentially controlling embryonic development.")
> I suppose utility rests on whether you treat it as a collaborative development platform or merely as a host for your code (and keep track of discussions, proposed changes, and what-not through other means).
They both naturally blend together. I honestly can't understand what is the difference between these two that you are thinking about.
> Essentially, whether or not it turns out to be useful assumes that it is used as the central collaboration platform to an extent.
This is the initial plan.
> Though on the other hand, merely tracking changes on a higher-level could be sufficient.
Some day we can implement a client side structural diff tool.
Sure, more languages are on the way! The problem with PHP, however, is that when it is used in a HTML page as template language, you can't get much from it. On the other side, when it is a simple class file with no HTML markup, things should work as with any other language.
> It will probably be pretty hard to apply that to C (cpp) and Lisp (macros, and especially the programmable readers in some Lisps).
C is really hard to parse because of preprocessor. We built a prototype parser for it, and it mostly works, but it's not ready yet for the prime time.
Lisp must be a much simpler language to parse, though.
> scanning for API changes between two versions of a framework
Yes, we have this idea on the to-do list! Imagine that you are comparing two different branches of development, or two different tagged releases, and see high-level API changes between them.
> Question: For every language, are you writing a full-blown language parser to get the semantic information you need?
That is correct. The structural diff algorithm is generic, it operates on langauge-neutral feature trees. And those are built with the langauage-specific parsers.
> Can I hook in new parsers to add language support?
Writing a parser is not an easy job. But some day we hope to open API for developers to write custom plugins.
> Pathological love for Java and anything resembling Java.
And I think that's the good thing. Over years I finally realized, it's not the programming language you use that matters, or makes you look smarter. It's the kind of problem you are trying to solve by writing code. Computer Science field is far, far reacher than the PL research subfield.
I mean, you may be writing another boring enterprise web application in Haskell, or solving Artificial Intelligence problem in Visual Basic. I would prefer later rather than former, although I hate VB. I know, both situations are contrived, this is just a thought experiment to illustrate my point.
Don't get me wrong, I love "esoteric" programming languages. Few years ago I spent quite a lot of time playing with Haskell, Prolog Lisp, etc, and I don't regret it. No, I don't use these on daily basis or going to, but I studied a hell lot of coll new stuff. Most importantly, it taught me about new _paradigms_ of programming, that I really think every programmer should understand.
These days, however, I try to squeeze as much math and algorithms from different domains as I can in my poor stupid head and I think that payoff of this would be much bigger for me.
PS
Few month ago at a local functional programming meetup some guys presented their Scala solution to a trivial problem of validating web forms in a rather trivial web application. Their solution employed the whole lot of functional stuff, like functors, mappings and the things whose names I forgot. I was trying to understand what they are doing but they lost me after fifth minute of the presentation. It took them maybe a week to write all this code. Do you see the irony?
Although I must admint, jogojapan has written a really clear and thoughtful explanation of Ukkonen's algorithm on stackoverflow, the best one I've ever read.