Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 Why Java sucks
Index -> Java
Goto page Previous  1, 2, 3, ... 14, 15, 16  Next
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message
rizzix




PostPosted: Sun Oct 09, 2005 1:00 pm   Post subject: (No subject)

actually the jvm is ingeniously designed.. it can actually support all sorts of various syntax(es) very efficiently.. that is many different kinds of langauges can be implemented to run under the jvm.

SUN's jvm is fast. it's close to C in performance and at rare times it can even beat C. there really shouldn't be any complaints about the jvm though.. cuz the all the jvm is required to do is parse bytecode.. how it does it is up to the implementor.

as for operator overloading. Oh hell No. that's soo anti-java. Twisted Evil
Sponsor
Sponsor
Sponsor
sponsor
wtd




PostPosted: Sun Oct 09, 2005 1:06 pm   Post subject: (No subject)

rizzix wrote:
as for operator overloading. Oh hell No. that's soo anti-java.


It's just syntax sugar that makes code easier to work with.

Yes, it can be abused, but "with great power comes great responsibility". I think I'd rather have the power and take my chances on the responsibility. Smile
wtd




PostPosted: Sun Oct 09, 2005 1:11 pm   Post subject: (No subject)

As for supporting multiple languages...

The only problem with that idea is that you have to support only a restricted subset of what different languages are capable of. If you support "exotic" features, you may have one language create code that another cannot understand.

But the whole reason many programming languages exist is that there's more than one way to get things done, and some programming languages offer features that make some/all tasks easier.

If you require adherence to one set of capabilities, you invariably bias the community towards a single implementation of those features.

I worry about this a bit with Parrot, but am reassured since the languages targetting it are generally speaking all very high-level and support a wide range of capabilities.
rizzix




PostPosted: Sun Oct 09, 2005 1:14 pm   Post subject: (No subject)

ehm... what i meant is that the JVM can support a large variety of languages (and quite efficiently).. just cuz of the way it's designed (to parse bytecode).. it's quite remarkable.
rizzix




PostPosted: Sun Oct 09, 2005 1:20 pm   Post subject: (No subject)

wtd wrote:
Yes, it can be abused, but "with great power comes great responsibility". I think I'd rather have the power and take my chances on the responsibility. Smile
I beleive it's best not to bloat the language.. keep it simple.. and coding will be done efficiently.
wtd




PostPosted: Sun Oct 09, 2005 7:33 pm   Post subject: (No subject)

rizzix wrote:
ehm... what i meant is that the JVM can support a large variety of languages (and quite efficiently).. just cuz of the way it's designed (to parse bytecode).. it's quite remarkable.


Well, the JVM is essentially just a CPU in software. That compilers can be written which turn other programming languages into JVM bytecodes is no more surprising than that one can create native executables for physical CPUs in a number of widely differing programming languages.

The difficulty is interoperability.

If I write a program in Ruby that defines a module, and a series of classes, and mixs that module in, yes, I can compile that to the JVM and have it run and give me the result I expected.

But, can I use that code in Java code? How does the concept of mix-ins map to the Java programming language which has no such concept? Smile
rizzix




PostPosted: Sun Oct 09, 2005 7:59 pm   Post subject: (No subject)

simple... turn those mix-ins into objects.. of a class called let say "Mixin".. now whether u use it or not in java is not important.. but it's now usable in both languages.. Ruby would just have a special syntax-sugar to it.
wtd




PostPosted: Sun Oct 09, 2005 8:11 pm   Post subject: (No subject)

There would be no meaningful way to implement mixins as objects. Mix-ins add another is-a relationship to the object model.

code:
$ irb
irb(main):001:0> class Foo
irb(main):002:1>    def each
irb(main):003:2>       yield 42
irb(main):004:2>       yield 65
irb(main):005:2>    end
irb(main):006:1> end
=> nil
irb(main):007:0> class Foo
irb(main):008:1>    include Enumerable
irb(main):009:1> end
=> Foo
irb(main):010:0> Foo.new.is_a? Enumerable
=> true
irb(main):011:0> Foo.new.sort.reverse
=> [65, 42]


I demonstrate in Ruby just because Ruby happens to make mix-ins absurdly easy.

If you can't support them in Java, then there's no reason for anyone targetting the JVM to use them in their Ruby code. At that point you've lost one of Ruby's most important features, and one of the more convincing arguments for not just using Java.

In the end, I can't help but think that such limitations will make Java remain the dominant language on the JVM, and close most minds to alternative languages. Which is a shame, since being open-minded is the only way to make progress.
Sponsor
Sponsor
Sponsor
sponsor
wtd




PostPosted: Mon Oct 10, 2005 12:13 pm   Post subject: (No subject)

I suppose uou could model an entire Ruby environment as an object, but that doesn't make two languages equal peers.
rizzix




PostPosted: Mon Oct 10, 2005 4:22 pm   Post subject: (No subject)

what are you talking about? AspectJ does it (but in a more typesafe manner).. why can't it be done otherwise.. geez.
wtd




PostPosted: Mon Oct 10, 2005 6:43 pm   Post subject: (No subject)

rizzix wrote:
what are you talking about? AspectJ does it (but in a more typesafe manner).. why can't it be done otherwise.. geez.


AspectJ adds an additional "is-a" relationship to the object model?

I didn't see that in my research.
rizzix




PostPosted: Mon Oct 10, 2005 6:50 pm   Post subject: (No subject)

yes through interfaces Wink
wtd




PostPosted: Mon Oct 10, 2005 7:15 pm   Post subject: (No subject)

I'm quite aware of interfaces. But interfaces and mix-ins, while similar to some extent, are ultimately very different.

An interface abstracts all implementation details away, expecting the implementing class to write it all.

A mix-in, on the other hand can be used when one realizes the difference in implementation lies at a higher level. Thus a set of methods can be identically written, and depend only on the difference in implementation of a single or a few method(s). You get the implementation of all of the methods, so that

Something like the way an abstract class works in Java, but with the ability to use one or more as a base.
rizzix




PostPosted: Mon Oct 10, 2005 7:25 pm   Post subject: (No subject)

yes.. but what i'm saying is you implement the interface.. and inject the code through aspectJ.. anyways.. but the point of the converstion is that mix-ins is very much possible in java.. and it will be compatible with the Java language.. so long as the mechanism involved in implementing the mix-in ensures that it implements the respective interface(s). thus defining the respective Type (and ensuring it's compatible with the Java lang)
wtd




PostPosted: Mon Oct 10, 2005 7:28 pm   Post subject: (No subject)

Care to demonstrate an example of this?

I would find it genuinely interesting.
Display posts from previous:   
   Index -> Java
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 2 of 16  [ 228 Posts ]
Goto page Previous  1, 2, 3, ... 14, 15, 16  Next
Jump to:   


Style:  
Search: