Open source client
Posted: Fri Jan 19, 2007 8:39 am
From last night's tech talk discussion about family history, it appears that no decision has been made as far as which language to use for the open source client. As I drove home last night, I have some additional thoughts you might want to consider in your decision to either use C++ and widgets, or Java.
1. Cross platform - C++, although "formally" an ISO standard, has significant deviations between compilers, let alone across platforms. Due to the differences just in compilers, it would be more difficult to port code from one platform to another (or one compiler to another). Java does not have this problem.
2. The API - While C++ has a tremendous number of addons, the language itself does not compare to the standard API that comes with Java. This API is available across all platforms Java supports--that's not any additional work the Church has to do--it's done by others. Yet you get the benefit of it.
3. "Grandma doesn't want a 50MB download for the JRE". What does the "typical user" get out of the box on their PC? They get Windows, along with the power of WordPad, Paint and calc. If they want some type of word processor or spreadsheet application, they're going to purchase something on a CD and install it (if they don't have a broadband connection). Or they'll be really patient and download it over their slow connection.
From my point of view, the overhead of the JVM is minimal in comparison. How much "overhead" (i.e. installed size) does Microsoft office take? Yet how many people use it? There's so much out of the box with the JRE (especially in Java 6 with derby, matisse & the gang) this 50MB download isn't an issue. Besides, with the open sourcing of Java, the JRE is more likely to appear on the standard images major PC manufacturers send out. My word, the Church is a large enough customer of Dell--start requesting the JRE put on all the machines you purchase. If that happens with enough other companies, the JRE will be more often pre-installed.
Again, look at all you can do out of the box with the JRE. That's a piece of software you won't have to tweak--you just distribute your app and say it requires the JRE. Done deal. It would be significantly more complex to say "well, here's the C++ code, and by the way you'll need packageA, and packageB, and packageC, and packageD and so on).
4. Language features - If you really are serious about "leaving behind" the mistakes of the past, and are serious about supporting multiple platforms, stay away from C++. You likely know as well as I how easy it is to write procedural code with C++. You should be writing this client not only as a proof of concept, but as an example to show others how to be successfully using your new API. Write it well, and write it in a language that more easily supports the principles of OOP. Yes, I'm fully aware that C++ supports OOP. And I'm also fully aware that the same program can have bits of C in it. Are you interested in hacky code, or are you interested in solid design?
5. Internet/networking support - Back to the API. What built-in (i.e. standard support) does C++ have in the internet/networking realm? Sure, you can get code to do ssh, or http or whatever, but is it part of the "standard" language? Nope. Java on the other hand--designed with the Internet in mind.
6. Portability - If the client were to be written in Java, you suddenly have cross platform support. No additional work on your end is required. If it were done in the C++ route, that would require you to suddenly be maintaining 3 (at least three) separate clients--one for the Mac, one for Windows, and one for Linux. Why write it three times (or at least maintain it three times) when you can do it once in java and be done with it?
For those living in the .NET world, C# is close enough to Java that it could easily be ported by anyone wishing to do that. However, the conversion from C++ to Java (or C#, for that matter) is more complicated.
7. Java is slow - I've found Java 6 to be significantly faster on Windows than previous versions (won't get into the political reasons between Sun and Microsoft here). Running Java on other OSes (say linux and OS X), speed has never been a problem.
From my point of view, any possible deterrent of using Java is FAR outweighed by its advantages. By the way, I'm not a Java bigot--I'm fully aware of .NET. However, I'm far more interested in using something open and cross platform by design (did I mention open?) with support on major OSes. While I agree that mono is cool (http://www.mono-project.org) and works remarkably well, it is done without any support from Microsoft at all. Heaven knows even with Microsoft support you're on shaky ground (Symantec, McAffee, Citrix anyone?), let alone without it. Besides, use of Java would make you more internally consistent as well (based on other presentations by the development folks in ICS).
Then again, there's always kde4 ([url]http://www.kde.org)[/url]...
1. Cross platform - C++, although "formally" an ISO standard, has significant deviations between compilers, let alone across platforms. Due to the differences just in compilers, it would be more difficult to port code from one platform to another (or one compiler to another). Java does not have this problem.
2. The API - While C++ has a tremendous number of addons, the language itself does not compare to the standard API that comes with Java. This API is available across all platforms Java supports--that's not any additional work the Church has to do--it's done by others. Yet you get the benefit of it.
3. "Grandma doesn't want a 50MB download for the JRE". What does the "typical user" get out of the box on their PC? They get Windows, along with the power of WordPad, Paint and calc. If they want some type of word processor or spreadsheet application, they're going to purchase something on a CD and install it (if they don't have a broadband connection). Or they'll be really patient and download it over their slow connection.
From my point of view, the overhead of the JVM is minimal in comparison. How much "overhead" (i.e. installed size) does Microsoft office take? Yet how many people use it? There's so much out of the box with the JRE (especially in Java 6 with derby, matisse & the gang) this 50MB download isn't an issue. Besides, with the open sourcing of Java, the JRE is more likely to appear on the standard images major PC manufacturers send out. My word, the Church is a large enough customer of Dell--start requesting the JRE put on all the machines you purchase. If that happens with enough other companies, the JRE will be more often pre-installed.
Again, look at all you can do out of the box with the JRE. That's a piece of software you won't have to tweak--you just distribute your app and say it requires the JRE. Done deal. It would be significantly more complex to say "well, here's the C++ code, and by the way you'll need packageA, and packageB, and packageC, and packageD and so on).
4. Language features - If you really are serious about "leaving behind" the mistakes of the past, and are serious about supporting multiple platforms, stay away from C++. You likely know as well as I how easy it is to write procedural code with C++. You should be writing this client not only as a proof of concept, but as an example to show others how to be successfully using your new API. Write it well, and write it in a language that more easily supports the principles of OOP. Yes, I'm fully aware that C++ supports OOP. And I'm also fully aware that the same program can have bits of C in it. Are you interested in hacky code, or are you interested in solid design?
5. Internet/networking support - Back to the API. What built-in (i.e. standard support) does C++ have in the internet/networking realm? Sure, you can get code to do ssh, or http or whatever, but is it part of the "standard" language? Nope. Java on the other hand--designed with the Internet in mind.
6. Portability - If the client were to be written in Java, you suddenly have cross platform support. No additional work on your end is required. If it were done in the C++ route, that would require you to suddenly be maintaining 3 (at least three) separate clients--one for the Mac, one for Windows, and one for Linux. Why write it three times (or at least maintain it three times) when you can do it once in java and be done with it?
For those living in the .NET world, C# is close enough to Java that it could easily be ported by anyone wishing to do that. However, the conversion from C++ to Java (or C#, for that matter) is more complicated.
7. Java is slow - I've found Java 6 to be significantly faster on Windows than previous versions (won't get into the political reasons between Sun and Microsoft here). Running Java on other OSes (say linux and OS X), speed has never been a problem.
From my point of view, any possible deterrent of using Java is FAR outweighed by its advantages. By the way, I'm not a Java bigot--I'm fully aware of .NET. However, I'm far more interested in using something open and cross platform by design (did I mention open?) with support on major OSes. While I agree that mono is cool (http://www.mono-project.org) and works remarkably well, it is done without any support from Microsoft at all. Heaven knows even with Microsoft support you're on shaky ground (Symantec, McAffee, Citrix anyone?), let alone without it. Besides, use of Java would make you more internally consistent as well (based on other presentations by the development folks in ICS).
Then again, there's always kde4 ([url]http://www.kde.org)[/url]...