Why does Java suck so much?

Discussion in 'Programming & Software Development' started by one4spl, Jun 13, 2008.

  1. Ravenclaw

    Ravenclaw Member

    Joined:
    Dec 6, 2004
    Messages:
    2,090
    problems with c++

    also, you need proper language support to do garbage collecting right. a conservative garbage collector is pretty weak. i don't think you can even do compaction with a conservative GC because you can't change what looks like pointers because they might not be pointers. i think if you want to use a garbage collector you are better off using a language like java/c# or a dynamic language like python/ruby.
     
    Last edited: Jun 24, 2008
  2. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    No. You don't understand. Programming is hard. Really hard. Even for Dijkstra. Once you accept that you must also accept that you are a crap programmer and you will always make mistakes.

    There are two kinds of difficulties in programming that lead to mistakes: essential difficulties and accidental difficulties. The first relates to the hardness of the problem at hand that requires automation. The latter however stems from inadequate/inappropriate tools and includes problems that exist due to manual memory management, manual bounds checking and so forth.

    Any tool that minimises the number of accidental difficulties and allows one to focus on solving the actual problem is a positive step in the right direction.
     
    Last edited: Jun 24, 2008
  3. phreeky82

    phreeky82 Member

    Joined:
    Dec 10, 2002
    Messages:
    9,696
    Location:
    Qld
    Your first point that I didn't quote is not even worth replying to.

    Secondly, you obviously don't understand and I really couldn't give a flying f*ck, but for your benefit I'll explain anyway.

    The requirement for manual memory management and bounds checking is actually USED as a BENEFIT by some people in the right circumstances. Yes, that does mean that a mistake can be a bigger mistake, but that's part of the language, and all comes back to the right tool for the right job.
     
  4. PoyZ

    PoyZ Member

    Joined:
    Jun 28, 2001
    Messages:
    300
    I disagree, this benefit you speak of is the result of a hardware constraint or a bad decision made somewhere earlier in the piece.

    Besides embedded systems I can't think of anything where this would be considered a benefit, but even C++ isn't used here. I'm sure you had more in mind? I once wrote software for Portable Data Terminals and Barcode Scanners...be interested in your thoughts.
     
    Last edited: Jun 24, 2008
  5. yihfeng

    yihfeng Member

    Joined:
    Nov 23, 2005
    Messages:
    1,400
    Location:
    Melbourne
    Why the ego phreeky? If you aren't happy replying, by all means don't! I doubt if we'll miss out on your 2 cents worth...

    A quote from my Uni lecturer some time ago with regards to malloc/free VS automatic garbage collection:

    I personally agree with him, and think that garbage collection is the way to go, besides on certain extremely low end embedded systems.

    Cheers.
     
  6. phreeky82

    phreeky82 Member

    Joined:
    Dec 10, 2002
    Messages:
    9,696
    Location:
    Qld
    No ego, just frustration I guess.

    I mean what you guys are saying is that there is no place for languages like C/C++, which just has me stumped.

    I wonder what language the virtual machines you guys use are written in (yes, I know myself).
     
  7. yihfeng

    yihfeng Member

    Joined:
    Nov 23, 2005
    Messages:
    1,400
    Location:
    Melbourne
    I guess what most people are saying is that languages such as Java/PHP etc. while not as primitive as C/C++ has its place. For most modern, complex software, it is just much faster to write things in the more modern languages.

    And guess what? C is translated into assembly, which eventually turns out as 1/0.

    It is called abstraction.
     
  8. phreeky82

    phreeky82 Member

    Joined:
    Dec 10, 2002
    Messages:
    9,696
    Location:
    Qld
    I think you'll find I never argued otherwise, and even stated that I rarely code in C/C++ anyway.
     
  9. kona_boy

    kona_boy Member

    Joined:
    Apr 21, 2004
    Messages:
    5,132
    Location:
    BC, Canada
    Just like Microsoft


    i did it for the lulz.
     
  10. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    That's sad because it was the most important thing in the whole post. To paraphrase Dijkstra (not that I expect you read either of the articles I linked to), the humble programmer is very much aware of the limited size of his cranium.

    It's never a benefit. The complexity you associate with writing low-level code that drives hardware is, as someone already pointed out, a side-effect of the hardware. There's no reason we have to use C for this job. We use it because there's no easy solution to the problem of automatic performance tuning for specific hardware.
    No-one, except masochists, willingly opt for manual memory management when it can be avoided. The problem is it can't always be.

    BTW, you should chill out. Your posts carry more weight when you don't rant like a lunatic.
     
  11. phreeky82

    phreeky82 Member

    Joined:
    Dec 10, 2002
    Messages:
    9,696
    Location:
    Qld
    I respect his opinion, but don't bow to it like he is some kind of god thank you very much.

    Exactly right? If you bother to read my posts properly, I've stated time again that C/C++ is not better than Java/.NET/whatever period. It's simply better in cases where its attributes are well suited.

    Unfortunately, reading posts properly appears to be an ever increasing rarity here. Anyway, I've had enough with this, gotta get back to doing some work! (in C# at the moment ;))
     
  12. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,058
    Location:
    Sydney
    u r a movie star programmer, xsive and say it better than I could.
     
  13. Bion1c

    Bion1c Member

    Joined:
    Jul 19, 2001
    Messages:
    1,223
    Location:
    Melbourne
    ok i'm playing buzzword bingo in this thread.. points for:

    - right tool for the right job
    - movie/rock star programmer
    - name drops of CS celebrities (e.g. Dijkstra)
    - memory management
    - garbage collection

    I think by this point it has been agreed java "doesnt suck" so is there any cohesive argument whatsoever here or are we all just trying to look smart ?
     
  14. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,058
    Location:
    Sydney
    youre new to OCAU arent you...
     
  15. Bion1c

    Bion1c Member

    Joined:
    Jul 19, 2001
    Messages:
    1,223
    Location:
    Melbourne
    yeah man i just signed up last week but i fully hax0r3d my join date
     
  16. ACodingFettish

    ACodingFettish Member

    Joined:
    Feb 7, 2004
    Messages:
    6,652
    Location:
    Brisbane
    STOP SAYING MOVIE STAR PROGRAMMER
     
  17. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,058
    Location:
    Sydney
    youre a rock star programmer.:D
     
  18. GumbyNoTalent

    GumbyNoTalent Member

    Joined:
    Jan 8, 2003
    Messages:
    9,786
    Location:
    Briz Vegas
  19. Semi-Evolved

    Semi-Evolved Member

    Joined:
    Aug 11, 2003
    Messages:
    7,089
    Location:
    Brisbane
    It looks like Phreeky's having a bit of a tantrum, so I'll reply :).

    The key problem is that there are a good deal of situations where it can't be avoided. Automatic memory is a great piece of functionality for the right situations, but it also puts a lot of constraints on what can be done in other situations.

    An obvious example is console game development, which these days is the bulk of the game industry. For one, even the latest generation of consoles still have incredibly restrictive memory architectures. Take the PS3; you've only got 224MB (256mb - 32mb for the OS) of RAM available to the core application, with a further 256MB of video Memory for graphics. Putting aside the fact that most VM runtimes provide zero ability to control the latter, the users of such applications also have very specific performance expectations that simply can't be met by most VM runtimes, due to the lack of control over memory that's inherent in a memory managed runtime. For such applications, having your gameplay occasionally stutter because the garbage collector's kicked in at an innopertune moment is unacceptable to the client base. Similarly, the small amount of memory available makes hand-tuned memory management a desirable method of development.

    The same extends to any situation where performance within hardware constraints is a key criteria. Databases are a good example of this; they form the key dependency point in most enterprise applications, and are the base structure upon which the entire enterprise application's performance is dependant. In such a situation, whilst automated memory management would be a boon to the developers, it's unrealistic to demand it given the performance expectations often put upon a database in a key corporate role. Given the requirements, it's entirely reasonable that a tradeoff of development ease be made to achieve the best possible performance. On a more local level, core operating system APIs fulfil a similar role; they're services upon which the entire system depends, and thus are also a key performance bottleneck of all applications running on that system. If a better performance result can be achieved by way of developing in C/C++ and forgoing memory management, as in the case of a database it's entirely reasonable that that tradeoff be made.

    In a similar vein to console development is embedded development. When you've got a device that has at most 128mb of RAM and a 300-400mhz CPU (such a Nokia N95 or Apple iPhone, for example), the performance tradeoff for generic memory management can look rather unattractive. Tight hardware demands tight development. That goes doubly so for the less powerful devices around, or those that have even higher performance requirements; Cameras, handheld consoles, media players, televisions. There's a lot more to software development than the software that runs on a good old fashioned PC.

    Finally, most people have so far assumed that memory management and the like is an all-or-nthing proposition, which isn't necessarily the case. Returning to the gaming example, many modern engines make use of embedded virtual machines to allow the most performance sensitive graphics, physics and environment code to be written in C/C++, whilst allowing mcuh of the game logic to run in a virtual machine environment. This is surprisingly common; at the core of the Unreal series of engines is a VM running UnrealScript, which is used for game logic. The World of Warcraft client uses the LUA embedded language for its user interface. EVE Online uses stackless Python for its core game logic on both the server and client sides. Such setups are entirely viable in many other applications.

    Anyway, don't get me wrong; I'm not saying that memory management doesn't have its place. Ultimately, I'm a Java developer by trade, and my day to day job is made a hell of a lot easier by the tools that a memory managed language provide for the sort of development that I'm doing (Enterprise business logic and web applications). That said, I'm enough of a realist to understand that what's theoretically a good idea ("memory management for all!") doesn't suit all situations. There are many tools for software development, and there exists no single development technology that is necessarily going to suit all situations, or be inherently better than some other tool in all situations.
     
  20. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,058
    Location:
    Sydney
    see the big picture. in 10 years time computers will be programming themselves. manual memory of all things will be the first to go. Programming units will be distributed over many computers worldwide. the idea of hardware resources will be irrelevant. you will describe problems in business terms and solutions will form through computer learning algorithms.
     

Share This Page

Advertisement: