I wrote a question on the OpenCV forum and got an amazingly comprehensive and useful answer from pklab.
It’s extraordinary how he (or she) has immersed themselves into the project of solving my problem. I’m humbled.
Dog seems to be a little language for writing social software.
Initial thoughts :
Big question is what it compiles to. It’s about time we had a programming language that compiles a single program down to parts that run on both server and clients, in a really easy and transparent way.
Building in knowledge of protocols like http and json and making services like twitter at least members of the standard library is a good idea.
Like most programmers, I’m sceptical of the “easy English-like” nature of it. We’ve had plenty of time to learn that what’s hard in programming is the logical thinking not the strange syntax. (Update : See my Quora answer)
But if Dog can become a little-language which makes it easy to configure and administrate social software back-ends then it will be very useful. Particularly if there are ways of compiling the same program down to multiple back-ends (Django, Rails, Chicago Boss etc.)
More of Joel Spolsky’s smart understanding of “social software” as both social and software. Now StackOverflow evolves to become a smart online CV for recruiters.
Socialtext is announcing today that they are adding integrated spreadsheet capability to their enterprise-level wiki, making use of the new SocialCalc code I’ve been developing with them. This isn’t just a repository of separate spreadsheets, nor a separate standalone system like wikiCalc, but rather a full wiki where a page can be either the traditional paragraphs of text or a spreadsheet grid.
Cool … now, if they could just *also* add network diagramming as another page-type that would really be getting somewhere. (Not, of course, that the grid pages in SdiDesk really achieved “spreadsheet” status … but that was always a long term hope.)
Ah … well …
Actually, there may be some SdiDesk news soon … you never know.
Chatting with BillSeitz I found myself saying this :
MTC needs to have what Udel called the “special charmpower” of email … that groups are spontaneous and form bottom-up from the flow, rather than having to be designed up-front, prior to the flow …. otherwise people keep using email