Rupert Smith wrote:
Aha! So we get down to the real reason that all language choice arguments
are founded on: personal preference.
Note entirely :)
There are 2 objective reasons for preferring a scripting language:
- no compiler.
- faster implementation cycle, less code.
On the first point, full interop testing will involve a Java build
anyway. However I'd like to be able to run ruby/python interop against
the C++ broker as part of our standard build cycle - precisely because I
can run those tests with no further compilation. Adding a Java build to
the C++ build cycle is possible but very unappealing.
The second point is more important though. I've used C++, Java, python
and ruby and for time spent per feature without a doubt C++ is the most
painful, Java is in the middle, and the scripting languages are way out
in front. Here's an interesting metric:
wc `find cpp -name *.h -o -name *.cpp` | tail -1
42537 133707 1247482 total
wc `find java/client java/common -name *.java` | tail -1
77318 232166 2475349 total
wc `find python -name *.py` | tail -1
4396 14149 149905 total
wc `find ruby -name *.rb` | tail -1
1312 3465 29522 total
Line counts are distorted by code formatting practices, but byte counts
are a good reflection at the very least of how long it would take to
type all the code in. The java counts are inflated by JMS support,
however even if you cut the it in half it is still an order of magnitude
higher than python. It's very hard to argue that the Java client could
have been implemented as quickly as python. (Aside: I'm still surprised
that java client+common is 2x C++ *including broker*!)
If you want to run the full interop tests, you'll need everything anyway.
And that includes the .Net, which as a Linux developer I'd be more
worried
about than the Java. The .Net client ought to run on Mono though. Or you
could run it through the windows emulator thingy perhaps? Or as a VM?
Full interop tests yes, but it should be possible to do interop tests
restricted to a subset of clients - .Net is a fine example of why.
I reckon it will take you about 30 minutes to install Java + Maven (+ Ant
can't remember if thats still needed for the code generator?) and get a
succesfull build of the Java ... Compared with how long I spent
figuring out how to run the C++ build,
thats good going.
Good going indeed! But for someone with a qpid checkout, a python
"build" takes 0 minutes.
I admit the real reason that I did it in Java is personal preference.
I know
the quirks of extending JUnit, because I wrote the junit-toolkit that
does
the performance tests.
I don't want to slow your progress, if Java is the fastest for you then
go ahead
in Java , we need to get something in place.
When I get to C++ interop I will take a look at porting to ruby/python.
As a contractor, I've done more than my fair share of maintaining other
peoples code. Here's my top list of the qualities that easy to
maintain code
should have:
* High level documentation, explains the purpose and intention of the
code,
and the interesting parts of the grand scale design (I leave the
boring and
irrelevant bits out, because no-one will read them).
* Comments in the code. Explains the purpose and intention of the
code, with
the details.
* No cut and paste coding. Where possible re-usable code should be put
into
convenient libraries.
Hear hear! Applies to python or ruby as much as Java. There are
pydoc/rubydoc tools similar to javadoc.
Choice of language seems pretty irrelevant on the whole.
In my experience this is definitely not the case. I have written
python/ruby code in hours that
would have taken me days to write in C++ or Java.
Looks like python is only more concise because there's no curly braces on
new lines and no comments.
If you can identify a subset of the Java codebase that corresponds to
the python client's
functionality, filter out all the comments and get a byte count
difference explainable as
curly braces & newlines I will never mention this again :)
Cheers,
Alan.
