Thread: What's up with Java programmers, anyway?

  1. #31
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Code:
    	Type
    		ref = data, // OK
    		copy = new Type( data ); // Error
    The only way that this can "work" is if you specify the supertype in the declaration!
    Pardon me for butting in but maybe that's not so bad. I'm not very clear on new and how it is different in Java, or "supertype" and if that means what it should in OOP jargon, but it seems like this error is only an error because you're doing too much on one line.

    And we all know that's cute in C++ too. Your argument doesn't wash with me.

    Of course, it's another thing that's great for obfuscation, but that shouldn't be how we make our preferences.
    Last edited by whiteflags; 05-18-2009 at 02:18 PM.

  2. #32
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    >> Pardon me for butting in but maybe that's not so bad. I'm not very clear on new and how it is different in Java, or "supertype" and if that means what it should in OOP jargon, but it seems like this error is only an error because you're doing too much on one line.

    Java doesn't have "stack-based" objects (except for ints, floats, etc). All variables are references, and as such you have to call 'new' to allocate an object. So the code I posted is actually equivalant to this in C++:

    Code:
    Type
    	copy = data;
    The meaning of "super-type" is the same as in C++. A base class. But my point was, to actually be able to invoke functions (including constructors) or access variables from the object, you would have to change the declaration to something like:

    Code:
    public static < Type extends Bar > void foo( Type data )
    {
    	Type
    		ref = data, // OK
    		copy = new Type( data );  // OK
    	ref.bar( ); // OK
    	ref.baz = 1024; // OK
    }
    ...where Bar is an actual type having, at the minimum, this interface:

    Code:
    public class Bar
    {
    	Bar( Bar rhs );
    	void bar( );
    	int
    		baz;
    }
    In other words, using generics in this case would really buy you nothing, as it is the exact same thing as:

    Code:
    public static void foo( Bar data )
    {
    	Bar
    		ref = data,
    		copy = new Bar( data );
    	ref.bar( );
    	ref.baz = 1024;
    }
    [edit]
    There is *one* thing it does buy you in this case, and that is to call the constructor of the derived type. But besides that, nothing.
    [/edit]
    Last edited by Sebastiani; 05-18-2009 at 02:43 PM. Reason: clarification
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  3. #33
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Well I can see why that would be annoying now. It would be easier if you could specify the extension earlier in the code, instead of member by member like that. Thanks.

  4. #34
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Sebastiani View Post
    The only way that this can "work" is if you specify the supertype in the declaration! The reason for all of this, of course, is because generics are compiled into bytecode (and reused via "type erasure"). But it still doesn't make sense. A more logical approach would be to either allow a dual facility where compile-time code could use the templates fully but run-time code could only use the more limited "type erasure" feature, or else provide full support with the aid of reflection or whatnot. Instead, the designers of the language chose a half-hearted and, frankly, dim-witted implementation. So while I agree that we probably shouldn't sit around and make fun of people (who could be just as talented as any other programmer), I reserve the right to have an "elitist" attitude with respect to the language itself.
    I've always viewed Java as a Bandaid programming language. When they want to add something new like Generics, they need to keep backwards compatibility, so they just put a bandaid on the language. Maybe it's because they're so runtime oriented instead of compile-time oriented?
    I'd like to see a whole new version of Java that has the nice rich library that Java currently has but has all the things it's missing like: unsigned types, stack based variables, destructors, the option of passing by value or reference, real templates, const, C++ type casts, operator overloading, typedef, default values for function parameters, a separation of references & pointers instead of the strange reference/pointer mutation they have now...
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  5. #35
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    >> I'd like to see a whole new version of Java that has the nice rich library that Java currently has but has all the things it's missing like: unsigned types, stack based variables, destructors, the option of passing by value or reference, real templates, const, C++ type casts, operator overloading, typedef, default values for function parameters, a separation of references & pointers instead of the strange reference/pointer mutation they have now...

    I would love to see those features as well, of course, but that would effectively mean completely overhauling the language, which will probably never happen. Besides that, there are some inherent limitations in the virtual machine itself that indicate that it may not be the "language of the future". Just as an example, the instruction set itself can never exceed 255 unique opcodes, since no bits were reserved to allow for multi-byte encoding (there are ways around this, of course, but it would be an ugly hack), and considering that there are already 200+ existing opcodes, real estate is already pretty scarce. Another problem is the fact that almost everything (relating to sizes/counts) are encoded in 16 bits or less. No function, for instance, can be larger than 65535 bytes. While that may be reasonable in *most* cases, it's nonetheless not very 'forward-thinking' (and would certainly make things such as inline functions practically impossible to implement in future versions). Other width-related limitations have even led to the introduction of things such as special 'widening' opcodes, adding yet another layer of complexity and inefficiency to the environment. And as time goes on, computers become more powerful, memory models grow, etc, these problems are just going to get worse - all of the sudden you could be faced with a development tool that just can't handle it. Which isn't to say that these problems can't be fixed, but it will definitely require some drastic changes to the specification itself.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  6. #36
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Sebastiani View Post
    I would love to see those features as well, of course, but that would effectively mean completely overhauling the language, which will probably never happen. Besides that, there are some inherent limitations in the virtual machine itself that indicate that it may not be the "language of the future". Just as an example, the instruction set itself can never exceed 255 unique opcodes, since no bits were reserved to allow for multi-byte encoding (there are ways around this, of course, but it would be an ugly hack), and considering that there are already 200+ existing opcodes, real estate is already pretty scarce. Another problem is the fact that almost everything (relating to sizes/counts) are encoded in 16 bits or less. No function, for instance, can be larger than 65535 bytes. While that may be reasonable in *most* cases, it's nonetheless not very 'forward-thinking' (and would certainly make things such as inline functions practically impossible to implement in future versions). Other width-related limitations have even led to the introduction of things such as special 'widening' opcodes, adding yet another layer of complexity and inefficiency to the environment. And as time goes on, computers become more powerful, memory models grow, etc, these problems are just going to get worse - all of the sudden you could be faced with a development tool that just can't handle it. Which isn't to say that these problems can't be fixed, but it will definitely require some drastic changes to the specification itself.
    I'm not saying they should add those features to the current Java code. I don't think Java is flexible enough to handle those kinds of changes. They need to break backward compatibility and create a whole new Java. Isn't that what happened when they moved from the original Java to Java 2?
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  7. #37
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    I'm pretty sure that Java1 is *binary* compatible with Java2, but I think I remember reading somewhere that some of the Java1 packages were deprecated (which of course would break an application just the same), but I'm 100% certain about that. I'd have to look it up.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  8. #38
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by cpjust View Post
    I'd like to see a whole new version of Java that has the nice rich library that Java currently has but has all the things it's missing like: unsigned types, stack based variables, destructors, the option of passing by value or reference, real templates, const, C++ type casts, operator overloading, typedef, default values for function parameters, a separation of references & pointers instead of the strange reference/pointer mutation they have now...
    That would just turn Java into C++ with garbage collection. What would be the point of doing this? The only real distinction between C++ and Java at that point would be the platform-independent nature of the binaries. But a platform-independent C++ is still C++, not Java. We just don't have it yet. (The garbage collection is just an add-on which could be suitably specified)

    In fact, what you're talking about seems an awful lot like "Managed C++" by Microsoft. Seriously -- go have a look and tell me it's not.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #39
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote Originally Posted by Sebastiani View Post
    The meaning of "super-type" is the same as in C++. A base class. But my point was, to actually be able to invoke functions (including constructors) or access variables from the object, you would have to change the declaration to something like:

    Code:
    public static < Type extends Bar > void foo( Type data )
    {
    	Type
    		ref = data, // OK
    		copy = new Type( data );  // OK
    	ref.bar( ); // OK
    	ref.baz = 1024; // OK
    }
    That's still invalid. You can't allocate an object of a parameter type.


    There's nothing wrong with F-bound generics. It has slightly different applications than parametric generics (as C++ has), and it fits in better with a purely object-oriented language like Java. Once you understand the principle behind Java's generics, you can also trivially see why you need a type bound in the example above.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #40
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Sebastiani View Post
    >> "Java is C++ without the guns, knives, and clubs." -- James Gosling

    Java is C++ without the guns, knives, clubs, hammers, alan wreneches, welder, or cutting torch. Java gives you one hell of a set of regular wrenches, but they only fit 1/2 inch and 9/16, and it gives you a nail gun, but it can only put nails in 1 inch plywood or 2x4's.
    Last edited by abachler; 05-19-2009 at 06:28 AM.

  11. #41
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by brewbuck View Post
    That would just turn Java into C++ with garbage collection. What would be the point of doing this? The only real distinction between C++ and Java at that point would be the platform-independent nature of the binaries. But a platform-independent C++ is still C++, not Java. We just don't have it yet. (The garbage collection is just an add-on which could be suitably specified)

    In fact, what you're talking about seems an awful lot like "Managed C++" by Microsoft. Seriously -- go have a look and tell me it's not.
    Exactly! I'd like a platform independent C++ with the huge library of Java. We could call it "C?"
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  12. #42
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    That would just turn Java into C++ with garbage collection. What would be the point of doing this? The only real distinction between C++ and Java at that point would be the platform-independent nature of the binaries. But a platform-independent C++ is still C++, not Java. We just don't have it yet. (The garbage collection is just an add-on which could be suitably specified) In fact, what you're talking about seems an awful lot like "Managed C++" by Microsoft. Seriously -- go have a look and tell me it's not.


    C++ with garbage collection, sounds like C# eh? No wait, C# is java with a new name and proprietary languge protectign it. I'm so confused, what was the need that was so great we needed a new flavor of language gain?
    Last edited by abachler; 05-19-2009 at 06:35 AM.

  13. #43
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Anyway, does this stereotype apply if you know, and use, say Java and C/C++?

    If so,

    If not,

  14. #44
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    Quote Originally Posted by Nyda View Post
    I don't know about Java, but I'd concur that PHP definitely has this effect on me. I recently went through my old backups, trying to consolidate them a bit, and glanced at a few C applications I wrote. "what the .... was I doing there" - "how did I do that"...
    Ever thought that you wrote the code poorly and now as a detached observer (having been detached over the years) you can no longer understand the rotted code?

    Happens when I look at my early college programs.

  15. #45
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by indigo0086
    Ever thought that you wrote the code poorly and now as a detached observer (having been detached over the years) you can no longer understand the rotted code?
    I think Nyda's anecdote was meant to illustrate that his/her old code, written in C, was "better" than his/her new code, written in PHP.

    EDIT:
    Ah, but you are saying that the old code is not actually better, but merely so bad to the point that Nyda was unable to understand it even after accumulating more programming experience and presumably having a refresher on C?
    Last edited by laserlight; 05-19-2009 at 11:11 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. java for c++ programmers book
    By qwertiop in forum Tech Board
    Replies: 3
    Last Post: 05-18-2007, 03:17 PM
  2. C#, Java, C++
    By incognito in forum A Brief History of Cprogramming.com
    Replies: 10
    Last Post: 10-05-2004, 02:06 PM
  3. Do programmers still like Java ?
    By dot_rain in forum Tech Board
    Replies: 3
    Last Post: 11-23-2003, 09:44 AM
  4. Calling all Java programmers...
    By face_master in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 04-14-2002, 05:43 AM
  5. Programming Puns
    By kermi3 in forum A Brief History of Cprogramming.com
    Replies: 44
    Last Post: 03-23-2002, 04:38 PM