Java is Slow!

  • Cro 2009-05-12 11:04
    First!

    And just to say - love the graphic!

    CAPTCHA: praesent
  • Alin 2009-05-12 11:16
    Communist Management rulez!
  • zoips 2009-05-12 11:21
    Wait, let me guess, Dick was given a raise for that, right?
  • Dick 2009-05-12 11:22
    Knock Knock

    Who's There














    Java
  • ubersoldat 2009-05-12 11:29
    Not a Java or C++ thing. TRWTF is that Dick's name is very appropriate. Anyway, a tool for each job.
  • Justice 2009-05-12 11:31
    ubersoldat:
    a tool for each job.


    Especially Dick's.
  • hikari 2009-05-12 11:32
    ubersoldat:
    Not a Java or C++ thing. TRWTF is that Dick's name is very appropriate. Anyway, a tool for each job.


    I believe the tool in this case was Dick.
  • Joshua 2009-05-12 11:34
    My experiments show that in most cases, Java is between 1x and 3x slower in CPU time, but most things simply aren't CPU bound anymore.
  • Zapp Brannigan 2009-05-12 11:37
    Ok the two guys' names are Dick and Peter? Did Rod or Mr. Johnson work there too?

    Oh yeah, Java is slow compared to C++ as long as you don't account for the development time.

    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!
  • snoofle 2009-05-12 11:45
    Zapp Brannigan:
    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!


    As a staunch Java advocate, to be fair, that just means you're a good app designer, not that Java rules.
  • Procedural 2009-05-12 11:46
    Is Alex writing or rewriting everything these days ? I really enjoyed the writing on this one. The images (loved the quip about change), the tone and rhythm, this was stellar (minor quibble: "As the years past by" -> "As the years passed by")
  • Bluesman 2009-05-12 11:52
    snoofle:
    Zapp Brannigan:
    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!


    As a staunch Java advocate, to be fair, that just means you're a good app designer, not that Java rules.


    Either that, or mom and dad are dirt poor.
  • theo geer 2009-05-12 11:57
    snoofle:
    Zapp Brannigan:
    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!


    As a staunch Java advocate, to be fair, that just means you're a good app designer, not that Java rules.


    It probably means that they don't tell him about their Excel problems because they don't want him to realize they aren't using his slick little Java app.
  • quintopia 2009-05-12 11:59
    I hope that lost contract was enough motivation for upper management to get Dick fired.
  • ThePants999 2009-05-12 12:06
    I thought everyone these days understood the "My <relative> used to <something normal>, and were always asking me for help. I <horrendous solution>, and now they never ask me for help!" ad-lib. Hint: it ISN'T meant to imply the solution was a good one...
  • xian 2009-05-12 12:07
    so the writing to text files truly is a wtf...

    choosing C++ over Java for performance reasons is a valid concern. Of course if there was no performance issue then Dick is an idiot. However it seems the dev team wasn't terribly bright either:

    "That's most likely what's slowing the whole thing down so much," the developer explained.

    your system was ground to a hault by a performance issue and you haven't even done the work to profile the app and see where the problem is? more over this system wasn't tested at expected loads?
  • Mike 2009-05-12 12:08
    TRWTF is disagreeing that Java is slow. SQL Developer, Zend Studio, and pretty much all other Java-based development tools I've used have been horridly slow in comparison to non-Java based equivalents.
  • BoomWav 2009-05-12 12:08
    I'd use C#.NET over java any day though.
  • BoomWav 2009-05-12 12:12
    In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.
  • Peter 2009-05-12 12:16
    snoofle:
    Zapp Brannigan:
    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!


    As a staunch Java advocate, to be fair, that just means you're a good app designer, not that Java rules.


    I think the point was that he wrote something that was so not what was needed that they never bothered him again. :)
  • xorsyst 2009-05-12 12:17
    BoomWav:
    In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.


    Yep - which is why I avoid java like the plague.
  • .NETguy 2009-05-12 12:20
    True, but you said "enterprise environment". Now you have to have special servers running special software for your java applications to run. This leads to more maintenance costs and epertise (that you'll have to pay for) when a problem does occur.

    The only decent "enterprise environment" I've ever seen was on TNG.
  • Fedaykin 2009-05-12 12:27
    .NETguy:
    True, but you said "enterprise environment". Now you have to have special servers running special software for your java applications to run. This leads to more maintenance costs and epertise (that you'll have to pay for) when a problem does occur.


    What "special servers" and "special software" do you think is required to run Java?

  • Anonymous Coward 2009-05-12 12:29
    TRWTF is 65 cents for a can of soda. I hate when management nickle and dimes (and two quarters) developers. Sell soda at cost, sheesh.
  • ObiWayneKenobi 2009-05-12 12:31
    Fedaykin:

    What "special servers" and "special software" do you think is required to run Java?


    The kind that highly-paid "Enterprise Java Consultants" will tell (and sell!) you is required to run Java, of course!
  • Morry 2009-05-12 12:32
    Transactions in the 100s per second?! Say it ain't so!

    /get a real system. and code it in assembler.
  • Anon 2009-05-12 12:35
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.
  • kastein 2009-05-12 12:37
    I'm generally a java disliker, but... wow. Dick needs to stop sabotaging his own company and his own company's internal software (as usual, the major source of WTF is the company's management.)

    I definitely agree about the writing BTW, this one was awesome with the only exception being the minor "past" instead of "passed" homonym swap, as noted above.
  • brillo 2009-05-12 12:37
    I agree, our company sells soda at a 2 cent loss per bottle...
  • j_random_hacker 2009-05-12 12:41
    Java slow? Nooo. That may have been true once, but everyone knows that nowadays Java code typically runs 500 times faster than assembly.

    Sometimes a method will finish running before it began!
  • javabeats 2009-05-12 12:43
    TRWTF is that Dick survived 25 years on that company.
  • d3matt 2009-05-12 12:43
    kastein:
    I definitely agree about the writing BTW, this one was awesome with the only exception being the minor "past" instead of "passed" homonym swap, as noted above.

    You mean homophone... http://en.wikipedia.org/wiki/Homonym (I used to call them homonyms as well)
  • Eric 2009-05-12 12:43
    You rewrote their Excel spreadsheet in Java? You are either a liar or a moron. Why would you rewrite ANYTHING when you can get off the shelf software to do anything you could possibly do and do it better? Grab QuickBooks if it is business based, or an old copy of Money and I guarantee you'd be better off.
  • AnonX2 2009-05-12 12:43
    > But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.

    aggreed. That is not the point of using higher level languages. In the same regard I cannot compare C code to a well written assembly program. Java(and .NET; same thing, hold your rage please) is a nice cross between an interpreted simplicity and compiled language performance IMO.
  • AnonX2 2009-05-12 12:45
    All thanks to the quantum physics included in the VM
  • xtremezone 2009-05-12 12:46
    Java does suck... The language semantics are a bitch (I wouldn't consider it quick to write, though perhaps I just have to learn "the Java way" first), the code is ugly (I wouldn't call it maintainable), and in my experience it always performs poorly (nearly every Java app I've used has been near unusable).

    I think C++ is probably still my favorite language to write, but I can understand one's need for a higher level language. C#/.NET (i.e., they were developing in Visual C++ anyway) would have been my preference, not Java. Although I doubt Mono is considered enterprise ready yet and it sounds like these projects were going to be running on UNIX platforms (a good thing).

    When I think of software to manage transportation for an entire country (even a relatively small one) I think of limited scope and high performance. So C++ sounds like a reasonable tool to use, unless they were specifically going to be building clients or something for the backend system.
  • snoofle 2009-05-12 12:46
    brillo:
    I agree, our company sells soda at a 2 cent loss per bottle...
    Quit whining you babies! Our company no longer provides coffee and charges > $street for snacks.

    I was always under the impression that a company cafeteria/snack machine was there to keep you from going out and taking longer to get back to your desk; not to make a profit.

    Edit: Quoted wrong person; meant to quote earlier message...[need to go out for coffee]
  • Jay 2009-05-12 12:47
    Dick uses C++ ?! But I can write much faster programs if I do it in machine code. Compilers are for wimps! You can do much better optimization on your programs if you write the machine code yourself than you would ever get from a compiler.

    http://www.farid-hajji.net/fun/cj-progmachine.html

    'Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.'

    Next lesson: Bypassing that sleazy keyboard stuff and modifying data directly on your hard drive by hand with a magnet.
  • Jay 2009-05-12 12:52
    [quote user="Anon]The reality is that Java remains to this day far slower than an application that gets compiled to native code.[/quote]

    The Just-in-Time compiler that came out with, what was it, Java 2.4?, really puts Java into a different league from version 1.

    Java 6 so fast that it can execute an infinite loop in 12 seconds.
  • Zapp Brannigan 2009-05-12 12:56
    Eric:
    You rewrote their Excel spreadsheet in Java? You are either a liar or a moron. Why would you rewrite ANYTHING when you can get off the shelf software to do anything you could possibly do and do it better? Grab QuickBooks if it is business based, or an old copy of Money and I guarantee you'd be better off.
    Originally, I wanted them to use Microsoft Money, but I couldn't get Microsoft to send me the source code.
  • Jay 2009-05-12 12:57
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.


    Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.

    I'm surprised that Sun hasn't made it easier to install the JVM -- at least as of when I was last working with desktop apps, maybe they've done it better by now. (These days I'm on web apps, where I don't ask the user to install anything besides a browser.) But you write your own installer for it once and re-use it for every app and it doesn't really matter.
  • Ryan Gardner 2009-05-12 12:59
    TRWTF it seems is that a lot of Dick's peers seem to be in this comment thread. Java isn't as slow as you think it is, people, and probably hasn't been for a long time.

  • Fedaykin 2009-05-12 12:59
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.


    On no... you mean I have to download the JVM to run my apps, and it's only available (and open source) on every major platform? I mean, that's just vastly more complicated than making sure you have the right libs (e.g. GTK, QT, et al.) installed to run apps in many other languages.

    The original person I was responding to was obviously a .NET dev, and for a .NET guy to complain about special software and platform requirements for Java is laughable.


    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    Who the frack suggested that? It certainly wasn't me...
  • Dennis 2009-05-12 13:00
    Procedural:
    Is Alex writing or rewriting everything these days ? I really enjoyed the writing on this one. The images (loved the quip about change), the tone and rhythm, this was stellar (minor quibble: "As the years past by" -> "As the years passed by")


    TRWTF is that many of the articles have this kind of "typo".
  • amischiefr 2009-05-12 13:03
    xtremezone:
    Java does suck... The language semantics are a bitch (I wouldn't consider it quick to write, though perhaps I just have to learn "the Java way" first), the code is ugly (I wouldn't call it maintainable), and in my experience it always performs poorly (nearly every Java app I've used has been near unusable).

    You sir win the Idiot of the Day award.

    Let's start with "The language semantics are a bitch." How so? You don't like "public int x = 1"? Is that terribly difficult for you to understand? Maybe since it doesn't have a * or an & in there you can't comprehend it. <shrug /> The semantics are some of the easiest to understand (and yes I program in ANSI C, C++, ASP .NET and VB .NET, and Java), and coincidentally they are VERY VERY similar to C#, which I believe you recommend :)

    "The code is ugly" Alright now you're just being stupid. Java code is very easily readable and is VERY straight forward. ESPECIALLY compared to C and C++. What don't you understand about:

    public int getX() {
    return x;
    }

    Are there just not enough of those * and & that you love so much in C++? if it was:

    return &x;

    Would it be that much easier to read, oh and "sexier"?

    "...in my experience it always performs poorly ... near unusable)." You need more experience. I don't have too much to say except that you are completely ignorant and need to experience more in life.

    I am not saying that Java is the best. Hell I would rather be programming in C# .NET myself. But I hate senseless Java bashers that have no idea what the fuck they are talking about.
  • snoofle 2009-05-12 13:04
    Re the Java-is-slow debate...

    I've been working with Java in huge enterprise-sized apps for about 12 years, longer for C++ and C and have a few observations with the benefit of hindsight:

    Back when disk space wasn't so plentiful, users used to complain about the size of the jvm on disk. In fact, it was similar to a C++ version of the app linked with debug info (necessary for debuggable core dump files).

    Before the JIT compilers came out, the complaints that it was too slow were in some cases valid. Ever since, for most cases (in the context of financial applications, and end-of-day crunching through MM's of records in a constrained time period), speed has not been the constraining factor (usually works out to be an IO bound DB/disk/network).

    For some things that are brute force computationally intensive (eg: risk analysis), it is not fast enough and C++ apps are usually used, but that's more the exception than the rule.

    Bad code can be written in any language.

    Good code can be written in any language.

    Efficient code can be written in any language.

    Inefficient code can be written in any language.

    Bad comments/documentation (in [language of choice] code) is universal.

    Badly written third party libraries can kill even the best of applications (TIBCO, are you listening?)

    Inept managers who think they are still capable of making sound technical decisions can undo any amount of technical competance on your part.
  • wee 2009-05-12 13:06
    TRWTF is nobody proofreads shit.
  • Fedaykin 2009-05-12 13:07
    xtremezone:
    Java does suck... The language semantics are a bitch (I wouldn't consider it quick to write, though perhaps I just have to learn "the Java way" first), the code is ugly (I wouldn't call it maintainable),


    The syntax and semantics of Java are, by design, very similar to C and C++. Any competent programmer that writes Java can pick up a C or C++ app and be able to understand it pretty easily (and visa versa).

    So please, enlighten me as to what's so radically different about Java to make it's semantics "a bitch".

  • snoofle 2009-05-12 13:08
    wee:
    TRWTF is nobody proofreads shit.

    Sorry, I gotta ask.... what braille-literate person would want that job?
  • snookerdoodle 2009-05-12 13:11
    I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.

    I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.
  • SomeCoder 2009-05-12 13:11
    BoomWav:
    In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.


    Which is why computers get faster and yet when you get a new machine, they run as slow or slower as your old machine. The new software eats up all of the new hardware's capability.

    While I would agree that you have to consider development time vs performance, I see developers these days choosing development time far too often when performance is still needed. Saying that "Well the user has a gig of RAM/Fast CPU/quick hard drive/etc. so I can be lazy" is becoming acceptable and that is truly TRWTF.

    That said, I would never agree with Dick in this particular situation :)
  • Dennis 2009-05-12 13:13
    Dennis:
    Procedural:
    Is Alex writing or rewriting everything these days ? I really enjoyed the writing on this one. The images (loved the quip about change), the tone and rhythm, this was stellar (minor quibble: "As the years past by" -> "As the years passed by")


    TRWTF is that many of the articles have this kind of "typo".


    Here are more from this one [green=additions, red=deletions]:

    "...anger to one of the lead developers in the other group..."

    "...Dick had of predictably blamed Java..."
  • Kef Schecter 2009-05-12 13:15
    d3matt:
    kastein:
    I definitely agree about the writing BTW, this one was awesome with the only exception being the minor "past" instead of "passed" homonym swap, as noted above.

    You mean homophone... http://en.wikipedia.org/wiki/Homonym (I used to call them homonyms as well)


    Homophones are homonyms. It's just a more specific kind of homonym. See the "variant definitions" section of that Wikipedia article. For instance, the first two definitions Merriam-Webster gives for "homonym" are "homophone" and "homograph" -- it's probably noteworthy that these appear *before* the definition Wikipedia gives.
  • greatfog 2009-05-12 13:46
    Jay:
    Java 6 so fast that it can execute an infinite loop in 12 seconds.


    Now, just a minute, sonny. Is that an aleph-null-iterations infinite loop or an aleph-one-iterations infinite loop?
  • Franz Kafka 2009-05-12 13:47
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    C++ apps have a runtime too, but so what? The jdk is easily found and installed. The special server thing has been dropped, I see - good thing too, since java servers are just like other servers.

    Java is absolutely fasater than C++ when you consider dev time.
  • Franz Kafka 2009-05-12 13:52
    SomeCoder:
    I see developers these days choosing development time far too often when performance is still needed. Saying that "Well the user has a gig of RAM/Fast CPU/quick hard drive/etc. so I can be lazy" is becoming acceptable and that is truly TRWTF.

    That said, I would never agree with Dick in this particular situation :)


    If I can write a system that works quickly and use a ton of RAM doing it, that just may be the thing to do. Writing the prototype app quickly and iterating the design a bit before making the code tight is my preferred approach, although the apps are usually not that wasteful.
  • kastein 2009-05-12 14:09
    snoofle:
    wee:
    TRWTF is nobody proofreads shit.

    Sorry, I gotta ask.... what braille-literate person would want that job?
    if it's bumpy enough to be read as braille, you need more fiber.

    ... anyways...

    wow, the language zealots are out in full force! can't we all just pick on PHP and VB and be happy?
  • insquinormalc 2009-05-12 14:09
    You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.
  • BoomWav 2009-05-12 14:15
    SomeCoder:
    BoomWav:
    In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.


    Which is why computers get faster and yet when you get a new machine, they run as slow or slower as your old machine. The new software eats up all of the new hardware's capability.

    While I would agree that you have to consider development time vs performance, I see developers these days choosing development time far too often when performance is still needed. Saying that "Well the user has a gig of RAM/Fast CPU/quick hard drive/etc. so I can be lazy" is becoming acceptable and that is truly TRWTF.

    That said, I would never agree with Dick in this particular situation :)


    It's important to take the right tool for the job. There's no language that is the best for all jobs. It's not like that and it never will.

    At this time, from my POV, it's pretty clear.

    If portability is important for you, I'd go with Java, everytime. It's the main strenght of Java, there's no doubt into that. Java is easy enough to maintain too. It a bit hard to find good people however since there's a broad range of different libraries that do the same things making experience difficult to acquire.

    C++ is the expert language. It's good for really dedicated application. You have so much freedom into everything that it's the easiest way to make your tool the best for its job. You can have no tradeoff at all. Put everything in performance or memory management for the maximum boost. It's difficult to maintain however and the deadlines are always too close for everybody. Ask the game developpers.

    C# with the .NET framework is really appealing to a lot of people. You can go web-based with the same code with ASP.NET. The .NET framework is really solid too and well known. If you hire someone with C# experience, you know he will do the job since .NET is universal. It's also faster than java and is better supported.

    I might be biaised however but it's my view on things.
  • BoomWav 2009-05-12 14:18
    insquinormalc:
    You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.


    Yep, the code is really similar. Some syntax is better in C# however. The whole foreach() for example. Do not forget that the framework is also better in C#. Did you ever try to work with dates in Java? You'll want to kill yourself the first week you try to get something working. I exaggerate but so do you!
  • Spectre 2009-05-12 14:20
    The installer pictured on the screenshot was actually awfully slow on one computer I had to install JRE on. It kept on trucking for 15 minutes or so. So I thought it was generally slow, and then it ran in under a minute on an another PC.
  • Jeremy 2009-05-12 14:24
    They didn't get the contract, because Peter was lying out the kazoo and Dick was oblivious to what they were selling. If Peter was the good little programmer he makes himself out to be, why didn't he leave year after year?
  • SomeCoder 2009-05-12 14:25
    Franz Kafka:
    SomeCoder:
    I see developers these days choosing development time far too often when performance is still needed. Saying that "Well the user has a gig of RAM/Fast CPU/quick hard drive/etc. so I can be lazy" is becoming acceptable and that is truly TRWTF.

    That said, I would never agree with Dick in this particular situation :)


    If I can write a system that works quickly and use a ton of RAM doing it, that just may be the thing to do. Writing the prototype app quickly and iterating the design a bit before making the code tight is my preferred approach, although the apps are usually not that wasteful.


    I guess it depends on what the system is supposed to do. If you are writing something that is to run on a Windows machine and mostly likely have to share resources with other programs being open at the same time, I'd rather you work a little slower and use the RAM more efficiently so I can still have some left over for other programs that I may be running at the same time.

    On the other hand, if you are writing a system that is going to run in Unix and needs to crunch a lot of data very quickly, I see no reason to try and be efficient with memory.

    I was generalizing above (and in my previous post as well), and you probably were too, but my point still stands: I see lots of lazy developers these days and when my brand new, top of the line computer grinds to a halt because of it, that is irritating and I think it should be unacceptable.

    I would definitely agree with you that iterating over the code/design is a good method to use.
  • C4I_Officer 2009-05-12 14:26
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.



    The Java is Faster than C++ and C++ Sucks Unbiased Benchmark.

    Have fun ;-)
  • campkev 2009-05-12 14:29
    Kef Schecter:
    d3matt:
    kastein:
    I definitely agree about the writing BTW, this one was awesome with the only exception being the minor "past" instead of "passed" homonym swap, as noted above.

    You mean homophone... http://en.wikipedia.org/wiki/Homonym (I used to call them homonyms as well)


    Homophones are homonyms. It's just a more specific kind of homonym. See the "variant definitions" section of that Wikipedia article. For instance, the first two definitions Merriam-Webster gives for "homonym" are "homophone" and "homograph" -- it's probably noteworthy that these appear *before* the definition Wikipedia gives.


    This argument is making me homophobic
  • Technical Thug 2009-05-12 14:34
    A man had a problem. He said, "I know I'll fix it using Java!" Then all his co-workers took him out back and beat him to death.
  • insquinormalc 2009-05-12 14:36
    "Some syntax is better in C# however. The whole foreach() for example."

    Ok.

    C#:

    foreach (Thing t in my_list) {
    // do some stuff
    }

    Java:

    for (Thing t : my_list) {
    // do some stuff
    }


    I don't see much of a difference. I suppose if you enjoy typing "each" and "in", the C# example is "better", and if you enjoy typing colons, the Java example is better, but it's pretty much, um, the same.

    I have *never* met a date library I liked.
  • lol 2009-05-12 14:39
    TRWTF is letting the customer establish language platform as a functional requirement.
  • C4I_Officer 2009-05-12 14:39
    insquinormalc:
    "Some syntax is better in C# however. The whole foreach() for example."

    Ok.

    C#:

    foreach (Thing t in my_list) {
    // do some stuff
    }

    Java:

    for (Thing t : my_list) {
    // do some stuff
    }


    Well, not everyone is aware of Java's enhanced for loops since...uhmm...version 1.5 or so. Some people seem to conveniently forget about Java's JIT and Hotspot optimizations, too.
  • Zer0 2009-05-12 14:40
    snookerdoodle:
    I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.

    I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.


    Hahahaha. That was worth reading through all the crap about managed code being so much slower than native code. Anyone see Quake ported over in C#?
  • Franz Kafka 2009-05-12 14:48
    BoomWav:
    insquinormalc:
    You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.


    Yep, the code is really similar. Some syntax is better in C# however. The whole foreach() for example. Do not forget that the framework is also better in C#. Did you ever try to work with dates in Java? You'll want to kill yourself the first week you try to get something working. I exaggerate but so do you!


    Java after 1.5 has for(i:iterable), which is the same as foreach. Dates work fine - use Calendar and the DateFormatter classes.
  • kastein 2009-05-12 14:55
    insquinormalc:
    "Some syntax is better in C# however. The whole foreach() for example."

    Ok.

    C#:

    foreach (Thing t in my_list) {
    // do some stuff
    }

    Java:

    for (Thing t : my_list) {
    // do some stuff
    }


    I don't see much of a difference. I suppose if you enjoy typing "each" and "in", the C# example is "better", and if you enjoy typing colons, the Java example is better, but it's pretty much, um, the same.

    I have *never* met a date library I liked.


    // java.h
    // Purpose: make stupid java stuff work right in a real langauge

    #ifndef JAVA_H
    #define JAVVA_H

    #define : in

    #endif
  • RBoy 2009-05-12 14:56
    First!

    (Comment was written in Java, running on a nulla machine, so it may be slow to post)
  • SomeCoder 2009-05-12 15:01
    Zer0:
    snookerdoodle:
    I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.

    I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.


    Hahahaha. That was worth reading through all the crap about managed code being so much slower than native code. Anyone see Quake ported over in C#?



    I've seen the Quake 2 port from C to C++.NET (CLR). It was quite a bit slower but in practice it was at least playable. The framerate suffered more than I would have liked for a video game though
  • xtremezone 2009-05-12 15:10
    Jay:
    Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.
    A library is just reused code and that concept still exists for Java on top of the JVM. Java programs need to be run inside of the JVM, which is a different concept all together, and qualifies as "special software" IMHO.
    Jay:
    I'm surprised that Sun hasn't made it easier to install the JVM -- at least as of when I was last working with desktop apps, maybe they've done it better by now. (These days I'm on web apps, where I don't ask the user to install anything besides a browser.) But you write your own installer for it once and re-use it for every app and it doesn't really matter.
    In college (two years ago), one of the things that confused the Hell out of me was how I could be downloading version 5 of the JDK or JRE if the most recent version was 1.5... WTF?! I didn't figure out WTF they were doing until a year outside of college...
    amischiefr:
    Let's start with "The language semantics are a bitch." How so? You don't like "public int x = 1"? Is that terribly difficult for you to understand? Maybe since it doesn't have a * or an & in there you can't comprehend it. <shrug /> The semantics are some of the easiest to understand (and yes I program in ANSI C, C++, ASP .NET and VB .NET, and Java), and coincidentally they are VERY VERY similar to C#, which I believe you recommend :)
    Sure, show the C-like syntax to try to make it seem the same, but any C/C++ coder that's moved on to Java will quickly point out the frustrating semantics. For example, immutable strings.
    // Java
    
    char c;
    String name = "john";
    // Let's uppercase the first letter of name.
    c = char.toUpperCase(name.charAt(0));
    name = new String(c) + name.substring(1);

    // C++
    
    std::string name = "john";
    // Let's uppercase the first letter of name.
    name[0] = toupper(name[0]);

    amischiefr:
    "The code is ugly" Alright now you're just being stupid. Java code is very easily readable and is VERY straight forward. ESPECIALLY compared to C and C++. What don't you understand about:

    public int getX() {
    return x;
    }

    Are there just not enough of those * and & that you love so much in C++? if it was:

    return &x;

    Would it be that much easier to read, oh and "sexier"?
    Again, you're using C-like syntax to make it appear the same, when in reality there are very different semantics in Java. One of the things I find extremely ugly about Java code is that there are no operator overloads (except for those provided as part of the language, like operator+ for String) which results in lots of verbose, nested method calls with really long lines (or that many more lines if you split it up).
    // Java
    
    MyNumberClass number = new MyNumberClass(5);
    MyNumberClass number2 = new MyNumberClass(6);
    number = number.divideBy(number2.multiplyBy(number.add(number2))).subtract(number2);

    // C++
    
    MyNumberClass number(5);
    MyNumberClass number2(6);
    number = (number / (number2 * (number + number2))) - number2;

    The pointer and reference operators in C/C++ don't make the code easier to read, but they give the programmer more control over the program and let him or her do exactly what they want. It isn't n00b friendly, but then n00bs shouldn't be entrusted with writing important software anyway. Java doesn't make the code maintainable automatically. It just limits what the programmer can do through its language semantics with the belief that it will lead to fewer errors. We've seen just as many WTFs on this site for Java, if not more, than we have for C or C++. :P The real truth is that not everybody can program well and creating "dummy-proof" languages to encourage them to try is TRWTF. :D
    amischiefr:
    "...in my experience it always performs poorly ... near unusable)." You need more experience. I don't have too much to say except that you are completely ignorant and need to experience more in life.
    Performance is not Java's strength and probably never will be. Anybody arguing that is insane. It can perform OK for simple tasks, but workstations (particularly for developers like ourselves) are always being pushed to the limits (I probably have something like 60+ tabs open in Firefox right now). Java doesn't perform well enough for me to enjoy using it. On top of that, in my experience, .NET performs better (although honestly I've noticed that ASP.NET is also very slow, at least how "we're" using it, but that could just be because we're doing it wrong).
    amischiefr:
    I am not saying that Java is the best. Hell I would rather be programming in C# .NET myself. But I hate senseless Java bashers that have no idea what the fuck they are talking about.
    I'm not trying to come across as a senseless Java basher. I recognize that Java has its niche and can be used effectively. I just haven't really found it useful yet, and I've tried many times (both in college and out).
    Fedaykin:
    The syntax and semantics of Java are, by design, very similar to C and C++. Any competent programmer that writes Java can pick up a C or C++ app and be able to understand it pretty easily (and visa versa).

    So please, enlighten me as to what's so radically different about Java to make it's semantics "a bitch".
    The syntax of Java is very similar to C and C++ because it's a C-like language. The semantics, however, are VERY different. If you don't understand semantics, implicitly passing arguments by reference is an example of a semantic with consequences.

    Another thing that bothers me about Java is its lack of constants...

    The first language I learned was C++ and I've picked up C along the way. And I prefer them to anything else I've used. Although D sounds like a great compromise between C-like and high-level, it won't really be useful until it gets a powerful standard library and it really catches on, which could take a few more years.
    Franz Kafka:
    Java is absolutely fasater than C++ when you consider dev time.

    How many programs do you know of that spend more time in development then being executed? Probably not that many. While lots of time can be spent developing software, it is usually run much longer and by many more people (thousands, hundreds of thousands, millions, etc.). End users want a user-friendly experience and part of that is responsiveness and the ability to play nice with the rest of the system.
  • SNF 2009-05-12 15:10
    Fine, fine, I'll do it.

    Ok, let's see.. s... h... i... t... end of a sentence, period, no initial capital...

    It's fine, everyone! Now get back to work.
  • Procedural 2009-05-12 15:11
    Dennis:
    Dennis:
    Procedural:
    Is Alex writing or rewriting everything these days ? I really enjoyed the writing on this one. The images (loved the quip about change), the tone and rhythm, this was stellar (minor quibble: "As the years past by" -> "As the years passed by")


    TRWTF is that many of the articles have this kind of "typo".


    Here are more from this one [green=additions, red=deletions]:

    "...anger to one of the lead developers in the other group..."

    "...Dick had of predictably blamed Java..."


    Right; although my point is that, typos and such notwithstanding, Alex is turning, post by post, into a truly accomplished writer here.
  • Capt. Obvious 2009-05-12 15:13
    greatfog:
    Now, just a minute, sonny. Is that an aleph-null-iterations infinite loop or an aleph-one-iterations infinite loop?
    Well, depending on your view of the continuim hypothesis, aleph-one may lack an understandable defintion. Just ask if it was aleph-null iterations or beth-null iterations next time.
  • justsomedude 2009-05-12 15:18
    greatfog:
    Jay:
    Java 6 so fast that it can execute an infinite loop in 12 seconds.


    Now, just a minute, sonny. Is that an aleph-null-iterations infinite loop or an aleph-one-iterations infinite loop?


    Omega baby, we're talking THE INFINITE.

    *shout out to rudy rucker*

  • justsomedude 2009-05-12 15:18
    greatfog:
    Jay:
    Java 6 so fast that it can execute an infinite loop in 12 seconds.


    Now, just a minute, sonny. Is that an aleph-null-iterations infinite loop or an aleph-one-iterations infinite loop?


    Omega baby, we're talking THE INFINITE.

    *shout out to rudy rucker*

  • Milligan 2009-05-12 15:23
    [quote user="snoofle"
    I was always under the impression that a company cafeteria/snack machine was there to keep you from going out and taking longer to get back to your desk; not to make a profit.
    [/quote]
    That's usually true, until the beancounters take over.
  • xtremezone 2009-05-12 15:24
    insquinormalc:
    You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.
    C# supports a number of syntactic sugars that make it better than Java in many ways. For example, properties and overloaded operators. The whole language is a much improved Java. And .NET is much nicer to work with, IMHO, than Java's standard library. I still have my gripes with C# though. It isn't perfect.
  • Capt. Obvious 2009-05-12 15:32
    Zapp Brannigan:
    Oh yeah, Java is slow compared to C++ as long as you don't account for the development time.
    I guess it depends on how many people use your application. As Steve Jobs once told someone assigned to cut 0.1 seconds off the boot time, it was worth spending a week on because it would save hundreds of customer-lifetimes.

    Or words to that effect. He's a better speaker than I am a paraphraser.
  • Owner 2009-05-12 15:32
    insquinormalc:
    "Some syntax is better in C# however. The whole foreach() for example."

    Ok.

    C#:

    foreach (Thing t in my_list) {
    // do some stuff
    }

    Java:

    for (Thing t : my_list) {
    // do some stuff
    }


    I don't see much of a difference. I suppose if you enjoy typing "each" and "in", the C# example is "better", and if you enjoy typing colons, the Java example is better, but it's pretty much, um, the same.


    Ah, but can you do this:

    foreach(var t in myList) { }

    in java??

    For example

    for (MultipleComponentProfileHolder m : myList) { }

    I tried to find a longer java class name but I couldn't.


    Personally? C# over java any day of the week. There are just too many good things about developing in C# that java can never give you (ex. Web Applications). Yes multiplatform IS the upside to Java, but reality is unless its research or home user downloadable software, its really quite a useless requirement.

    Commercial and Enterprise applications? Only if you can't afford Visual Studio + programmers :)

    Agree 100% with previous post.
  • Gerrit 2009-05-12 15:32
    insquinormalc:

    I have *never* met a date library I liked.


    Try dating humans.
  • zoips 2009-05-12 15:33
    xtremezone:
    In college (two years ago), one of the things that confused the Hell out of me was how I could be downloading version 5 of the JDK or JRE if the most recent version was 1.5... WTF?! I didn't figure out WTF they were doing until a year outside of college...


    The naming scheme is stupid, but that's such an idiotic quibble it reflects badly on your argument.

    xtremezone:

    // Java
    
    char c;
    String name = "john";
    // Let's uppercase the first letter of name.
    c = char.toUpperCase(name.charAt(0));
    name = new String(c) + name.substring(1);

    // C++
    
    std::string name = "john";
    // Let's uppercase the first letter of name.
    name[0] = toupper(name[0]);


    I'm not sure that arguing about the immutability of strings in Java is helping you. If you want a C string, pass around a char[] array, it's the same damn thing (except, you know, it's bounds checked), or use java.lang.StringBuilder since its intended use is more closely aligned with std::string than java.lang.String is.


    StringBuilder str = new StringBuilder("john")

    str.setCharAt(0, Character.toUpperCase(str.charAt(0))


    Yes, more verbose, goes to below which I concede.

    xtremezone:

    // Java
    
    MyNumberClass number = new MyNumberClass(5);
    MyNumberClass number2 = new MyNumberClass(6);
    number = number.divideBy(number2.multiplyBy(number.add(number2))).subtract(number2);



    That is one of the most oft leveled complaints at BigDecimal, BigInteger, and matrix libraries, I'll give you that. Operator overloading is nice.

    xtremezone:

    The syntax of Java is very similar to C and C++ because it's a C-like language. The semantics, however, are VERY different. If you don't understand semantics, implicitly passing arguments by reference is an example of a semantic with consequences.


    I'm not sure where you would want to pass by value in Java...

    xtremezone:

    Another thing that bothers me about Java is its lack of constants...


    Java has a final keyword. On fields it makes them readonly, on method parameters, it prevents the object from being modified. This goes to the above where, again, I'm not sure where you'd need to pass by value in Java.
  • EmperorOfCanada 2009-05-12 15:35
    My experience with C++, .net and Java has generally been that C++ is often overkill for smaller applications. But with Java and .net you reach a certain point where you are fighting with the language itself to get to where you need to go. This results in a project where you spend the last half of the project in the "90% done" phase. With C+ you begin the fight with your first line of code but generally it will be able to plod along to a final product at a predictable speed.
    I suspect that Dick not only didn't like Java but also didn't like anything new in C++ if I had to guess he also was still using MFC or something. Bring things like Boost and QT to the table and C++ can actually be fun to develop in.

    All that said, I use PHP most of the time now. Right tool for the job is the real rule.

    P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.

  • benryves 2009-05-12 15:36
    xtremezone:
    Sure, show the C-like syntax to try to make it seem the same, but any C/C++ coder that's moved on to Java will quickly point out the frustrating semantics. For example, immutable strings.
    Isn't that more a library issue than a language issue? .NET's string is also immutable, but StringBuilder acts as a mutable string:
    // C#
    
    var Name = new StringBuilder("john");
    Name[0] = char.ToUpper(Name[0]);
  • Zer0 2009-05-12 15:39
    SomeCoder:
    Zer0:
    snookerdoodle:
    I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.

    I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.


    Hahahaha. That was worth reading through all the crap about managed code being so much slower than native code. Anyone see Quake ported over in C#?



    I've seen the Quake 2 port from C to C++.NET (CLR). It was quite a bit slower but in practice it was at least playable. The framerate suffered more than I would have liked for a video game though


    I saw a Quake 2 port to C# (i think it was the second one now that I think about it) with an added map interface in a seperate GUI. There was a framerate drop, but not by much.
  • BikeHelmet 2009-05-12 15:40
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.

    http://www.excelsior-usa.com/jet.html

    A fast x86 java compiler.

    In my experience, the shorter dev time of java results in more time being spent creating quality code and adding new features. Higher performance algorithms are implemented, and the end result runs faster than C++ apps, without memory leaks or other bugs.

    "1x to 3x slower" isn't even worth mentioning. C++ is roughly that much slower than assembly, but you'd take C++ over ASM because of the dev time alone.

    And don't give me that crap about the modern compiler optimizing more than assembly can. If you write the entire program in ASM, it will be significantly faster than a C++ program would be.

    It's a scale; for dev time and ease of implementing features, C++ is somewhere in the middle.
  • donnie 2009-05-12 15:57
    2 pages of comments and nobody points out that the story directly amounts to "cockblock?"
  • Franz Kafka 2009-05-12 15:59
    xtremezone:
    Jay:
    Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.
    A library is just reused code and that concept still exists for Java on top of the JVM. Java programs need to be run inside of the JVM, which is a different concept all together, and qualifies as "special software" IMHO.

    Who cares if it's special? Operationally, it's about the same as a library.

    In college (two years ago), one of the things that confused the Hell out of me was how I could be downloading version 5 of the JDK or JRE if the most recent version was 1.5... WTF?! I didn't figure out WTF they were doing until a year outside of college...


    If you can't figure our marketing driven naming, then you may not be cut out for programming.



    Franz Kafka:
    Java is absolutely fasater than C++ when you consider dev time.

    How many programs do you know of that spend more time in development then being executed? Probably not that many. While lots of time can be spent developing software, it is usually run much longer and by many more people (thousands, hundreds of thousands, millions, etc.). End users want a user-friendly experience and part of that is responsiveness and the ability to play nice with the rest of the system.


    Wrong metric, but you're a noob, so it's ok. It's cheaper to spend a bit more (50%, say) to make a java web app run well than it is to write it in C++, mainly because C++ sucks from a dev time perspective. Sure, if you're shipping to a million people, 1 second saved is a big deal, but we're talking about web apps and backend processing.
  • xtremezone 2009-05-12 16:01
    benryves:
    xtremezone:
    Sure, show the C-like syntax to try to make it seem the same, but any C/C++ coder that's moved on to Java will quickly point out the frustrating semantics. For example, immutable strings.
    Isn't that more a library issue than a language issue? .NET's string is also immutable, but StringBuilder acts as a mutable string:
    // C#
    
    var Name = new StringBuilder("john");
    Name[0] = char.ToUpper(Name[0]);
    Touche. :P Like I said, C# isn't perfect. I view StringBuilder as an efficient way to make strings from multiple sources or rules. So I think the string class should still be able to do this, albeit less efficiently (although in this case, it should be more efficient).

    I like that in D (AFAIK: it's been a while since I've look into D), there is no string class at all. Between the char type and arrays as objects, everything a conventional string class can do can be accomplished with an array of characters. It's brilliant.
  • Havstein 2009-05-12 16:09
    After Java 1.4.2, Java got so fast they could skip Java 2,3 and 4 and go straight to Java 5. I think that's remarkable.
  • Zer0 2009-05-12 16:15
    xtremezone:
    benryves:
    xtremezone:
    Sure, show the C-like syntax to try to make it seem the same, but any C/C++ coder that's moved on to Java will quickly point out the frustrating semantics. For example, immutable strings.
    Isn't that more a library issue than a language issue? .NET's string is also immutable, but StringBuilder acts as a mutable string:
    // C#
    
    var Name = new StringBuilder("john");
    Name[0] = char.ToUpper(Name[0]);
    Touche. :P Like I said, C# isn't perfect. I view StringBuilder as an efficient way to make strings from multiple sources or rules. So I think the string class should still be able to do this, albeit less efficiently (although in this case, it should be more efficient).

    I like that in D (AFAIK: it's been a while since I've look into D), there is no string class at all. Between the char type and arrays as objects, everything a conventional string class can do can be accomplished with an array of characters. It's brilliant.


    C-strings. Blah. I think char arrays have been beaten to death, so I think that's why string classes showed up to begin with. Sounds like a step backwards. Not sure how in the world that's brilliant...

    FYI, I think it was a great design decision to make strings immutable.
  • voyou 2009-05-12 16:18
    xtremezone:
    Sure, show the C-like syntax to try to make it seem the same, but any C/C++ coder that's moved on to Java will quickly point out the frustrating semantics. For example, immutable strings.


    I don't think this is a good example; AFAIK, pretty much everyone in the C++ community now thinks making std::string mutable was a mistake, and that, if the C++ standard were being written today, there would be an immutable string class (it's much more efficient in the more common case where strings aren't mutated, especially in multithreaded applications).

    You're right that Java's lack of operator overloading is annoying, as is the lack of user-defined value types. And Java's generics are a bit weak, too (though making them just syntactic sugar for casts to and from Object maintains backwards combatibility, which was probably the right trade-off to make).

    (captcha: "persto," which I assume, in keeping with the theme of this comments thread, is a type for "pesto")
  • hoselade 2009-05-12 16:21
    BoomWav:
    ...Yep, the code is really similar. Some syntax is better in C# however. The whole foreach() for example. Do not forget that the framework is also better in C#. Did you ever try to work with dates in Java?...


    Since a couple of versions ago, java does have a foreach equivalent as well.

    Not sure if i would agree that the framework is better just based on functionality around dates/calendar... what i find most interesting and scary at the same time is the sheer infinite number of frameworks that are out there, lot's of them are very powerful, but only few play well together...
  • noob 2009-05-12 16:21
    lol:
    TRWTF is letting the customer establish language platform as a functional requirement.


    Why is that a WTF? Many customers want to buy the initially developed and tested source code and maintain it themselves. Almost all of the projects I've worked on have a RFQ that specifies a preferred language.
  • sylvic 2009-05-12 16:23
    EmperorOfCanada:

    P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.



    emacs
  • Daniel 2009-05-12 16:27
    And yet, Java is slow.
  • xtremezone 2009-05-12 16:28
    BikeHelmet:
    C++ is roughly that much slower than assembly, but you'd take C++ over ASM because of the dev time alone.

    And don't give me that crap about the modern compiler optimizing more than assembly can. If you write the entire program in ASM, it will be significantly faster than a C++ program would be.
    A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.
  • Daniel 2009-05-12 16:34
    Why do you keep discussing these outdated languages? Learn Scala and get on with the program.
  • xtremezone 2009-05-12 16:35
    Franz Kafka:
    If you can't figure our marketing driven naming, then you may not be cut out for marketing.
    FTFY.
  • GrandmasterB 2009-05-12 16:36
    Choosing C++ over Java is not a WTF. If anything, its the anti-WTF.

  • Michael J 2009-05-12 16:37
    Java has steadily increased in speed to the point it is in the same order of magnitude as C code. The advantage of a static compilation vs. dynamic compilation is immense. We are replacing C code with EJB3 code at present, and the performance increase is approximately 41x. The difference is in how easy it is to distribute the work. If we need to increase performance we let the app server create another MDB. If the server runs out of capacity, we add another. The point is that C and to a degree C++ suck arse in performance in most applications. Java and .Net as Virtual Machine based languages are the future. Long live the VM.
  • WWWWolf 2009-05-12 16:39
    SomeCoder:
    I've seen the Quake 2 port from C to C++.NET (CLR). It was quite a bit slower but in practice it was at least playable. The framerate suffered more than I would have liked for a video game though


    There's also a port of Quake 2 for Java. Can't remember where it was, but it was pretty scary-awesome - click a link, JWS pops up, you tell it where your Quake2 data lives, boom, you get a pretty decently working Q2.
  • Buddy 2009-05-12 16:45
    SomeCoder:
    BoomWav:
    In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.


    Which is why computers get faster and yet when you get a new machine, they run as slow or slower as your old machine. The new software eats up all of the new hardware's capability...


    You really see it when you run old stuff on new machines - everything runs and finishes, meanwhile your finger hasn't left the enter key.
  • iMalc 2009-05-12 16:45
    C4I_Officer:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.



    The Java is Faster than C++ and C++ Sucks Unbiased Benchmark.

    Have fun ;-)
    Not so fast...

    'The Java Faster than C++' Benchmark Revisited

    Happy trolling ;-)
  • Fedaykin 2009-05-12 16:52
    [quote user="xtremezone"]A library is just reused code and that concept still exists for Java on top of the JVM. Java programs need to be run inside of the JVM, which is a different concept all together, and qualifies as "special software" IMHO.[/quote]

    Different purpose? Sure. Fundamentally different? No.

    [quote]
    In college (two years ago), one of the things that confused the Hell out of me was how I could be downloading version 5 of the JDK or JRE if the most recent version was 1.5... WTF?! I didn't figure out WTF they were doing until a year outside of college...
    [/quote]

    So that Java 5 == JVM version 1.5 is a highly confusing concept for you?

    [quote]Sure, show the C-like syntax to try to make it seem the same, but any C/C++ coder that's moved on to Java will quickly point out the frustrating semantics. For example, immutable strings.[/code]

    You are confusing core language semantics with the semantics of a particular library or class.

    To get on a sidetrack, the String class in Java is immutable for a very good reason: multi-threading and performance (something Java and its core libraries were designed for from the ground up). If you need mutable but still thread safe strings use a StringBuffer. If you don't care about thread safety you can also use a StringBuilder which is generally the fastest mutable String manipulation class in the core libraries.

    As a StringBuilder

    StringBuilder name = new StringBuilder("john");
    name.setCharAt(0, Character.toUpperCase(name.charAt(0));


    [quote]Again, you're using C-like syntax to make it appear the same, when in reality there are very different semantics in Java. One of the things I find extremely ugly about Java code is that there are no operator overloads (except for those provided as part of the language, like operator+ for String) which results in lots of verbose, nested method calls with really long lines (or that many more lines if you split it up).[/quote]

    This is one reason why Java 1.5 and above have Autoboxing which allows you to treat Objects and primitives interchangeably (with an equalities caveat).

    Now, while operator overloading can be useful, the functionality is just as easily done with other language tools (methods, classes, etc.) and arguably much more clearly.

    There isn't a great deal of gain to be had from something like:

    cout << MyObject;

    over the much more clear:

    MyObject.print();

    There's nothing you can do with operator overloading that you can't do in a different and often more clear way. The latter is also a more elegant solution because it allows for proper encapsulation of functionality.

    Plus, you won't have some jackass who overloads the dot operator or some stupid thing like that.

    [quote]I'm not trying to come across as a senseless Java basher. I recognize that Java has its niche and can be used effectively. I just haven't really found it useful yet, and I've tried many times (both in college and out).[/quote]

    I agree that Java is not a very good solution for desktop apps, but desktop apps are only a small portion of apps. Java excels in the enterprise environment.

    [quote]
    The syntax of Java is very similar to C and C++ because it's a C-like language. The semantics, however, are VERY different. If you don't understand semantics, implicitly passing arguments by reference is an example of a semantic with consequences.
    [/quote]

    Are you claiming that C++ does not have pass by reference?

    [quote]
    Another thing that bothers me about Java is its lack of constants...
    [/quote]

    WTF? Have you ever actually programmed in Java? It doesn't allow GLOBAL constants (though you can easily achieve the same functionality), but to say that Java doesn't have constants is nonsensical.
  • xtremezone 2009-05-12 16:55
    Zer0:
    C-strings. Blah. I think char arrays have been beaten to death, so I think that's why string classes showed up to begin with. Sounds like a step backwards. Not sure how in the world that's brilliant...
    It's brilliant because it makes sense. Strings are and always have been arrays of characters. In the days of C and C++, arrays were just dumb sequential bytes of memory though. You needed external routines to operate on them and it took time for the string libraries of today to develop.

    Now that arrays are always objects in modern languages, it doesn't make sense to have a separate class for strings (StringBuilder, sure, but not string).

    Anyway, I guess I take it back because it looks like D does has immutable strings (now, anyway). >_> However, you can still use an array of chars and accomplish everything if you need a mutable one. I liked the concept of "strings aren't special", which really they aren't... They're just arrays of data like any other data. We want to concatenate, replace, remove, join, splice, split, etc., all types of data in arrays.

    What made it particularly nice (and I forget most of it now) was the syntactic sugar for working with arrays. You didn't need to call methods on them a lot of the times because there were operators for lots of things. It's been so long I don't really remember anymore though.
  • jro 2009-05-12 16:58
    zoips:
    Wait, let me guess, Dick was given a raise for that, right?


    Sicko:

  • xtremezone 2009-05-12 17:02
    Fedaykin:
    Are you claiming that C++ does not have pass by reference?
    Of course not. Don't be ridiculous. Your reading comprehension is broken. I said IMPLICITLY passing arguments by reference. In C++, you have to explicitly declare reference parameters or the data will be copied. Which I prefer because it allows a way to keep data from being changed unintentionally.

    In C#, I haven't found a solution for this problem... You pass an object into a method and to my knowledge you have no way to ensure that the method doesn't modify it... AFAIK, Java is the same.
    Fedaykin:
    WTF? Have you ever actually programmed in Java? It doesn't allow GLOBAL constants (though you can easily achieve the same functionality), but to say that Java doesn't have constants is nonsensical.
    Of course I have, but only a little bit here and there. I play with it now and then until I get frustrated with the semantics and return to the sane world of me being in control. :D

    Please demonstrate how to accomplish constants in Java. It's been a while, but as I remember it, final isn't the same thing...
  • Franz Kafka 2009-05-12 17:16
    xtremezone:
    Franz Kafka:
    If you can't figure our marketing driven naming, then you may not be cut out for marketing.
    FTFY.


    If you can't outthink a marketer, then I'm very sorry.

    xtremezone:
    Zer0:
    C-strings. Blah. I think char arrays have been beaten to death, so I think that's why string classes showed up to begin with. Sounds like a step backwards. Not sure how in the world that's brilliant...
    It's brilliant because it makes sense. Strings are and always have been arrays of characters. In the days of C and C++, arrays were just dumb sequential bytes of memory though. You needed external routines to operate on them and it took time for the string libraries of today to develop.

    Now that arrays are always objects in modern languages, it doesn't make sense to have a separate class for strings (StringBuilder, sure, but not string).


    No, strings are not just arrays of chars, they are strings that happen to be stored as an array. Java Strings are an improvement over the mishmash of C++ string classes and I like them a lot better. If you don't like the slightly better abstraction, that's fine, but it isn't Java's problem.


    xtremezone:

    Please demonstrate how to accomplish constants in Java. It's been a while, but as I remember it, final isn't the same thing...


    public static final String CONSTANT="Some stuff"

    xtremezone:
    Fedaykin:
    Are you claiming that C++ does not have pass by reference?
    Of course not. Don't be ridiculous. Your reading comprehension is broken. I said IMPLICITLY passing arguments by reference. In C++, you have to explicitly declare reference parameters or the data will be copied. Which I prefer because it allows a way to keep data from being changed unintentionally.


    The only reliable way is to use immutable objects, like your maligned String.
  • anonymous wanker. 2009-05-12 17:20
    I was at a conference and they were describing the NUnit framework. (or was it XUnit?)

    NUnit 0.1 was simply JUnit run through the C# compiler. They then fixed all the errors, lather rinse repeat until it compiled.

    They said it was the fastest way to get a port running.
  • Zer0 2009-05-12 17:25
    [quote user="Franz Kafka"][quote user="xtremezone]
    Blah blah blah
    [/quote][quote]

    Um, hate to break it to you, but there's NO way in C++ to ensure a method doesn't modify a variable so I'm not sure why in the world you're expecting that from C# (and there are design patterns to account for this - cough properties cough). If you're starting to think 'const' ensures constness in C++, please read-up about it and don't bother replying. Also, C++ doesn't have constants. C# does.

    Some code-

    C++

    const - not guaranteed to be constant

    C#

    const - guaranteed to be constant


    C# wins.


    Java

    public static final String FAKE_CONSTANT = "Some stuff"

    C#

    public static readonly string FAKE_CONSTANT = "Some stuff";


    Tie.


    C#

    public const string REAL_CONSTANT = "Some stuff";

    Java

    none


    C# wins. =P


  • Charles400 2009-05-12 17:26
    If your company has a Dick, keep him zipped.
  • Franz Kafka 2009-05-12 17:32
    Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?
  • Jim S. 2009-05-12 17:37
    That would be jake.


    And for the comments about pass by reference vs. pass by value:

    Java passes *everything* by value. End of story.

    Explanation in mind-numbing detail can be found here
  • bENDER 2009-05-12 17:39
    snoofle:
    Zapp Brannigan:
    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!


    As a staunch Java advocate, to be fair, that just means you're a good app designer, not that Java rules.


    If you rewrote my spreadsheets into a Java App, I'd never ask for your help either.

    (My sarcasm detector may have malfunctioned when I read this...)
  • gr 2009-05-12 17:42
    Knock knock.

    Who's there?

    Java.

    Java who?

    Java na lemme in, already?
  • Franz Kafka 2009-05-12 17:42
    Jim S.:
    That would be jake.


    And for the comments about pass by reference vs. pass by value:

    Java passes *everything* by value. End of story.

    Explanation in mind-numbing detail can be found here


    This is true, however the value is an object ref, so it behaves much like pass by ref.
  • Ref 2009-05-12 17:43
    j_random_hacker:
    Java slow? Nooo. That may have been true once, but everyone knows that nowadays Java code typically runs 500 times faster than assembly.

    Sometimes a method will finish running before it began!


    GOAL!!!!
  • Johnno 2009-05-12 17:52
    snoofle:
    wee:
    TRWTF is nobody proofreads shit.

    Sorry, I gotta ask.... what braille-literate person would want that job?

    hahahahahahahahahahahahaha.......

    FMD, what a refreshing break from the "Java Rocks" vs "Java is Shite" debate.

    I'll be laughing all day on that one.....
  • Pedant 2009-05-12 17:55
    Went & looked up that java quake2 port previously mentioned, and interestingly it had benchmarks!

    http://bytonic.de/html/benchmarks.html

    Fullscreen (probably more reliant on CPU)

    C - 315fps
    Java 1.5 - 250fps

  • Some Other Coder 2009-05-12 17:59
    SomeCoder:
    BoomWav:
    In a enterprise environment, maintainability is WAY WAY more important than performance most of the time.


    Which is why computers get faster and yet when you get a new machine, they run as slow or slower as your old machine. The new software eats up all of the new hardware's capability.

    While I would agree that you have to consider development time vs performance, I see developers these days choosing development time far too often when performance is still needed. Saying that "Well the user has a gig of RAM/Fast CPU/quick hard drive/etc. so I can be lazy" is becoming acceptable and that is truly TRWTF.

    That said, I would never agree with Dick in this particular situation :)


    You have noticed, though, that while the apps eat much of the resource improvement, they do a hell of a lot more than they did on your old machine, haven't you?

    Sure the resources get eaten up, and some of this may be lazy choice in development language, but some of it is because they have more bu..(I mean "Features"). Often the language chosen makes it easier for such features to be quickly added, and the difference to resource usage only becomes apparent because the application is doing more nifty little things.
    In addition, choice of language can minimise problems down the track - a program written purely in assembler would be more likely to have (unknown) bugs. Quick is not always best, and lots more, but I suddenly can't be bothered....
  • ell0bo 2009-05-12 18:02
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.
  • Fedaykin 2009-05-12 18:06
    xtremezone:

    In C#, I haven't found a solution for this problem... You pass an object into a method and to my knowledge you have no way to ensure that the method doesn't modify it... AFAIK, Java is the same.


    Using proper encapsulation and access controls is the proper way to prevent unintended modification of your class members.

    Is there some other issue you have?


    Please demonstrate how to accomplish constants in Java. It's been a while, but as I remember it, final isn't the same thing...



    public class Globals {

    public static final int MY_GLOBAL_CONST = 1;

    }


  • Blingot 2009-05-12 18:07
    Franz Kafka:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    C++ apps have a runtime too, but so what? The jdk is easily found and installed. The special server thing has been dropped, I see - good thing too, since java servers are just like other servers.

    Java is absolutely fasater than C++ when you consider dev time.


    Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)

    How is Java dev time any quicker to c++ dev time? They are (on the whole) very similar languages (and have very similar libraries [although I'm not sure that's what java calls them - classes, perhaps] available to them).

    Let me say I am not anti-Java, and think (as with most things) there is a time and place for it, however to try to make an argument that it is an easier or quicker language to use than c++ is laughable at best. That being said, to make the claim the opposite way is probably laughable too - in terms of development, I can't see that there would be significant savings in dev time using either of them - other than if you don't know one of them as well as the other, that one would probably take you longer to debug.
  • Franz Kafka 2009-05-12 18:20
    Blingot:
    Franz Kafka:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    C++ apps have a runtime too, but so what? The jdk is easily found and installed. The special server thing has been dropped, I see - good thing too, since java servers are just like other servers.

    Java is absolutely fasater than C++ when you consider dev time.


    Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)

    How is Java dev time any quicker to c++ dev time? They are (on the whole) very similar languages (and have very similar libraries [although I'm not sure that's what java calls them - classes, perhaps] available to them).

    Let me say I am not anti-Java, and think (as with most things) there is a time and place for it, however to try to make an argument that it is an easier or quicker language to use than c++ is laughable at best. That being said, to make the claim the opposite way is probably laughable too - in terms of development, I can't see that there would be significant savings in dev time using either of them - other than if you don't know one of them as well as the other, that one would probably take you longer to debug.


    Yes a runtime does need to be installed for C++. The only difference is that the runtime is almost always installed already

    Java dev cycles are faster due to shorter compile loops and better behavior on failure - instead of a random memory stompage, you get an exception and a stack trace. In terms of web sites, java has a lot going for it over C++.
  • MZ 2009-05-12 18:20
    BoomWav:

    <snip>
    It's important to take the right tool for the job. There's no language that is the best for all jobs. It's not like that and it never will.

    At this time, from my POV, it's pretty clear.

    If portability is important for you, I'd go with Java, everytime. It's the main strenght of Java, there's no doubt into that. Java is easy enough to maintain too. It a bit hard to find good people however since there's a broad range of different libraries that do the same things making experience difficult to acquire.

    C++ is the expert language. It's good for really dedicated application. You have so much freedom into everything that it's the easiest way to make your tool the best for its job. You can have no tradeoff at all. Put everything in performance or memory management for the maximum boost. It's difficult to maintain however and the deadlines are always too close for everybody. Ask the game developpers.

    C# with the .NET framework is really appealing to a lot of people. You can go web-based with the same code with ASP.NET. The .NET framework is really solid too and well known. If you hire someone with C# experience, you know he will do the job since .NET is universal. It's also faster than java and is better supported.

    I might be biaised however but it's my view on things.


    I don't understand how Java Code is more maintainable than c++?
    Maintainability is largely affected by coding style, rather than by language. Finding people with enough experience to maintain either can be a difficult thing, but I don't see how maintaining one can be more difficult than the other - It boils down to the understanding of the language (and possibly the techniques used by predecessors). It may be easier to write obfuscated code in c++ than java, but this doesn't suggest that c++ developers write obfuscated code.

    Deadlines are a management issue, and are not affected by the language. If you are suggesting that c++ takes longer to develop, I'm not convinced. A complicated App will always take longer to develop than a simple one, irrespective of language. If deadlines are tight, though, it's more to do with management and planning (I would think)

    the .NET stuff confuses me a little. Is it somehow more universal than Java? If you hire someone with c# experience, he will do the job provided the job requires c# experience. If you hire someone with COBOL <**Shudder**> experience to fill a COBOL role, I'm sure they will do the job too. I'll take your word for c# being better supported ('cos frankly, I don't know any different).

    As so many others have said it's a 'horses for courses' thing. All languages have different weaknesses, and most languages have some strengths, and are best suited to different tasks/applications. To say out and out that one language is better than another is a brave thing to do - particularly without much justification.
  • QuercusMax 2009-05-12 18:23
    The funny thing is, there's actually a fairly big guy in the Java space named Rod Johnson (http://blog.springsource.com/author/rodj/) - he created the Spring suite of Java frameworks.

    Definitely one of the manliest names ever, after Staff Sgt. Max Fightmaster.
  • Me 2009-05-12 18:23
    BoomWav:
    insquinormalc:
    You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.


    Yep, the code is really similar. Some syntax is better in C# however. The whole foreach() for example. Do not forget that the framework is also better in C#. Did you ever try to work with dates in Java? You'll want to kill yourself the first week you try to get something working. I exaggerate but so do you!


    I don't use java much, but AFAIK foreach was introduced through the Iterator class around version 4 or 5...
    As for Dates, I think the biggest problem in Java is that they made a mistake, and then tried to fix it causing confusion. Pretty sure one of the Calendar (or was that Date) classes would be equivalent to C# these days.

  • DOS 2009-05-12 18:45
    EmperorOfCanada:
    My experience with C++, .net and Java has generally been that C++ is often overkill for smaller applications. But with Java and .net you reach a certain point where you are fighting with the language itself to get to where you need to go. This results in a project where you spend the last half of the project in the "90% done" phase. With C+ you begin the fight with your first line of code but generally it will be able to plod along to a final product at a predictable speed.
    I suspect that Dick not only didn't like Java but also didn't like anything new in C++ if I had to guess he also was still using MFC or something. Bring things like Boost and QT to the table and C++ can actually be fun to develop in.

    All that said, I use PHP most of the time now. Right tool for the job is the real rule.

    P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.



    CodeBlocks (codeblocks.org) is supposedlymulti-platform, multi-language. I've only ever used it on win for c++ and c, so I don't know whether it supports other languages well (I know of people using it on various Unix Flavours).

    Notepad++, though it isn't actually an IDE it has Syntax Highlighting, Code Folding and lots of other handy little tricks for a variety of languages

    Xemacs - you either like emacs or you find it difficult


  • LordOfThePigs 2009-05-12 18:48
    iMalc:
    C4I_Officer:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.



    The Java is Faster than C++ and C++ Sucks Unbiased Benchmark.

    Have fun ;-)
    Not so fast...

    'The Java Faster than C++' Benchmark Revisited

    Happy trolling ;-)


    Both of these are over 4 years old... try that one for a more up-to-date and neutral roundup:

    http://www.stefankrause.net/wp/?p=9
  • Gewn 2009-05-12 18:49
    sylvic:
    EmperorOfCanada:

    P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.



    emacs


    I believe emacs is developed in LISP not C++
  • Omnifarious 2009-05-12 18:50
    My main issue with Java is that Hello World in Java is slower than it is in Python. This causes people to want to shove every single little thing every program on the system does into one VM because of the startup costs.

    I think the world belongs to good 'scripting' languages like Python combined with C++ for optimizing the speed sensitive portions. I don't like Java at all. It has the worst tradeoff between ease of development, speed and verbosity of any language in popular use today.
  • Gewn 2009-05-12 18:52
    iMalc:
    C4I_Officer:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.



    The Java is Faster than C++ and C++ Sucks Unbiased Benchmark.

    Have fun ;-)
    Not so fast...

    'The Java Faster than C++' Benchmark Revisited

    Happy trolling ;-)


    I was thinking http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp.html


    There are many others....
  • LordOfThePigs 2009-05-12 19:03
    And this one for a comparison of java with C#
    http://kingrazi.blogspot.com/2008/05/shootout-c-net-vs-java-benchmarks.html

    or even better:
    The computer Language Benchmark Game for always up to date benchmarking of a lot of languages. Pretty cool benchmark place.

    After that, the conclusion is Java is slower than C/C++, but not by an awful margin (around 50% slower)
  • Ralph 2009-05-12 19:08
    [quote user="Zer0"][quote user="Franz Kafka"][quote user="xtremezone]
    Blah blah blah
    [/quote][quote]

    Um, hate to break it to you, but there's NO way in C++ to ensure a method doesn't modify a variable so I'm not sure why in the world you're expecting that from C# (and there are design patterns to account for this - cough properties cough). If you're starting to think 'const' ensures constness in C++, please read-up about it and don't bother replying. Also, C++ doesn't have constants. C# does.

    Some code-

    C++

    const - not guaranteed to be constant

    C#

    const - guaranteed to be constant


    C# wins.


    Java

    public static final String FAKE_CONSTANT = "Some stuff"

    C#

    public static readonly string FAKE_CONSTANT = "Some stuff";


    Tie.


    C#

    public const string REAL_CONSTANT = "Some stuff";

    Java

    none


    C# wins. =P


    [/quote]

    perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
    Forget const...
  • LordOfThePigs 2009-05-12 19:09
    Omnifarious:
    I don't like Java at all. It has the worst tradeoff between ease of development, speed and verbosity of any language in popular use today.

    Well, according to the language shootout link posted above, java is more than 100 times faster than python 3, Ruby 1.9 and Perl, 50 times faster than PHP and Javascript with Tracemonkey.

    The myth of Java beeing awfully slow is mainly due to the fact that is used to be, but isn't any more. It basically 3rd fastest, right after ASM and C/C++.
  • dkf 2009-05-12 19:12
    xtremezone:
    One of the things I find extremely ugly about Java code is that there are no operator overloads
    If you claim operator overloading, then you also have to explain why shift operators make sense for I/O and how it is much easier to look at a bit of code and work out what it is really doing (where the costly activities are) with C++ given that virtually any symbol (and even some places without symbols) can be assigned near-arbitrary semantics.

    Java makes you write out what you mean. This is certainly more bureaucratic, but it makes the life of maintenance programmers much better. That's really important for a lot of software...
  • LordOfThePigs 2009-05-12 19:14
    Ralph:

    perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
    Forget const...

    Not really, #define is preprocessor magic. This means that the preprocessor will basically copy whatever text is #defined everywhere it is referred to in the source code, before passing that modified code to the compiler. That works really well for int and other numeric types, but I'm unsure of how it really behaves with object or more complicated structures (my C++ is a bit too rusty).

    IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.
  • dkf 2009-05-12 19:19
    BoomWav:
    [C# is] also faster than java and is better supported.
    Only on a single expensive platform with some distinct scaling issues. (To be frank, Mono doesn't count!) If you don't mind being non-portable and bound to the whole Windows platform for execution environments, C# isn't a bad choice. But that doesn't work for everything.
  • Tama 2009-05-12 19:19
    xtremezone:
    Fedaykin:
    Are you claiming that C++ does not have pass by reference?
    Of course not. Don't be ridiculous. Your reading comprehension is broken. I said IMPLICITLY passing arguments by reference. In C++, you have to explicitly declare reference parameters or the data will be copied. Which I prefer because it allows a way to keep data from being changed unintentionally.

    In C#, I haven't found a solution for this problem... You pass an object into a method and to my knowledge you have no way to ensure that the method doesn't modify it... AFAIK, Java is the same.


    Nope, there are several ways to deal with this: make your object immutable, wrap it in an immutable wrapper class, or make a defensive copy that you pass around (but that might end up being quite expensive since you need to make a copy of all the readable references your object holds if they don't refer to immutable object themselves).

    First solution: if your class is immutable (like String, or the class Foo below), you can pass it around and it can never be modified:

    public class Foo {
    private final int _a;

    public Foo(int a) {
    _a = a;
    }

    public int getA() {
    return _a;
    }
    }


    Second solution: if you wrap your class in an immutable wrapper (like Collections.unmodifiableCollection() for instance - but beware references to other objects), it won't be able to be modified either:

    public class Foo {
    private int _a; // _a is a native type, so it's passed by value
    private String _b; // _b is immutable, so cannot be modified by getB().setSomething()
    private MyOtherClass _c; // We'll have to be careful about _c

    public Foo(int a, String b, MyOtherClass c) {
    _a = a;
    _b = b;
    _c = c;
    }

    public int getA() {
    return _a;
    }
    public String getB() {
    return _b;
    }
    public MyOtherClass getC() {
    return _c;
    }
    public void setA(int a) {
    _a = a;
    }
    public void setB(String b) {
    _b = b;
    }
    public void setC(MyOtherClass c) {
    _c = c;
    }
    }

    public class FooWrapper extends Foo {
    public MyOtherClass getC() {
    // Wraps _c itself in an immutable wrapper
    return new MyOtherClassWrapper(getC());
    }
    public void setA(int a) {
    throw new UnsupportedOperationException();
    }
    public void setB(String b) {
    throw new UnsupportedOperationException();
    }
    public void setC(MyOtherClass c) {
    throw new UnsupportedOperationException();
    }
    }


    Last solution: make a copy constructor, or introduce a copy() method (do NOT use clone() for that purpose). Implementation left as an exercise for the reader.
  • Betty 2009-05-12 19:21
    Jim S.:
    That would be jake.


    And for the comments about pass by reference vs. pass by value:

    Java passes *everything* by value. End of story.

    Explanation in mind-numbing detail can be found here


    Um, yeah. But I think the point of that article is that the value of a variable is a reference not the object itself.
    Consider:

    SomeMethod()
    {
    SomeObject foo = new SomeObject();
    foo.setSomeProperty("bar");
    /* 1 */
    println(foo.getSomeProperty());
    bar(foo)
    /* 2 */
    println(foo.getSomeProperty());
    }


    (Assuming SomeObject is a class with SomeProperty and associated getter and setter methods, and we have a method bar() that takes SomeObject)
    Will print 2 give the same thing as 1?? Always? No Matter what bar() does?
    If you pass by reference, any change made within a method is made to the Object referred by that reference.
    If you pass by value, the object is 'cloned' (probably bad terminology), and a clone is passed to the method. That is, the method has its own COPY of the object, but not the object itself, and modifying it does not modify the original object.

    Try passing an object in java to a method that modifies it, and you will find that the original object is modified. This is because java passes by reference, not by value. What the article you refer to is saying, is that the variable itself is a reference, and it is passed by its value. The article is merely being a little facetious.

    NB: If you answered that the code may print something different the second time, you are only half right. The code doesn't compile - it's missing a semi-colon on the method call, but nice try.
  • far9999 2009-05-12 19:26
    I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.

    Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.
  • Ralph 2009-05-12 19:26
    LordOfThePigs:
    Ralph:

    perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
    Forget const...

    Not really, #define is preprocessor magic. This means that the preprocessor will basically copy whatever text is #defined everywhere it is referred to in the source code, before passing that modified code to the compiler. That works really well for int and other numeric types, but I'm unsure of how it really behaves with object or more complicated structures (my C++ is a bit too rusty).

    IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.


    Point Taken, I've never used a Constant Object.
    #define works nicely for my ints and strings....
  • Bimbo 2009-05-12 19:32
    LordOfThePigs:
    Ralph:

    perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
    Forget const...

    Not really, #define is preprocessor magic. This means that the preprocessor will basically copy whatever text is #defined everywhere it is referred to in the source code, before passing that modified code to the compiler. That works really well for int and other numeric types, but I'm unsure of how it really behaves with object or more complicated structures (my C++ is a bit too rusty).

    IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.


    #define is a preprocessor trick, but it is (reasonably) invisible to even the developer for simple uses (more complicated macros bring trouble very quickly - make sure to overuse brackets, and all that)

    For more complicated constant Objects/structures (that you want lots of reuse), wouldn't a static class suffice? This would be reasonably constant (assuming you didn't allow it to be modified), or am I not switched on today??

    Perhaps I'm clutching at straws....
  • Anon 2009-05-12 19:38
    TRWTFs here are:

    a) They told Dick about the meeting
    b) They let Dick within 10 miles of the offices on the day of the meeting

    Either that, or they knew they were not going to get the contract, and they set Dick up so they could fire his ass.
  • dkf 2009-05-12 19:39
    LordOfThePigs:
    IIRC, #define doesn't allow you to build a complicated object/structure and use the same copy multiple times accross your program. Due to the fact that it is just a preprocessor trick, you end up with many copies of the same data.
    If you're talking C, #define can't build objects because C doesn't have them. It can build shared structures, but that's not usually considered to be good style. C programmers tend to like their macro definitions to be simple and clear. (Unlike C++ templates...)
  • Tama 2009-05-12 19:46
    far9999:
    I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.

    Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.


    Correct. As explained above, you have to have an immutable object or wrap it in an immutable container.

    Practically, when confronted with this kind of problem, I do something like this:

    private static final Set<String> _CONSTS = new HashSet<String>();
    static {
    // Strings are immutable, so we're safe; if we were dealing with non-immutable classes
    // in the collection, we'd have to wrap them too
    _CONSTS.add("foo");
    _CONSTS.add("bar");
    }
    public static final Set<String> CONSTS = Collections.immutableSet(_CONSTS);



    As for the whole references / value: in Java, primitives are passed by value, and for everything else, a reference to the object is passed by value (meaning the object pointed to can be altered if possible, but not the memory location of the object).
  • Tama 2009-05-12 19:48
    Tama:


    public static final Set<String> CONSTS = Collections.immutableSet(_CONSTS);



    I meant Collections.unmodifiableSet(...), but the rest is correct.
  • trincanapera 2009-05-12 20:08
    lol:
    TRWTF is letting the customer establish language platform as a functional requirement.


    If you read it again, FooNorsk designed and was building the system, they needed ACME to develop parts of it. And of course, the platform was already chosen.
  • trincanapera 2009-05-12 20:27
    ell0bo:

    This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.


    I once wrote an application in Java that spawned hundreds of threads to run perform concurrent tasks for several days. Although it was a memory hog, I find it hard to believe your application screwed up so badly. Either you coded it extremely bad, your teacher can't properly configure a server, or you're just trolling.

    What do you mean by forking processes? Are you talking about processes or threads?
  • Dirk Diggler 2009-05-12 20:49
    xtremezone:
    A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.
    The 1% that can beat the compiler intersects nicely with the programmers than CAN program in assembly. The rest of us need to stick with higher level languages.
  • erich 2009-05-12 22:09
    xtremezone:
    Again, you're using C-like syntax to make it appear the same, when in reality there are very different semantics in Java. One of the things I find extremely ugly about Java code is that there are no operator overloads (except for those provided as part of the language, like operator+ for String) which results in lots of verbose, nested method calls with really long lines (or that many more lines if you split it up).
    // Java
    
    MyNumberClass number = new MyNumberClass(5);
    MyNumberClass number2 = new MyNumberClass(6);
    number = number.divideBy(number2.multiplyBy(number.add(number2))).subtract(number2);

    // C++
    
    MyNumberClass number(5);
    MyNumberClass number2(6);
    number = (number / (number2 * (number + number2))) - number2;



    Fair enough with MyNumberClass, but it is a total WTF to assume that non-number classes need the ability to overload these.


    Dog dog = new Dog("Shih Tzu);
    Cat cat = new Cat("Persian");
    animal = dog + cat;
    if (animal == somethingFingUgly) {
    postComment("Obviously");
    }


    Far less than 1% of classes are numbers and assuming that these corner cases need a universal feature of the language is a proof by example.
  • xtremezone 2009-05-12 22:48
    Franz Kafka:
    If you can't outthink a marketer, then I'm very sorry.
    My job isn't to make assumptions. Assumptions lead to mistakes. I'm also not interested in anything that needs to be falsely advertised.
    Franz Kafka:
    No, strings are not just arrays of chars, they are strings that happen to be stored as an array. Java Strings are an improvement over the mishmash of C++ string classes and I like them a lot better. If you don't like the slightly better abstraction, that's fine, but it isn't Java's problem.
    Perhaps "array" is too low-level for you. Sequences of symbols is how Wikipedia chooses to define it.

    http://en.wikipedia.org/wiki/String_(computer_science)

    Franz Kafka:
    public static final String CONSTANT="Some stuff"
    Does that hold up for a method parameter?
  • Watson 2009-05-12 23:00
    Franz Kafka:
    Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?


    If my failing memory serves, the only place in compiled Java bytecode where a static final is referenced is the point where it was defined - every other occurrence would have been replaced by its value; the reference is only kept to maintain the interface. But this is the same behaviour as a C# const. So I'm curious, too.

    It's C#'s static readonly members that are the fakes: the substitution isn't made until runtime (or at least jitting). Why the delay? It's not like the value will change in the meantime, is it?

    A static readonly member might look and behave a lot like a const (except that a const is limited in what it can contain compared with a readonly), but if you change a const you have to recompile every module that references it, while changing the member only requires recompiling the module in which it's defined (all the others would obtain the new value at runtime).
  • shishkabob 2009-05-12 23:18
    A least with Dick & Rod being the protagonists, we can be confident that he didn't mean homophobe.
  • xtremezone 2009-05-12 23:44
    dkf:
    If you claim operator overloading, then you also have to explain why shift operators make sense for I/O and how it is much easier to look at a bit of code and work out what it is really doing (where the costly activities are) with C++ given that virtually any symbol (and even some places without symbols) can be assigned near-arbitrary semantics.

    Java makes you write out what you mean. This is certainly more bureaucratic, but it makes the life of maintenance programmers much better. That's really important for a lot of software...
    I have two responses to this. Firstly, I was just discussing this on a game programming forum. If you consider UNIX shells, they've been using angle braces to redirect streams for decades (I don't know how old it is, but my impression is that it's about as old as UNIX itself; I could be wrong). For example:
    echo foo 1>>bar

    Which for those that don't know, would redirect stdout (i.e., 1) to append to a file named "bar".

    Further, while you're free to implement operators any way you want in C++, best practice is to obviously not abuse it (documentation should explain what does occur and a reasonable developer should say WTF to something that doesn't make sense and look for an alternative). However, note there's nothing stopping you from implementing this in Java:
    public class MyNumber
    
    {
    .
    .
    .
    public MyNumber Add(MyNumber rhs)
    {
    return new MyNumber(this.getInt() - rhs.getInt());
    }
    }

    Basically, common sense always plays a factor. Sure, operators can be abused, but any language feature can be abused. That's where best practices play a role. You wouldn't likely use a framework that did something like this in Java, and similarly you wouldn't likely use something illogical in C++ (or C#, which also supports operator overloading).

    The bitshift operators make excellent stream IO operators, IMHO. Some argue that operator+ (and I assume operator-) would make more sense, but those operators are much more likely to be put to use more often.
    // Existing syntax with potential bitshift:
    
    std::cout << (a << b) << c;

    // Alternate syntax 1 with potential arithmetic:
    std::cout + (a + b) + c;

    // Alternate syntax 2a:
    std::cout.append(a << b);
    std::cout.append(c);

    // Alternate syntax 2b:
    std::cout.append(a + b);
    std::cout.append(c);

    Honestly, I like the stream IO operators. I think they were the best choice.
  • erich 2009-05-12 23:56
    ell0bo:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.


    Proof that in college you wrote crappy java programs. Bravo, sir. Sounds like you will soon be proud of many achievements noted here.
  • Wayne D. 2009-05-13 00:45
    Well, it should be. Sometimes flashy new features are WAY WAY more important than performance, which is WAY WAY more important than stability, which is WAY WAY more important than maintainability.
  • Anon 2009-05-13 03:12
    Watson:
    Franz Kafka:
    Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?


    If my failing memory serves, the only place in compiled Java bytecode where a static final is referenced is the point where it was defined - every other occurrence would have been replaced by its value; the reference is only kept to maintain the interface. But this is the same behaviour as a C# const. So I'm curious, too.


    No, Java classloading is far more screwed up than that.

    If you define a static final field of a primitive type, the bytecode for the given class may (at the discretion of the compiler) replace the value in the bytecode. It can do that because the value doesn't have to be determined during linking.

    However, if the final field is referenced outside that class (note that inner classes count as "outside that class"), then the final field is always compiled as a reference, since the value isn't known until runtime.

    The JIT compiler is free to detect that something is a constant and then rewrite the code such that it's constant, but that's an additional process beyond the initial compile step. C#'s constants avoid that extra linkage penalty.

    An even more screwy case is when you have a final primitive field where the value isn't set until runtime. These are always references, since the value isn't set until runtime - which means that even if it's a primitive type, it still has to be referenced.

    Yes, you can make final static fields be determined at runtime, thanks to static initializer blocks. It ensures that the compiler can never inline the value.
  • Severity One 2009-05-13 03:34
    A lot of interesting comments to read, although there are quite a few that are rather poorly corroborated.

    At our place, we use Java almost exclusively. Why? Because it works best for us. We're a mobile phone company (in a rather small country), so we deal with large amounts of data. But this data is usually stored in a database, in which case a lot of the crunching takes place there.

    If it comes to raw number crunching speed, C or C++ will indeed be faster, but since we don't do aircraft design or simulating nuclear explosions, that is not an issue: Java is fast enough for what we do.

    We develop on Windows, and run on Solaris, Linux or the few Windows servers we have left. The maintenance people don't like Windows very much, because it's a bitch to administer remotely, what with all the limitations you have on number of users, and they're virtualising everything. Quite apart from the operational expenditure of Windows licences.

    But the platform-independence is more a convenience than a deciding factor. Java's strength lies in its large standard library, the number of available third-party libraries, and the nice way it abstracts things from you like database access.

    Yes, JDBC has plenty of weaknesses, but I'm yet to see a standard library for C++ that both compiler suppliers and database engine suppliers use. Oracle gives you ojdbc6.jar and you know it'll work on your system, whether it's Windows, Solaris, Linux or anything else that runs Java.

    Another thing about Java is that it's a resource hog. Netbeans easily gobbles up hundreds of megabytes, and what for? But on the other hand, what's cheaper: a better kitted out computer, or paying a developer? We've found that C++ development takes a lot longer, because whilst you have all this power, it doesn't have a great deal of convenience, and as a result, applications take longer to develop.

    Certain things, though, I wouldn't do in Java if my life depended on it. BER decoding, for example. Not having unsigned integers and not having mmap() is a major headache, so this I do with a combination of C and Perl.

    C++ may be a Formula 1 car compared to Java being a family car, but very few people can drive a Formula 1 car without crashing it.

    All in all, Java gives us the lowest capital and operational expenditure overall. That's what keeps our development section from being outsourced to India.
  • JoJo 2009-05-13 03:44
    Zapp Brannigan:

    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!


    Yeah, I've also written software that bad in order to get people to stop bugging me...
  • Kimbo Slice 2009-05-13 03:49
    COBOL Rulez
  • Jimmy Jones 2009-05-13 04:10
    >"In a enterprise environment, maintainability is WAY WAY more important than performance most of the time. "

    Does Java have some special magic that makes it easier to maintain...?

  • dude 2009-05-13 04:34
    Indeed it's slow! Hate when I have to use any of Java software
  • MichaelWH 2009-05-13 05:09
    Jay:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code.


    The Just-in-Time compiler that came out with, what was it, Java 2.4?, really puts Java into a different league from version 1.

    Java 6 so fast that it can execute an infinite loop in 12 seconds.


    I tried to run this benchmark with Haskell but it can't do loops.
  • Bench Marker 2009-05-13 05:41
    Java vs. C benchmark:

    http://www.stefankrause.net/wp/?p=9
  • Anonymous 2009-05-13 06:01
    dkf:
    If you claim operator overloading, then you also have to explain why shift operators make sense for I/O(...)

    Yes, language features can be abused.

    Java makes you write out what you mean.

    No it doesn't. It makes you fall back to the few native types more often than it is useful, or otherwise leaves you with unreadable arithmetic expressions.

    Think of it the other way around: Why should there be a fixed set of "special" types? Java developers should have been honest and abolished every operator except "." if they thought this way lead to more expresiveness. They didn't, because obviously, it's ugly.

    Take a look at Ada, which certainly is the essence of "write out what you mean": Allows operator overloading. Why? Because Ada strongly discourages (ab)using the built-in types for everything. (It allows you to e.g. declare two integer types that behave identical but are incompatible with each other.) So if operators couldn't be overloaded, it would be almost pointless to have them in the first place.

    Operator overloading provides you with a great chance of extensibility and readability in arithmetic expressions. Of course only small parts of most programs deal with arithmetic, but these are usually also the most tricky ones.
  • Ragnax 2009-05-13 06:09
    far9999:
    I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.

    Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.


    The existence of const_cast<T> or similar methods to forcibly throw out const, ways to access private class members by using raw memory offsets, etc. all guarantee that C++ can't guarantee const correctness. It's a programmer's aid and that is all it is.
  • Watson 2009-05-13 06:11
    MichaelWH:
    Jay:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code.


    The Just-in-Time compiler that came out with, what was it, Java 2.4?, really puts Java into a different league from version 1.

    Java 6 so fast that it can execute an infinite loop in 12 seconds.


    I tried to run this benchmark with Haskell but it can't do loops.

    Haskell can't do loops but it can do infinite recursion in constant time.

    iterate :: (a -> a) -> a -> [a]
    iterate f x = x : iterate f (f x)
  • Watson 2009-05-13 06:13
    xtremezone:
    If you consider UNIX shells, they've been using angle braces to redirect streams for decades (I don't know how old it is, but my impression is that it's about as old as UNIX itself; I could be wrong).

    You'd be right; they were in there within the first few months, so they've been there for nigh on forty years now.

    (Dennis Ritchie's first hand account, which specifically mentions the pipeline model.)
  • someguy 2009-05-13 06:23
    The reason "Java is slow" gets passed around so much is that so many things which display the java logo are so slow. Maybe there's something about the language which is secretly fast, but capabilities mean nothing to what is actually perceived if the end result is: Java logo next to something unusable.

    To give a couple of examples:
    - OpenOffice. Very very very very slow.
    - Eclipse. Very very very very very very very slow.
    - Every "Java Applet" ever: may as well re-write it in flash in the time it takes to respond
  • Foobar 2009-05-13 06:49
    snoofle:
    Re the Java-is-slow debate...

    Good code can be written in any language.



    Wrong! I know of at least one language that makes it impossible to write good code: Fortran 77. Malbolge, Intercal, whitespace, and brainfuck are also contenders.
  • Roy T. 2009-05-13 06:59
    SomeCoder:
    Zer0:
    snookerdoodle:
    I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.

    I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.


    Hahahaha. That was worth reading through all the crap about managed code being so much slower than native code. Anyone see Quake ported over in C#?



    I've seen the Quake 2 port from C to C++.NET (CLR). It was quite a bit slower but in practice it was at least playable. The framerate suffered more than I would have liked for a video game though


    True, but that's because the .Net platform is optimized for database and backoffice applications, not for games, where as C/C++ is optimized for nothing/everything. Functions on Vectors, Floats and Matricres are therefor not as fast in .Net as in C++, and a game uses allot of those. So yeah, for making full blown games C# and Java are not a good choise, however for (boring) database interacting applications (like say 99% of all the applications written). C#/JAVA/C++ are all valid candidates depending on the requirements.
  • mauhiz 2009-05-13 07:06
    Now that guy is the real Dick!
  • London Developer 2009-05-13 07:44
    Homophobe???
  • IByte 2009-05-13 08:07
    Jay:
    Java 6 so fast that it can execute an infinite loop in 12 seconds.
    ...wait, what?

    (CAPTCHA: Abbas. Is that a political statement?)
  • dpm 2009-05-13 08:13
    Gerrit:
    insquinormalc:

    I have *never* met a date library I liked.
    Try dating humans.
    Unfortunately she slapped my face when I asked her how old she was. I doubt carbon-dating would give accurate results . . . what other method is there?
  • Severity One 2009-05-13 08:18
    someguy:
    The reason "Java is slow" gets passed around so much is that so many things which display the java logo are so slow. Maybe there's something about the language which is secretly fast, but capabilities mean nothing to what is actually perceived if the end result is: Java logo next to something unusable.

    To give a couple of examples:
    - OpenOffice. Very very very very slow.
    - Eclipse. Very very very very very very very slow.
    - Every "Java Applet" ever: may as well re-write it in flash in the time it takes to respond


    Have you actually looked at a Java desktop application in the last, say, 10 years? Or maybe you still have a Pentium II based computer with 128 MB of memory?

    The computers I use aren't exactly premier league (an AMD Athlon 2.2 GHz and a Core 1 Duo laptop), but to call the Java applications I use (mostly Netbeans) slow? No. Memory hogs, oh yes, but not slow. Just make sure you have 2 GB of memory.

    Anyway, everybody knows that Java on the desktop is as good as dead, but that it's extensively used in back-end server applications for the reasons I pointed out a few posts up.
  • Burp 2009-05-13 08:18
    Jimmy Jones:
    >"In a enterprise environment, maintainability is WAY WAY more important than performance most of the time. "

    Does Java have some special magic that makes it easier to maintain...?



    The magic of trying to hide this deadly weapon people call pointers manipulation. Let's face it, 2/3 or more of the so called "software professionals" have no idea how to correctly deal with memory. A language with which you can't do anything is a language with which you can't do any harm...
  • dkf 2009-05-13 08:40
    Severity One:
    Just make sure you have 2 GB of memory.
    Even 1GB is fine when running Eclipse, but 512MB was painfully slow.
  • OldHand 2009-05-13 08:47
    Daniel:
    Why do you keep discussing these outdated languages? Learn Scala and get on with the program.


    Agreed.
  • A Developer 2009-05-13 08:49
    Java is poo.
  • OldHand 2009-05-13 09:05
    OldHand:
    Daniel:
    Why do you keep discussing these outdated languages? Learn Scala and get on with the program.


    Agreed.


    For those unaware of Scala, it can use alla existing Java libs, compiles into class files and runs on the JVM. Also, it allows operator overloading, including using funny Unicode symbols. Mixed blessing?

    See http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html for a hilarious progression of languages, with Scala at its apex.
  • Delk 2009-05-13 09:14
    Franz Kafka:
    It's cheaper to spend a bit more (50%, say) to make a java web app run well than it is to write it in C++, mainly because C++ sucks from a dev time perspective. Sure, if you're shipping to a million people, 1 second saved is a big deal, but we're talking about web apps and backend processing.


    Exactly, and that's what most people seem to be missing here. We're talking about backend processing, not a direct desktop application, so even if a desktop application such as Eclipse is pretty resource-hungry, that doesn't mean it's relevant for a server application.

    If the application is built to be scalable e.g. for multiple cores, and you add in load-balancing and stuff, you can improve performance simply by adding hardware. You can't really do that with a desktop computer, not for a reasonable price anyway, but for server-side systems you can. If you can save a few man-months of development time by investing a few thousand dollars/euros/whatever more on hardware, it makes sense economically.
  • Tom 2009-05-13 09:43
    dpm:
    Gerrit:
    insquinormalc:

    I have *never* met a date library I liked.
    Try dating humans.
    Unfortunately she slapped my face when I asked her how old she was. I doubt carbon-dating would give accurate results . . . what other method is there?


    Of course carbon dating wouldn't give you her age accurately: Carbon dating tells you how long an object has been dead, so unless you were dating a zombie, it would always give 0.
  • bd 2009-05-13 09:45
    Jimmy Jones:
    >"In a enterprise environment, maintainability is WAY WAY more important than performance most of the time. "

    Does Java have some special magic that makes it easier to maintain...?

    - already mentioned lack of pointers and automated memory management
    - simplified language (no Obfuscated Java Contests, no template wizardry or Pythic compiler errors)
    - platform independence that goes beyond basic computation
    - stack trace with line numbers after a crash
    - always present remote debugger and a development culture where you don't strip symbols from built applications
  • far9999 2009-05-13 09:54
    Tama:

    Correct. As explained above, you have to have an immutable object or wrap it in an immutable container.

    Practically, when confronted with this kind of problem, I do something like this:

    private static final Set<String> _CONSTS = new HashSet<String>();
    static {
    // Strings are immutable, so we're safe; if we were dealing with non-immutable classes
    // in the collection, we'd have to wrap them too
    _CONSTS.add("foo");
    _CONSTS.add("bar");
    }
    public static final Set<String> CONSTS = Collections.immutableSet(_CONSTS);



    As for the whole references / value: in Java, primitives are passed by value, and for everything else, a reference to the object is passed by value (meaning the object pointed to can be altered if possible, but not the memory location of the object).


    You are right - I got a little bit hung up on the parameter thing... Really it applies everywhere. You can write a getter function that returns a const reference to an object and the caller cannot modify that object. There are ways to approximate this in Java/C# but they aren't anywhere near as clean.

    What is up with the lack of unsigned value types in Java. That's just stupid!

    Not that I have anything against Java - I'm programming in it right now....
  • RandomUser223957 2009-05-13 10:16
    Jay:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.


    Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.

    I'm surprised that Sun hasn't made it easier to install the JVM -- at least as of when I was last working with desktop apps, maybe they've done it better by now. (These days I'm on web apps, where I don't ask the user to install anything besides a browser.) But you write your own installer for it once and re-use it for every app and it doesn't really matter.

    As may or may not have been pointed out by now, C and C++ apps can usually be compiled against static libraries, which does increase the size of the resulting binary, but eliminates those "numerous libraries...[the] app will have to install" that comprise the runtime, et al. So, one file (EXE) versus JVM + Java file(s).

    Of course, the comparison isn't entirely fair, because in any case where common libraries are used, once they are installed for one app, they don't have to be for any additional apps that use them.
  • xtremezone 2009-05-13 10:47
    I would be more open to Java if it was compiled down to native code instead of byte-code. A release build of a particular version of a program is only going to be compiled once. I'm fine with compiling separate programs for each platform if it means I can get rid of the performance penalty of running an extra layer above the OS.

    I mean, to me, JIT means "recompile every time you run the program" whereas it could be done once and you'd have a native build... :-/ Even if the byte-code concept was kept, but instead of JITing byte-code every time, compile the byte-code down to a native binary on the first run and cache it in a secure directory somewhere. Win. From there, re-running the program would consist of hashing it to identify the cache and running the native build.

    Why not?
  • Georgem 2009-05-13 11:04
    > The reality is that Java remains to this day far slower than an application that gets compiled to native code.

    The reality is that that myth was de-bunked years ago. In some circumstances, Java has even been observed to out-perform the equivalent C++ code. It's true that for any trivial snippet of Java code, the equivalent C++ code will be quicker, but software isn't a trivial snippet of code, and the optimisations that, say, HotSpot, provides, blow this long-standing Java myth out out of the water.

    Next
  • Georgem 2009-05-13 11:07
    > TRWTF is letting the customer establish language platform as a functional requirement.

    Not really. Java isn't merely a programming language, it's a platform. If an enterprise has decided on a specific platform, then so be it
  • Blitz 2009-05-13 11:59
    insquinormalc:
    You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.


    Yeah, you're using C-sharp, and he's using C-pound.
  • Lego 2009-05-13 12:54
    MichaelWH:
    Jay:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code.


    The Just-in-Time compiler that came out with, what was it, Java 2.4?, really puts Java into a different league from version 1.

    Java 6 so fast that it can execute an infinite loop in 12 seconds.


    I tried to run this benchmark with Haskell but it can't do loops.


    Brainfuck anyone?
  • sylvic 2009-05-13 13:21
    Gewn:
    sylvic:
    EmperorOfCanada:

    P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.



    emacs


    I believe emacs is developed in LISP not C++


    Actually, I think the core is C, not C++, but the rest is in LISP.

    Still, it meets the spirit of the the request. Fast, multi-language, and doesn't hog resources. I have 40+ buffers open atm (Java, .NET, news, mail, shells, ...) and only using ~25MB of RAM.
  • amischiefr 2009-05-13 14:01
    Blingot:

    Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)

    Lolwut? Take a fresh install of Windows XP, create a test file, Test.cpp, and then try to run "gcc Test.cpp". You won't be able to because the OS has no fucking idea what gcc means, until you do what? That's right: install something. So, install the necessary files to compile and run C code or downloading the Java runtime is, well, about the same.
  • xtremezone 2009-05-13 14:30
    amischiefr:
    Blingot:

    Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)

    Lolwut? Take a fresh install of Windows XP, create a test file, Test.cpp, and then try to run "gcc Test.cpp". You won't be able to because the OS has no fucking idea what gcc means, until you do what? That's right: install something. So, install the necessary files to compile and run C code or downloading the Java runtime is, well, about the same.
    After installing your toolchain, compile your C++ program and statically link it with all required libraries, then take the resulting executable to a freshly installed OS and try to run it. There you fucking go. Try that with Java. Oh wait, you need extra tools to run Java programs. Right.

    Dynamically linked libraries are not even a C++ thing. They are an executable thing. Everything could be statically linked, but there are advantages to dynamically linking.

    It is in no way the same thing as Java's VM. It's ridiculous to claim that it is. Java programs run a layer above native programs. You can't compare that. It's different. Until that layer is eliminated and you no longer need to run your program through a native program, STFU, KTHX.
  • Franz Kafka 2009-05-13 14:39
    Dirk Diggler:
    xtremezone:
    A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.
    The 1% that can beat the compiler intersects nicely with the programmers than CAN program in assembly. The rest of us need to stick with higher level languages.


    I'd rather write a simple nested loop to iterate a large 2d array and have the compiler section it up so I don't thrash L1 cache than worry about doing it myself, especially when I want it unrolled too.
  • Franz Kafka 2009-05-13 15:01
    xtremezone:
    Franz Kafka:
    If you can't outthink a marketer, then I'm very sorry.
    My job isn't to make assumptions. Assumptions lead to mistakes. I'm also not interested in anything that needs to be falsely advertised.
    Franz Kafka:
    No, strings are not just arrays of chars, they are strings that happen to be stored as an array. Java Strings are an improvement over the mishmash of C++ string classes and I like them a lot better. If you don't like the slightly better abstraction, that's fine, but it isn't Java's problem.
    Perhaps "array" is too low-level for you. Sequences of symbols is how Wikipedia chooses to define it.

    http://en.wikipedia.org/wiki/String_(computer_science)

    Franz Kafka:
    public static final String CONSTANT="Some stuff"
    Does that hold up for a method parameter?


    Your job is to make judgements and analyze crap. The java 2 thing was confusing for exactly 5 seconds, and then it was ignored. If you can't deal with marketroid crap, why are you even here?

    you're the one who claimed that strings were arrays of chars and then bitched about how java strings are immutable. mutable strings is largely regarded as a mistake, so you're in the minority on this one.

    re: constants, yes, of course you can pass a constant string as a parameter. Why wouldn't that work?
  • xtremezone 2009-05-13 15:09
    Franz Kafka:
    Your job is to make judgements and analyze crap. The java 2 thing was confusing for exactly 5 seconds, and then it was ignored. If you can't deal with marketroid crap, why are you even here?
    Please explain what being here has to do with "marketroid crap".
    Franz Kafka:
    ...constants, yes, of course you can pass a constant string as a parameter. Why wouldn't that work?
    You don't seem to comprehend const-correctness. I want to pass a normal (non-"constant") object into a method and have that method agree not to modify any part of it. In other words, the source data is not constant, but according to the method, its parameter is.
  • Franz Kafka 2009-05-13 15:17
    xtremezone:
    Franz Kafka:
    Your job is to make judgements and analyze crap. The java 2 thing was confusing for exactly 5 seconds, and then it was ignored. If you can't deal with marketroid crap, why are you even here?
    Please explain what being here has to do with "marketroid crap".


    Apparently, you aren't smarter than a marketroid. I'm sorry.

    xtremezone:

    Franz Kafka:
    ...constants, yes, of course you can pass a constant string as a parameter. Why wouldn't that work?
    You don't seem to comprehend const-correctness. I want to pass a normal (non-"constant") object into a method and have that method agree not to modify any part of it. In other words, the source data is not constant, but according to the method, its parameter is.


    You can't pass an object into a method in java period. A final const string is as close as you will get - at most the method can change the reference it's using. As many people have said, passing an immutable wrapped object ref will prevent the method from modifying the parm's members.

    Now then, if you haven't done this in C++, you don't have const either - const is a suggestion, and can be cast away. Const, just like class visibility only works if the other programmers are acting in good faith.

    Now then, you need to settle down and listen a little more if you want to get better at what you do.
  • BikeHelmet 2009-05-13 15:19
    xtremezone:
    A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.

    The same argument can be applied to Java and C++, unfortunately.

    Ahh, the 99% statistic! Why not just say "most"? :P
  • xtremezone 2009-05-13 15:27
    Franz Kafka:
    Now then, if you haven't done this in C++, you don't have const either - const is a suggestion, and can be cast away. Const, just like class visibility only works if the other programmers are acting in good faith.
    I'm well aware. It requires an explicit cast (which is simple to check for) and if it does cast to non-const then it isn't const-correct (i.e., it can be considered a bug).
  • Zer0 2009-05-13 15:45
    Franz Kafka:
    Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?


    Because it doesn't use the const keyword. I'm just playing around, functionally they are the same.
  • Zer0 2009-05-13 15:53
    someone:

    perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
    Forget const...


    There is a million and one reasons NOT to use a preprocessor directives. This is common knowledge for C++ developers.
  • Zer0 2009-05-13 15:56
    dkf:
    BoomWav:
    [C# is] also faster than java and is better supported.
    Only on a single expensive platform with some distinct scaling issues. (To be frank, Mono doesn't count!) If you don't mind being non-portable and bound to the whole Windows platform for execution environments, C# isn't a bad choice. But that doesn't work for everything.


    C# is not bound to any platform. You even mentioned Mono in your post (and uh, it does count).

    Compiling C# produces IL code, not machine code. So theoretically it could be executed on any platform with a virtual machine capable of executing the IL.
  • Zer0 2009-05-13 15:58
    far9999:
    I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.

    Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.


    For the last time, C++ DOES NOT HAVE CONST CORRECTNESS. Please don't ever code in C++ again, thanks. And yes, there are plenty of ways to guarantee this in C# (and Java too I'm assuming; I'm not a Java coder).
  • Jake Clarson 2009-05-13 16:02
    Joshua:
    My experiments show that in most cases, Java is between 1x and 3x slower in CPU time, but most things simply aren't CPU bound anymore.


    Slower in CPU then what? When you say something like that you really should be more specific.

    For pure 100% CPU bound number crunching algorithms, the performance of Java ranges from approximately 2x as fast to 3x times as slow when compared to C++. In a fair number of situations Java is nearly exactly as fast as C++, but C++ is more often 2x as fast then its 2x as slow. For some specific algorithms, C++ is 3x as fast.

    It all depends on how well the actual run-time data can be used to optimize the algorithm. Java depends heavily on a very high-performance run-time optimizer, while C++ depends on a very high-performance static optimizer. Both have their virtues. As said, on some algorithms Java performs better, on some C++ performs better. Overall the two are nowadays at approximately the same level.

    If you compare Java to PHP however, it becomes a completely different league. Algorithms implemented in Java can be a 100x(!) faster, in some occasions even almost up to 200x.

    Still, as other posters have pointed out, a lot of business systems simply aren't about number crunching, but are a mix of CPU and IO, with IO typically being the more important aspect. That's precisely why a *horribly* slow language as PHP is still able to implement high performing web applications. Basically PHP simply isn't the one doing any heavy lifting. Typical PHP applications put request values in an SQL query, sent that to some DB and after a little while they'll iterate over the resultset to pump out some HTML.
  • xtremezone 2009-05-13 16:05
    Zer0:
    someone:

    perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
    Forget const...


    There is a million and one reasons NOT to use a preprocessor directives. This is common knowledge for C++ developers.
    On the contrary, there are many reasons TO use preprocessor directives. Achieving "constants", however, is not one of them.

    Macros (i.e., via the #define directive) in particular are bad because they make the code obscure to the programmer and hide things that aren't obvious. However, there are still times where there is no other solution.
    // Bad:
    
    #define MY_CONSTANT 5

    // Better:
    const int MY_CONSTANT = 5;

    The main reason macros are bad is because the C++ compiler doesn't even know about them (they are substituted before it sees the code) so it has no way to know where the actual offending code is. As a result, tracking down errors that are the result of macro substitution is painful and error prone: you can be looking at valid code, but part of that code might be substituted with text that makes it invalid.
  • xtremezone 2009-05-13 16:08
    Zer0:
    For the last time, C++ DOES NOT HAVE CONST CORRECTNESS.
    Const-correctness is a best practice, not a language feature. It describes correct code in much the same way other logic errors do. Just because the language lets you do it doesn't mean it's correct.
    Zer0:
    And yes, there are plenty of ways to guarantee this in C# (and Java too I'm assuming; I'm not a Java coder).
    I'd really appreciate it if you could show us a few of them.
  • awfwefewa 2009-05-13 16:19
    xtremezone:
    Zer0:
    someone:

    perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant??
    Forget const...


    There is a million and one reasons NOT to use a preprocessor directives. This is common knowledge for C++ developers.
    On the contrary, there are many reasons TO use preprocessor directives. Achieving "constants", however, is not one of them.

    Macros (i.e., via the #define directive) in particular are bad because they make the code obscure to the programmer and hide things that aren't obvious. However, there are still times where there is no other solution.
    // Bad:
    
    #define MY_CONSTANT 5

    // Better:
    const int MY_CONSTANT = 5;

    The main reason macros are bad is because the C++ compiler doesn't even know about them (they are substituted before it sees the code) so it has no way to know where the actual offending code is. As a result, tracking down errors that are the result of macro substitution is painful and error prone: you can be looking at valid code, but part of that code might be substituted with text that makes it invalid.
    You may think it's bad, but it's great for job security!
  • antred 2009-05-13 16:20
    Zer0:

    For the last time, C++ DOES NOT HAVE CONST CORRECTNESS. Please don't ever code in C++ again, thanks.


    Oh come on, it does for all practical purposes. If you're going to const_cast the constness away (or declare all your class member variables 'mutable'), that's your own fault and nobody else's.

    That said, these C++ vs Java debates are silly, and I think deep down in your hearts you ALL know this. Personally, my languages are C++, Python and Tcl. I've only had minimal exposure to Java and C#, but from all I've heard and read, in MOST cases there's not much to choose between these languages (C++, Java, C#), as far as performance is concerned. If you code your programs using efficient data structures / algorithms, either of those languages will more than cut the mustard. There may be some specialized cases where you may have to revert to C++ or even C (or ASM), but for the vast majority of applications this should be unnecessary.
    Oh, and I full believe that an interpreted language can do __some__ things as fast or faster than C++, because sometimers the virtual machine will be able to make certain optimizations AT RUNTIME that can allow out it outpace functionally equivalent C++.

    QUESTION: The one thing that kinda puts me off Java is the lack of RAII, which to me is one of the most essential tools a computer language can offer. In C++ this is easily doable by simply allocating RAII guard object on the stack. These objects will then perform cleanup when their destructor is run. Python offers RAII functionality via 'context managers'. In Incr Tcl, one can create 'local' objects, whose destructors is run as soon as the function they were created in is left.
    Last time I checked, Java didn't have anything like that, but then I haven't been doing any Java in ages. Does anybody know whether this has changed in the meantime?
  • Franz Kafka 2009-05-13 16:39
    Zer0:
    dkf:
    BoomWav:
    [C# is] also faster than java and is better supported.
    Only on a single expensive platform with some distinct scaling issues. (To be frank, Mono doesn't count!) If you don't mind being non-portable and bound to the whole Windows platform for execution environments, C# isn't a bad choice. But that doesn't work for everything.


    C# is not bound to any platform. You even mentioned Mono in your post (and uh, it does count).

    Compiling C# produces IL code, not machine code. So theoretically it could be executed on any platform with a virtual machine capable of executing the IL.


    C# is not supported outside of the MS platform. Mono is always a rev back and needs to be validated separately, so no, it doesn't count. Let's not talk about theory when discussing operating code.

    /hoping xtremezone goes away
  • woah! 2009-05-13 16:59
    Jay:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.


    Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.


    Exactly. You still have to install the equivalent components.
  • xtremezone 2009-05-13 18:38
    woah!:
    Jay:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.


    Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.


    Exactly. You still have to install the equivalent components.
    A virtual machine is not equivalent to a dynamically linked library. At all. A class library or JAR is an approximate equivalent to a dynamically linked library. Java byte-code means nothing to the Windows or Linux kernels, nor the machine's processor, whereas the code in a dynamically linked library should.

    In other words, with a native program (written in any language and compiled to a supported binary format) you need:

    - The program.
    - Probably, though not necessarily, dynamically linked libraries.

    With Java:

    - The program.
    - Probably, though not necessarily, class libraries.
    - A (compatible) Java Virtual Machine.

    Count the points. :P You might notice an extra requirement for Java. :P

    The JVM is essentially an interpreter. To my knowledge, your Java program is always interpreted (probably JIT compiled) by it before being fed to the processor. It isn't essentially the same. It's completely different.

    And there's nothing wrong with that. But it means that in practice, Java will probably never be faster than C++ in more than a few select areas, where run-time analysis reveals a few useful optimizations.

    My processor time AND memory are important to me. I don't want to waste them on needless layering and lazy programmers. In practice, Java can be replaced with a high-level language (like D) that is designed to abstract all platform specifics so that code doesn't need to be ported and can easily be compiled natively for each platform.

    With that, Java sounds obsolete.

    ** EDIT **

    This reminds me of an interesting note... It sounds like a huge WTF that static properties are implemented at the JVM level, not the program level... :-X When is that useful (for non-"constants")?
  • Jim S. 2009-05-13 20:45
    After installing your toolchain

    Check. Excelsior Jet installed.
    Compile your Java program.

    Check.
    Statically link it with all required libraries.

    Check.
    then take the resulting executable to a freshly installed OS and try to run it.

    Check.
    There you fucking go. Try that with Java.

    Check(mate).

    STFU indeed.
  • xtremezone 2009-05-13 21:45
    Jim S.:
    After installing your toolchain

    Check. Excelsior Jet installed.
    Compile your Java program.

    Check.
    Statically link it with all required libraries.

    Check.
    then take the resulting executable to a freshly installed OS and try to run it.

    Check.
    There you fucking go. Try that with Java.

    Check(mate).

    STFU indeed.
    Good to know. Does it actually improve performance as one would expect?

    Java is technically a language and a platform, and you simply compiled the language to a native binary (which can be done with any language). That doesn't work with Java byte-code which was the point I was making (that is, you can't take Java byte-code to a fresh OS and run it without installing a JVM). Look at all of the Java applications used today. None of the popular ones are distributed as native binaries to my knowledge. They all require Java to be installed.

    It's still not really the same thing. Java compiled to machine code would eliminate one of the problems I have with it.

    Addendum (2009-05-13 22:00):
    <sigh/>

    According to the Web site, applications still require about the same amount of RAM and disk space on end user machines as if used by Sun JRE...
  • anon 2009-05-14 00:28
    snookerdoodle:
    I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.

    I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.


    Was the client rep named "Dick" ?
  • voyou 2009-05-14 03:42
    Zer0:
    For the last time, C++ DOES NOT HAVE CONST CORRECTNESS.


    Yes it does. A program that casts away the const-ness of a const object is not a conforming C++ program.
  • Severity One 2009-05-14 05:08
    xtremezone:

    My processor time AND memory are important to me. I don't want to waste them on needless layering and lazy programmers. In practice, Java can be replaced with a high-level language (like D) that is designed to abstract all platform specifics so that code doesn't need to be ported and can easily be compiled natively for each platform.


    Now I know you're trolling, but that doesn't give you a right to become downright offensive. So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?

    Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.

    Between then and now I've worked with Z80 assembler, 8088 assembler, 68000 assembler, several flavours of BASIC, (Turbo) Pascal, C on MS/DOS, C on the Amiga, C on Unix, C++ on Unix, Perl, Bourne Shell and a bunch of others that aren't worth mentioning. And Java, of course.

    There's no way that I'll ever go back to an environment where I have to spend time on things that a computer could do for me, like all the things a JVM does for me. I've got better things to do.

    And abstraction, yes, that's important too. Try writing an application on a Windows system that you test with a MySQL database, and then port it to Solaris with Oracle. If you're using something like Hibernate to abstract the database engine, you don't even need to change your SQL queries and recompile.

    Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?
  • acsi 2009-05-14 06:25
    Joshua:
    My experiments show that in most cases, Java is between 1x and 3x slower in CPU time, but most things simply aren't CPU bound anymore.

    Proof please. Links to your papers detailing your method.
  • acsi 2009-05-14 06:27
    Mike:
    TRWTF is disagreeing that Java is slow. SQL Developer, Zend Studio, and pretty much all other Java-based development tools I've used have been horridly slow in comparison to non-Java based equivalents.

    Eclipse vs Visual Studio?
  • Pedant 2009-05-14 08:53
    Ah, Eclipse, an awesome development environment.

    Also, reposting FTW: -
    Went & looked up that java quake2 port previously mentioned, and interestingly it had benchmarks!

    http://bytonic.de/html/benchmarks.html

    Fullscreen (probably more reliant on CPU)

    C - 315fps
    Java 1.5 - 250fps
  • xtremezone 2009-05-14 10:35
    Severity One:
    Now I know you're trolling, but that doesn't give you a right to become downright offensive. So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?

    Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.

    Between then and now I've worked with Z80 assembler, 8088 assembler, 68000 assembler, several flavours of BASIC, (Turbo) Pascal, C on MS/DOS, C on the Amiga, C on Unix, C++ on Unix, Perl, Bourne Shell and a bunch of others that aren't worth mentioning. And Java, of course.

    There's no way that I'll ever go back to an environment where I have to spend time on things that a computer could do for me, like all the things a JVM does for me. I've got better things to do.
    I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.

    I don't find myself getting caught by those kinds of bugs very often. I find it's relatively easy to track them down. I'm sure you're aware that debuggers and stack traces exist for native programs...

    As for security, I'm not sure if you mean system security or application security, but operating systems are fully capable of handling system security (i.e., what memory addresses and/or resources your program can access) and I don't really see a difference between application security in C++ and Java applications (with the possible exception of buffer overruns, etc., in poorly written native code).
    Severity One:
    And abstraction, yes, that's important too. Try writing an application on a Windows system that you test with a MySQL database, and then port it to Solaris with Oracle. If you're using something like Hibernate to abstract the database engine, you don't even need to change your SQL queries and recompile.
    Absolutely. Abstraction is a good thing. There's nothing preventing abstraction from being written into C++ though. The reason C++'s standard library is so lacking is mostly because of its age. There are libraries and frameworks to fill in the gaps. Boost has a ton of functionality, though I'm not sure what exists for data layer abstraction.
    Severity One:
    Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?
    No, the time I spend USING is more important than the time I spend developing and it's related to CPU time. I don't care if it takes me 6 months to develop an application if it does what I need efficiently for the next 3 years.

    Time adds up quickly. I don't know about you, but if I could somehow count the time wasted on slow Java applications it would probably amount to a lot of wasted time.

    And development time is directly affected by CPU time as well. You can only test an application's functionality as quickly as it can run. So if it takes more time to run then it will take you more time to test.

    Maybe you need Java to hold your hand, but I don't. There is absolutely a time to use RAD tools and interpreted programs can be useful to get something simple done quickly, but personally for something that myself or others will be using a lot, I think it's worth the development time to build an efficient native program (even if you decide to prototype it in Java first).
  • John Smallberries 2009-05-14 14:45
    My parents used to have problems with Excel, and were always asking me for help. I installed VisualStudio.NET and the full MSDN library onto their computer and told them to write their own spreadsheet application, and now they never ask me for help!
  • Jake Clarson 2009-05-14 14:54
    antred:

    QUESTION: The one thing that kinda puts me off Java is the lack of RAII, which to me is one of the most essential tools a computer language can offer. [...]
    Last time I checked, Java didn't have anything like that, but then I haven't been doing any Java in ages. Does anybody know whether this has changed in the meantime?


    Well, it's STILL not in the current version of Java which at the time of writing this is Java 6 update 13. However, former Sun employee and designer of among others the collection framework in Java, Joshua Bloch, is currently making a strong argument to have this ability included in Java 7.

    The original reason for leaving this very useful feature out might be exactly the same reason why enums and templates among others where left out: Java needed to remove a lot of 'redundant' and 'unnecessary' features to be able to position itself as the easy alternative to C++. Of course, beginners and people who program only occasionally for fun don't need RAII. Well, they basically would need it, but they will never understand that they'll need it. When Java took of as a development language for serious development, it became clear that leaving out all of this had been a mistake. Later versions of Java thus added enums, and something that captures one use case for which one typically uses templates in C++ (generics). Although Generics are but a shadow of C++'s templates, enums are actually better implemented in Java.

    Currently try/finally is used in Java to make up for the missing RAII functionality. Hopefully Joshua's proposal will make it to Java 7. Java 7 is slated for a release in 2010, but release dates tend to slip by a year or so. This is one area where Java surely does better than C++, where release dates tend to slip by close to a decade. <ducks> :P
  • antred 2009-05-14 15:12
    Jake Clarson:

    Currently try/finally is used in Java to make up for the missing RAII functionality. Hopefully Joshua's proposal will make it to Java 7. Java 7 is slated for a release in 2010, but release dates tend to slip by a year or so. This is one area where Java surely does better than C++, where release dates tend to slip by close to a decade. <ducks> :P


    Well, that's good to hear. I might get my feet wet with Java some more then. And you're right, the pace at which C++ evolves IS painfully slow. I mean I understand the need to carefully review all decisions lest they turn out to be a mistake later on, but gosh ... it's been 6 years since the last C++ revision and it'll probably be one more before C++0x arrives. And then it'll be a couple of years before compiler vendors implement all the new features? ... :-(
  • antred 2009-05-14 15:40
    John Smallberries:
    My parents used to have problems with Excel, and were always asking me for help. I installed VisualStudio.NET and the full MSDN library onto their computer and told them to write their own spreadsheet application, and now they never ask me for help!



    LOL!! :D
  • dog 2009-05-14 17:19
    Why?

    Because of its lack of concurrent classes like ConcurrentHashMap, etc..?

    Because of its lack of a TreeMap?

    Or because of its failure to give you a reasonable way to handle timezones? (Don't say DateTimeOffset because it doesn't even have proper daylight savings handling)

    Or maybe it is because of its VERY POORLY encapsulated database API? I mean.. I thought MS invented ODBC, they could at least have made a good copy of JDBC.

    ASP.Net is awesome.. but .Net and C# are just Ok when compared to Java. In Java world the UI frameworks are mostly a mess (though Wicket and GWT are nice).


  • far9999 2009-05-14 17:53
    const_cast is used to interact with legacy interfaces. Any other use would be an abuse.

    I'm not sure what you mean by you can't pass an object into a method. You can pass a reference to an object... I commonly refer to this as passing an object. Maybe that's wrong but that's what I say.

    This whole comment flame war has mostly been C programmers who think they are C++ programmers vs Java and C# programmers who may or may not know what they are doing...
  • Severity One 2009-05-15 03:58
    xtremezone:
    I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.

    At which point you lose quite a bit of your coveted performance.

    I don't find myself getting caught by those kinds of bugs very often. I find it's relatively easy to track them down. I'm sure you're aware that debuggers and stack traces exist for native programs...

    I rarely, if ever, have to use a debugger. For one thing, I use proper programming techniques, and second, Java helpfully points out where something went wrong, with stack traces and everything. Source code analysis with a tool like PMD helps as well to hunt down trivial bugs that the Java compiler (which catches a lot more bugs than a C compiler) doesn't catch. And then there are unit tests, which become easy with JUnit, etcetera.

    As for security, I'm not sure if you mean system security or application security, but operating systems are fully capable of handling system security (i.e., what memory addresses and/or resources your program can access) and I don't really see a difference between application security in C++ and Java applications (with the possible exception of buffer overruns, etc., in poorly written native code).

    I didn't mention security.

    Absolutely. Abstraction is a good thing. There's nothing preventing abstraction from being written into C++ though. The reason C++'s standard library is so lacking is mostly because of its age. There are libraries and frameworks to fill in the gaps. Boost has a ton of functionality, though I'm not sure what exists for data layer abstraction.

    There is simply nothing like it. You cannot take a C/C++ program from one architecture and take it to a different one without spending a lot of time. Heck, even if you try to compile something on Solaris that was written by someone who only knows Linux and GCC (instead of Sun's compiler) it's a nightmare. Perl has a quite reasonable database abstraction layer, and it's relatively easy to install a module, and I think PHP has one too, but both are a far cry from JDBC. But you don't even have that for C++, for the simple reason that outside the Windows platform, C++ is very much a niche product. C, no, but C++, yes.

    No, the time I spend USING is more important than the time I spend developing and it's related to CPU time. I don't care if it takes me 6 months to develop an application if it does what I need efficiently for the next 3 years.

    You obviously don't work in an environment where people actually have to deliver products and meet commercial deadlines... contrary to most of the readers of this site, I would imagine.

    Time adds up quickly. I don't know about you, but if I could somehow count the time wasted on slow Java applications it would probably amount to a lot of wasted time.

    Could you corroborate this claim perhaps? I work daily with Netbeans, developing Java applications, and they're not slow. I never spend more than a couple of seconds compiling, and it may take maybe - just maybe - a minute if I re-compile an application from the ground up. But that is only if I re-compile all the projects that are listed as dependencies, and all of their source code has to be compiled as well.

    And development time is directly affected by CPU time as well. You can only test an application's functionality as quickly as it can run. So if it takes more time to run then it will take you more time to test.

    You mean you don't use unit tests? I thought you said you knew what you were doing, and not throw code at a compiler until it works.

    And again you come with this claim that Java is so slow, without ever trying to back it up with some evidence. What sort of applications do you write anyway? You haven't mentioned that, you've just been re-hashing the 'Java is slow' mantra.

    Maybe you need Java to hold your hand, but I don't. There is absolutely a time to use RAD tools and interpreted programs can be useful to get something simple done quickly, but personally for something that myself or others will be using a lot, I think it's worth the development time to build an efficient native program (even if you decide to prototype it in Java first).

    Again, what sort of program? Note that the code I write runs on back-end servers, deals with very large amounts of data, and is very much bound by the database engine (Oracle) that we use. As said, Java is fast enough, because we don't do simulating of aircraft or nuclear explosions.

    But apparently you typically write programs where development time and deadlines are not an issue, but quick run times are? If you're working at a university, it could make sense, but please do enlighten us.
  • Bench Marker 2009-05-15 05:25
    xtremezone:
    I would be more open to Java if it was compiled down to native code instead of byte-code.


    It is perfectly possible to do that.

    http://www.excelsior-usa.com/java-download-size.html

    http://www.excelsior-usa.com/protect-eclipse-rcp-applications.html

    have some examples of natively compiled Java apps, including Eclipse Classic, available for download.
  • John Dugeen 2009-05-15 09:59
    Java is indeed slow, as you can see for yourself by visiting any site with an embedded applet and watch Java painfully struggling to load, while the page displays a pathetic 'Applet loading' message.
  • Izink 2009-05-15 10:15
    why is the cpu execution still in focus when it comes to sw?

    As many seem to say that it is maintainabillity that really makes sw usefull over time..then we could pay some performance pennalities in order to gain maintainabillity..one factor in this is portabillity.

    we need to think in execution cykles of the sw not the cpu?

    C++ and old hw thinking might screw up a lot.
    1.cpu centrik seems really cilly as we have multiple cpu..
    2.OO thinking in the old code reuse way is cilly as reusabillity is really worthwhile first on high levels of abstraction..
    Dicks argumentation that got him into trouble is that he did not understand what is the driving force behind his system.
    1.adaptabillity to requirement changes is far more important than performance when in reasonable diffrencies.
    2.integration that works is the responsibillity not of any older system but of the CIO.
    3.If a faliure occurs and it is to be fixed and it is the interface techniqe between the applikations that causes the problem..only severe constraints should prevent you from updating the older app to a newer more effective interface.If it is not doable this should be a signal to rewrite in the other language.
    4 cost of apps is not just the maintenance cost day by day.It can be total replacement cost if it is keept in to old environment.
  • Rob 2009-05-15 10:35
    Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.
  • Rob 2009-05-15 10:51
    John Dugeen:
    Java is indeed slow, as you can see for yourself by visiting any site with an embedded applet and watch Java painfully struggling to load, while the page displays a pathetic 'Applet loading' message.


    Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.

    What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

    To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.
  • xtremezone 2009-05-15 10:59
    Severity One:
    xtremezone:
    I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.
    At which point you lose quite a bit of your coveted performance.
    No more than Java. Matter of fact, probably a lot less than Java if you do it well.
    Severity One:
    I didn't mention security.
    Yes, you did:
    Severity One:
    So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?
    Severity One:
    There is simply nothing like it. You cannot take a C/C++ program from one architecture and take it to a different one without spending a lot of time. Heck, even if you try to compile something on Solaris that was written by someone who only knows Linux and GCC (instead of Sun's compiler) it's a nightmare. Perl has a quite reasonable database abstraction layer, and it's relatively easy to install a module, and I think PHP has one too, but both are a far cry from JDBC. But you don't even have that for C++, for the simple reason that outside the Windows platform, C++ is very much a niche product. C, no, but C++, yes.
    I've heard Java zealots claim that in practice Java often needs to be tailored to a specific machine too. Write once, run everywhere isn't quite so clear cut in practice.

    You can, however, take C++ from one machine to another without much extra work if your team is aware of platform specifics and everybody writes platform independent code (and all libraries used are either platform independent or equivalent functionality is pulled from platform specific libraries for all supported platforms). It isn't like C++ needs to be completely rewritten in order to work on another machine. There's nothing platform specific about C++, the language. It's the compiler implementations and operating systems that bring the specifics. And that stuff can easily be wrapped up just like Java wraps it. Reusing stable and powerful platform independent frameworks can really save you a lot of work.

    In practice it usually isn't as convenient as Java, sure, but then again the end result is hopefully software that greatly outperforms the equivalent Java software and is that much more user-friendly for it. I hate waiting for computers to do things and therefore expect applications to perform as quickly as possible. Especially applications that I use a lot. Perhaps the way we use computers differs.
    Severity One:
    You obviously don't work in an environment where people actually have to deliver products and meet commercial deadlines... contrary to most of the readers of this site, I would imagine.
    The right tool for my jorb right now is ASP.NET. I never said to use C/C++ (or other native alternatives) for everything.
    Severity One:
    Could you corroborate this claim perhaps? I work daily with Netbeans, developing Java applications, and they're not slow. I never spend more than a couple of seconds compiling, and it may take maybe - just maybe - a minute if I re-compile an application from the ground up. But that is only if I re-compile all the projects that are listed as dependencies, and all of their source code has to be compiled as well.
    I wonder what your machine specs are. I haven't used NetBeans in about a year or two, but when I used it it was nearly unusable on decent hardware (albeit, it ran MUCH better in Linux than Windows). I spent much of my Java classes in college wishing it had been written in a native language.

    And actually, Visual Studio has become quite slow as well (at least, in my experience). I don't know if it was written in managed code or is just bloated, but I'd guess it's probably a little bit of both... :P

    I find it refreshing to get home and develop in Vim. :D
    Severity One:
    You mean you don't use unit tests? I thought you said you knew what you were doing, and not throw code at a compiler until it works.
    Sure I do. If the code runs slower than native code then it will be slower to test than the equivalent native code. It doesn't matter if it's a full scale application (which still needs to be tested regardless of unit tests) or a unit test.
    Severity One:
    And again you come with this claim that Java is so slow, without ever trying to back it up with some evidence. What sort of applications do you write anyway? You haven't mentioned that, you've just been re-hashing the 'Java is slow' mantra.
    It's common knowledge that Java is slow. I don't need to prove it. Anybody that doesn't believe me can install it and find themselves a nice Java application to use. Obviously a zealot will deny this. And maybe the Java applications that you use aren't slow. I don't know. The ones I've used have been.

    Slow is a relative term anyway. As somebody said earlier (maybe you, maybe not), on the backend you can throw hardware at it to make it perform adequately. Most users don't know what's happening in the backend and only experience the Java running on their own hardware. Even if the backend is fast because of lots of hardware, there are usually many many frontends that you don't have control over (and couldn't afford to anyway) that need to interface with the backend. If those are all written in Java, hardware might not be available to solve the problem.

    By all means, if you can afford to make your Java applications perform well with hardware on the backend, go for Java. I don't care what you use on the backend as long as it performs well and works correctly. However, unless you're going to buy me an uber powerful gaming rig to use your frontend, write it in something less wasteful so it doesn't hog all my system's resources.
    Severity One:
    Again, what sort of program? Note that the code I write runs on back-end servers, deals with very large amounts of data, and is very much bound by the database engine (Oracle) that we use. As said, Java is fast enough, because we don't do simulating of aircraft or nuclear explosions.

    But apparently you typically write programs where development time and deadlines are not an issue, but quick run times are? If you're working at a university, it could make sense, but please do enlighten us.
    I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).

    I never said to use C/C++/D/etc. for everything. However, there is absolutely a time to use it and IMHO the use for Java is a relatively small niche. Again, that's based on my personal experience running Java applications which obviously isn't like yours because you love it.

    IMHO, the vague description the article gives doesn't give us enough information to make a technology decision. By the sound of it, the system will handle lots of data for an entire country and won't change much once written. To me, that sounds like a good candidate for native programs. I don't know that obviously. I know next to nothing about what this particular contracted company was being considered for. You don't know that Java was the right tool either though.
  • xtremezone 2009-05-15 11:08
    Rob:
    Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.
    How well do you think your JVM will run without the operating system? Thought so.
    Rob:
    Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.

    What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

    To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.
    Perhaps they should write the JVM in Java... Oh wait...
  • Rob 2009-05-15 11:14
    xtremezone:
    It's common knowledge that Java is slow.
    ...

    I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).


    It is also common knowledge that people who write in ASP.NET are talentless and brain-dead. They're all VB6 drag'n'drop muppetts who've retrained using a Learn * in 24 hours book. They didn't have the design talent to get a PHP job or the programming skill to get a job writing real applications in Java/C++/C/... They use Windows because they're soulless corporate micro-drones and aren't smart enough to use a real shell. They once tried to install Linux but were confused when they didn't have to click Start to Stop their PC.

    It turns out that 'common knowledge' isn't that reliable since one, or more, of my previous statements may be untrue.
  • Rob 2009-05-15 11:19
    xtremezone:
    Rob:
    Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.
    How well do you think your JVM will run without the operating system? Thought so.
    Rob:
    Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.

    What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

    To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.
    Perhaps they should write the JVM in Java... Oh wait...


    1. Java requires AN operating system not A SPECIFIC operating system.

    2. Point 1 isn't quite true since there are/were Java machines that had the JVM on bare metal - effectively it was the OS. This was an awful idea but, that aside, Java can run without an OS.

    3. With each release of Java more and more of it is written in Java and it gets faster with each release. Make of that what you will.
  • Shakje 2009-05-15 11:20

    At which point you lose quite a bit of your coveted performance.


    Not enough to worry about.


    I rarely, if ever, have to use a debugger. For one thing, I use proper programming techniques, and second, Java helpfully points out where something went wrong, with stack traces and everything. Source code analysis with a tool like PMD helps as well to hunt down trivial bugs that the Java compiler (which catches a lot more bugs than a C compiler) doesn't catch. And then there are unit tests, which become easy with JUnit, etcetera.


    Just because you rarely use a debugger (surely if Java catches more syntactic errors, the majority of bugs will require a debugger, being logic errors) just suggests a different technique. I know C++ coders who rarely use one, but the VS2005 one is by and large fantastic. There's plenty of static analysis tools for C++, ever heard of Lint?


    There is simply nothing like it. You cannot take a C/C++ program from one architecture and take it to a different one without spending a lot of time. Heck, even if you try to compile something on Solaris that was written by someone who only knows Linux and GCC (instead of Sun's compiler) it's a nightmare. Perl has a quite reasonable database abstraction layer, and it's relatively easy to install a module, and I think PHP has one too, but both are a far cry from JDBC. But you don't even have that for C++, for the simple reason that outside the Windows platform, C++ is very much a niche product. C, no, but C++, yes.


    Don't be silly, you can, if you want, write portable C++ code. I've come across it on several occasions. The difference is that you can also use platform specific libraries to leverage (really hate that word) specific functionality. It's there if you want it, and most people use it, probably because the majority of software is Windows based. Java doesn't offer that. Portability is a noble cause, but different things for different purposes, and if you don't need it for your requirements, why limit yourself for it?


    You obviously don't work in an environment where people actually have to deliver products and meet commercial deadlines... contrary to most of the readers of this site, I would imagine.


    I do, but I also work in an environment where performance is absolutely critical (and fits neither of your scenarios). For quick things I'll use C#. It's quicker than Java because VS2005 has one of the best IDEs out there (although I did particularly like IDEA [possibly the only one that I think had any real chance of beating it] when I did Java, although ReSharper changes the playing field) and because the framework has a better selection of commonly used things for the things I need to do. The performance critical stuff is done using C++, memory management, stability and speed are absolutely critical (in terms of life/death), and Java really doesn't quite cut it, however much it's improved.


    Could you corroborate this claim perhaps? I work daily with Netbeans, developing Java applications, and they're not slow. I never spend more than a couple of seconds compiling, and it may take maybe - just maybe - a minute if I re-compile an application from the ground up. But that is only if I re-compile all the projects that are listed as dependencies, and all of their source code has to be compiled as well.


    What does compilation have to do with this? People are used to seeing slowish Java apps, I think some of that is perceived because Swing apps generally look dog. I really don't understand why you keep mixing dev/compile/run timings altogether. Different projects have different priorities, and if your company gets them consistently wrong then maybe you should leave (and yes, I've plenty of experience with rushed prototypes which are sold).


    You mean you don't use unit tests? I thought you said you knew what you were doing, and not throw code at a compiler until it works.
    And again you come with this claim that Java is so slow, without ever trying to back it up with some evidence. What sort of applications do you write anyway? You haven't mentioned that, you've just been re-hashing the 'Java is slow' mantra.


    It IS slower than C++ on most operations. Evidence has been posted previously, and I'll quite happily collab to optimise some tests. The thing is, while it may be relatively negligible on some JVMs, the Sun JVM is woefully slow compared to other ones and that's what most people's experience of Java is, so yes, I think it's perfectly fair to call it slow.


    Again, what sort of program? Note that the code I write runs on back-end servers, deals with very large amounts of data, and is very much bound by the database engine (Oracle) that we use. As said, Java is fast enough, because we don't do simulating of aircraft or nuclear explosions.

    But apparently you typically write programs where development time and deadlines are not an issue, but quick run times are? If you're working at a university, it could make sense, but please do enlighten us.


    Good for you. The thing is, his argument is completely irrelevant, and you claiming that Java is better because of dev-time is irrelevant as well. At the end of the day it's not how fast the language is but, as you rightly say, if it is "fast enough". For exactly the same that random optimising is stupid, complaining about language speeds when it's negligible is pointless unless you need that extra speed. If you have a company full of C++ devs who are shit hot you'll probably get better, more maintainable code than a mediocre Java coder. On the other hand if you have one stupid developer, he's less likely to do harm in your Java app. I'm trying to say it's all relative. There's a lot of stupid criticism of both languages but they both have very important usages, and if it fits your company and your requirements then there's no real reason to change it.
  • Shakje 2009-05-15 11:36
    Rob:
    Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.


    This is bollocks. What are you actually talking about. Idiot.

    Rob:
    1. Java requires AN operating system not A SPECIFIC operating system.


    Cool, same with C++ then.

    Rob:
    2. Point 1 isn't quite true since there are/were Java machines that had the JVM on bare metal - effectively it was the OS. This was an awful idea but, that aside, Java can run without an OS.


    Yay, go Java! Why was it an awful idea? Try and explain it without making Java sound crap. Go on.

    Rob:
    3. With each release of Java more and more of it is written in Java and it gets faster with each release. Make of that what you will.


    Well how about this, it gets faster because it doesn't have to constantly swap in and out of the JVM to run code. Logically the more Java code it runs the faster it'll get because it has to do less interfacing with a different language. Also, it'd be a kind of shit release if it didn't get faster wouldn't it.

    Rob:
    Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.

    What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

    To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.


    What is actually wrong with you? If there wasn't a JVM to start up wouldn't it be a lot faster?

    Why would anyone be stupid enough to try writing an applet in C++? It's like telling you to write a DirectX game in Java. Fucking dense.

    So is the JVM fast or slow? Maybe if they weren't writing buggy C++ they wouldn't have to get round it.
  • xtremezone 2009-05-15 11:39
    Rob:
    xtremezone:
    It's common knowledge that Java is slow.
    ...

    I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).


    It is also common knowledge that people who write in ASP.NET are talentless and brain-dead. They're all VB6 drag'n'drop muppetts who've retrained using a Learn * in 24 hours book. They didn't have the design talent to get a PHP job or the programming skill to get a job writing real applications in Java/C++/C/... They use Windows because they're soulless corporate micro-drones and aren't smart enough to use a real shell. They once tried to install Linux but were confused when they didn't have to click Start to Stop their PC.

    It turns out that 'common knowledge' isn't that reliable since one, or more, of my previous statements may be untrue.
    As a matter of fact, I'm an avid Linux user, hate Visual Basic, and hate Windows.
  • Rob 2009-05-15 12:08
    Shakje:
    Rob:
    Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.


    This is bollocks. What are you actually talking about. Idiot.


    And here we have it. Someone points out that you're a moron, but does you the service of not using the word moron and... you're off with your insults. Well, I shall hold back no more. You, sir, are a moron of the worst kind. I will answer the rest of your points below, but please note, this is purely for the interest of others. You are far too stupid to understand the reasoned discourse that has been occurring here.

    Shakje:


    Rob:
    1. Java requires AN operating system not A SPECIFIC operating system.


    Cool, same with C++ then.


    So your point is that I can compile a C++ application on Linux, test it send it to my tester friend who uses windows and after he signs it off, deploy it on Solaris? No, I didn't think so. It turns out that cross-platorm applications and potentially cross-platform source code aren't the same thing.

    Shakje:

    Rob:
    2. Point 1 isn't quite true since there are/were Java machines that had the JVM on bare metal - effectively it was the OS. This was an awful idea but, that aside, Java can run without an OS.


    Yay, go Java! Why was it an awful idea? Try and explain it without making Java sound crap. Go on.


    Why would I want to do that? I'm being honest, not a trolling moron. At the time, the JVM in use didn't provide support for real-time or near real-time garbage collection algorithms which introduced more uncertainty in some operations than was appropriate - reading system-time for example.

    Shakje:
    Rob:
    3. With each release of Java more and more of it is written in Java and it gets faster with each release. Make of that what you will.


    Well how about this, it gets faster because it doesn't have to constantly swap in and out of the JVM to run code. Logically the more Java code it runs the faster it'll get because it has to do less interfacing with a different language. Also, it'd be a kind of shit release if it didn't get faster wouldn't it.


    What swapping in and out of the JVM are you talking about you buffoon (I thought I'd throw in a little of your own language there). If you had even a vague clue what the words coming from your pea-sized brain meant you'd be twice the man you are just now (hey, I can see why you like this, you shiftless fool). Everything is inside the JVM, there is nothing else.

    Why would a new release be shit if it didn't get faster? That, like you, makes no sense.

    Shakje:

    Rob:
    Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.

    What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

    To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.


    What is actually wrong with you? If there wasn't a JVM to start up wouldn't it be a lot faster?

    Why would anyone be stupid enough to try writing an applet in C++? It's like telling you to write a DirectX game in Java. Fucking dense.

    So is the JVM fast or slow? Maybe if they weren't writing buggy C++ they wouldn't have to get round it.


    If there wasn't a JVM wouldn't it be faster? Err, no. That doesn't make any sense, you demented swine. Flash applets don't have a JVM - it is also written in C++ - and it is slower at computation than a Java applet at run-time.

    Why would it be stupid to write an applet in C++? Ohh, hold on. I see, you don't understand the words you're using. It turns out that you think the word applet means only a Java applet. Sorry, thank-you for playing on this weeks episode of "Let's see what the moron does with a keyboard".

    In some future version of Silverlight you might actually be able to write applets in managed C++.

    Shakje:
    So is the JVM fast or slow? Maybe if they weren't writing buggy C++ they wouldn't have to get round it.


    This is the core of your problem. Fast and slow are meaningless terms in this context (you worthless sack of excrement). As far as VMs go, the JVM is amongst the fastest. Is it fast enough for any particular application? That depends on the application and the hardware? Same with C++, C and ASM.

    There is no right or wrong answer. If the application is performance sensitive, is the application suitable for parallelisation, then the JVM might be good. Is the application one where memory can be allocated and de-allocated deterministically, then C++ might be good. Does the application involved only the manipulation of very primitive types with simple algorithms, then C might be best. Is it single threaded and every instruction is vital, then ASM might be best.

    Oh, and you're a fool (hadn't pointed out the obvious for a while)
  • Rob 2009-05-15 12:27
    xtremezone:
    Rob:
    xtremezone:
    It's common knowledge that Java is slow.
    ...

    I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).


    It is also common knowledge that people who write in ASP.NET are talentless and brain-dead. They're all VB6 drag'n'drop muppetts who've retrained using a Learn * in 24 hours book. They didn't have the design talent to get a PHP job or the programming skill to get a job writing real applications in Java/C++/C/... They use Windows because they're soulless corporate micro-drones and aren't smart enough to use a real shell. They once tried to install Linux but were confused when they didn't have to click Start to Stop their PC.

    It turns out that 'common knowledge' isn't that reliable since one, or more, of my previous statements may be untrue.
    As a matter of fact, I'm an avid Linux user, hate Visual Basic, and hate Windows.


    But all the rest is true? Who'd have thought it, I thought I was just making a rhetorical point. My point stands, your protestations of loathing for the technologies you spend your life working in, notwithstanding. The two points of contention about common knowledge are that it is neither common, nor actually knowledge. If it was knowledge it would be built on a demonstrable foundation, which you obviously lack.

    PS If you really hated the technologies you use, you'd get a better job, if you could.
  • xtremezone 2009-05-15 12:31
    Rob:
    So your point is that I can compile a C++ application on Linux, test it send it to my tester friend who uses windows and after he signs it off, deploy it on Solaris? No, I didn't think so. It turns out that cross-platorm applications and potentially cross-platform source code aren't the same thing.
    Java proponents have told me that in their experience, Java can behave differently on different platforms. So you still need to test it on each intended platform to be sure. The only real difference is what is cross platform: the code or the build. Sure, with Java you can theoretically build one and move it around between platforms (usually without problems, I'm sure), but building on a given platform isn't a very challenging thing. Cross compilers can make it even easier. And then the program will probably perform better than the Java equivalent would for the lifetime of that build. I can understand why some people wouldn't like that model, but personally I do.
    Rob:
    If there wasn't a JVM wouldn't it be faster? Err, no. That doesn't make any sense, you demented swine. Flash applets don't have a JVM - it is also written in C++ - and it is slower at computation than a Java applet at run-time.
    AFAIK, Flash has an interpreter the same as the JVM interprets (albeit, these days probably JIT compiles) Java byte-code. The Flash "player" is probably written in C or C++ (I don't know), but the actual implementation of Flash "programs" (I wouldn't call it a program, but you know what I mean) is done with ActionScript, which is basically ECMAScript/JavaScript.
  • code monkey 2009-05-15 12:41
    xtremezone:
    and in my experience it always performs poorly (nearly every Java app I've used has been near unusable


    This is not an issue with Java, it's an issue with the programmers who can't write a stable application. I could write a crap application in C++ that crashes all the time, but that doesn't mean that C++ performs poorly.
  • Rob 2009-05-15 12:46
    xtremezone:
    Rob:
    So your point is that I can compile a C++ application on Linux, test it send it to my tester friend who uses windows and after he signs it off, deploy it on Solaris? No, I didn't think so. It turns out that cross-platorm applications and potentially cross-platform source code aren't the same thing.
    Java proponents have told me that in their experience, Java can behave differently on different platforms. So you still need to test it on each intended platform to be sure. The only real difference is what is cross platform: the code or the build. Sure, with Java you can theoretically build one and move it around between platforms (usually without problems, I'm sure), but building on a given platform isn't a very challenging thing. Cross compilers can make it even easier. And then the program will probably perform better than the Java equivalent would for the lifetime of that build. I can understand why some people wouldn't like that model, but personally I do.
    Rob:
    If there wasn't a JVM wouldn't it be faster? Err, no. That doesn't make any sense, you demented swine. Flash applets don't have a JVM - it is also written in C++ - and it is slower at computation than a Java applet at run-time.
    AFAIK, Flash has an interpreter the same as the JVM interprets (albeit, these days probably JIT compiles) Java byte-code. The Flash "player" is probably written in C or C++ (I don't know), but the actual implementation of Flash "programs" (I wouldn't call it a program, but you know what I mean) is done with ActionScript, which is basically ECMAScript/JavaScript.


    I've been building and deploying Java applications for over ten years, building and deploying across Windows, Linux and Solaris. I've never had any problems other than people hard-coding paths with backslashes that work on windows but not *nix. So, yeah, nothing's perfect. But I've never seen any other deviations.

    Java isn't interpreted. There is no interpreter. Java is compiled to bytecode and then compiled to machine code dynamically by the JIT part of the VM. So it gets compiled twice.

    Interestingly this second part can often produce faster code than an un-tuned C++ compiler because it can make use of processor specific extensions that you couldn't , or didn't, take advantage of when performing a generic "work on as many boxes as possible" build with C++. You certainly could use the same, or similar, optimisations in many cases but not all. The JVM can optimise based on run-time behaviour that a static compiler could never see. So for instance if a loop is called with a counter that is 2 most of the time, then the HotSpot compiler can unroll that loop at run-time for increased performance.

    I'm not saying that Java is faster than C++ in general, but in some cases it is. There are now a very large number of potential deployment configurations, if you're only compiling for a single known platform you can get the best performance out of ASM, C, C++ and Java in ( probably ) that order. If you don't know the exact deployment platform hardware configuration then the runtime performance is not as clear. If you're creating general purpose apps, the number of potential deployment platforms is too large to create hardware optimised versions.

    Interestingly the .NET model where an assembly is put through an optimising compile stage at deploy time seems like a really good middle ground.
  • xtremezone 2009-05-15 13:09
    Rob:
    Java isn't interpreted. There is no interpreter. Java is compiled to bytecode and then compiled to machine code dynamically by the JIT part of the VM. So it gets compiled twice.
    The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.
  • 133tz0n3 2009-05-15 14:13
    [quote user=xtremezone]The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.[/quote]

    What a tool. You don't even know an interpreter is.

  • xtremezone 2009-05-15 14:25
    133tz0n3:
    xtremezone:
    The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.


    What a tool. You don't even know an interpreter is.
    You fail at pwning. You also fail at typing.
  • voyou 2009-05-15 19:11
    xtremezone:
    The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.


    Well, JIT-ed bytecode needs to be interpreted in order to be compiled in the sense that it needs to be "understood" and processed. But in that sense, C and assembly need to be "interpreted" too. In the more specific sense of "interpreted" we use in talking about program execution, an interpreter performs the instructions specified by the program. A JIT doesn't involve that kind of interpretation; if it did, a JIT would run the program while interpreting it, and then run the compiled version; but, obviously, a JIT doesn't require that you run every program twice.
  • xtremezone 2009-05-15 22:18
    voyou:
    xtremezone:
    The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.


    Well, JIT-ed bytecode needs to be interpreted in order to be compiled in the sense that it needs to be "understood" and processed. But in that sense, C and assembly need to be "interpreted" too. In the more specific sense of "interpreted" we use in talking about program execution, an interpreter performs the instructions specified by the program. A JIT doesn't involve that kind of interpretation; if it did, a JIT would run the program while interpreting it, and then run the compiled version; but, obviously, a JIT doesn't require that you run every program twice.
    When the terminology for interpreters first came into play the game was very different. Java and other similar strategies have greatly blurred the lines.

    Anyway, the difference is that a C/C++ program is "interpreted" and compiled once whereas Java byte-code is (AFAIK) interpreted and JIT compiled every time you run the program (on top of the original time by the developer). There's a performance penalty there at run-time, whereas for a C/C++ program, for example, that penalty is felt by the developers building it; usually not the end-user, and even if it is the end-user, it's a one time expense.
  • Rob 2009-05-16 06:19
    xtremezone:
    voyou:
    xtremezone:
    The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.


    Well, JIT-ed bytecode needs to be interpreted in order to be compiled in the sense that it needs to be "understood" and processed. But in that sense, C and assembly need to be "interpreted" too. In the more specific sense of "interpreted" we use in talking about program execution, an interpreter performs the instructions specified by the program. A JIT doesn't involve that kind of interpretation; if it did, a JIT would run the program while interpreting it, and then run the compiled version; but, obviously, a JIT doesn't require that you run every program twice.
    When the terminology for interpreters first came into play the game was very different. Java and other similar strategies have greatly blurred the lines.

    Anyway, the difference is that a C/C++ program is "interpreted" and compiled once whereas Java byte-code is (AFAIK) interpreted and JIT compiled every time you run the program (on top of the original time by the developer). There's a performance penalty there at run-time, whereas for a C/C++ program, for example, that penalty is felt by the developers building it; usually not the end-user, and even if it is the end-user, it's a one time expense.


    You're wrong, there is no interpreter. The terminology for what an interpreter is has been consistent for the best part of half a century. Interpreted programs are executed as the source - normally textual but also including other forms - is loaded. That's what an interpreter does: you wishing it was something else, so you could avoid being wrong, won't make it so.

    Java byte-code is not interpreted. Beyond that there are a number of compilers that will render Java down to native executables - but nobody uses them because ... Java performance is indistinguishable from ASM/C/C++ performance in most cases because most applications involve much slower technologies such as disks, networks and databases; CPU and/or memory limitations are only the bottlenecks in a sub-set of applications, a subset that is shrinking every year.
  • IdiotHater 2009-05-16 09:31

    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    What a bunch of tripe. It's motherfucking idiots like you that give programmers a bad name.
  • tgape 2009-05-17 15:53
    Severity One:
    Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.


    I too started programming in the early eighties. The only times I hung/crashed the first platform I really learned, I was POKEing around haphazardly. But, then the C64 had no protected memory, so that was kind of a hardware problem. Later on, I got access to Unix boxes and mainframes, and they were all rock-solid. Despite the fact I was then programming in C - the highly dangerous language you're complaining about - I never crashed the system on those. Out of hundreds of students sharing those systems, we generally only had one student-triggered OS crash per year.

    The system instability you're complaining about is more appropriately attributed to Microsoft, for the most part. While they've mostly fixed their stability issues, they're still causing problems in other areas. According to court records, they've intentionally created platform incompatibilities for the specific purpose of having platform incompatibilities. That's the whole origin of C#, if I'm not mistaken.

    Severity One:
    Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?


    Back in the beginning of this decade, I was maintaining an application which was performing poorly. I estimated to management that fixing the problem would take about 3 months of my time. They chose to upgrade the hardware, doubling the server cluster size, as it was cheaper. A year later, the workload had increased, and the system was again having performance problems. They quadrupled the size of the hardware - we had a fairly decent size server farm of Solaris boxes, so that was definitely more expensive, but they felt my time was better spent on other areas. Two years later, the hardware cost for upgrading to meet the expected needs of the next two years was over $1,000,000 US, and they approved my time to fix the application.

    In two months (I'd had time to think about the exact implementation), I'd fixed the application performance issues, reducing the program run time from O(n^2) to O(nlogn), and thus decreased the load to the point where the original hardware would have still had enough capacity - despite the fact that two of those old servers had since died. (We didn't throw out the old hardware; we repurposed it.)

    Scalability is still very important on the backend, as doubling the server size every time your 'n' increases by one is a losing game - eventually, the cost to double your server is prohibitive.
  • tgape 2009-05-17 16:20
    Shakje:
    What does compilation have to do with this? People are used to seeing slowish Java apps, I think some of that is perceived because Swing apps generally look dog [slow].


    Agreed. Although, to be honest, I consider NetBeans to be one of the slow java apps I deal with. Sure, it can generally keep up with my typing and flipping between windows and stuff just fine. However, these are *me* bound, and as such, the last computer/software combo I've used which *couldn't* handle that was a Commodore 64 running GEOS. But when you get to things like performing CVS operations on the whole project, setting up the project, running tests, and especially starting up, it's crap. Give me vim and a command-line any day - vim's esoteric, but I've learned it already.

    Shakje:
    At the end of the day it's not how fast the language is but, as you rightly say, if it is "fast enough".


    We seem to forget this far too much around here.

    Shakje:
    On the other hand if you have one stupid developer, he's less likely to do harm in your Java app.


    If you only have one 'stupid developer', and you have at least one other developer, fire your 'stupid developer'. He will do more damage in any language than his pay is worth.

    Of course, before one does this, it's probably worthwhile to do some checking on the amount of time the rest of the team spends fixing, kludging, or working around problems the 'stupid developer' creates, and just how productive the 'stupid developer' is. I've seen people who were described as "stupid developer"s have an effective work index, relative to the average group member, anywhere from about -20 hours/day to 12 hours/day. While you clearly want to get rid of the left end of that range, you also clearly want to keep the right end. However, you might want to send said developer to code legibility training...

    (The preceding paragraph depends upon having an accurate method to measure it. This can be very difficult; we only managed to measure the worst case scenario after we got rid of the guy - but it was pretty clear he was an issue. Since then we learned a bit, but it's still never easy.)
  • tgape 2009-05-17 16:26
    SomeCoder:
    I guess it depends on what the system is supposed to do. If you are writing something that is to run on a Windows machine and mostly likely have to share resources with other programs being open at the same time, I'd rather you work a little slower and use the RAM more efficiently so I can still have some left over for other programs that I may be running at the same time.

    On the other hand, if you are writing a system that is going to run in Unix and needs to crunch a lot of data very quickly, I see no reason to try and be efficient with memory.


    WTFlyingF? Historically, I've seen a *lot* more dedicated-purpose Windows boxes than I have dedicated-purpose Unix boxes - despite the fact I'm a Unix admin, not a Windows admin.

    In any event, I typically find that either system allocates new memory much quicker than it swaps in old memory. I also find the free-pool reuse capabilities of every program I've encountered to be pathetic - I believe this is inherently true, but I do not have a proof for it.

    So, if you can guarantee that a program will entirely fit within memory, and there won't be other large-memory programs competing with it, you may get better performance without worrying about memory usage. That having been said, I've seen a lot of large-memory algorithms which like to move their large data pools around, and this fundamentally scales horribly.

    For example, I've seen quite a few programs which read in an entire file into memory - say, for example, a 2M file. They then process the first line of the file, and then shift the rest of the file forward in memory, to clear off the first line. Repeat. If one rewrote the algorithm to read in a single line at a time, so it didn't have to shift the memory, assuming that the file is not just two lines long, it'll run faster. If the lines average less than 160 characters, it'll run a *lot* faster. Note that the programs that behave as I've described here are generally written in pointer-free languages, so they can't just simply shift the char pointer forward.
  • rodgerlvu 2009-05-18 01:23
    Java does suck... The language semantics are a bitch (I wouldn't consider it quick to write, though perhaps I just have to learn "the Java way" first), the code is ugly (I wouldn't call it maintainable), and in my experience it always performs poorly (nearly every Java app I've used has been near unusable).

    I think C++ is probably still my favorite language to write, but I can understand one's need for a higher level language. C#/.NET (i.e., they were developing in Visual C++ anyway) would have been my boots, not Java. Although I doubt Mono is considered enterprise ready yet and it sounds like these projects were going to be running on UNIX platforms (a good thing).

    When I think of software to manage transportation for an entire country (even a relatively small one) I think of limited scope and high performance. So C++ sounds like a reasonable tool to use, unless they were specifically going to be building clients or something for the backend system.
  • Severity One 2009-05-18 03:20
    xtremezone:
    I've heard Java zealots claim that in practice Java often needs to be tailored to a specific machine too. Write once, run everywhere isn't quite so clear cut in practice.

    In that case, you've been listening to people who know crap about programming. Bear in mind that this site is dedicated to people who make stupid mistakes when writing programs, and this happens in all languages, including Java.

    We've had exactly one case where an application behaved slightly differently between Windows and Solaris, and this was when we were load-testing a web service proxy/auditing tool that I'd written. We're still not clear whether it was a bug in the JVM, or a setting in the operating system. For the rest, there have been no cases of applications not working on another platform, other than silly mistakes like hard-coded paths or path separators.

    You can, however, take C++ from one machine to another without much extra work if your team is aware of platform specifics and everybody writes platform independent code (and all libraries used are either platform independent or equivalent functionality is pulled from platform specific libraries for all supported platforms). It isn't like C++ needs to be completely rewritten in order to work on another machine. There's nothing platform specific about C++, the language. It's the compiler implementations and operating systems that bring the specifics. And that stuff can easily be wrapped up just like Java wraps it. Reusing stable and powerful platform independent frameworks can really save you a lot of work.

    Begging your pardon, but what sort of frameworks are we talking about that will easily take an application that uses databases from, say, Windows to Linux? Let alone graphical applications; I've tried getting Qt applications to work on Solaris, and given up.

    If you just do standard I/O and maybe CGI, you can write code that easily compiles on both Windows and Unix. Many years ago, I've written a PHP-like interpreter that did just that. But as soon as you want to do more (say, network sockets), you're out of luck.

    In practice it usually isn't as convenient as Java, sure, but then again the end result is hopefully software that greatly outperforms the equivalent Java software and is that much more user-friendly for it. I hate waiting for computers to do things and therefore expect applications to perform as quickly as possible. Especially applications that I use a lot. Perhaps the way we use computers differs.

    'Hopefully' indeed. But would you say that using a toolkit like Qt (because otherwise you'd have to totally rewrite your user interface code) is much more user-friendly than a Swing application? That's a novel way of looking at things.

    The right tool for my jorb right now is ASP.NET. I never said to use C/C++ (or other native alternatives) for everything.

    Hang on a second. You write applications that run in the CLR, and you are complaining about the JVM? WTF are you on about then? Happy happy that you can spend 'six months on an application' so it may run a bit faster, but in reality you're writing contact forms on web sites?

    Oh my (insert favourite deity here).

    I wonder what your machine specs are. I haven't used NetBeans in about a year or two, but when I used it it was nearly unusable on decent hardware (albeit, it ran MUCH better in Linux than Windows). I spent much of my Java classes in college wishing it had been written in a native language.

    A Dell D620 laptop, with a T2300 Core Duo (not Core 2 Duo) CPU running at 1.66 GHz, and 2 GB of RAM, driving a screen in 1680x1050 resolution.

    It's common knowledge that Java is slow. I don't need to prove it. Anybody that doesn't believe me can install it and find themselves a nice Java application to use. Obviously a zealot will deny this. And maybe the Java applications that you use aren't slow. I don't know. The ones I've used have been.

    From all the comments I've seen on this site, this must be a contender for the most uninformed one. It used to be common knowledge that the sun revolved around earth, and that you tell somebody's character from the shape of his head.

    'It is common knowledge' doesn't cut it. You'll have to come up with something better.

    Slow is a relative term anyway. As somebody said earlier (maybe you, maybe not), on the backend you can throw hardware at it to make it perform adequately. Most users don't know what's happening in the backend and only experience the Java running on their own hardware. Even if the backend is fast because of lots of hardware, there are usually many many frontends that you don't have control over (and couldn't afford to anyway) that need to interface with the backend. If those are all written in Java, hardware might not be available to solve the problem.

    By all means, if you can afford to make your Java applications perform well with hardware on the backend, go for Java. I don't care what you use on the backend as long as it performs well and works correctly. However, unless you're going to buy me an uber powerful gaming rig to use your frontend, write it in something less wasteful so it doesn't hog all my system's resources.

    But I've never said that Java would be the solution for everything, and it obviously isn't. However, you, on the other hand, have pretty much claimed that Java is useless, purely based on the speed argument.

    And even that I have my sincere doubts about. You've looked at old versions of Netbeans, you've written code in college on even older Java versions... things have moved ahead over the years.

    I was pretty sceptical about Java, too, after my first experiences. But then I wrote my first application (using EJB, Java WebStart, Swing and what else), and I've never looked back since. It allows me to write better code.

    I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).

    In which case, your argument about running time being more important than development time can pretty well be chucked in the rubbish bin, because the company you work for will have to make a profit, just like everybody else.

    I never said to use C/C++/D/etc. for everything. However, there is absolutely a time to use it and IMHO the use for Java is a relatively small niche. Again, that's based on my personal experience running Java applications which obviously isn't like yours because you love it.

    It gets the job done, and with less hassle than everything else I've tried. If it has to be big, multi-tiered, interfacing with a lot of systems, Java is (for me at least) the way to go. If it is simple and can be done quickly, I use Perl. And if I need to decode a binary file such as BER, I use C. It just so happens that most things I do involve talking to databases and multiple systems, and Java is just very good at that.

    IMHO, the vague description the article gives doesn't give us enough information to make a technology decision. By the sound of it, the system will handle lots of data for an entire country and won't change much once written. To me, that sounds like a good candidate for native programs. I don't know that obviously. I know next to nothing about what this particular contracted company was being considered for. You don't know that Java was the right tool either though.

    Somebody made the choice for Java, though. Given that it would run the public transport for an entire country, we're probably talking about a lot of nodes (in which case Windows boxes would mean a lot of licences), a lot of inter-node communications, interfacing with legacy systems, and a lot of databases. These are all things that Java is very good at. All the things it needs to be doing are limited by network and database speeds.

    But given that you've probably never written an application that is seriously big, or constitutes an infrastructure, you probably cannot appreciate the advantages that a platform like Java (rather than a language like C++) has to offer under these circumstances.
  • Schlong 2009-05-18 08:20
    What a dick.
  • rodger 2009-05-19 01:02
    SomeCoder:
    I've seen the Quake 2 port from C to C++.NET (CLR). It was quite a bit slower but in practice it was at least playable. The framerate suffered more than I would have liked for a video game though

    There's also a port of Quake 2 for Java. Can't remember where it was, but it was pretty scary-awesome - click a link, JWS pops up, you tell it where your Quake2 data lives, boom, you get a pretty decently working Q2.
  • xtremezone 2009-05-19 11:52
    Severity One:
    But as soon as you want to do more (say, network sockets), you're out of luck.
    Actually, WinSock is basically Berkeley Sockets with a new name and a few minor differences (at least, from what I've heard and what I've done). It's very easy to wrap it up if you know you plan to be doing it. For example, in Windows, you have closesocket instead of close. You can probably use a simple macro to fix that problem,...
    #ifndef WINDOWS
    
    #define closesocket close
    #endif

    ...but even if you can't, it isn't all that complicated to get around it with the preprocessor.

    Beej's Guide To Network Programming (arguably the best socket guide available on the Web) has a section explaining the minor differences.

    GUI programming is surely one place where things get much more complicated to port (hell, even just writing a GUI application for a single platform can be a pain), but unfortunately some of those applications are the ones that benefit most from being native builds because workstation users like to use many of them all at the same time for extended periods of time (the exception being short utility programs which are fine written in interpreted or JIT compiled languages because you probably only use it for a minute now and then anyway).

    X Windows has been ported to Windows, but I don't have any experience writing X software so I can't say what the porting concerns are. Obviously it's nice to keep a native look/feel, but that's something that Java frameworks don't seem to like to do by default anyway.
    Severity One:
    Hang on a second. You write applications that run in the CLR, and you are complaining about the JVM? WTF are you on about then? Happy happy that you can spend 'six months on an application' so it may run a bit faster, but in reality you're writing contact forms on web sites?

    Oh my (insert favourite deity here).
    I didn't get to choose the technology. :P In my experience, though, .NET applications (on Windows, at least) perform better than Java applications (though you must have missed it earlier where I said that ASP.NET has been performing poorly IMHO, so either we're doing something wrong or it suffers the same problems, even on Windows).
    Severity One:
    But given that you've probably never written an application that is seriously big, or constitutes an infrastructure, you probably cannot appreciate the advantages that a platform like Java (rather than a language like C++) has to offer under these circumstances.
    You are correct. Maybe when I do my appreciation will change. :P Maybe not. Speed is really only one of my problems with Java. I'm also not a fan of the language (probably just because I'm too used to C/C++, and they are quite different) and I'm also not a fan of Java formatting styles, which makes pretty much any code not written by me illegible (which can honestly be said for most languages, as most people don't care too much about style, but I digress...).
  • Single User 2009-05-19 14:44
    xtremezone:

    Speed is really only one of my problems with Java.

    And it really is not a problem. Yes, most of the time Java is slower than native code produced by a good compiler, and if you need hard performance guarantees, you write C or Assembly anyway. But for the vast majority of apps, the speed difference doesn't matter, since most of the time they're waiting for some I/O to happen, so you can write them in Java, C#, Python, Erlang, Haskell, C, Ruby, whatever is the best compromise between your taste and the problem's demands.
    I'm also not a fan of the language (probably just because I'm too used to C/C++, and they are quite different)

    So you don't like the language because it's different? You must really love your work with ASP.Net then. Or is it rather that you don't like Java because it's not different enough?
    and I'm also not a fan of Java formatting styles, which makes pretty much any code not written by me illegible

    What styles are you referring to? Will we have another flamewar about the one true brace style? Or don't you like upper case class names and lower case method names? camelCase? Long variable names?
    (which can honestly be said for most languages, as most people don't care too much about style, but I digress...).

    Now that makes me suspect that others may find code written by you illegible. I may err, but "everybody but me does it horribly wrong" is usually a good indicator.
  • antred 2009-05-20 13:30
    xtremezone:
    For example, in Windows, you have closesocket instead of close. You can probably use a simple macro to fix that problem,...
    #ifndef WINDOWS
    
    #define closesocket close
    #endif

    ...but even if you can't, it isn't all that complicated to get around it with the preprocessor.


    Mucking around with the preprocessor to solve this is probably the worst solution you could possibly come up with. Just hide the WINSOCK/Berkely sockets API underneath a wrapper and have that wrapper call either the Windows or the UNIX variant of the function based on whether you're compiling on Windows or UNIX. In C++, the preprocessor is best left alone unless there's a very good reason to use it.
  • xtremezone 2009-05-20 13:45
    antred:
    Mucking around with the preprocessor to solve this is probably the worst solution you could possibly come up with. Just hide the WINSOCK/Berkely sockets API underneath a wrapper and have that wrapper call either the Windows or the UNIX variant of the function based on whether you're compiling on Windows or UNIX. In C++, the preprocessor is best left alone unless there's a very good reason to use it.
    One way or another you need the preprocessor to do it (even if you hide it in a wrapper). You don't need to define a macro for it, which is what I was getting at with "...but even if you can't, it isn't all that complicated to get around it with the preprocessor." You could just simply call the appropriate routine for each given platform. Still need the preprocessor though. ;) The processor is good. It's macros that can be bad.
    void my_close_socket(int s)
    
    {
    #ifdef WINDOWS
    closesocket(s);
    #else
    close(s);
    #endif
    }
  • xtremezone 2009-05-20 14:16
    Single User:
    But for the vast majority of apps, the speed difference doesn't matter, since most of the time they're waiting for some I/O to happen, so you can write them in Java, C#, Python, Erlang, Haskell, C, Ruby, whatever is the best compromise between your taste and the problem's demands.
    Most of them are doing many things at once, one of them being waiting for I/O, but others being responding to I/O and other tasks that the application does. Few applications these days are single-task applications. There is usually something being done, even when waiting for I/O, except for single-task applications (and I don't use many of those outside of the command-line).
    Single User:
    So you don't like the language because it's different? You must really love your work with ASP.Net then. Or is it rather that you don't like Java because it's not different enough?
    C# isn't as different as Java is. It even supports more syntactic sugar than C++ does, making the code cleaner at times. Java for the most part supports less, making the code more verbose, at least IMHO. Obviously, Visual Basic is way worse than Java...
    Single User:
    What styles are you referring to? Will we have another flamewar about the one true brace style?
    That's my main gripe.
    Single User:
    Now that makes me suspect that others may find code written by you illegible. I may err, but "everybody but me does it horribly wrong" is usually a good indicator.
    /*
    
    * Double lines are single lines emphasized by Alex... >_>
    */


    #include <cstdlib>
    #include <iostream>

    void func1(void);
    void func2(int);

    int main(int argc, char *argv[])
    {
    if(argc > 1)
    {
    std::cout << "Args: " << argv[1];

    for(int i=2; i<argc; i++)
    std::cout << ' ' << argc[i];

    std::cout << std::endl;
    }

    func1();
    func2(argc - 1);

    return EXIT_SUCCESS;
    }

    void func1(void)
    {
    std::cout << "This program will measure your personality based on "
    "how demanding you are." << std::endl;
    }

    void func2(const int argc)
    {
    if(argc == 0)
    std::cout << "Pushover." << std::endl;
    else if(argc < 3)
    std::cout << "We can work with that." << std::endl;
    else if(argc < 5)
    std::cout << "Little pushy, aren't we..." << std::endl;
    else
    std::cout << "Fuck. That. Shit. Do it yourself." << std::endl;
    }

    Tabs to indent (I usually use spaces on the Web because of the default behavior of the tab key and the uncertainty for how a particular Web site will handle them), spaces to line up.
  • Single User 2009-05-20 14:59
    xtremezone:
    Obviously, Visual Basic is way worse than Java...

    :D
    Single User:
    What styles are you referring to? Will we have another flamewar about the one true brace style?
    That's my main gripe.
    Single User:
    Now that makes me suspect that others may find code written by you illegible. I may err, but "everybody but me does it horribly wrong" is usually a good indicator.

    [snip code]
    Tabs to indent (I usually use spaces on the Web because of the default behavior of the tab key and the uncertainty for how a particular Web site will handle them), spaces to line up.

    Okay, if that's your usual coding style, the indicator misfired :)
    I prefer the other brace style, but I'm not religious about it.
    I like braces around if-branches even if they're a single statement, but I can bear their absence.
    Tabs, however, are pure, unadulterated evil.
  • antred 2009-05-21 03:34
    Single User:
    Tabs, however, are pure, unadulterated evil.


    No, tabs are the only correct way to indent. Let the space fools rot in hell. :p
  • xtremezone 2009-05-21 12:55
    Single User:
    Tabs, however, are pure, unadulterated evil.
    What tabs do is allow the user to configure their editor to display indentation however they want. You can set them to 2, 3, 4, 8, 32, etc., spaces and all properly indented code should look right (to you, at least...). With spaces, everybody is stuck with the original programmer's preference, which may be OK or might be horrible.

    The only problem with tabs is that they don't line up well with single-space character data. Therefore, tabs are best for indentation, but spaces are best for lining things up.

    For example, with [--] representing a tab character and spaces representing spaces, this is how func1 and func2 from the above code would be intended:
    void func1(void)
    
    {
    [--]std::cout << "This program will measure your personality based on "
    [--] "how demanding you are." << std::endl;
    }

    void func2(const int argc)
    {
    [--]if(argc == 0)
    [--][--]std::cout << "Pushover." << std::endl;
    [--]else if(argc < 3)
    [--][--]std::cout << "We can work with that." << std::endl;
    [--]else if(argc < 5)
    [--][--]std::cout << "Little pushy, aren't we..." << std::endl;
    [--]else
    [--][--]std::cout << "Fuck. That. Shit. Do it yourself." << std::endl;
    }

    That should look right no matter how you have tabs configured in your editor.

    I find that using spaces for indentation makes me crazy. I never know when I'm going to skip one character or 4 and need to pay extra attention and it slows me down. Tabs are also better supported (you might not be able to configure how many spaces wide they are, but they'll work in pretty much any text editor whereas spaces require a ton of extra typing in editors that don't support smart indentation).
  • Single User 2009-05-21 14:08
    xtremezone:
    Single User:
    Tabs, however, are pure, unadulterated evil.
    What tabs do is allow the user to configure their editor to display indentation however they want. You can set them to 2, 3, 4, 8, 32, etc., spaces and all properly indented code should look right (to you, at least...).

    Unfortunately, many people don't indent properly, but mix tabs and spaces. That doesn't look right if your tab setting is different from theirs.
    The only problem with tabs is that they don't line up well with single-space character data. Therefore, tabs are best for indentation, but spaces are best for lining things up.

    You've never programmed in Haskell or Python, have you?
    Tabs can do worse things than make the code look funny there.

    That being said, the above remark may not have been made in absolute earnest.
  • xtremezone 2009-05-22 10:56
    Single User:
    Unfortunately, many people don't indent properly, but mix tabs and spaces. That doesn't look right if your tab setting is different from theirs.
    If a guy can't even handle proper indentation then you better get him the fsck away from teh c0d3z! :P
    Single User:
    You've never programmed in Haskell or Python, have you?
    Tabs can do worse things than make the code look funny there.

    That being said, the above remark may not have been made in absolute earnest.
    Don't you have to indent with tabs in Python? :P (I've never actually learned it before... Maybe I will now... :P)
  • Single User 2009-05-22 12:19
    xtremezone:
    Single User:
    Unfortunately, many people don't indent properly, but mix tabs and spaces. That doesn't look right if your tab setting is different from theirs.
    If a guy can't even handle proper indentation then you better get him the fsck away from teh c0d3z! :P

    If only I could...
    Don't you have to indent with tabs in Python? :P (I've never actually learned it before... Maybe I will now... :P)

    No, the preferred way is spaces:
    Guido van Rossum, Barry Warsaw:

    Indentation

    Use 4 spaces per indentation level.

    For really old code that you don't want to mess up, you can continue to
    use 8-space tabs.

    Tabs or Spaces?

    Never mix tabs and spaces.

    The most popular way of indenting Python is with spaces only. The
    second-most popular way is with tabs only. Code indented with a mixture
    of tabs and spaces should be converted to using spaces exclusively. When
    invoking the Python command line interpreter with the -t option, it issues
    warnings about code that illegally mixes tabs and spaces. When using -tt
    these warnings become errors. These options are highly recommended!

    For new projects, spaces-only are strongly recommended over tabs. Most
    editors have features that make this easy to do.
  • antred 2009-06-01 13:03
    Single User:

    You've never programmed in Haskell or Python, have you?
    Tabs can do worse things than make the code look funny there.


    I code in Python quite a bit, and tabs for indenting work JUST FINE in Python. :)
  • antred 2009-06-01 13:09
    Advising against the use of tabs for indenting on the grounds that you might end up mixing them with spaces is akin to advising against the use of pointers because you might end up trying to dereference a null pointer.

    Anyone who mixes spaces and tabs is a fool. Use tabs the RIGHT WAY (i.e. tabs to indent, spaces to align ... if you absolutely must align things), and tabs beat spaces hands down because that way you're not forcing your personal tab-width preference on everybody else.

    The fact that some crappy editors do not handle tabs correctly is NOT a reason to be a space-indenting fascist scumbag. :P
  • Ilya Ehrenburg 2009-06-01 13:34
    antred:
    Single User:

    You've never programmed in Haskell or Python, have you?
    Tabs can do worse things than make the code look funny there.


    I code in Python quite a bit, and tabs for indenting work JUST FINE in Python. :)

    Sure, just don't mix tabs and spaces.
    If you're maintaining space-indented code, don't use any tabs; if you're maintaining tab-indented code, don't indent with spaces.
    If you're maintaining mixed-indented code, isn't there such a thing as justifiable homicide?
  • beavis 2009-09-24 00:55
    That is odd because memory allocation and deallocation is 5-10 times faster than C or C++ and a good chunk of nearly any programs execution time is spent in these two tasks.
  • beavis 2009-09-24 01:12
    [quote]
    I'm not sure where you would want to pass by value in Java... [/bold]

    Are you serious?

    Java uses pass by value and only pass by value.

    What Java call references are nothing more than implicit pointers, and once more, they are only passed by value.

    The ignorance on this thread is astounding.
  • beavis 2009-09-24 01:18
    Franz Kafka:
    Jim S.:
    That would be jake.


    And for the comments about pass by reference vs. pass by value:

    Java passes *everything* by value. End of story.

    Explanation in mind-numbing detail can be found here


    This is true, however the value is an object ref, so it behaves much like pass by ref.


    Only if the object is mutable! Geez, it is always jackasses without the first clue about Java that rail against it.
  • beavis 2009-09-24 01:20
    ell0bo:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?


    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.


    This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.


    Java threads do not fork processes.
  • beavis 2009-09-24 01:41
    xtremezone:
    Severity One:
    Now I know you're trolling, but that doesn't give you a right to become downright offensive. So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?

    Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.

    Between then and now I've worked with Z80 assembler, 8088 assembler, 68000 assembler, several flavours of BASIC, (Turbo) Pascal, C on MS/DOS, C on the Amiga, C on Unix, C++ on Unix, Perl, Bourne Shell and a bunch of others that aren't worth mentioning. And Java, of course.

    There's no way that I'll ever go back to an environment where I have to spend time on things that a computer could do for me, like all the things a JVM does for me. I've got better things to do.
    I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.

    I don't find myself getting caught by those kinds of bugs very often. I find it's relatively easy to track them down. I'm sure you're aware that debuggers and stack traces exist for native programs...

    As for security, I'm not sure if you mean system security or application security, but operating systems are fully capable of handling system security (i.e., what memory addresses and/or resources your program can access) and I don't really see a difference between application security in C++ and Java applications (with the possible exception of buffer overruns, etc., in poorly written native code).
    Severity One:
    And abstraction, yes, that's important too. Try writing an application on a Windows system that you test with a MySQL database, and then port it to Solaris with Oracle. If you're using something like Hibernate to abstract the database engine, you don't even need to change your SQL queries and recompile.
    Absolutely. Abstraction is a good thing. There's nothing preventing abstraction from being written into C++ though. The reason C++'s standard library is so lacking is mostly because of its age. There are libraries and frameworks to fill in the gaps. Boost has a ton of functionality, though I'm not sure what exists for data layer abstraction.
    Severity One:
    Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?
    No, the time I spend USING is more important than the time I spend developing and it's related to CPU time. I don't care if it takes me 6 months to develop an application if it does what I need efficiently for the next 3 years.

    Time adds up quickly. I don't know about you, but if I could somehow count the time wasted on slow Java applications it would probably amount to a lot of wasted time.

    And development time is directly affected by CPU time as well. You can only test an application's functionality as quickly as it can run. So if it takes more time to run then it will take you more time to test.

    Maybe you need Java to hold your hand, but I don't. There is absolutely a time to use RAD tools and interpreted programs can be useful to get something simple done quickly, but personally for something that myself or others will be using a lot, I think it's worth the development time to build an efficient native program (even if you decide to prototype it in Java first).


    You are funny, I guess you didn't know that memory allocation and deallocation is considerably faster in Java.

    There are many java programs that beat the living snot out of C and C++, and vice versa. Your ignorance does not change that.
  • beavis 2009-09-24 02:08
    antred:
    Advising against the use of tabs for indenting on the grounds that you might end up mixing them with spaces is akin to advising against the use of pointers because you might end up trying to dereference a null pointer.

    Anyone who mixes spaces and tabs is a fool. Use tabs the RIGHT WAY (i.e. tabs to indent, spaces to align ... if you absolutely must align things), and tabs beat spaces hands down because that way you're not forcing your personal tab-width preference on everybody else.

    The fact that some crappy editors do not handle tabs correctly is NOT a reason to be a space-indenting fascist scumbag. :P


    You must not know Python. Mixing spaces and tabs will cause your program to crash. Whitespace matters a lot in Python.
  • kickback 2009-10-10 12:50
    If you think javas slow or hard to maintain, it means your not competent in it.
  • D&G Ladies Leather Watches 2010-09-27 23:13
    unless you should concerning lAmid A smeach particular, certain equally discount Womens Watches though anyhow having the status of Jaquet Droz Watches Les Lunes, you surround come on the road on the road that the apposite stance. Cartier Watches Montres 21/Chronoscaph offers a deep get hold of of brin addition-name Audemars Piguet Watches Ladies Collection - Danaé at bizarre regards.we hope the so as topgreatest timbre of watch replicas friendly, in force type by the adjoining of side as well as the manufacturers to infer the most straight middling to repeat each one tyle, prepared of towering appraise equipment, afterward also species consideration. we retain crowd very inflexible quality stas well asards & material rudder to all suppliers.
    our Jaquet Droz Watches Les Lunes and Womens Watches are in effect the awfully as the primary ones having the status of including the welcoming price, high quality materials and imposing workmanship. sell Breitling Watches Aeromarine Collection - Colt Automatic is also publicized.
    our aim is to reserve you with first sort services as well as preeminent impressions watches, and issue your online shopping skill a wonderful one.9088232343002
  • cindy 2011-03-02 09:54