In article <42b2f729$0$2414$ed261...@ptn-nntp-reader02.plus.net>, Jon Harrop <use...@jdh30.plus.com> wrote:
>Bent C Dalager wrote: >> Does the C++ implementation use heap objects or stack objects?
>My guess is that the C++ is stack-allocated, and the OCaml and SML are >definitely heap allocated.
Ok. I'm not familiar with OCaml and SML, but a stack-based C++ implementation could very well beat a primarily heap-based Java implementation. It would have to take care not to do excessive copy constructor calling and have fast destructors, but this seems quite doable.
I am not aware of any reasonably easy methods of getting stack-like effeciency out of Java. Presumably, the JIT might optimize some heap objects into stack objects but pulling this off for the whole application (or even just the frequently used parts) seems like quite a challenge for the programmer.
Bent C Dalager wrote: > Ok. I'm not familiar with OCaml and SML, but a stack-based C++ > implementation could very well beat a primarily heap-based Java > implementation. It would have to take care not to do excessive copy > constructor calling and have fast destructors, but this seems quite > doable.
> I am not aware of any reasonably easy methods of getting stack-like > effeciency out of Java. Presumably, the JIT might optimize some heap > objects into stack objects but pulling this off for the whole > application (or even just the frequently used parts) seems like quite > a challenge for the programmer.
Note firstly that Java's inefficiency clearly has nothing to do with the stack as it is 5x slower than other heap-based methods and secondly that it isn't easy to tell when stack allocation will be faster (e.g. tail recursive map is only faster on long lists).
IMHO, there is something very inefficient going on with Java. I suspect a bad allocator and GC but this would mean costly objects in a heavily OO language, which would surprise me.
> Bent C Dalager wrote: > > Ok. I'm not familiar with OCaml and SML, but a stack-based C++ > > implementation could very well beat a primarily heap-based Java > > implementation. It would have to take care not to do excessive copy > > constructor calling and have fast destructors, but this seems quite > > doable.
> > I am not aware of any reasonably easy methods of getting stack-like > > effeciency out of Java. Presumably, the JIT might optimize some heap > > objects into stack objects but pulling this off for the whole > > application (or even just the frequently used parts) seems like quite > > a challenge for the programmer.
> Note firstly that Java's inefficiency clearly has nothing to do with the > stack as it is 5x slower than other heap-based methods and secondly that it > isn't easy to tell when stack allocation will be faster (e.g. tail > recursive map is only faster on long lists).
I'm still waiting on you pointing out what exactly is so inefficient about Java and it's JVM implementations. Repeating a point more than once doesnt make it true. I agree that stack vs. heap will not explain a factor 5 speed difference.
> IMHO, there is something very inefficient going on with Java. I suspect a > bad allocator and GC but this would mean costly objects in a heavily OO > language, which would surprise me.
More "Java inefficiency". Object creation is obviously something that will slow a Java (or any other VM-based OO language) application down if used excessively, but i would be surprised if that'll ever cause serious issues in properly designed applications. Also, garbage collection does introduce additional overhead and speed decrease, but that's marginal at best, and reduces a few headaches for programmers.
My point being, Java will be slower for certain applications compared to other languages, but you keep making claims based on what can best be descriped as hunches. Even if the benchmark would display the speed differences you claim (which i still cant reproduce i might add) then you're still testing a very limited collection of language functionality. Also, one could argue that even *if* Java is structurally slower than C++ the tradeof for getting an easier, more structured and in the end better development language is worth it. That, obviously, is a subjective matter and cannot be captured in benchmarks.
Remon van Vliet wrote: > "Jon Harrop" <use...@jdh30.plus.com> wrote in message > news:42b30700$0$2414$ed2619ec@ptn-nntp-reader02.plus.net... >> Note firstly that Java's inefficiency clearly has nothing to do with the >> stack as it is 5x slower than other heap-based methods and secondly that > it >> isn't easy to tell when stack allocation will be faster (e.g. tail >> recursive map is only faster on long lists). > I'm still waiting on you pointing out what exactly is so inefficient about > Java and it's JVM implementations.
I don't know what is so inefficient about Java, I just know that it is inefficient because all of the other languages that I've tried are many times faster than Java on this test.
> I agree that stack vs. heap will not explain a factor 5 speed difference.
Yes.
>> IMHO, there is something very inefficient going on with Java. I suspect a >> bad allocator and GC but this would mean costly objects in a heavily OO >> language, which would surprise me.
> More "Java inefficiency".
That is the topic of this thread. :-)
> Object creation is obviously something that will > slow a Java (or any other VM-based OO language) application down if used > excessively,
I don't believe that this is true. For example, if I were to use OCaml's objects to implement 3D vectors I don't think it would be much slower, just unnecessarily verbose.
> but i would be surprised if that'll ever cause serious issues > in properly designed applications.
The ray tracer is clearly an application. Are you saying that it isn't properly designed? If so, how?
> Also, garbage collection does introduce > additional overhead and speed decrease, but that's marginal at best, and > reduces a few headaches for programmers.
Sure, SML and OCaml are GC and the C++ uses destructors to achieve the same effect (no explicit deallocation).
> My point being, Java will be slower for certain applications compared to > other languages, but you keep making claims based on what can best be > descriped as hunches.
Yes. Here is what I know:
1. On 32-bit Athlon t-bird, SML is 5x faster than Java, OCaml is 3.7x faster than Java, C++ is 3.2x faster than Java.
2. On 64-bit Athlon64, C++ is 2.5x faster than Java, SML is 2x faster than Java, OCaml is 1.85x faster than Java.
> Even if the benchmark would display the speed > differences you claim (which i still cant reproduce i might add)
Perhaps Java runs well on Intel and very poorly on AMD. Has anyone else found evidence of this?
> then > you're still testing a very limited collection of language functionality.
This ray tracer uses data structures (3D vectors, trees and lists), variant types/inheritance, both floating point and integer arithmetic, both imperative looping and functional recursion. So I'd say that, for such a small benchmark, it is actually testing quite a lot.
> Also, one could argue that even *if* Java is structurally slower than C++ > the tradeof for getting an easier, more structured and in the end better > development language is worth it. That, obviously, is a subjective matter > and cannot be captured in benchmarks.
I have two points here:
1. Although not ideal, LOC goes some way to capturing the expressiveness of the languages. Java is not only by far the slowest language on this test but also the most verbose (least expressive). In contrast, OCaml requires half as much code and runs twice as fast as Java.
2. Although C++ lacks some of the features of Java (e.g. GC), SML and OCaml are both much safer, more expressive, higher-level languages than Java. So the argument that Java's performance is excusable because it has GC is not valid.
I just read up on Ocaml and i found out the entire discussion comparing it to Java is manky. Apparently your natively compiling your benchmark instead of running the bytecode version. This makes comparing it to Java unfair at best. One of Java's main features is the fact that it is portable due to the bytecode runtime compiliation and execution. This enables mana of Java'sstrong features. I'd be interested in the benchmark results when running the bytecode version of your tracer, a much fairer comparison i would say.
Also, on an unrelated note, i'm finding the OCaml language itself a small dissaster but that's most likely related to being used to different languages. I see the reasoning behind these kind of languages (in the scope of it's scientific background it's okay) but i wouldnt call this a viable alternative for general day-to-day projects.
Owen Jacobson wrote: > On Tue, 21 Jun 2005 20:52:54 +0100, Jon Harrop wrote: >> 1. On 32-bit Athlon t-bird, SML is 5x faster than Java, OCaml is 3.7x >> faster than Java, C++ is 3.2x faster than Java.
> Please be careful what you assert. I'm in no way disputing your > observations, but for correctness you might say that your SML > benchmark program runs five times faster than your Java benchmark program, > not that SML is five times faster than Java.
Yes, absolutely, this is all only in the context of this ray tracer.
On Tue, 21 Jun 2005 20:52:54 +0100, Jon Harrop wrote: > Here is what I know:
> 1. On 32-bit Athlon t-bird, SML is 5x faster than Java, OCaml is 3.7x > faster than Java, C++ is 3.2x faster than Java.
Please be careful what you assert. I'm in no way disputing your observations, but for correctness you might say that your SML benchmark program runs five times faster than your Java benchmark program, not that SML is five times faster than Java.
> Remon van Vliet wrote: > > "Jon Harrop" <use...@jdh30.plus.com> wrote in message > > news:42b30700$0$2414$ed2619ec@ptn-nntp-reader02.plus.net... > >> Note firstly that Java's inefficiency clearly has nothing to do with the > >> stack as it is 5x slower than other heap-based methods and secondly that > > it > >> isn't easy to tell when stack allocation will be faster (e.g. tail > >> recursive map is only faster on long lists). > > I'm still waiting on you pointing out what exactly is so inefficient about > > Java and it's JVM implementations.
> I don't know what is so inefficient about Java, I just know that it is > inefficient because all of the other languages that I've tried are many > times faster than Java on this test.
Well, if this is the case, could you please post a page where you have the benchmarks downloadable for the mentioned languages, if anything i'm quite interested in observing the differences and maybe finding out why the differences are so excessive. Like i mentioned before i ported a raytracer to Java once and the spead decrease was in the single digits percents, not a factor 5..
> > I agree that stack vs. heap will not explain a factor 5 speed difference.
> Yes.
> >> IMHO, there is something very inefficient going on with Java. I suspect a > >> bad allocator and GC but this would mean costly objects in a heavily OO > >> language, which would surprise me.
> > More "Java inefficiency".
> That is the topic of this thread. :-)
True, but at the risk of repeating myself, just claiming it's inefficient is a bit easy. I just dont get how on earth you can get such huge performance differences. It's simply so far from my practical experience that i do not understand how you can get those results. Do note that i'm only familiar with C <-> Java conversions.
> > Object creation is obviously something that will > > slow a Java (or any other VM-based OO language) application down if used > > excessively,
> I don't believe that this is true. For example, if I were to use OCaml's > objects to implement 3D vectors I don't think it would be much slower, just > unnecessarily verbose.
Hm, test this, it's entirely possible OCaml's object managment is faster than Java's, but you should see a significant decrease in performance.
> > but i would be surprised if that'll ever cause serious issues > > in properly designed applications.
> The ray tracer is clearly an application. Are you saying that it isn't > properly designed? If so, how?
If you argue that object creation slows the Java version down by a factor 5 than designing/implementing it in such a way that object creation is extensive is not a good design no? If you reply with that it shouldnt matter because a proper OOP design should be executed efficiently in an OO language than i can only agree. But as mentioned before i have trouble believing Java's object instantiating is so much slower than other VM languages. Although i'll be the first to admit i can easily be proved wrong with a simple object creation benchmark, or even a 3D vector math benchmark.
> > Also, garbage collection does introduce > > additional overhead and speed decrease, but that's marginal at best, and > > reduces a few headaches for programmers.
> Sure, SML and OCaml are GC and the C++ uses destructors to achieve the same > effect (no explicit deallocation).
Like i said, my knowledge of the other languages is limited, if you say similar things can be done i'll take your word for it. It's the magic of them doing the same thing 5 times as fast that i find hard to believe. If they offer the same benefits that Java offers at 5 times the speed people should seriously consider moving to these alternatives ;)
> > My point being, Java will be slower for certain applications compared to > > other languages, but you keep making claims based on what can best be > > descriped as hunches.
> Yes. Here is what I know:
> 1. On 32-bit Athlon t-bird, SML is 5x faster than Java, OCaml is 3.7x faster > than Java, C++ is 3.2x faster than Java.
That's for your benchmark though. I know it's factually untrue that C++ is more than 3 times faster than Java per definition.
> 2. On 64-bit Athlon64, C++ is 2.5x faster than Java, SML is 2x faster than > Java, OCaml is 1.85x faster than Java.
> > Even if the benchmark would display the speed > > differences you claim (which i still cant reproduce i might add)
> Perhaps Java runs well on Intel and very poorly on AMD. Has anyone else > found evidence of this?
Cant say, something is up with your Java VM and/or config though. My -server VM runs all math/vector/object intensive programs at least 30-50% faster and you hardly see any difference.
> > then > > you're still testing a very limited collection of language functionality.
> This ray tracer uses data structures (3D vectors, trees and lists), variant > types/inheritance, both floating point and integer arithmetic, both > imperative looping and functional recursion. So I'd say that, for such a > small benchmark, it is actually testing quite a lot.
You use the Java Collection Framework for inner workings of raytracers you might have found your performance issue of you use the wrong/synchronized collections. But i trust you didnt. You're still testing very limited functionality in the stress part of your benchmark though.
> > Also, one could argue that even *if* Java is structurally slower than C++ > > the tradeof for getting an easier, more structured and in the end better > > development language is worth it. That, obviously, is a subjective matter > > and cannot be captured in benchmarks.
> I have two points here:
> 1. Although not ideal, LOC goes some way to capturing the expressiveness of > the languages. Java is not only by far the slowest language on this test > but also the most verbose (least expressive). In contrast, OCaml requires > half as much code and runs twice as fast as Java.
This i can only agree with, OCaml is apparently quite a bit more code efficient than Java.
> 2. Although C++ lacks some of the features of Java (e.g. GC), SML and OCaml > are both much safer, more expressive, higher-level languages than Java. So > the argument that Java's performance is excusable because it has GC is not > valid.
Safer?
Anyway, like i suggested, how about you make your benchmark programs public and we can run them on our systems for more benchmark test results. Apart from us disagreeing on some points it's quite helpful to actually test these things properly. I'm quite interested in comparing VM languages' performance in terms of object/instance managment, garbage collection (or related features), vector math, integer math, collections etc...what do you think? Let me know if i can help in any way with making this happen. Perhaps we can define a benchmark that tests language features that often cause performance issues in cpu-intensive applications.
Remon van Vliet wrote: > "Jon Harrop" <use...@jdh30.plus.com> wrote in message > news:42b9ba77$0$41917$ed2619ec@ptn-nntp-reader03.plus.net... >> Yes, Java lacks a decent native code compiler. > It's more that Java isnt all that suitable for one.
Note that gcj is a Java native code compiler. Its performance is aweful, much worse than Sun's JIT.
> Also, Java is based on > a few underlying principles, one of which is portability.
Sure, and that can be a big plus. It just isn't relevant for me and, therefore, to this thread.
> And like i said, > there are a few obvious language features that make native compiling an > issue. Tried the OCaml bytecode interpreter?
Someone seems to have taken the OCaml bytecode results off the shootout, but they were over an order of magnitude slower. However, this is still irrelevant because I wouldn't use OCaml byte code for this. Indeed, I only use OCaml's bytecode for fast compilations.
>> Can you give any specific reasons for thinking this? > Most application development nowadays revolves around web-based > applications or applications heavy on database support, and user > interaction. I have yet to find any of these as an inherent part of the > language, as opposed to Java (in order; J2EE, JDBC, Swing), i did find > some 3rd party libraries for some of this.
Ok, that makes sense and I can well believe that Java is ideal for this.
For me, I'm interested in applications which make use of complicated data structures and algorithms and where brevity and expressiveness is important. Speed is much less important but I'm still interested to see big performance differences (like 5x). I had expected all modern languages to be within a factor of 2 of each other but that clearly isn't always the case.
Remon van Vliet wrote: > "Jon Harrop" <use...@jdh30.plus.com> wrote in message > news:42b87060$0$2398$ed2619ec@ptn-nntp-reader02.plus.net... > I just read up on Ocaml and i found out the entire discussion comparing it > to Java is manky. Apparently your natively compiling your benchmark > instead of running the bytecode version. This makes comparing it to Java > unfair at best. One of Java's main features is the fact that it is > portable due to the bytecode runtime compiliation and execution. This > enables mana of Java'sstrong features. I'd be interested in the benchmark > results when running the bytecode version of your tracer, a much fairer > comparison i would say.
Yes, Java lacks a decent native code compiler.
> Also, on an unrelated note, i'm finding the OCaml language itself a small > dissaster but that's most likely related to being used to different > languages. I see the reasoning behind these kind of languages (in the > scope of it's scientific background it's okay) but i wouldnt call this a > viable alternative for general day-to-day projects.
Can you give any specific reasons for thinking this?
> Remon van Vliet wrote: > > "Jon Harrop" <use...@jdh30.plus.com> wrote in message > > news:42b87060$0$2398$ed2619ec@ptn-nntp-reader02.plus.net... > > I just read up on Ocaml and i found out the entire discussion comparing it > > to Java is manky. Apparently your natively compiling your benchmark > > instead of running the bytecode version. This makes comparing it to Java > > unfair at best. One of Java's main features is the fact that it is > > portable due to the bytecode runtime compiliation and execution. This > > enables mana of Java'sstrong features. I'd be interested in the benchmark > > results when running the bytecode version of your tracer, a much fairer > > comparison i would say.
> Yes, Java lacks a decent native code compiler.
It's more that Java isnt all that suitable for one. Also, Java is based on a few underlying principles, one of which is portability. And like i said, there are a few obvious language features that make native compiling an issue. Tried the OCaml bytecode interpreter?
> > Also, on an unrelated note, i'm finding the OCaml language itself a small > > dissaster but that's most likely related to being used to different > > languages. I see the reasoning behind these kind of languages (in the > > scope of it's scientific background it's okay) but i wouldnt call this a > > viable alternative for general day-to-day projects.
> Can you give any specific reasons for thinking this?
Most application development nowadays revolves around web-based applications or applications heavy on database support, and user interaction. I have yet to find any of these as an inherent part of the language, as opposed to Java (in order; J2EE, JDBC, Swing), i did find some 3rd party libraries for some of this.
["Remon van Vliet" <re...@exmachina.nl>] | | Most application development nowadays revolves around web-based | applications or applications heavy on database support, and user | interaction.
it is tempting to assume that what you see every day is what everyone else is seeing every day.
[Jon Harrop <use...@jdh30.plus.com>] | | For me, I'm interested in applications which make use of complicated | data structures and algorithms and where brevity and expressiveness | is important.
could you give some examples of complicated data structures that you find hard to implement in Java? (you did graphics, right? a topic I unfortunately know very little about)
the brevity and expressiveness in Java, as far as application development is concerned in general, is that Java has so much in its standard library that most of the time I do not have to waste time designing and implementing rather mundane things.
even more advanced things are starting to crop up, like the java.util.concurrency things, which I find very useful in my work since they provide good implementations, but more importantly, good APIs, which I can build my applications upon. things I'd have to hand-craft each time, or make some (sometimes exclusive) decision about what implementation to use in C or C++ are just *there* in Java -- and the quality is rather good. so it doesn't matter if defining a class involves a bit of typing for me -- I still save a lot of work by having appropriate abstractions around to build on.
also, I find Java's lack of syntactical and paradigmatic diversity to be a big advantage. it helps write more homogenous code, more disciplined code. look at C++ and Perl for instance. there is a *lot* of code out there where you really have to stop and wonder exactly what the code is doing and then try to go from there and reason yourself back to the intention.
> Remon van Vliet wrote: > > "Jon Harrop" <use...@jdh30.plus.com> wrote in message > > news:42b9ba77$0$41917$ed2619ec@ptn-nntp-reader03.plus.net... > >> Yes, Java lacks a decent native code compiler. > > It's more that Java isnt all that suitable for one.
> Note that gcj is a Java native code compiler. Its performance is aweful, > much worse than Sun's JIT.
Hence me saying it isnt all that suitable for one, some features are hard or near impossible to compile to a native executable.
> > Also, Java is based on > > a few underlying principles, one of which is portability.
> Sure, and that can be a big plus. It just isn't relevant for me and, > therefore, to this thread.
Fair enough
> > And like i said, > > there are a few obvious language features that make native compiling an > > issue. Tried the OCaml bytecode interpreter?
> Someone seems to have taken the OCaml bytecode results off the shootout, but > they were over an order of magnitude slower. However, this is still > irrelevant because I wouldn't use OCaml byte code for this. Indeed, I only > use OCaml's bytecode for fast compilations.
Agreed, which doesnt change the fact that it's a crooked comparison. By their very nature JVM based execution will be slower than native compiled code. The fact that Java JIT VM's get so close to native program performance is quite impressive, which was my point from the start.
> >> Can you give any specific reasons for thinking this? > > Most application development nowadays revolves around web-based > > applications or applications heavy on database support, and user > > interaction. I have yet to find any of these as an inherent part of the > > language, as opposed to Java (in order; J2EE, JDBC, Swing), i did find > > some 3rd party libraries for some of this.
> Ok, that makes sense and I can well believe that Java is ideal for this.
> For me, I'm interested in applications which make use of complicated data > structures and algorithms and where brevity and expressiveness is > important. Speed is much less important but I'm still interested to see big > performance differences (like 5x). I had expected all modern languages to > be within a factor of 2 of each other but that clearly isn't always the > case.
Java is suitable for this, although i'll be the first to agree to OCaml seems to be a more natural language for these things. I fail to see how that's relevant for a speed comparison thread still though.
> I think Java is just the wrong tool for this job.
I'll try making a version in Java that stays within 50-90% of your OCaml version (i.e. within your point of staying within a factor 2). Can you mail me the OCaml executable?
> > Yes, Java lacks a decent native code compiler.
> Which of the existing ones (GCJ, TowerJ, possibly others) have you tried?
On this i sorta have to agree with Jon though, i tried most i could find, performance is similar or worse than the server VM in all instances i tried them. I must point out that this was over half a year ago though.
> ["Remon van Vliet" <re...@exmachina.nl>] > | > | Most application development nowadays revolves around web-based > | applications or applications heavy on database support, and user > | interaction.
> it is tempting to assume that what you see every day is what everyone > else is seeing every day.
> -Bjørn
Look it up, i'm a game programmer, i have little to do with either ;) But your point is fair, although it is an established fact that more web apps are made than raytracers (or even any other kind of graphical app)...i wouldnt be surprised if the ratio is like 100:1 actually.
Remon van Vliet wrote: > Look it up, i'm a game programmer, i have little to do with either ;) But > your point is fair, although it is an established fact that more web apps > are made than raytracers (or even any other kind of graphical app)...i > wouldnt be surprised if the ratio is like 100:1 actually.
Speaking as someone who has never managed to get another person's Java web app to work but who has played a lot of games, I'm not sure that's true. :-)
Remon van Vliet wrote: > "Jon Harrop" <use...@jdh30.plus.com> wrote in message > news:42b9c57a$0$41917$ed2619ec@ptn-nntp-reader03.plus.net... >> Someone seems to have taken the OCaml bytecode results off the shootout, > but >> they were over an order of magnitude slower. However, this is still >> irrelevant because I wouldn't use OCaml byte code for this. Indeed, I >> only use OCaml's bytecode for fast compilations. > Agreed, which doesnt change the fact that it's a crooked comparison.
Well, no. If you are trying to compare languages which must be executed via a bytecode then yes, this benchmark isn't doing that. But the fact that Java compiles to bytecode and then to native code is irrelevant for me (and therefore, for my benchmark) save for the fact that it might be the cause of Java's slow run-time performance.
> By > their very nature JVM based execution will be slower than native compiled > code. The fact that Java JIT VM's get so close to native program > performance is quite impressive, which was my point from the start.
Yes, it is impressive. Unfortunately it is also useless for me. But it is still impressive.
There is actually a JIT for OCaml bytecode, maybe I should try the ray tracer with that...
>> For me, I'm interested in applications which make use of complicated data >> structures and algorithms and where brevity and expressiveness is >> important. Speed is much less important but I'm still interested to see > big >> performance differences (like 5x). I had expected all modern languages to >> be within a factor of 2 of each other but that clearly isn't always the >> case. > Java is suitable for this, although i'll be the first to agree to OCaml > seems to be a more natural language for these things. I fail to see how > that's relevant for a speed comparison thread still though.
I wrote my ray tracer to compare implementations as well as speed. This thread was about the Java implementation's poor performance but brevity is still important to me.
>> I think Java is just the wrong tool for this job. > I'll try making a version in Java that stays within 50-90% of your OCaml > version (i.e. within your point of staying within a factor 2). Can you > mail me the OCaml executable?
Bjorn Borud wrote: > could you give some examples of complicated data structures that you > find hard to implement in Java? (you did graphics, right? a topic I > unfortunately know very little about)
Yes, I used to do scientific computing but my work is now more on graphics.
Here is one of the examples from my book on OCaml:
which computes the "n"th nearest neighbour of the "i" vertex in an infinitely tiled graph. The code of the OCaml code is:
let rec nth = function 0 -> singleton | 1 -> fun (i, io) -> let nn = bonds.(i - 1) in if io = zero then nn else let aux (j, jo) s = add (j, add_i io jo) s in fold aux nn empty | n -> fun ((i, io) as iio) -> let pprev = nth (n-2) iio and prev = nth (n-1) iio in let aux j t = union (nth 1 j) t in let t = fold aux prev empty in diff (diff t prev) pprev
In mathematics, you would write set union when describing the algorithm. Note that in OCaml you write "union". In C++ (and Java AFAIK) the built-in union functions are so much slower than OCaml's that you have to roll your own by carefully reusing old sets and mutating the ones that you don't need.
> the brevity and expressiveness in Java, as far as application > development is concerned in general, is that Java has so much in its > standard library that most of the time I do not have to waste time > designing and implementing rather mundane things.
OCaml has lots of useful things in its standard library but, IMHO, the language features are much more important. This is discussed in the context of the ray tracer (vs C++, but Java is almost identical) on this page:
In particular, look at the use of a variant type and pattern matching in the OCaml compared to an inheritance hierarchy and member functions in the C++/Java.
> even more advanced things are starting to crop up, like the > java.util.concurrency things, which I find very useful in my work > since they provide good implementations, but more importantly, good > APIs, which I can build my applications upon. things I'd have to > hand-craft each time, or make some (sometimes exclusive) decision > about what implementation to use in C or C++ are just *there* in Java > -- and the quality is rather good. so it doesn't matter if defining a > class involves a bit of typing for me -- I still save a lot of work by > having appropriate abstractions around to build on.
Yes. The fact that OCaml functions are inferred to be polymorphic whenever possible is one such abstraction. The ability to use higher-order functions is another. Both are vastly more useful than objects (but OCaml has these too!).
For example, to accumulate a value of any type over a list in OCaml you write something like:
List.fold_left f accu l
For example, to sum a list of integers you fold the integer add function "+" over the list, starting with the integer zero:
# let sum l = List.fold_left ( + ) 0 l;; val sum : int list -> int = <fun>
> also, I find Java's lack of syntactical and paradigmatic diversity to > be a big advantage. it helps write more homogenous code, more > disciplined code. look at C++ and Perl for instance. there is a > *lot* of code out there where you really have to stop and wonder > exactly what the code is doing and then try to go from there and > reason yourself back to the intention.
> Remon van Vliet wrote: > > Look it up, i'm a game programmer, i have little to do with either ;) But > > your point is fair, although it is an established fact that more web apps > > are made than raytracers (or even any other kind of graphical app)...i > > wouldnt be surprised if the ratio is like 100:1 actually.
> Speaking as someone who has never managed to get another person's Java web > app to work but who has played a lot of games, I'm not sure that's > true. :-)
Well i did say more are being made, not used :-) (i.e. more people are involved in web development compared to game development, and i doubt the 1:100 ratio is very unrealistic, but it is little more than a hunch). Getting a web app to work is a whole different matter altogether, and i'm embarrassed to admit the succesful first attempts i had with getting existing ones to work can be counted on one hand probably. That and i have a moderate dislike for webapps to begin with. Gimme games, raytracers, scientific apps and the like any day. Unfortunately getting a job in one of the above isnt all that easy, so i should be happy i actually found one.
|
