qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Draft Interop Testing Spec - Please Read
Date Wed, 14 Mar 2007 14:31:54 GMT
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 :)


View raw message