Err... No, not really.
The thread is long, yes, but to say that matters have come to a conclusion, that it is possible to even arrive at an executive summary is premature. As far as I'm concerned, there have been no conclusive arguments in favor of Scott's summary. But since the discussion is now apparently to be held in blog form, here's my summary.
- Blessing the use of scripting languages for writing complete applications is important. Equally important is not to bless a single language. Let's first see in which languages applications actually will be written. The really important thing is that among the set of tarballs that comprises a complete kde release can be applications completely written in a scripting language. Of course, apart from Python and Ruby there are no serious candidates.
- There are still people who think that the current bindings to Qt and KDE of, for instance Python, are not completely mature and stable and that the maintenance of those bindings will cost kde-core hackers time. Come on, guys! Living under a rock is not healthy. We've had stable scripting language bindings for more than half a decade. They just didn't take off because kde doesn't package scripted applications, relegating them to the whims of distribution packagers.
- Forcing users to script in Javascript is an act of unmitigated evil. Allowing them to do that is okay.
- Making applications extensible through scripting should be done with Kross. Using Kross exposes a single API for your applications to dbus, javascript, python and ruby. That means, no longer designing a separate dcop api and a separate kjsembed api. It also means that people actually using the applications can code their extensions in the language they already know.
- I'm fine with no, or just one, or two scripting languages allowed for extending or implementing kde-base and kde-core bits. I still think that Kross is better than just mandating kjsembed. Look at how cool Kross is: Kross 2.0 and DBus. Kross really is the definitive solution to scripting KDE, on a par with what Beos had, maybe even better.
- The reason we haven't had a ruby-python flame war is, I think, that the proponents of both languages have been pussy-footing especially to avoid such a flame-war. Nobody wants anybody to lose that war. (As for me, as soon as Ruby has real Unicode support, I'll look at it, not earlier. I still remember the days Python didn't have Unicode support. That was hell.)
Oh, and I would rather not that people term a programming language discussion that has been remarkable for its civility "wanking". That's about as bad a rhetorical discussion-killing device as I've ever seen.