Java or C++ (Benchmarking)

[phil hunt]

On Wed, 9 May 2001 09:05:25 +0100, Jon Skeet <skeet at pobox.com> wrote:
>phil hunt <philh at comuno.freeserve.co.uk> wrote:
>> On Mon, 30 Apr 2001 18:53:40 +0100, Jon Skeet <skeet at pobox.com> wrote:
>> >phil hunt <philh at comuno.freeserve.co.uk> wrote:
>> >>[stuff]
>> >
>> >for (Iterator it = collection.iterator();
>> >     it.hasNext(); )
>> >{
>> >     ItemClass item = (ItemClass) it.next();
>> >     item.doSomething();
>> >}
>> 
>> Not in the general case, because item might not have a doSomething()
>> method -- for example ItemClass could be a built-in class. 
>
>Not at all sure what you're getting at here.

E.g. if your collection is an array of Strings, you can only say
item.doSomething() if the String class has a doSomething() method.
Otherwise you must pass the item as a parameter to the method, e.g.

   doSomething(item)

but that won't work because you can't have a function in Java, it
all has to pretend it is OO, even when it isn't, so you have to 
make doSomething() a class method and say:

   SomeClass.doSomething(item)
 
>> >Hardly that painful, although far from ideal. Of course, you could 
>> >further contract it:
>> >
>> >for (Iterator it = collection.iterator(); it.hasNext(); )
>> >    ((ItemClass)it.next).doSomething();
>> 
>> In the general case, you might want to do lots of things with item,
>> so you'd create it as a separate variable, e.g. in Python:
>> 
>> for item in collection:
>>    doSomething(item)
>>    doSomethingElse(item)
>
>Sure, so use the *slightly* more longwinded version as above. Yes, you
>need braces to indicate the block. Is that really such a problem?

Not on its own, it's just a niggle (the fact that there is no way
of fixing Java's overly verbose way of doing things (such as a
#define perhaps), *is* a problem, IMO, becuse it shows the
language is hard to extend to make it do what you want.

>> That's 8 symbols, plus whatever's in the loop. The Java code of
>> equal generality is 32 symbols (4 times longer). If we just count
>> characters, we get 24 for Python and 90 for Java, 3.75 times longer.
>> 
>> Now consider that C is reputed to be about 5 times quicker in
>> prgramming time, and produce 5 times less LOC than assembler.
>> 
>> So, it is like the difference between Python and Java is almost
>> as big as the difference between C and assembler. (Interestingly
>> for this analogy, there's a version of Python that compiles to
>> JVM code).
>
>For this *one* section of code. I don't know Python, but I suspect there 
>would be other examples where it takes 3.75 as many symbols to do 
>something in Python as in Java.

Probably, but I expect that for longish code segments, the Python version
will typically be several times shorter. My guess is that it would
probably be around 2-3 times shorter. (Crosssposeted to comp.lang.python to
see what other people think, who know both Java and Python).

>> I think Java would be better if it had a construct:
>> 
>>    iterate (ItemClass item in collection){
>>       ...operate on item...
>>    }
>
>Yes, quite possibly that would be an improvement. I don't think it would 
>be a huge improvement, however, and I don't believe the lack of such a 
>syntax is the huge problem you portray it as.

On it's own, I don't think it's a huge problem. The huge problems IMO are 
that (1) my whole experience of programming is Java is like this, and
(2) you can't fix it within the Java language.

Consider another example. Blocks in Python have a very simple
syntax, e.g:

   myFun = lambda x: x*2

The equivalent in Java involves inner classes and has (IMO)
horrendously complex syntax.

Consider this in Python looks quite straightforward:

funs = []
funs.append(lambda x: x)
funs.append(lambda x: 2*x)
funs.append(lambda x: x*x)
funs.append(lambda x: x*x*x)
for i in range(1,10):
   for f in funs:
      print "% 4d" % f(i),
   print
 
And outputs:

philh:~> python temp.py
   1    2    1    1
   2    4    4    8
   3    6    9   27
   4    8   16   64
   5   10   25  125
   6   12   36  216
   7   14   49  343
   8   16   64  512
   9   18   81  729    

The equivalent code in Java would be much longer.

>> > and I'd also dispute the idea that you 
>> >weren't fighting the Java way of doing things,
>> 
>> Yes, it always feels like I am fighting the language whenever I
>> code in Java.
>
>No, fighting the Java way of doing things. 

That amounts to the same thing, IMO. Java has a "way of doing
things", i.e. to use it essectively you have to bowe down to the
Gospel According To Gosling about the One True Way to write code.
That's why I call it a "bondage and discipline" language. Pascal
is like this too. C and C++ don't have this philosophy, IMO.

-- 
*****[ Phil Hunt ***** philh at comuno.freeserve.co.uk ]*****
Pstream class library for C++: a Parsing Stream library that 
facilitates writing lexical analysers and other programs
that parse data files. Available on an open source license from
<http://www.vision25.demon.co.uk/oss/phlib/intro.html>