Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
You were 'forced' to start working on Git as a result of Jeremy Allison's reverse engineering of the BitKeeper protocol and Larry McVoy's hostile reaction.
At first you weren't too enchanted about the waste of time having to write your own DVSC system from scratch for lack of acceptable alternatives. I remember you complaining about that work preventing you to progress on the kernel.
Now Git is becoming the de-facto tool for source control management in most F/OSS communities and inside companies. That's another very successful project you fathered, and while I guess Mercurial or other projects would have existed anyway, the usage of Git on the kernel has demonstrated its reliability and its performance and traction have made DVCS'es gain visibility and market in no time.
Here come the questions:
* Are there any features you still miss from BK?
* As a happy Git user, I thank Jeremy Allison for his refusal to accept compromise and his tentative to create a Free BK client and I thank you for your refusal to accept a technically inferior/ill-suited solution like SVN. How do you reflect on this?
In fact, I think OSGi is costing us *less*, because for an application like the one we're developing that requires modularity, we would have ended up writing our own inferior, more expensive and most of all not standardized "plugin system". In fact, in my company there are many different kinds of modules systems that were previously developed and we can't easily exchange modules between those systems (developed for different projects, clients, etc). With OSGi, we can start to share more than just classes or jars. Good bundles do half the integration work.
Anyway I'm not trying to convince you. OSGi is no silver bullet, and it can be difficult in practice when you're plugging into legacy. But when it's working, then it's really nice. My non-OSGi inclined co-workers even grew to like it.
A lot of Java projects are now OSGi-ready though. It's really taking off. I also agree that the tooling is not perfect yet, but it's improving. If you are using Eclipse, I recommend using BndTools rather than PDE. It's a lot less stressful.
In general, I believe the constraints clean programming in OSGi put on the developer lead to better design/architecture, cleaner separation of concerns, even if you're going to dump OSGi after that. But usually when you reach that point you usually get to like it: like coffee, it tastes bad at first. Unlike coffee though, there are too many ways to do OSGi wrong, because there's a lot of contradicting approaches around there. The common wisdom is to avoid the OSGi API when we can (it can be avoided if we don't have to register services dynamically or do framework-level stuff), but after that all hell breaks lose when it comes to testing, building, what editor to use etc. Too many dissenting voices make it long to find a non-intrusive way, but it exists!
Damn, I sound like a commercial, but really OSGi and DI are the only thing that made me enjoy Java. I disliked it before. Also, OSGi is a nice way to do mix polyglot JVM components and that's the "next big thing" (which is not novel at all, but all this has happened before, and will happen again...)
By the way, another great (but free/creative commons) book on OSGi is Neil Bartlett's "OSGi in Practice". I can't recommend it enough. Unfortunately, it's still in draft so some parts are not completed, but I learnt more about OSGi reading this book than any other resource I could find (printed or online), except maybe looking at the frameworks' code directly.
A branch of the Scala IDE for eclipse shows when there's an implicit conversion by underlining the converted expression. I guess this feature will come to other editors soon enough. Also, to have this conversion, you must have imported it (or its package object). The predefined conversions in scala.Predef are doing what you'd expect them to do and aren't very dangerous (much less, than say, built-in automatic conversion in some dynamic languages).
Implicit parameters are just like dynamic default values. Not a big deal really, especially since Scaladoc hides them by default, you don't even have to know they're here. But they open for a world of possibilities to change the behavior of an API.
In general, implicits in Scala are really a powerful tool and they're useful for API designers more than 'common' users. You said it's not about FP, but Scalaz which is the FP lib for Scala uses them to their fullest extent to replace class inheritance (considered harmful) altogether.
Your pejorative, and erroneous use of the word "socialism" betrays your bias.
All of these alternate languages can use the wealth of libraries available for Java, generally on all platforms on which the JVM runs. For example, I know of Scala apps that can run on Andriod, which is close enough to Sun's VM.
Concerning type erasure, as it has been pointed out by my sibling-thread, it's a design choice. Scala also has adopted type erasure with generics. The other choice could have been made, that is encode type annotations for generics in the bytecode. There is nothing in the JVM preventing it to be done, since it can be done manually, the [alternative language] compiler can add the required info. In Scala, the choice has been made to mimics Java (and I guess, the more the generated code will look like Java, the more we will benefit from runtime optimizations). Thanks to Scala's very powerful syntax, there is a library called Manifest that automatically adds the type information and easily allows you to code as if there were no type erasure.
Still, I agree this feels like a weird rule, especially the first time you run into it. It is not the expected uniform behavior. The same goes will tail-call optimization that should be in the JVM (and should be in OpenJDK7), closures, etc. Generally speaking, the JVM should be a generic platform for languages exactly like the
But I am one of those guys who wouldn't run Scala on
You have done an impressive work with Mono. Don't you think the same effort could have been to make the [renamed] Java platform as generic and powerful at the
We both know the linked article is a joke and Mono doesn't seem to be gaining any real share. Sure, C# and
At the end of the day, I just regret the Mono vs Java situation created yet another division in the community. Of course, and I thank you for it, you are very much responsible for OpenJDK becoming free. And I agree that Sun's strategy regarding both licensing, evolution and genericity of the Java platform has been awful. Yet, right now, between the two, most free software enthusiasts would choose Java. There is no way to rewrite the past, but maybe there could be a way for a better outcome.
(2) Do you think creating your own SCM was the good decision, in opposition with using metadata in combination with SVN or git?
(3) Are there any plans to liberate Jazz under the EPL or another Free license, and do you believe Jazz can really gain enough traction as it is? There are plans to integrate Google Wave in the Eclipse Communications Framework by 2010, EGit is coming fast and has a lot of momentum among Eclipse developers, Mylin is getting better with every release, issue trackers are getting a lot better, continuous integration engines such as Hudson work really well... To me it looks like Free Software alternatives are going to beat Jazz at its game (not as well integrated at first), because this is typically software that companies want for free, and Free Software communities want Free Software (I know Jazz is gratis for Open Source projects).
(4) What's your opinion on the new wave of JVM languages such as Scala or Clojure? Did you try playing with them?
(5) Are you planning on participating in the development of E4? Regarding alternative JVM languages, there is a real need to refactor JDT to extract a "JVM-language" development tooling on which the specific Java - the language - tooling is built. The current architecture has been problematic to the development of good environments for alternative JVM languages (Groovy, Scala, JRuby,
In fact, this goes so far that there is a French word for it that has no exact English equivalent: http://en.wikipedia.org/wiki/La%C3%AFcit%C3%A9
I never figured why you "atheists" need to justify your lack of belief and disprove God's existence. Who gives a shit really? Over here in France, I have maybe met 10-15 true believers of my generation in my whole life, including a few who were simply insane.