-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/8/10 17:35 , Josh Berry wrote: > It seems that the thing that is "off" in all of this discussion is > that we are trying to determine which is more complex between the > languages, when what we really care about are the programs written > in those languages. > > To that end, I really just want to simply point to something like > scalatest or squeryl to get an idea of the simplicity of some of > the client code that can be written against Scala. > > Take your example, though, "5 + 2." This works for simple > numbers, but what about the fun of matrix math? Or complex numbers > math? Both of which would undoubtedly look nicer --- one might say > simpler --- using the familiar symbols for addition, but this can > not be done in Java. Now, I would agree that this is a complexity > of the language, but it is a simplification in the program. I've been fooled by this idea fifteen years ago with C++ and I dramatically changed my mind :-) At the time I was expanding my knowledge of C++ by writing my first public app (not open source at the time) that was a flight simulator for MS-DOS (it was called FGFLY (*)). Of course there was a relatively simple physics engine inside (but it was by far much more sophisticated than most of the stuff available at the time) and of course there was vector / matrix maths inside. Also, I didn't use any library, so even 3D rendering was done by me. I thought that being able to write stuff such as f = m * a or x = [M] * y was great, and pushed the use of templates and operator overloading to a big extent. In the end, it turned out to be a nightmare. Sometimes I completely lost control of implicit conversions, thus generating unoptimized code; when I tried to compile the thing under two compilers (I started with Borland C++, then moved to Watcom C++ for MSDOS - it supported 32bits and included a memory extended that allowed to bypass the infamous 640MB limit, and eventually started to port it under Linux with the GNU compiler) I ran in a number of gray areas in the C++ specifications, so one compiler usualy got it right and the other got it wrong. At the end, I gave up.
Of course, it's perhaps an implementation problem rather than a specification problem, and maybe today they can get it right in Scala (and maybe bytecode even improves the quality of the final native code). But we're always in the same side: operator overloading is powerful, but complex. It's a way to shoot into your feet. (*) There are no more traces of FGFLY in Internet (you might find some screenshots having fgfly in the name, but they're likely to be FlightGear). Unfortunately I've lost the sources of it (that's when I learned how to to backups :-) but I think an executable is still downloadable from there: http://www.nic.funet.fi/pub/msdos/games/demos/fgfly01c.zip. I don't think it runs on any modern computer, since it depended heavily on VESA extensions for the graphics and needed a SoundBlaster for the sound. - -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." java.net/blog/fabriziogiudici - www.tidalwave.it/people [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxftfwACgkQeDweFqgUGxcWjwCeIn0HM7AuFulYDb399rVWOQTJ 6lcAn12KnNf8vbC7EaH+xDcxV3M6gC8x =2WBs -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
