Slashdot Mirror


If Java Is Dying, It Sure Looks Awfully Healthy

Hugh Pickens DOT Com writes "Andrew Binstock writes at Dr. Dobb's that a recurring prejudice in the forums where the cool kids hang out is against Java, often described as verbose and fading in popularity but Binstock sees little supporting evidence of Java being in some kind of long-term decline. While it is true that Java certainly can be verbose, several scripting languages have sprung up which are purpose-designed to spare developers from long syntactical passages to communicate a simple action, including NetRexx, Groovy, and Scala. As far as Java's popularity goes, normally, when technologies start their ultimate decline, tradeshows are the first to reflect the disintegrating community. But the recent JavaOne show was clearly larger and better attended than it has been in either of the last two years and vendors on the exhibiting floor were unanimous in saying that traffic, leads, and inquiries were up significantly over last year. Technically, the language continues to advance says Binstock. Java 8, expected in March, will add closures (that is, lambda expressions) that will reduce code, diminish the need for anonymous inner classes, and facilitate functional-like coding. Greater modularity which will be complete in Java 9 (due in 2016) will help efficient management of artifacts, as will several enhancements that simplify syntax in that release. 'When you add in the Android ecosystem, whose native development language is Java, it becomes very difficult to see how a language so widely used in so many areas — server, Web, desktop, mobile devices — is in some kind of decline,' concludes Binstock. 'What I'm seeing is a language that is under constant refinement and development, with a large and very active community, which enjoys a platform that is widely used for new languages. None of this looks to me like a language in decline.'"

577 comments

  1. Wake me up... by Anonymous Coward · · Score: 0, Troll

    Wake me up when java supports unsigned integers. Until then it's not a real language.

    1. Re:Wake me up... by nitehawk214 · · Score: 5, Insightful

      Wake me up when netcraft confirms it. Until then it's not dying.

      --
      I'm a good cook. I'm a fantastic eater. - Steven Brust
    2. Re: Wake me up... by DVega · · Score: 2

      It has an unsigned 16 bits integer. It is called "char"

      --
      MOD THE CHILD UP!
    3. Re:Wake me up... by stewsters · · Score: 5, Informative

      The great part about Java is that there are so many libraries for it.

      http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/primitives/UnsignedInteger.html

    4. Re:Wake me up... by Anonymous Coward · · Score: 5, Informative

      Wake me up when java supports unsigned integers. Until then it's not a real language.

      Python, Perl, and Ruby are examples of other languages that don't support unsigned integers. These languages are independent of the underlying hardware and automatically upsize the integer to handle larger value. You can always use the AND operator to convert to an unsigned integer for C calls. (e.g. var & 0x0FFFFFFFF).

      You're not a real programmer if you can't adapt to the lack of unsigned variables.

    5. Re:Wake me up... by binarylarry · · Score: 3, Interesting

      You should tell John Carmack about your theory, I bet he'd be really interested:

      https://twitter.com/ID_AA_Carmack/status/85734195644727297

      --
      Mod me down, my New Earth Global Warmingist friends!
    6. Re:Wake me up... by BreakBad · · Score: 4, Insightful

      You're not a real programmer if you can't adapt to the lack of unsigned variables.

      BOOM

    7. Re:Wake me up... by frinkster · · Score: 5, Insightful

      You're not a real programmer if you can't adapt to the lack of unsigned variables.

      Forget about being a "real programmer" and focus on being a "real developer.' There are functional requirements and then there are technical requirements. Functionally speaking, how important is it to have an unsigned data type rather than having the equivalent data type and enforcing a "no negative values" rule? I'm not sure I can think of any, aside from the case of being able to interpret unsigned data types for interoperability. But that says nothing about the need for the actual storage of that data.

      I'm pretty sure that some respected Computer Scientist said something about premature optimization....... It's a good rule. Focus on meeting the functional requirements of the system you are developing, and then optimize where it makes sense. I don't think you are going to notice the lack of unsigned data types. But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

    8. Re:Wake me up... by Anonymous Coward · · Score: 0

      You're not a real programmer if you can't adapt to the lack of unsigned variables.

      So I am not a real programmer. But how about some choice. Why would I be calling an 0x0FFFFFFF masking operation everywhere in my program, if I don't have to do that in C? Just because some language programmers are so lazy they don't want to think about speed, doesn't mean I have to use their slow language. It's just sad.

    9. Re:Wake me up... by Anonymous Coward · · Score: 0

      Wake me up when java supports unsigned integers. Until then it's not a real language.

      Python, Perl, and Ruby are examples of other languages that don't support unsigned integers. These languages are independent of the underlying hardware and automatically upsize the integer to handle larger value. You can always use the AND operator to convert to an unsigned integer for C calls. (e.g. var & 0x0FFFFFFFF).

      You're not a real programmer if you can't adapt to the lack of signed variables.

      there, fixed it for you.

    10. Re:Wake me up... by petermgreen · · Score: 4, Insightful

      I'm pretty sure that some respected Computer Scientist said something about premature optimization

      I think there is a balance to be struck, putting too much effort into optimising early on is a waste of time but that doesn't mean that languages that make inefficient soloutions easy and efficient soloutions painful are a good thing. Unsigned types are just one of many cases where java does this.

      Unsigned types are a good thing for several reasons.

      1: They are easier to bounds check. If you have an unsigned type you only have to worry about making sure it is not too large. If you only have a signed type then you either have to make sure all your bounds checks cover the negative case or be very careful not to accidently generate negative values.
      2: They can store values twice as large. Sometimes that is the difference between fitting the number you want in one size of data element and being forced up to the next size (which is likely to double your memory requirements).
      3: Some algorithms (particulally in crypto) are designed arround unsigned integers of a specific size.
      4: the interoperability requirement you mention. Sometimes you have to work with another system where it has been decided by someone outside your project that say a 32-bit signed integer is sufficient.

      Don't get me wrong all these things CAN be worked arround but those workarrounds mean lower efficiency AND more potential for mistakes.

      P.S. Java does have an unsigned 16 bit integer type despite lacking unsigned 8 , 32 and 64 bit types. It calls that 16 bit unsigned type "char".

      But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

      Mixing languages adds extra complexity, especially with stuff like java. So IMO a good critera for a language is what range of "levels" it can cover without having to resort to mixing languages.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    11. Re:Wake me up... by Anonymous Coward · · Score: 0

      [quote]
      I don't think you are going to notice the lack of unsigned data types.
      [/quote]
      Say what :)
      [quote]
      But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.
      [/quote]
      Well, there it is. If you need to address a serious problem, don't use a language that can only do signed integers. Including Java.

    12. Re:Wake me up... by hammyhew · · Score: 3, Funny

      You're not a real programmer if you can't adapt to the lack of unsigned variables.

      You're not a True Programmer unless you use Gamemaker! Return! Return! Return! Return!

      Return...TO GAMEMAKERDOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOM!

    13. Re:Wake me up... by Anonymous Coward · · Score: 0

      > 0x0FFFFFFFF ...
      0x7FFFFFFF
      dammit. You're not really a programmer if you fail basic hex

    14. Re: Wake me up... by Anonymous Coward · · Score: 0

      Hey great 80s computing all over again :)

    15. Re:Wake me up... by RabidReindeer · · Score: 4, Informative

      "unsigned integers" are an artefact of "bit twiddling" programming languages. Bit twiddlers are essentially high-level assembly language.

      Java is not an assembly language, it is an abstract language. It is intended to create write-once/run-anywhere code that isn't dependent on the CPU or OS, byte/bit orders or how many bits are in an "unsigned integer".

      Most programmers actually use "unsigned integer" to refer to a collection of bits, not actually as a mathematical unsigned integer (cardinal number), just as they erroneously refer to characters interchangeably with "bytes".

      If you really DO want to work with cardinal numbers in Java, just don't use negative values. A java int can hold a respectably large integer value. And if that's not big enough, there are special classes that are more or less open-ended.

      If you absolutely positively must work with 100%-guaranteed cardinal numbers, use Ada, which allows user-defined types to contain user-defined ranges that will be checked at compile time and enforced at run time and that includes integers whose range is from 0..whatever. Of course, there's a price to be paid for that.

    16. Re:Wake me up... by robmv · · Score: 1

      Java 8, Unsigned Integer Arithmetic API, not an unsigned type but helps doing integer arithmetic using signed types

    17. Re: Wake me up... by KiloByte · · Score: 1

      On the other hand, it has no type meant to store a single character that is capable of doing so.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    18. Re:Wake me up... by VGPowerlord · · Score: 4, Insightful

      1: They are easier to bounds check. If you have an unsigned type you only have to worry about making sure it is not too large. If you only have a signed type then you either have to make sure all your bounds checks cover the negative case or be very careful not to accidently generate negative values.

      So, what does your code do if an end-user passes -1 which would get stored in your unsigned value? And as a reminder, your argument is that you don't have to do bounds checking for the lower bound.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    19. Re: Wake me up... by gnasher719 · · Score: 1

      On the other hand, it has no type meant to store a single character that is capable of doing so.

      But then no language has. In C++, std::string is the simplest thing guaranteed to store any single character.

    20. Re:Wake me up... by interval1066 · · Score: 1

      It would be nice if java supported something like typedefs.

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    21. Re:Wake me up... by MightyMartian · · Score: 1

      For something that's not a "real" language, it certainly seems to have significant penetration in the enterprise.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    22. Re:Wake me up... by 0xdeadbeef · · Score: 1

      But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

      Yeah, that worked real well when j2me was the only game in town. The phone companies were so amenable breaking out of the sandbox.

      As one of those "real programmers" who did work around the sign bit for bignum math, I laugh at you and the anonymous retard above, who didn't even get the bitmask right. Being able to work around other people's stupidity is something that "real programmers" can do, but it isn't something that makes them a "real programmer".

    23. Re:Wake me up... by geminidomino · · Score: 1

      So do Microsoft Access (or, gods help us all, Excel) "databases" and PHP.

      Talk about damning with faint praise.

    24. Re:Wake me up... by MouseTheLuckyDog · · Score: 2

      Unsigned integers are not just for optimization.

      I remember as a young pup writing a part of a program which suddenly crashed in certain circumstances but not on NT only in Win95.
      Of course the problem was not detected until the program was out in the field because all the developers used NT.

      I was using memory mapped IO. At one point I was reading from I something in an array of variable size. At the end I was supposed to determine how many there were. Simple enough calculate the length divide by the size.

      So I cast the final address and the base address into an int and subtracted to get the length.
      Turns out that when using NT the address of memory mapped IO is something like 0x1XXXXXXX and on WIn95 it's 0x8XXXXXXX. So on WIn95 the addresses got cast into negative numbers and returned a negative length. All because I used ints instead of unsigned ints.

      BTW when I worked at Lucent, I got a chance to speak to one the the automated testers. Turns out that often times when you run an automated stress test, and get an intermittent failure a couple of times out of a thousand that it is usually an int somewhere that should have been declared an unsigned int.

    25. Re: Wake me up... by Joey+Vegetables · · Score: 1

      IMO, an optimal type system does not contain every type anyone anywhere might need at any time. It does contain the primitives from which developers can construct their own. Do I need a 36-bit "word" type? No, but if I did, I know how to construct one, in any of the statically typed languages I know. A Roman Numeral type? Same. I do not expect a language to be burdened, at least in the core language or standard libraries themselves, with either of these types, so long as I can construct them out of what the core language/libraries *do* contain. In most modern languages, which are Unicode-aware, the very concept of what constitutes a "character" is somewhat complex, but that complexity is buried in the implementation of a String or similar class. And the String class already does a superset of what you are asking. It will store a single character. (Or zero characters, or multiple characters). A subclass of String could trivially be designed to hold one, exactly one and only one, and still be Unicode-aware. Or, if you don't care about Unicode, and define "character" as simply a character representation of an unsigned 8 bit byte, then, notwithstanding Java's unfortunate exclusion of unsigned char/short/int/long types, you still can construct a class that will do what you want. Now I can't promise optimal C-like efficiency in either case. If you truly do need that, well, my Java may be too rusty to help you in detail, but I'm guessing there are multiple good approaches. Including just writing it in C and using JNI or whatever the modern equivalent is today. I sympathize with your frustration over Java lacking some of what even I would consider basic primitive (unsigned) types, and I happen to prefer C# over Java for that among other reasons, but Java's popularity and widespread use across virtually every niche and industry segment all suggest that there are ways to work around and/or through it.

    26. Re: Wake me up... by jythie · · Score: 3, Informative

      char []?

    27. Re:Wake me up... by jythie · · Score: 1, Funny

      Premature optmztion is rt of al evl.

    28. Re:Wake me up... by sydneyfong · · Score: 2

      It would probably become UINT_MAX, then I suppose what the GP means is that the value would violate the upper bound check, and then implicitly and magically fail the validation without having to type an extra " || x 0".

      Yep I think the argument is crazy, but at least the code works.

      --
      Don't quote me on this.
    29. Re:Wake me up... by jeremyp · · Score: 0

      Wake me up when you learn to code without unsigned integers. Until then, you are not a programmer.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    30. Re:Wake me up... by 0xdeadbeef · · Score: 2

      It would throw an exception at the site of the cast. Why do you think Java would be dumber than C with warnings turned off?

      You apparently don't know the difference between something the VM should be doing and having to repeat stupid boilerplate like this a thousand times:

      if (index < 0) throw new IllegalArgumentException()

    31. Re:Wake me up... by Urkki · · Score: 3, Interesting

      Wake me up when java supports unsigned integers. Until then it's not a real language.

      While unsigned numbers are great for a few things, mixing them with signed numbers is a real pain. Just consider all the C functions, which take in unsigned but return signed, and casting galore that follows. Of course you can just disable relevant warnings entirely and blindly hope implicit casts anywhere will never overflow, but that is kind of sloppy, and just asking for someone to find a way to use it for an exploit. Which incidentally is what most C code does.

    32. Re: Wake me up... by zakeria · · Score: 1

      a "char" would be 8 bits

    33. Re:Wake me up... by Ravaldy · · Score: 1

      I love my signed/unsigned variables. When you do high level programming this is the kind of shit you don't want to worry about. It makes code easier to read and understand AND it has zero impact on the performance of the final product. The compiler brings it back to it's native form.

      Now, if you do low level programming I understand you don't want the signed/unsigned BS but Java is mostly for high level programming so it's a moo point.

    34. Re:Wake me up... by 0123456 · · Score: 3, Informative

      Yeah, no Java programmer needs unsigned ints. It's not as though they need to interface to code which does have unsigned ints, like calling C++ libraries, or reading data from files or databases created by C or C++ programs, or reading files in standard, language-agnostic formats which are packed full of bytes that you then have to process as 16-bit signed integers instead.

      Lack of unsigned variables is one of the most braindead ideas in Java.

    35. Re:Wake me up... by 0123456 · · Score: 2

      So I cast the final address and the base address into an int and subtracted to get the length.

      If you're ever, anywhere in your code, casting pointers to integers, and it's not because you're passing it to some low-level interface to hardware... you're almost certainly doing something wrong.

    36. Re: Wake me up... by Anonymous Coward · · Score: 0

      Your kidding right? C++ supports many types of characters, including Unicode and arrays of those characters.

    37. Re:Wake me up... by toopok4k3 · · Score: 1

      Your choice comes in the form of picking the language that suits your needs.

    38. Re: Wake me up... by lgw · · Score: 4, Informative

      Characters suck. C++ and Python both allow easy 32-bit characters, which at least allows you to store one Unicode codepoint per "char". But in non-Western languages there are still glyphs that must be composited from several codepoints.

      But why would anyone care? UTF-8 works fine for sorting and comparing and so on, it's well designed that way.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    39. Re:Wake me up... by lgw · · Score: 1

      No, that's just wrong.

      Often you have a value for which negative numbers are always wrong/senseless. An unsigned type neatly encapsulates that constraint. It trivially becomes part of the API contract that "negative values don't make sense, so you can't pass one here".

      ADA of course takes it a step farther, allowing both min and max constraints on any integer. But the "non-negative integer" is a common enough special case to justify a type of its own.

      Oh, and your completely misusing "cardinal number" - when you use big words to try to sound smart, but get them wrong, it's quite embarrassing.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    40. Re:Wake me up... by Anonymous Coward · · Score: 0

      Any *real* programmer that used anything but a toy language would understand why unsigned integers are important.

    41. Re:Wake me up... by lgw · · Score: 1

      Yes, just like COBOL. And just like COBOL, it's mostly used for the most boring sorts of "Enterpise" software (which used to be called "card-whalloping code" back in the day).

      The phone thing is new, and at least gave Java a new chance at being cool. Hasn't worked out that way so far, mostly because, like COBOL, there's all this annoying wordiness and boilerplate all over the place, so it's hard to ever feel the result is "elegant". And if stuff you write on your own can't be "elegant", that just uncool.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    42. Re: Wake me up... by Anonymous Coward · · Score: 0

      It's called a moot point. But yes, if this dude can't find a language that has unsigned, the he's a fucking retard.

    43. Re:Wake me up... by MightyMartian · · Score: 1

      I don't code out of some desire to be a hipster. As we speak, I'm writing a Joomla component in PHP, a language I loathe (though it has improved of late), but it's the language the project requires, so here I am. In a few months, maybe I'll be coding in Java, if the project requires it. For me, the one place I have little or no desire to go is to any of the .Net languages, simply because of the lack of meaningful portability.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    44. Re: Wake me up... by angel'o'sphere · · Score: 1

      No it is not!
      char a = 1234; // compiles
      char b = a + 15; // does not compile
      char c = 15;
      char d = a + c; // does not compile

      Everywhere a char is used (and the java code actually compiles) the char is promoted to an int, an signed int.

      Just because a char is 16 bits wide and arguable a 'variation' of an int does not make it a useable 16 bit unsigned int.

       

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    45. Re: Wake me up... by DickBreath · · Score: 1

      > a "char" would be 8 bits

      It's the 21st century. A byte is 8 bits, something computers use. A character is something that is the basis of human languages and comes in many, very many, different varieties.

      There are various ways of encoding characters (for humans) into bytes (for computers) and then later decoding them back to characters again. Several of these 'charsets' or 'character encodings' are standard and well known. UTF-8 is a particularly nice way of encoding characters because in one byte it can represent the commonly used Roman characters and ancient 7-bit ascii from some forgotten millennium long ago swept away in the sands of time. Any character can be coded as UTF-8 and may end up encoding into multiple bytes. Those bytes are just as easily decoded back to a string of characters.

      Banish from your thinking the very idea that characters and bytes are the same thing and are assignment compatible. They are not assignment compatible. An array of characters is passed to an encoding function to give back an array of bytes. And vice versa.

      --

      I'll see your senator, and I'll raise you two judges.
    46. Re:Wake me up... by RabidReindeer · · Score: 1

      Yeah, no Java programmer needs unsigned ints. It's not as though they need to interface to code which does have unsigned ints, like calling C++ libraries, or reading data from files or databases created by C or C++ programs, or reading files in standard, language-agnostic formats which are packed full of bytes that you then have to process as 16-bit signed integers instead.

      In other words, "bit twiddling".

    47. Re:Wake me up... by DickBreath · · Score: 1

      > Any *real* programmer that used anything but a toy language would understand why unsigned integers are important.

      As the Minbari ambassador Delenn says, it's all a matter of perspective.

      If you don't program close to the bare metal, then you seldom, if ever have a need for unsigned integers. Think of languages as a continuum starting from the very low level of abstraction (assembler) to the very high level of abstraction (Mathematica, Clojure, Scheme, Haskel, Scala, etc). What you call a real language and a toy language all depends on what kinds of software you write. If you are working on symbolic reasoning, you probably use a different language than you would if you were writing an mp3 encoder. The former would call C a toy language.

      Also, if you happen to have the PBS NOVA documentary about IBM's Watson (a couple years ago), pay attention to some of the close up screen shots of the Watson developers' laptops. It's all (gasp!) Eclipse and Java. OMG -- those not "real" programmers need to use a language with unsigned integers! How can they expect to accomplish great achievements without unsigned integers! (Gee, I wonder if they ever once, one single time, thought: "drat -- I wish Java had unsigned integers".)

      --

      I'll see your senator, and I'll raise you two judges.
    48. Re:Wake me up... by RabidReindeer · · Score: 1

      If you want to complain that Java lacks the ability to define its own non-class data types, I'll be glad to sign the petition. Although I don't like "special case" types, and the 0..(some limit) sequence isn't really any different than any other range-restricted integer type other than in popularity.

      As for definitions of Cardinal and Ordinal numbers, those were the ones foisted on me in 5th Grade. Blame my teachers for not being enough into advanced Set Theory.

    49. Re:Wake me up... by Drethon · · Score: 1

      And if that end user is working with a boundary constrained entry field?

    50. Re:Wake me up... by jeremyp · · Score: 1

      No, that wasn't the problem unless the memory mapped region crossed the boundary from 0x7FFFFFFF to 0x80000000. For example, 0x90000000 - 0x80000000 is 0x10000000 whether you use 32 bit signed or 32 bit unsigned arithmetic.

      Also (this might not have applied at the time of Win95 and crappy Microsoft C compilers) it is legal to subtract one pointer from another in the same array (or one past the end of it) without converting to an arithmetic type.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    51. Re:Wake me up... by IamTheRealMike · · Score: 1

      You know, it's not like Java lacks unsigned types because they simply forgot about them. It lacks them because experience with C and C++ indicated that mixing of signed and unsigned types can lead to lot of weird bugs. It's one of the reasons those languages have a reputation for being giant cannons pointed at the developers feet.

      On the flip side, although lack of unsigned types probably makes pure Java code more robust, the moment you have to do any kind of parsing of file or wire formats it immediately becomes a sharp edge with which to cut yourself (that and the decision to make the JVM big endian - doh!).

      Ultimately I'd rather Java had unsigned types, if only to make interop eaiser, but the line between safety and features is always a finely balanced judgement call.

    52. Re:Wake me up... by jeremyp · · Score: 1

      A real programmer uses the tools that are available or mandated. A real programmer knows how to code around the limitations of whatever language they are using. When I program in C, I use unsigned types all over the place. When I program in Java, I barely notice they are missing. Certainly, the lack of unsigned integers in Java is far less of an inconvenience than the lack of a proper string type in C.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    53. Re:Wake me up... by znanue · · Score: 2

      hmm, wordiness is irritating, I'll grant you, as is boilerplate. But, it just stops being irritating the moment that your IDE starts taking care of all of that for you. Writing Java from the command line is an exercise in extreme torture, but Eclipse makes it just fine. Liberal use of ctrl-1, ctrl-space, and the refactor functions on context menus and the actual menu make most of these annoyances trivial. Also, I have yet to see something that can refactor javascript as well as eclipse refactors java.

      Also, cool I define by how powerful, flexible, and quick a language is to accomplish tasks. Boilerplate in the age of modern IDE's seems to have almost a negligable impact on those metrics. Boilerplate and language redundancy also often helps with human parsing of the language, imo, so it might even have a bit of a positive effect.

      Lastly, I almost never agree that 'terse' is elegant. Elegance should only be clever in what it is actually doing, not in how it is being expressed in the language.

    54. Re:Wake me up... by lgw · · Score: 1

      Oh, most people are innumerate these days.

      Nothing to do with set theory, really. Cardinal numbers indicate a count of objects: "one, two, three". Ordinal numbers indicate an order - a position in a sequence: "first, second, third". The major usecase for unsigned numbers is really indexing into arrays/collections (you don't know the max at compile time, but you do know the min) - in a sense those are ordinal numbers - positions in a sequence.

      Some people use "whole numbers" for the non-negative integers, and "counting numbers" for the positive integers, but I never heard those terms in college math classes. And anyway, I'm a programmer, I count from 0!

      --
      Socialism: a lie told by totalitarians and believed by fools.
    55. Re:Wake me up... by dkf · · Score: 2

      It would be nice if java supported something like typedefs.

      What for? Either you're doing it to name a type elegantly — except you don't need that in Java because classes already have reasonable names and you don't have a mess of structures as values plus pointers and references, as in C++ — or you're doing it to hide how complex the implementation of a data structure is — but there you're really encouraged to wrap a class around it and put an honest API in place — or you're doing something like aliasing. Aliasing isn't a great idea either; it's very non-obvious when used in substantial amounts. No, the lack of typedefs is not something that is particularly felt by Java programmers.

      I'd much rather have the built-in DOM support integrated into the standard collection model; that would genuinely save a lot of messing around.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    56. Re:Wake me up... by lgw · · Score: 1

      Having done both Java and C#. I choose to take the C# jobs now because the language is a lot more fun. Nothing to do with fashion. If you're managing your career well, you should eventually get to the stage where you can choose a platform that is pleasant to work on, by whatever subjective measure. I code for money, no doubt, but there's no reason to do that on an irritating platform, once you have the choice. Starting out, we all have to pay our dues, of course - someone has to do the shitwork.

      For fun projects I write C++, because I can be sure that proper style is used when I'm the only coder, but professionally I cringe at legacy C++ codebases.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    57. Re:Wake me up... by lgw · · Score: 1

      If the IDE can automatically insert it all, why not have the compiler do so? This is why I find Java too irritating to work with, but to each his own.

      Terseness is a necessary but not sufficient condition for elegance.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    58. Re:Wake me up... by MouseTheLuckyDog · · Score: 1

      What part of "So I cast..." did you not understand?

    59. Re:Wake me up... by TechyImmigrant · · Score: 1

      >So, what does your code do if an end-user passes -1

      Every verilog coder knows that you would get '1

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    60. Re:Wake me up... by TechyImmigrant · · Score: 1

      A real language would have reals, integers, natural numbers, complex numbers, rings, groups, fields, modular groups, vectors, matrices and booleans.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    61. Re: Wake me up... by Hognoxious · · Score: 1

      If ISO-8859-1 was good enough for Suetonius, Jesus and Shakespeare it's good enough for the likes of you.

      Want to draw heiroglyphics, Pitmanesque squiggles and Morse chuffing code? Do them as gifs.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    62. Re:Wake me up... by Anonymous Coward · · Score: 0

      Burn!

    63. Re: Wake me up... by VortexCortex · · Score: 1

      Well, I agree UTF-8 is good for storing and rendering (and it supports the full Unicode range [and then some], Unilke 32 bit chars), however, unless you are normalizing your composed characters (decompositions) then Unicode isn't very good for comparisons or sorting, and neither is any encoding of Unicode, such as: UTF-8.

      The problem is that normalized (decomposed) compositions can take up a lot more memory than the composed character, esp. in UTF-8 (which favors the western characters). Since memory (and bandwidth) is no longer as much of a concern UTF-8 is fine, but we should not store compose characters except for internal representations... However, I've yet to find an implementation that properly handles the normalization features of Unicode 3.0 as well as over-long forms -- both can be leveraged as exploit vectors: the former by improper sorts and duplicate displays despite different representations, and the latter to bypass input validation.

      Furthermore, at the lexical level Unicode is poorly supported, for identifier names, etc. See also the above exploits and more, then occurring at the source level. I've a toy compilable language in the works that handles these issues and more, for which I've had to implement my own Unicode processing functions. It's remarkable how poorly nearly all languages fail when I start applying my unit tests to them...

      I'm of the opinion Earth needs a single official language, but I'm disheartened that it will be English -- The least machine comprehensible of them all. Oh well, there's always next big bang.

    64. Re: Wake me up... by lgw · · Score: 1

      You should have seen language before this big bang!

      Yeah, composition sucks, but fortunately there just no reason to care how much space human-written text takes up these days (logfiles are a different matter). The biggest weakness in the Unicode standards is the lack of semantic information IMO. They should be releasing normative tables of machine-readable metadata about characters. It's still maddening just to write ToUppercase() in a cross-cultural way, and there's just no reason that should be hard.

      I've written "any encoding to good clean Unicode" readers that handle broken encodings well, but I just can't figure out where to even start on composition. Something from the standard to make it all clear (for every reasonable composition) would sure be nice.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    65. Re: Wake me up... by Anonymous Coward · · Score: 0

      Java char type is 16 bits.

      There are more characters than can be supported in 8 bits.

    66. Re:Wake me up... by Anonymous Coward · · Score: 0

      What is worse than no unsigned integers is that integer overflows are completely ignored and next to impossible to know that it happened.

      That is inexcusable.

      At least they didn't try to fix it like the clowns working on PHP by checking if the value is greater than the max value of an integer.

      Java: at least it isn't PHP!

    67. Re:Wake me up... by vilanye · · Score: 1

      That is the battle cry of the inept programmer.

      There is a difference between premature optimization and blatantly writing inefficient code because you don't know any better.

    68. Re: Wake me up... by turgid · · Score: 1

      Your kidding right? C++ supports many types of characters, including Unicode and arrays of those characters.

      C++ supports bytes and arrays of bytes (statically-allocated ones at that). The rest is in the library.

    69. Re: Wake me up... by ebno-10db · · Score: 3, Insightful

      ISO-8859-1

      The one with those funny marks on the letters? Bah. ASCII. The eighth bit is just a spare. If you can't do it in English, then it isn't worth doing.

    70. Re: Wake me up... by DickBreath · · Score: 1

      > ASCII. The eighth bit is just a spare. If you can't do it in English, then it isn't worth doing.

      The Vorlons would disagree.

      --

      I'll see your senator, and I'll raise you two judges.
    71. Re:Wake me up... by jkauzlar · · Score: 1

      This is a stupid thing to even argue about, but I've been using Java for a decade and have barely needed to do these things you mentioned. I suspect they're done so rarely that the collective time saved from not having to deal with mixed signed/unsigned types in APIs far outweighs the joys of having an extra bit. And when you need to, support for byte arrays is really very good.

    72. Re: Wake me up... by jd2112 · · Score: 1

      Wrong. You aren't a real witch if you don't pass basic hex.

      --
      Any insufficiently advanced magic is indistinguishable from technology.
    73. Re: Wake me up... by Anonymous Coward · · Score: 1

      "ToUppercase() in a cross-cultural way" ... doesn't mean anything. Case rules vary between languages, when you ask for Unicode to somehow solve this you're asking for cultural imperialism. "I want one case rule, so other cultures will be exterminated". That was never the purpose of Unicode, maybe start your own "Uniculture" forum where you agree to wipe out all the people who don't wear the same kind of clothes and eat the same kind of food. Good luck with that.

    74. Re: Wake me up... by lgw · · Score: 1

      No, I'm asking for a mapping. For every codepoint, identify as L/C, U/C, or n/a. Then give me a mapping between each L/C and U/C letter. If there are some cases where this mapping varies by culture, add that to the input. Whatever. But there are already rules in place for this wherever the concept applies - collect them into the standard normatively.

      I should not have to be an expert in every human language to write ToUppercase(). Take the rules that every schoolchild knows in each culture and collect them - the Unicode guys collectively know all this stuff, and it's somewhat documented in non-normative appendices and such, but it needs to be part of the standard, which will ensure completeness and accuracy.

      BTW, can you give me an example of where the L/C -> U/C mapping varies by culture?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    75. Re:Wake me up... by Anonymous Coward · · Score: 0

      Or not.

      I've wanted them once in 15 yrs of Java contracting, and it took about an hour to work around it. And in the '90s I spent a month in a C++ shop untangling the mess that had evolved through slightly enthusiastic mixing of unsigneds and signeds in a physics app. Roughly speaking, mass is unsigned, accn is signed. So F=ma gives you ... unsigned...

      There's a solid engineering reason for not having unsigneds in Java - it'd double the number of integer types, and therefore push the number of typed integer operations up, which means the number of bytecodes would exceed 256. Can't do it without breaking the whole bytecode system. You could have a prefix or similar I guess, but keeping it simple was a big deal.

      The applications for unsigneds that you list is kind of fair enough, but if you need a whole new set of fundamental types to do that stuff, then you really need to ask why you're being given all the shit jobs :-)

    76. Re:Wake me up... by Anonymous Coward · · Score: 0

      Lack of unsigned variables is one of the most braindead ideas in Java.

      Personally, I think using ">>>" for logical shift right and ">>" for arithmetic shift right trivially beats that for brain-deadness.

    77. Re: Wake me up... by KiloByte · · Score: 1

      The problem lies in UCS-2 and UTF-16. The former can't even represent most of Unicode, the latter includes all worst points of UTF-8 and UCS-4: it's not text, needs complete new APIs, any corruption corrupts the rest of the text rather than just a single character, doesn't allow random access, etc, etc.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    78. Re:Wake me up... by thegarbz · · Score: 1

      You're assuming it's the user that gives the input. Unsigned values are great in things such as automatic counters which only count in one direction. Gives you twice the space as signed values and you really do only have to check the upper bound and handle the case where it overflows back to zero.

      Classic use case: timekeeping in microcontrollers. Admittedly though you won't be using perl or ruby for that.

    79. Re:Wake me up... by RCL · · Score: 1

      You may want to hash them for maps or sets, log them out, or even save to disk (the latter might not make sense at first glance, but sometimes it's convenient as it provides an "unique ID" for objects in a saved file, helpful if your data is an arbitrarily connected graph).

    80. Re:Wake me up... by JAlexoi · · Score: 1

      The fact that lack of unsigned integers has not stopped Java shows that the designers made the right choice. If you need to have a value larger than 2bn you will probably not be satisfied with 4bn and will need a larger type. And in general, you rarely need to operate numerically without a sign.

    81. Re:Wake me up... by JAlexoi · · Score: 1

      1: Those bounds checks come at a cost of having overflows getting in the way of actually checking bounds. An overflow of an unsigned value results in just a small number... that means that you still have to check the lower bounds no matter what.
      2: They store the same number of values as unsigned, it's just handling of those values and comparison operations differ. A signed and unsigned 32bit integers store 2^32 values.
      3: Crypto algorithms do not operate numerically, thus 2147483647 * 100 will yield exactly the same result for uint32 and int32 as much as any crypto algorithm is concerned.
      4: Therefore you send 2147483648 in binary form as 4 bytes = 0x80000000

    82. Re:Wake me up... by JAlexoi · · Score: 1

      And what 32 bit integer is not a 32 bit integer in C/C++ or Java?

    83. Re: Wake me up... by Anonymous Coward · · Score: 0

      How do you represent Greek, Hebrew and Aramaic in ISO-8859-1 ?

    84. Re: Wake me up... by Anonymous Coward · · Score: 0

      It's a joke. From a line from Friends. Which was a show. On that thing we used to call a television.

    85. Re:Wake me up... by Pseudonym · · Score: 1

      Minecraft confirms that it's not dying. Does that count?

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    86. Re:Wake me up... by funky_vibes · · Score: 1

      What part of Java design isn't braindead?
      No, seriously.

    87. Re: Wake me up... by bucky0 · · Score: 1

      He was saying you don't have to cast

      --

      -Bucky
    88. Re:Wake me up... by RoboJ1M · · Score: 1

      *mumble mumble* ...C# has unsigned integers...

      Wait, what, why are you all pouring petrol/gasoline on me!? :'(

    89. Re: Wake me up... by RoboJ1M · · Score: 1

      I also prefer C#, although I've had precious little use for unsigned types.
      However, when I *have* needed them (dealing with legacy DLLs, etc) then thank god I had them.

      Anyway, we better go hide in the corner before they notice us. >.>!

      If you get caught, just strip all the UInt32 statements out of your code and pretend it's Java.

      Nobody can tell the difference anyway.

    90. Re:Wake me up... by nitehawk214 · · Score: 1

      Minecraft confirms that it's not dying. Does that count?

      Java or Netcraft?

      --
      I'm a good cook. I'm a fantastic eater. - Steven Brust
    91. Re:Wake me up... by Anonymous Coward · · Score: 0

      Yeah, no Java programmer needs unsigned ints. It's not as though they need to interface to code which does have unsigned ints, like calling C++ libraries, or reading data from files or databases created by C or C++ programs, or reading files in standard, language-agnostic formats which are packed full of bytes that you then have to process as 16-bit signed integers instead.

      Lack of unsigned variables is one of the most braindead ideas in Java.

      It is sad that a "news for nerds" readers would mark this informative despite a very mature binding system called Java Native Interface (JNI). It seems there are a lot of pretend coders that talk out of their asses.

    92. Re: Wake me up... by Outtascope · · Score: 1

      I would like to embrace and extend your comments, but unfortunately my conscience prevents from doing so.

    93. Re: Wake me up... by lgw · · Score: 1

      I've never seen these problem in practice. UTF-16 is just fine for 2-byte characters - like UTF-8 you can sort and search and whatnot because the multi-unit encodings were done right.

      No clue what you're going on about with "not text" "corrupts the rest" "no random access" and so on. I think you've mistaken UTF-16 for something else. UTF-16 and UCS-2 are the same for all valid Unicode codepoints under 0xFFFF. 0xD800-0xDFFF represent multi-unit encodings in UTF-16, and never had any valid meaning in UCS-2.

      If what you're wanting is "one slot in the array = one glyph on the screen" that just will never happen - that approach only even makes sense for languages with small "alphabets", but for those languages UTF-32 will work for that. Easier to just accept that a glyph on the screen may be more than one slot in an array - that hardly ever matters in practice, other than the need to detect invalid encodings for security reasons (but most software that deals with text already cleans it up in other ways for security reasons, and this is a simple case).

      --
      Socialism: a lie told by totalitarians and believed by fools.
    94. Re: Wake me up... by Anonymous Coward · · Score: 0

      Welcome to 2013 when a char can be up to 32 bits depending on character set encoding. java char's are 16 bits.

    95. Re:Wake me up... by Urkki · · Score: 1

      Maybe your code is different, but have you noticed how many C functions return signed value, where -1 means error? Often same functions take unsigned size in, and then return actual size written/read/whatever. Except the maximum returned size has one bit less for positive values, than the maximum size given as argument. Do you see the problem?

      As a result, lot of times an unsigned is used in C, even in standard library, a signed value should be used instead.

    96. Re:Wake me up... by Hognoxious · · Score: 1

      .Netcraft says so.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    97. Re: Wake me up... by Anonymous Coward · · Score: 0

      Exactly. Chinese has no uppercase.

    98. Re: Wake me up... by Hognoxious · · Score: 1

      You don't, you use gifs[1]. Can't you read?

      [1] png is better, but I doubt you've heard of it.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    99. Re: Wake me up... by Hognoxious · · Score: 1

      Oh come on. I know accents and diactritics are rare in English. But that's exactly why, when used correctly, they add a certain ambiance, a touch of the Belle Époque

      You're just being faux naïve

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    100. Re: Wake me up... by theshowmecanuck · · Score: 1

      C not C++
      char myChar;
      You can argue that this is actually an integer. But under everything, all information is stored as some form of number. So if you really want to be anal or dogmatic or both, you can't any store data type only binary numbers (unless you have a quantum computer I guess).

      --
      -- I ignore anonymous replies to my comments and postings.
    101. Re:Wake me up... by theshowmecanuck · · Score: 1

      This is a double edged sword.

      --
      -- I ignore anonymous replies to my comments and postings.
  2. Keep it up - you might just invent assembly... by xxxJonBoyxxx · · Score: 0

    >> While it is true that Java certainly can be verbose, several scripting languages have sprung up which are purpose-designed to spare developers from long syntactical passages to communicate a simple action

    Keep it up - you might just invent assembly...

    1. Re: Keep it up - you might just invent assembly... by Anonymous Coward · · Score: 0

      "Java 8, expected in March, will add closures (that is, lambda expressions)" - They're inventing Lisp!

    2. Re: Keep it up - you might just invent assembly... by znanue · · Score: 2

      As if features are the only thing that makes a language a language. I'm not saying Lisp isn't nice, but which lisp? And, after you select which lisp, which library to do the thing you're trying to do? Oh wait, they often don't exist. So you hand roll your own, because it is easy in lisp, due to lisp's powerful nature. So now you can't hire people who know about the things you're doing right out of the gate because you choose a specific lisp and hand rolled a bunch of stuff. Need to integrate with xyz technology? There's probably not a lisp library for it that is standard, if it exists at all. Its also rarely mature...

      In the end, some version of lisp might still be a really good choice for some project. However, it has significant disadvantages to overcome. Adding lisp like elements to a language like Java is a much nicer thing than your quip seems to appreciate because it gives you some of the advantages of using lisp while retaining all the advantages that java will provide. Maybe lisp should try to invent java by standardizing the language and writing a lot of mature libraries?

    3. Re: Keep it up - you might just invent assembly... by CastrTroy · · Score: 4, Insightful

      Very much agree with this. The library/API that comes along with a language is just as important, if not more important than the language itself. You don't want your programmers spending any time writing their own hashtable or arraylist implementations. You don't want your developers writing their own sorting functions, and you don't want your developers spending time trying to write their own "date math" functionality. Thie is why I find that .Net is actually quite good. The API is amazing. It includes just about everything, and it's very consistently done. It's also relatively free of bugs, and extremely well documented.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    4. Re: Keep it up - you might just invent assembly... by Anonymous Coward · · Score: 0

      Well, actually, Lisp doesn't have strong static data typing. Of the Lisp/Scheme-like languages, Typed Racket is closer.

      Static typing is valuable for catching lots of coding errors before execution. The potential improvement of run-time is a side effect.

      -- hendrik

    5. Re:Keep it up - you might just invent assembly... by Anonymous Coward · · Score: 0

      Assembly is even more verbose. The fact that almost every line of assembly code seems to do something instead of just declaring something is irrelevant, because each line ends up doing so little.

      -- hendrik

    6. Re: Keep it up - you might just invent assembly... by gbjbaanb · · Score: 1

      sort of. .NET is good simply because of Visual Studio and intellisense and all the other "make it easy" features they have - features I'm sure they could have added to other languages.

      But .NET is missing loads of stuff, the last one I found was the lack of a graph or tree container, a dictionary just doesn't cut it. Oh, and I keep using Single() in my EF LINQ calls.. which doesn't support it, even though its a method on IEnumerable... lovely that, an interface that supports some methods some of the time.

      So no, the API is not a good thing as it constrains you into using it and the bigger the API the more people think they have to use it, and only it. Other languages do much better in this regard, by letting you add in libraries for various functionality as you need it, so if I needed a tree container, there would be one, or more, standard libs available for me to fetch and pull in. Then my library of libraries would be filled with whatever was needed today - not what was hot 5 years ago when that API was thought up.

    7. Re: Keep it up - you might just invent assembly... by CastrTroy · · Score: 1

      The .Net library doesn't constrain you. If you don't like it, it's very easy to get another library that offers more functionality, and use that. Over the years, I've used third party libraries for things like FTP, Email, data charting, PDF rendering, and plenty of other tasks. Some of these, like data charting (bar graphs, pie charts), are now handled well by the .Net APIs, but they weren't always. But if you have more complex needs which they don't cover in their charting libraries, then there's tons of third party libraries which offer even more functionality.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    8. Re: Keep it up - you might just invent assembly... by jythie · · Score: 2

      Choosing a language is much less about technical requirements as it is about HR requirements. A while back I was watching a company that built their applications around LISP, but ended up switching to C++ due to Universities not providing enough 'ready to go' developers who use the language. Another company that I worked at ended up switching to Windows for the same reason, they had too much trouble finding Linux developers fresh out of school in the right domain, so it was cheaper and easier to move the whole system to Windows then to train up people on Linux constantly.

    9. Re: Keep it up - you might just invent assembly... by iONiUM · · Score: 2

      I don't know what you are talking about, EF does support .Single() just as any other LINQ method works on an IEnumerable (here's a question about it). If it was throwing an exception, it's because you had more than 1 item meeting the criteria, and you don't know what you're doing. Try .FirstOrDefault(), which will not throw an exception.

      As for why there is no Tree class in .NET, you can refer to this question, where the answer is enumerated for you. Having worked with .NET since 2003 when it came out, and in the interim having to work with Java, Obj-C, and other platforms, .NET is without question the most "well done." Typically if you're having problems like you cited above, it's due to a lack of understanding on your part.

    10. Re: Keep it up - you might just invent assembly... by Anonymous Coward · · Score: 0

      Clojure is Lisp on the JVM. With excellent interop, so you can use any Java library, or scala library, or write a library in Clojure and use it in the JVM (When Clojure won't do exactly what you need to do). The across-languages library usage has been something great for my project (where there are few developers on this project, but mature libraries exist in other places).

      Clojure itself isn't perfect, so I'm not trying to say that, I just wanted to let you know of the existence.

    11. Re: Keep it up - you might just invent assembly... by DickBreath · · Score: 1

      > sort of. .NET is good simply because of Visual Studio . . .

      In case you are not aware, there are some very nice IDEs, even free and open source ones, for Java. And the IDEs run on any platform, just like the rest of Java.

      --

      I'll see your senator, and I'll raise you two judges.
    12. Re: Keep it up - you might just invent assembly... by DickBreath · · Score: 1

      > Static typing is valuable for catching lots of coding errors before execution.

      Yes.

      Also, there are subtler benefits to static typing. It enables excellent 'toolability' of the language. That is, your IDE can do 'intellisense' type stuff and get it right. It can know exactly what members to offer on a variable or value of some particular type.

      Furthermore, the static type checking done by the compiler is your very first line of testing before you get into your own higher level unit tests that test the deeper logic of your code. Think of static typing as the compiler unit testing your code for obvious logic errors and assignments that couldn't possibly make sense at runtime.

      --

      I'll see your senator, and I'll raise you two judges.
    13. Re: Keep it up - you might just invent assembly... by Zero__Kelvin · · Score: 1

      "Java 8, expected in March, will add closures (that is, lambda expressions)"

      Closures and lambdas are not the same thing actually.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    14. Re: Keep it up - you might just invent assembly... by Gibgezr · · Score: 1

      None of the very nice IDEs I've tried have come close to being as nice as VS. Eclipse is OK, so is Code::Blocks, but nowhere near the magic ease-of-use and power combination that VS offers. VS isn't perfect, and it's ease-of-use has started a downward trend since VS9 in 2008, but it's still far beyond all the open-source IDEs I've tried under both Windows and Linux.

    15. Re: Keep it up - you might just invent assembly... by Atzanteol · · Score: 1

      What's interesting is that I've had the opposite reaction. When I use VS I'm amazed at the lack of functionality it has compared to Eclipse. Why the hell can't it just "import what's needed like Eclipse can" for me rather than making me click on silly little drop-downs which only show when I hover over squiggly-underlined types it can't find? Just one rant but I hit things like this all the time in VS (or VS2012 at least - the last one I used). That and I have to get used to compiling again. ;-)

      It all comes down to expectations.

      --
      "Ignorance more frequently begets confidence than does knowledge"

      - Charles Darwin
    16. Re: Keep it up - you might just invent assembly... by Anonymous Coward · · Score: 0

      Java has always had closures(it is just a property of something), what it has been lacking is anonymous functions(aka lambda expressions).

      I an curious to see how they handle that with checked exceptions.

      I suspect that they will not be making use of them in existing API's, but will be yet again making a new collections API, for example.

      Being able to easily override compareTo in sorting and searching would be a nice feature.

      array.sort {|l,r| /*whatever you want to do*/}

    17. Re: Keep it up - you might just invent assembly... by gbjbaanb · · Score: 1

      plain wrong.

      I have a compiler that proves it. I'm writing simple code, I have a query that ends in .Single() and the runtime throws an exception, telling me to use First() instead as Linq to entities doesn't support this method.

      I understand the difference between first and firstordefault, I know what I'm doing, and I can read the exception text. (caveat: I'm using .net 3.5, It wouldn't surprise me if they've changed it in current versions) I still think its nowhere near as clean a language as C# proponents keep claiming, not any more at least. .NET is the most "well done" if you consider developer happiness using it is the only factor. It is nice, it is easy, but I think all of that is down to the environment, not the language. Try coding C# in notepad to see what I mean.

    18. Re: Keep it up - you might just invent assembly... by gbjbaanb · · Score: 1

      you miss my point - that C# is a bit pants if you don't have VS. No VS = C# becomes just another, reasonably crappy language with loads of "evolved" functionality that occasionally is just nonsense,

      Try coding C# in notepad to see what I mean. Not that anyone would,but trying it highlights the language as opposed to the IDE assistance.

    19. Re: Keep it up - you might just invent assembly... by Xest · · Score: 1

      I've worked on a lot of large Java projects using Eclipse and a lot of .NET projects using Visual Studio and you're right there are some features Eclipse has that are nice and Visual Studio doesn't, but that's not without it's problems.

      For example, you hint at the fact that Eclipse will automatically rebuild for you, but I've found this feature particularly error prone in that it can sometimes fail to build, and like a jammed printer you have to prat around unjamming it before it will build properly again through no fault of your code (though this was the SpringToolSuite flavour, maybe the vanilla doesn't fail as badly at this). I've also found Eclipse's intellisense to be slow, sometimes too slow to be of any worth if you're a fast typer whereas I've never had that with Visual Studio. Things like code regions are much smarter in Visual Studio, it remembers properly what I have and haven't hid but Eclipse fails at this completely, you can make your document tidy by hiding rarely used regions only to have to do it all again next time you reopen the document. The theory behind Eclipse's plugin setup for supporting different frameworks and languages is nice but it almost never works requiring multiple installs for different flavours of Eclipse. Eclipse of course has a debugger but it's half-arsed compared to Visual Studios too. I think all this highlights the biggest problem I have with Eclipse - even where it does have features over and above Visual Studio they just never work well or properly and that applies to many features that it does share with Visual Studio.

      But I think in general this highlights the fundamental difference between Eclipse and Visual Studio, Eclipse does have more features (though Visual Studio also has some Eclipse doesn't have) but it's a clusterfuck of everyone's favourite feature and none of it works well together. In contrast, Visual Studio may lack some of those features but at least the features it does have all work in a responsive and well integrated manner and that's why most developers who have used both prefer Visual Studio - because it's just hassle free, you basically never have to fix projects that the IDE has randomly broken, you don't have to sit waiting around for some interface element to respond, and features "just work". This is also why I prefer NetBeans to Eclipse in many cases - it follows the same philosophy as Visual Studio, less about number of features, more about making sure the features you do have work and that the IDE is fast enough to not be painful to use sometimes. Other Java IDEs like JDeveloper are even better again.

      Eclipse would be best on the market if it cleaned up by making sure all features work properly, never break, and made the IDE more responsive in general, but it's had years and failed to achieve any of this - it's just added ever more features without making sure they all work well by themselves and work together with others also.

    20. Re: Keep it up - you might just invent assembly... by yacc143 · · Score: 1

      Furthermore, static typing catches many errors during compilation. The sad part is that it does not catch all errors in some categories, which leads to multiple ugly results, the foremost being that developers expect the bugs caught by the compiler, hence don't test for them.

      An example would be changing method arguments. Most developers expect the compiler to catch these. Sadly, a huge subset of these are not caught by compilers in most languages, e.g.:

      void doit(int x, int y) => void doit(int y, int x);

      Now while this sounds trivial, the underlying issue is fundamental (type theoretically spoken, type equivalence by structure), and even a developer knowing about this can be caught, as the typenames for x and y could be different (typedefs come to mind). Actually, C & C++ define a number of opaque datatypes where the developer is not expected to know what's inside. (e.g. FILE in Ansi C, guess most developers would not be able to tell by introspection if some random struct is type equivalent to FILE.)

      Now the ugly part is, because unittesting is work (and static-ness does not help, it usually makes it necessary for code to be developed explicitly allowing stubbing out stuff), and because the compiler is meant to catch this category ("argument errors"), you will find that most statically typed projects do not apply the same degree of testing to the code (and especially for issues that the compiler is supposed to handle).

      Dynamically typed languages do not promise any of these, hence testing usually includes also these topics that others believe to be checked by their compiler.

    21. Re: Keep it up - you might just invent assembly... by DickBreath · · Score: 1

      Thank you for your reply. If you look at my message which you replied to, I also said that strong typing enables 'toolability' of the language. I then gave only the most simplistic type of toolability -- intellisense.

      Eclipse, which is an IDE for writing code, has lots of toolability features for Java. For example, of your doit( int x, int y) method. In Eclipse, you would click in the word doit before the open paren, right-click, Refactor, Change Method Signature...
      (dialog box appears)
      The dialog shows a table with all of the method formal arguments. Click a row, such as the row for X, and then click the DOWN button to move that row down below Y, then click OK. Not only will the two arguments X and Y be interchanged in the signature of method doit, but all references in your code will also be changed as well.

      This is not done by some simplistic search and replace. Eclipse has a deep understanding of your source code. The editor is deeply integrated with the compiler. Or rather, to put it in simple terms, the Java compiler is a very large library and the compiler command line tool is just a wrapper around the large amount of compiler logic in a library. The Java editor in Eclipse makes extensive use of the library functions in the compiler to deeply understand the source code and have a database about everything in all of your source code in your entire project.

      Another example, in a large method, select several lines, refactor, extract method. A dialog appears. You give the new method a name, the dialog tells you what the arguments are, but gives you an opportunity to rename them, then when you click OK, the lines you selected are refactored out into a separate method, and the place where those lines were becomes a function call to that method.

      There are many other refactoring tools. This kind of toolability is enabled because the language is statically typed and the editor understands exactly what else in your project is related to what. There is no compile time (or editing time) doubt about what method a particular function call would go to.

      In dynamically typed languages, this can be difficult to impossible to do. In languages like, let's say Javascript, it can be impossible. You could have a reference like x["foo"] = bar, which could also have been s="foo"; x[s] = bar. Both of these are equivalent to x.foo = bar. Now if I did some refactoring, such as a rename to change x.foo into x.frob, should you or should you not rewrite other code to say: s="frob"; x[s] = bar? This has a certain similarity to how in C an array reference and pointer could be interchanged and refactoring tools might not recognize subtle tricks.

      As to the other part of your reply, static typing promises to catch exactly what it catches. No more, no less. Interchanging arguments is something you do with refactoring tools. Especially in a gigantic program. You never interchange function arguments by hand. Heck, you don't even reverse the then-else conditions of an if statement by hand -- you right click and refactor. The tools will reverse the logical condition in the if condition for you as well as reversing the then-else blocks.

      Like all good things, these great tools (eg Eclipse) are free and open source.

      --

      I'll see your senator, and I'll raise you two judges.
  3. scripting language? by Anonymous Coward · · Score: 1

    Is Java a scripting language? I think anyone that thinks Scala is a scripting language, whatever that is, doesn't know what they are talking about.

    1. Re:Scripting Language? by narcc · · Score: 1

      It's a completely meaningless term. When you see someone arguing about whether or not a given language is a "scripting language", just assume that they're morons.

  4. Java already had closures by Anonymous Coward · · Score: 3, Informative

    Java had closures in the form of Anonymous classes. While it is true that lamda expressions will be much more concise, it is not correct to suggest that closures are being added with Java 8.

    I often hear that Java "doesn't have closures." Since anonymous methods can capture variables within the scope of their declaration, they are closures.

    I also frequently hear that Java is "interpreted," but that's a whole 'nother discussion.

    1. Re:Java already had closures by Anonymous Coward · · Score: 1

      Since anonymous methods can capture variables within the scope of their declaration, they are closures.

      Only if variables in the outer scope are declared final, which works well for anything that's immutable or if you don't need to change an immutable without returning the new value. (final == const, but final !=== const, ymmv, etc)

    2. Re:Java already had closures by lgw · · Score: 4, Insightful

      That entirely misses the point. The conciseness is the entire point.

      If I have a list of strings, and want to append ".txt" to each, using a for loop is just one more annoying piece of COBOLesque boilerplate.

      fileNames = names.Map(n => n + ".txt");

      That's what you want.

      docFileNames = names.Where(n => n.StartsWith("Doc")).Map(n => n + ".txt");

      You can understand what that does even though I just make up the methods. That's the damn point.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    3. Re:Java already had closures by Hentes · · Score: 2

      Java doesn't have closures and it won't have any in Java8 either. A closure isn't the same as a lambda. In a closure, free variables are stored by reference, and their changes are reflected in the closure. Java8 lambdas require all free variables to be final.

    4. Re:Java already had closures by tyrione · · Score: 1

      That entirely misses the point. The conciseness is the entire point.

      If I have a list of strings, and want to append ".txt" to each, using a for loop is just one more annoying piece of COBOLesque boilerplate.

      fileNames = names.Map(n => n + ".txt");

      That's what you want.

      docFileNames = names.Where(n => n.StartsWith("Doc")).Map(n => n + ".txt");

      You can understand what that does even though I just make up the methods. That's the damn point.

      In short, you want the for loop to be done behind the scenes without you writing the code and just referencing a method to call that loop?

    5. Re:Java already had closures by Anonymous Coward · · Score: 0

      So you're claiming that the original primary purpose of Closures is purely a syntactic? I find that hard to believe, citation please.

    6. Re:Java already had closures by Anonymous Coward · · Score: 0

      well, brevity is only half the damn point of TFS, and has nothing to do with what OP is saying. i don't use closures because they're brief, it's because i can partially define an anonymous function that maintains some part of the stack in which it was constructed after the stack goes away, so AC is correct to say that that ability has existed in java forever. and just because i can write $('.foo').option().option().option() and it looks pretty when its called, the functions themselves still need some sort of loop or (tail-)recursive logic behind them, so the only case you're really making is for abstraction.

    7. Re:Java already had closures by stewsters · · Score: 1

      If conciseness is more important than structure, you could use you could use Groovy:

      ["here","is","a", "list", "of", "strings"].collect{it+".txt"}
      Result: [here.txt, is.txt, a.txt, list.txt, of.txt, strings.txt]

      ["Dochere","is","Doca", "list", "of", "strings"].collect{ it + (it.startsWith("Doc") ? ".txt" : '' )}
      Result: [Dochere.txt, is, Doca.txt, list, of, strings]

      That compiles down to a jar you can use from Java.

    8. Re:Java already had closures by tonywestonuk · · Score: 4, Insightful

      I find the following easier to know whats going on:

      I don't understand that. I do understand:

      Arraylist docFileNames = new Arraylist();
      for (String name:names)
                                  docFileNames.add(name+".txt");

    9. Re:Java already had closures by lgw · · Score: 1

      No, the for loop is a needless intrusion. If you're used to LISP-like languages, you wonder what all this wasteful for-loop-obsession is in other languages. But then, people talk about "map reduce solutions" on "big data" without even knowing those are canonical names for LISP functions for common list-processing tasks.

      Methods that clearly express an intent to operate across a collection of data are simply more straightforward. There's a limited set of such operations, they're quite common patterns, and there's no need to do boilerplate for them every time. Lambda is needed to avoid the boilerplate.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    10. Re:Java already had closures by lgw · · Score: 1

      No, the "original purpose" of closures is the abstract algebra od the lambda calculus, which is neither here nor there - that's very far removed from production code. The place where lambda make for better production code is for in-place definition of simple functions that need no name and aren't returned out of their context. Objects in most languages let you do the more general-purpose encapsulation of state that closures are the primitive for - and that's nothing new.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    11. Re:Java already had closures by lgw · · Score: 1

      Sure, but "real" closures are just objects with only 1 method, a not very interesting primitive, outside of the academic study of computability and the most primitive forms from which all else can be built.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    12. Re:Java already had closures by ahabswhale · · Score: 1

      FFS, anonymous inner classes aren't even close to being closures. Anyone who's ever used real closures could tell you that. AICs are a hideous frankenstein monster of a construct that should have never been included in the language in the first place. I would go so far as to say that they are one of the biggest mistakes in the language and had they actually added real closures early in the development of the language, the java programming world would be vastly better for it. It's not like closures are a new invention. There's no real excuse for it other than shortsightedness. It's the same level of retardation that gets you into the situation where new BigDecimal(0) doesn't actually equal zero. I could go on but I think I've made my point.

      --
      Are agnostics skeptical of unicorns too?
  5. Scala is a scripting language? by bendilts · · Score: 3, Insightful

    Funny, I thought Scala was a fully compiled, statically type-checked language (at least as much as Java is). A language is not a scripting language just because it doesn't suck.

    1. Re:Scala is a scripting language? by pscottdv · · Score: 2

      More to the point, it's not Java. It's Scala.

      --

      this signature has been removed due to a DMCA takedown notice

    2. Re:Scala is a scripting language? by binarylarry · · Score: 3, Interesting

      Scala is basically C++ on the JVM.

      It's what Java would be if the stewards of Java weren't so conservative (or lazy) about new features.

      The powerful features of Scala tend to make code unreadable months down the road in my experience. :(

      --
      Mod me down, my New Earth Global Warmingist friends!
    3. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      Then you're poorly informed.

      Just write a program to execute at toplevel of a .scala file (instead of inside a main class, as usual), and run it as script with "scala filename.scala", or add a "#! /usr/bin/env scala\n!#" at the beginning - it had this ability since ever.

      It also has plenty of niceties for using as scripting shell, like this.

      Scala 2.11 also adds support for using Scala interpreter through standard Java Scripting Engine interface.

    4. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      It's what Java would be if the stewards of Java weren't so conservative (or lazy) about new features.

      The powerful features of Scala tend to make code unreadable months down the road in my experience. :(

      Actually, there are two things about Scala that make Scala code unreadable:

      a) Operator overloading. Yeah, Matrix + Matrix looks nice, but the temptation to abuse operator overloading seems to be too overwhelming for most people that get exposed to it.
      b) Innumerable typing shortcuts for common operations. I'm ok with "f x" being a shortcut for f(x), but there are 38 shortcuts compounded on top of that which are conditionally valid depending on context.

      Outside of that, the type system in Scala is really nice, and it does support a nice mix of classes and functional programming.

    5. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      That proves nothing. You can make a similar wrapper for C or Haskell (runhaskell) and very few people would call C or Haskell scripting languages.

    6. Re:Scala is a scripting language? by GuldKalle · · Score: 1

      That doesn't mean it's not compiled. It just means that it's compiled automatically and possibly saved to a temporary location.

      --
      What?
    7. Re:Scala is a scripting language? by slack_justyb · · Score: 4, Funny

      Java only promised write once and run anywhere. Nowhere in that promise was write once, be able to read it later. <<Takes cover>> :-D

    8. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      So what? Python does the same, compiling to Python VM bytecode, and optionally storing bytecode for libraries. Lua does the same even more explicitly - basic primitive for executing any Lua script is loadstring that compiles source text to bytecode, all the functions like loadfile/dofile/require are simply wrapping it.

      "Scripting language" is orthogonal to interpreted/compiled and typing discipline. It refers to intended use cases, syntax, libraries and extensibility.

    9. Re:Scala is a scripting language? by marcosdumay · · Score: 1

      A language is not a scripting language just because it doesn't suck.

      Are you sure about that? I always tough not sucking was the definition of "scripting language".

    10. Re:Scala is a scripting language? by dkf · · Score: 3, Insightful

      Java only promised write once and run anywhere. Nowhere in that promise was write once, be able to read it later.

      Oh, you can read it later. It's just so damn verbose that you'd better set aside a long time for reading it...

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    11. Re:Scala is a scripting language? by DickBreath · · Score: 2

      > I always tough not sucking was the definition of "scripting language".

      Then Perl is obviously not a scripting language.

      --

      I'll see your senator, and I'll raise you two judges.
    12. Re:Scala is a scripting language? by jeremyp · · Score: 3, Informative

      Scala is basically C++ on the JVM.

      No. Scala is a functional programming language, it's nothing like C++.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    13. Re:Scala is a scripting language? by Lawrence_Bird · · Score: 1

      Scala is not C++, sorry.

    14. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      Java write once and run on a very particular version of the virtual machine on a single operating system/machine combination.
      What a joke.

    15. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      FWIW, I code in Scala professionally, and I think this is a horrible description of the language. Scala's highlights are things like an incredibly powerful type system and type inference, functional style collections libraries, and its powerful pattern matching.

      A better description would be something like a more pragmatic, object oriented ML on the JVM, or Java with reduced boilerplate and some of the nice functional programming from Haskell mixed in.

    16. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      No, Scala is not functional--it's multi-paradigm, just like C++. Scala definitely facilitates functional programming better than C++, but that's not the same thing.

    17. Re:Scala is a scripting language? by AmaDaden · · Score: 1

      The wiki def for a Scripting language is "A scripting language or script language is a programming language that supports the writing of scripts, programs written for a special run-time environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator." Check out this video and you'll see that Scala can do this. Scala is a weird hybrid. It's a full powered language build on top of the JVM that can run as a script or be compiled directly in to Java bytecode.

    18. Re:Scala is a scripting language? by Anonymous Coward · · Score: 0

      WTF?

      Scala is much closer to Haskell than C++. LOL

      OCaml might be the best language to compare to Scala.

    19. Re:Scala is a scripting language? by Douglas+Goodall · · Score: 1

      That is always how I felt about COBOL, closer to English than any other language at the time.

    20. Re:Scala is a scripting language? by GuldKalle · · Score: 1

      Java can run in a console, too. Does scala have an equivalent to python or javascript eval()?

      --
      What?
    21. Re:Scala is a scripting language? by AmaDaden · · Score: 1

      Java and Scala can both be run in the console but, as the video shows, Scala can be run AS a console. Scala code can be run one line at a time in a Scala console or compiled. Java code can only be compiled. By the above given definition, this makes Scala a scripting language.

      Scala does have similar support to eval with the ScalaInterpreter class.

  6. A Man Can Dream by techprophet · · Score: 0

    A man can dream, can't he?

    1. Re:A Man Can Dream by i+kan+reed · · Score: 4, Funny

      Yes, we can all dream of a day when Oracle is just ashes on the ground, and a footnote in corporate history.

  7. If in fact it is dying... by scottnix · · Score: 1, Insightful

    I wish it would get the fuck on with it. Type erasure.

    1. Re:If in fact it is dying... by Anonymous Coward · · Score: 1

      Fixing that will be one of the main features of Java 9. It's too bad it is taking so long to address that.

    2. Re:If in fact it is dying... by Anonymous Coward · · Score: 0

      Java totally died years ago, back in the '90s. What we see now is it's reanimated zombie corpse, that shambles about, keeping itself healthy seeming via a steady diet of brains.

  8. javas not dead! by nimbius · · Score: 4, Funny

    I use it on mission critical applications at work and it does a very efficient job of testing all the functionality of Nagios to page me at 3:00 AM. I have other java applications that are designed to explore the limits of slab allocation and heap return in memory. Theres even a java application I wrote that calculates financial reports. I know what you're thinking, and yes, it performs well as it stress-tests VoIP bandwidth and the helpdesk ticket system.

    there are still so many uses for java. one of my earliest and oldest projects I still use to this day! its an application to help post Slashdot comme!####)))!%[NO CARRIER]

    --
    Good people go to bed earlier.
    1. Re:javas not dead! by Anonymous Coward · · Score: 0

      No, Java is dead.
      Steve Ballmer said so, long time ago. He also said C# is the future!

    2. Re:javas not dead! by dmbasso · · Score: 0

      I only use two Java applications: Liferea (after google reader died) and Jitsi. When I start them, I can feel the sadness in my computer. They take ages to startup, but granted, after they've started they're just like any regular native application. Though Jitsi doesn't integrate well with gtk3, but overall it is pretty good.

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    3. Re:javas not dead! by znanue · · Score: 1, Insightful

      I only use two Java applications: Liferea (after google reader died) and Jitsi. When I start them, I can feel the sadness in my computer. They take ages to startup, but granted, after they've started they're just like any regular native application. Though Jitsi doesn't integrate well with gtk3, but overall it is pretty good.

      You can't know this unless you purposefully don't want to count using web apps as "using an app". My understanding is the backend of much of the google stuff is written in Java, just as an obvious example.

    4. Re:javas not dead! by dmbasso · · Score: 1

      I use plenty of Java applications, I have an Android phone. I was referring to those that I have to run a JVM in my computer, sorry for being vague.

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    5. Re:javas not dead! by X0563511 · · Score: 1

      32-bit or 64-bit JVM?

      If you're using the 64-bit, I don't think they have a client hotspot (optimized for quick-start) JVM, only the server (optimized for runtime throughput but with a long startup) one.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    6. Re:javas not dead! by MightyMartian · · Score: 1

      Microsoft could only wish .NET had the penetration Java has. Java may have its stinky bits, but at the end of the day, it's value is its ability to run on a large number of divergent platforms, from cell phones to supercomputers, running multiple operating systems and architectures.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    7. Re:javas not dead! by Anonymous Coward · · Score: 0

      I only use two Java applications: Liferea (after google reader died) and Jitsi. When I start them, I can feel the sadness in my computer. They take ages to startup, but granted, after they've started they're just like any regular native application. Though Jitsi doesn't integrate well with gtk3, but overall it is pretty good.

      Liferea claims to be written in C, not Java. Granted, it features 'Java startup emulation', allowing you to start it and then make a cup of tea while your computer thrashes about trying to load it.

    8. Re:javas not dead! by lgw · · Score: 4, Insightful

      have other java applications that are designed to explore the limits of slab allocation and heap return in memory

      You remind me of far to many C programmers I've met (and projects I've been on).

      "Look I've reinvented that difficult plumbing built into C++ - my language is just as good as C++!"

      "Yeah. How much time did that take? How many nightmarish bugs did you overcome?"

      "Lots. And a few."

      "Time well spent then, I'm sure, and my best wishes that there's not one last plumbing bug that you'll find in the field".

      Different tools for different jobs. C++ isn't the right tool for much, but nothing else comes close for jobs that actually need the cruft that clutters C++. Taking over memory allocation is a perfect example. (Checking an object every time it's dereferenced to make sure it hasn't been freed or worse, re-used is another - man that's a stupid problem to solve in Java or C#.)

      --
      Socialism: a lie told by totalitarians and believed by fools.
    9. Re:javas not dead! by Anonymous Coward · · Score: 0

      That's unpossible! Only Java is slow to startup! Therefore if it's slow it is written in Java. QED.

    10. Re:javas not dead! by dmbasso · · Score: 1

      Damn, you are right! The worse part is that I just assumed it was Java because it was slow (the whole startup behavior matched the Java timing pattern), but I never actually verified. In the end it was just terrible coding...
      I apologize for my misinfo and prejudice... ;)

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    11. Re:javas not dead! by RCL · · Score: 1

      I don't think "an app" applies to web "applications" and not sure those two will ever blend. The depedency on a (good) connection is still a problem, if you are commuting or, say, torrenting. Even on mobile devices, people want offline maps and offline dictionaries precisely for the reason of being location-independent.

    12. Re:javas not dead! by RCL · · Score: 3, Insightful

      Java abstracts away all the fun in programming. You cannot really target specific hardware with it, and it means you cannot get (close to) maximum performance on any given piece of hardware - you are deprived of control over processor cache, memory locality of data and code, or access to vector instructions. JIT, which "compiles" the code piecewise, is at obvious disadvantage compared to a proper compiler that has global view of the program (and JIT is also more time constrained, compiler can spend hours compiling the code), and uncontrollable garbage collector means that you will have hard time enforcing even "soft realtime" requirements.

      Different people may look differently, but for me, all that means that Java is suboptimal for games or other heavily performance-oriented stuff, and this is the only kind of software I enjoy programming. Making performance-insensitive backends full of "business logic" is for someone who is in the software industry for money only...

    13. Re:javas not dead! by petsounds · · Score: 2

      I think people find different sorts of fun in programming. For you, the fun may be getting down to the metal and squeezing every drop of hardware performance. For others, the fun may lie in the expressiveness of the language itself, where code feel more like poetry. In both cases Java misses the mark. Java feels more like it was designed by the same people who designed Soviet apartment blocks – soulless and severe. Entirely focused on function without the human form in mind, or any aspirations to truly inspired work.

    14. Re:javas not dead! by RCL · · Score: 1

      I like that comparison with soulless apartment blocks. To be fair, it wasn't only Soviets who built those - I have seen similar unimaginative housing in US, too. Either way, Java indeed feels like a typical business, "no nonsense" solution and I can picture a grey, dull world of a corporate 9-to-5 programmer for whom Monday is the worst day of the week. Don't want to work like that.

    15. Re:javas not dead! by Anonymous Coward · · Score: 0

      Hmmm you do realize that they write financial trading platforms on the JVM ? (check out LMAX http://martinfowler.com/articles/lmax.html ), they also use the JVM for high frequency trading ( lots of examples all over google)

      Not to mention that the main problem is usually early optimization. write your stuff on the JVM, find a hotspot, optimize it, isn't enough, use jni bindings and C, still not enough ? sure go down to assembly, though I doubt you can manually optimize better than JIT which can actually reoptimize on the fly based on actual data at runtime.

    16. Re:javas not dead! by RCL · · Score: 1

      I know that some HFT platforms are written in Java, but I think this is caused by other reasons than trying to attain maximum performance. E.g. it is certainly harder to find programmers who have both high- and low-level skills (i.e. know hardware well and have good understanding of math, for instance).

      As for "better than JIT" argument, I think you are putting too much trust into a rather generic approach. Even traditional (and performance oriented) compilers don't handle all use cases well and you can hit a roadblock there too, let alone all the fundamental problems with "managed" code (e.g. random memory access patterns which hurt CPU caches, various safety checks, stack-based VM design that doesn't map well to register-based hardware - stack-based processors are at inherent performance disadvantage, by the way, that's why Intel shunned FPU in favor of register-based SSE). My statement of JIT weakness is supported by the well-known fact that server-side software rarely has great single-thread performance (and often it doesn't need it, but it's another topic), so server CPUs tend to have gobs of cache in order to alleviate that.

      Again... language (syntax, etc) doesn't matter much for me, I wouldn't mind Java if it allowed me to get as close to hardware as possible, even via non-portable extensions. It's the layers of code to profile and debug through and resulting feeling of not being in control is what I don't like.

    17. Re:javas not dead! by Xest · · Score: 1

      "As for "better than JIT" argument, I think you are putting too much trust into a rather generic approach."

      It's not generic, that's the point. You have a JIT compiler specific to the platform, or at least, a generic one configured for the platform on which it has been installed, and that allows it to optimise for the specific platform it is executing on. In contrast, with, say, C++, you tend to only compile for a generic architecture, otherwise you end up with a combinatorial explosion of binaries for every case. This is why all in all, Java normally performs as well as C++.

      "My statement of JIT weakness is supported by the well-known fact that server-side software rarely has great single-thread performance (and often it doesn't need it, but it's another topic), so server CPUs tend to have gobs of cache in order to alleviate that."

      What do you mean server-side software doesn't have great single-thread performance? I could write a WCF web service right now and set it to single thread mode and it'll perform exactly the same on a desktop as it will an equivalently performant server. There's a lot of server software that's optimised for multi-threaded environments, but that's because normally when you're serving you rarely want to only be able to serve one client at a time and normally want to be able to serve multiple clients simultaneously. Server CPUs having more cache has literally fuck all to do with JIT compilers, I don't know where you came up with such an absurd idea. Server CPUs have more cache because a) corporations that buy such servers are more willing to accept the additional cost of greater CPU cache than consumers who would balk at CPU prices if consumer CPUs had more cache, and b) because it's extremely beneficial for many server applications, for example, databases.

      "I wouldn't mind Java if it allowed me to get as close to hardware as possible, even via non-portable extensions."

      Then pay attention to the GP's suggestion of using JNI. Sure you're not writing in Java, but that's not what Java was ever designed for. For the bits where you genuinely need to go native though, Java provides an interface, whilst for the bits where you don't, you can avoid all the pitfalls that come with doing so and gain the benefits of Java.

    18. Re:javas not dead! by Anonymous Coward · · Score: 0

      Java abstracts away all the fun in programming. You cannot really target specific hardware with it, and it means you cannot get (close to) maximum performance on any given piece of hardware - you are deprived of control over processor cache, memory locality of data and code, or access to vector instructions. JIT, which "compiles" the code piecewise, is at obvious disadvantage compared to a proper compiler that has global view of the program (and JIT is also more time constrained, compiler can spend hours compiling the code), and uncontrollable garbage collector means that you will have hard time enforcing even "soft realtime" requirements.

      Different people may look differently, but for me, all that means that Java is suboptimal for games or other heavily performance-oriented stuff, and this is the only kind of software I enjoy programming. Making performance-insensitive backends full of "business logic" is for someone who is in the software industry for money only...

      "Java abstracts away all tun fun in programming" -> this is exactly the power of that language. It abstracts away some details for the sake of concentrating more on your target business logic but it does not prevent you completely from accessing those details. Have a look and a read on http://mechanical-sympathy.blogspot.de/ and on the works of people like Peter Lawrey. There you will see, that you can program with Java as close to the hardware as possible. Who told you also that you are totally bound to garbage collection? Ever heard of memory mapped files in Java? And who told you that any developer out there can outperf a very well written general purpose garbage collector, like the ones located in JRockit and the newer versions of JRE? Arguments like uncontrollable garbage collection are out of scope and just show that you have never really worked with Java. Uncontrolled garbage colleciton can only happen, when your program is not efficient. Tuning the garbage collector is part of programming in Java and that forces you also to take a closer look to the nature of your data and behaviour of your program more than in any other language, where sometimes a best effort memory cleanup is used in order to get away of the problems. Moreover, there is a tendency and continuous research for people to move to garbage free data structures and programs, which are quite a challenge to write (like disruptor pattern from Google).

    19. Re:javas not dead! by tibit · · Score: 1

      Checking an object every time it's dereferenced to make sure it hasn't been freed or worse, re-used is another - man that's a stupid problem to solve

      What are you talking about? This applies neither to C++ nor to Java. Heck, there is in fact no way of checking for either directly, whether in C++ or in Java. You can hack around it in C++ by adding code to the destructor that will mark the object as "freed" in some global dictionary, but what's the point of doing that I wouldn't know. If you need such code, you're doing it wrong.

      In Java it's even simpler: if you can access the object, it's there, or you've hit a garbage collector bug or a bit flip in your hardware. There's basically no way of freeing an object. You can reset the reference, but that's it. It's same as in modern C++: if you use std::weak_ptr, you may get a nullptr and you must check for it. If you use a std::shared_ptr and it's non-nullptr, the object is there, and it won't magically become nullptr unless you reset it.

      --
      A successful API design takes a mixture of software design and pedagogy.
    20. Re:javas not dead! by lgw · · Score: 1

      what's the point of doing that I wouldn't know. If you need such code, you're doing it wrong.

      Ahh "I don't understand the ned for it, so there is no need for it and you're just wrong". Are you perhaps a manager?

      The need arises for complex embedded programming: appliances, storage networking boxes, some normal networking boxes (though much of that work actually uses functional languages), and so on. When you're coding for multi-year uptimes and need to be utterly, absolutely sure beyond any doubt that not only do you have no resource leaks, but that you have no "dangling pointers". Slab allocation makes dangling pointers the chief cause of corruption, and a much bigger security problem than in normal code, because a pointer to a object that has been freed will almost certainly become a pointer to a valid object of the same type soon enough.

      Marking the object as "freed" does you no good, because that object will be re-used by the next alloc and marked "good" again.

      Java is unsuitable for this sort of coding, unless perhaps you hack around to make slab allocation work in some way (which would bring these problems along), because it's quite important that the space reserved for each specific type of object be known and fixed in advanced.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    21. Re:javas not dead! by RCL · · Score: 1

      Thanks for the link, it's an interesting read. Still, I don't see any reason to use Java for performance work given that there are closer to metal languages available. It's like imposing an artificial limitation on myself, and then fighting hard to overcome it.

    22. Re:javas not dead! by RCL · · Score: 1

      JIT is generic in a sense that each program (and even different parts of a single program) is different and you cannot base them all on a common framework. E.g. in C++ sometimes you have to abandon STL at all because you cannot allow dynamic memory allocation (and memory fragmentation it causes). I wouldn't say that "Java performs as well as C++", unless you are speaking about UI-heavy programs where bottleneck is user input - or, alternatively, C++ programs written by people who don't know how CPUs implement a virtual method call and why it's slower than a non-virtual one.

      Yeah, with native languages you are bound to a specific architecture (and even variations of it, e.g. AVX, SSE), but is it better to be a jack of all trades and master of none? And also, there's no "explosion of binaries" anymore - unfortunately, the number of architectures available is continuously shrinking (kind of undermining that design goal of Java). "Boring" native software that is not performance-tuned may very well ship just a generic binary targeted at, say, all Pentium IV and higher CPUs.

      Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance. That is also the reason why Java can be used server-side without much problems, too. However, once you bring it to desktop, where performance matters, it starts to suck immediately. That's not a problem of Java, though, but all managed languages - .NET also sucks. Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)

      Sure, when I'm forced to use Java (e.g. Android), I immediately use the JNI window to escape. I am not interested in "benefits" of Java, if it means that I need to waste even more time trying to profile the application. Is there any low-level Java profiler, by the way, which would tell where CPU is burning cycles in your code at? Down to the level of assembly - i.e. something like perf annotate.

    23. Re:javas not dead! by Xest · · Score: 1

      "JIT is generic in a sense that each program (and even different parts of a single program) is different and you cannot base them all on a common framework."

      What does this have to do anything? That describes just about every language ever or are you under the impression that the JCL doesn't exist?

      "I wouldn't say that "Java performs as well as C++", unless you are speaking about UI-heavy programs where bottleneck is user input - or, alternatively, C++ programs written by people who don't know how CPUs implement a virtual method call and why it's slower than a non-virtual one."

      No, I'm saying it performs as well as C++ in most cases. Virtual method handling is one example as to why, the JIT has a better view at execution time as to what can and can't be inlined, so it can inline much more than a statically compiled C++ program possibly can.

      "Yeah, with native languages you are bound to a specific architecture (and even variations of it, e.g. AVX, SSE), but is it better to be a jack of all trades and master of none?"

      Well that's precisely the problem you face if you don't have an explosion of optimised binaries, unless you want to accept that the JVM is going to optimise more efficiently. It's not just about compiling for different architectures, it's about the JIT automatically being able to optimise to take advantage of extensions, and other hardware that may be present too. It can optimise dependent on amount of RAM, cache sizes etc. - something that just isn't known when you compile a plain old generic C++ binary for, say, the generic x86 platform.

      But there are a number of other things it can do better too - better loop vectorisation (as a result of better inlining of virtual functions) and more efficient heap allocations for example.

      "Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance."

      This is nonsense. It depends entirely on the application. A heavy load web server for example may not really be I/O bound in the slightest depending on the size and what it does. Bulldozer is designed for optimisation of performance per watt, you're again confusing cause and effect as to why some things are the way they are.

      "That's not a problem of Java, though, but all managed languages - .NET also sucks."

      Really, the problem is simply that you don't understand managed languages. Your understanding of the optimisations performed by JIT compilers is clearly woefully inadequate to being making this sort of comment. Your comments on server applications just don't even make sense for the most part to the point I'm not even sure you have the slightest grasp of what sort of things servers commonly serve.

      "Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)"

      This is just further nonsense. There was a Microsoft research project to try and build such a thing, and they did, and open sourced it. I don't know what you mean by "Now they are going native :)", they've always been native with their operating systems. If you were expecting their managed OS to cause them to throw out 3 decades of legacy code then you have a disturbing view of how software is developed.

      It was a research project and nothing more, and even then it wasn't purely managed, they still had to bootstrap natively because no one ever pretended that managed languages are designed to do such low level operations. You can find out more about it here:

      http://research.microsoft.com/en-us/projects/singularity/

      It's worth noting though that some of the things learnt from this research project have already made their way into Windows, but that's kind of the point of r

    24. Re:javas not dead! by RCL · · Score: 1

      No, I'm saying it performs as well as C++ in most cases. Virtual method handling is one example as to why, the JIT has a better view at execution time as to what can and can't be inlined, so it can inline much more than a statically compiled C++ program possibly can.

      You realize that JIT is inherently limited to a tiny bit of program which it compiles? JVM cannot spend neither time nor RAM building a whole program tree and making global optimizations like compilers can. And by the way, if you think that compilers are limited to static analysis only - there's also profile-guided optimization.

      Well that's precisely the problem you face if you don't have an explosion of optimised binaries, unless you want to accept that the JVM is going to optimise more efficiently. It's not just about compiling for different architectures, it's about the JIT automatically being able to optimise to take advantage of extensions, and other hardware that may be present too. It can optimise dependent on amount of RAM, cache sizes etc. - something that just isn't known when you compile a plain old generic C++ binary for, say, the generic x86 platform.

      But there are a number of other things it can do better too - better loop vectorisation (as a result of better inlining of virtual functions) and more efficient heap allocations for example.

      In theory, it could do that. But if you do a reality check, you'll find out that JVMs right now are pretty mediocre compilers that lack even basic optimizations. Again, everything that JVM does, can be done by a compiler, but not vice versa. Compilers have nearly unlimited time and can spend gobs of RAM analyzing the program. They can use profile-guided optimization, allowing you to gather stats from a compiled program and then recompile it to better account for runtime behavior - if needed.

      Oh, and while we're at it, fine-tuning assembly with specific CPU in mind does not matter these days except for SIMD ops. Waiting for memory accesses dominates CPU time - and here Java is at inherent disadvantage because you cannot really control memory layout of your data.

      "Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance."

      This is nonsense. It depends entirely on the application. A heavy load web server for example may not really be I/O bound in the slightest depending on the size and what it does. Bulldozer is designed for optimisation of performance per watt, you're again confusing cause and effect as to why some things are the way they are.

      Before you call this nonsense, go read some analysis and check benchmarks.

      "That's not a problem of Java, though, but all managed languages - .NET also sucks."

      Really, the problem is simply that you don't understand managed languages. Your understanding of the optimisations performed by JIT compilers is clearly woefully inadequate to being making this sort of comment. Your comments on server applications just don't even make sense for the most part to the point I'm not even sure you have the slightest grasp of what sort of things servers commonly serve.

      "Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)"

      This is just further nonsense. There was a Microsoft research project to try and build such a thing, and they did, and open sourced it. I don't know what you mean by "Now they are going native :)", they've always been native with

    25. Re:javas not dead! by ahabswhale · · Score: 1

      Your notions about JIT compilers and Java performance is really outdated. Java is extremely fast and the JIT is actually an advantage over traditional compiler optimization in that it evaluates what the program is actually doing as it's running to perform performance tuning. A traditional compiler has no insight whatsoever to what code gets hit hard and what doesn't. I've been writing Java a very long time and I have yet to run into a situation where a performance problem was due to poor performing Java. In fact, with the exception of very specialized situations that applies to less than 1% of all coding, I don't think there's a situation where Java's performance would ever hold you back.

      --
      Are agnostics skeptical of unicorns too?
  9. Android is not always Java by Anonymous Coward · · Score: 0

    "When you add in the Android ecosystem, whose native development language is Java" - unless your app is a NativeActivity running C / C++ or C# (Mono) without a shred of Java.

    1. Re:Android is not always Java by bluefoxlucid · · Score: 2

      It would have been better if Android supported Python instead of Java.

    2. Re:Android is not always Java by i_ate_god · · Score: 4, Informative
      --
      I'm god, but it's a bit of a drag really...
    3. Re:Android is not always Java by binarylarry · · Score: 0

      Leesin here fella! Android would have been better if it had used !

      That's proof you see!

      --
      Mod me down, my New Earth Global Warmingist friends!
    4. Re:Android is not always Java by BreakBad · · Score: 1

      kivy.org

    5. Re:Android is not always Java by Anonymous Coward · · Score: 1

      Great idea! Let's implement everything on our phone in an incredibly slow, dynamically typed language, whose only relevant implementation has a GIL and a pathetically bad concurrency model! That will be great for performance and battery life!

      Google is dropping Python for a reason.

    6. Re:Android is not always Java by Aguazul2 · · Score: 1

      It would have been better if Android supported Python instead of Java.

      To develop stable applications quickly, you want MORE compile-time checking, not less. Like if Java could mark variables as nullable or not and compile-time check that (there are some extensions for that, but they don't always keep up). Java/JVM does so much right ... If people can't see that, then I suggest they attempt some reasonably large project in several languages and compare. (I have done exactly that, in C, Vala and Java; Rust will be next when I get some time.)

    7. Re:Android is not always Java by bluefoxlucid · · Score: 1

      Actually, Python is strong-dynamic-duck-typed and pre-compiles. Each time you install a Python module, the package manager runs Python to load it as a privileged user--which automatically generates a .pyc and a .pyo compiled native object in the module directory. There are many further implementations of Python (including the ridiculous Pypy, a Python interpreter written in Python) that are compatible with the language; Google supplies Dalvik, a Google-written implementation of Java, so I fail to see why it's any huge obstacle for them to have supplied a Google-written implementation of Python instead.

      Java was used for strategic reasons, not technical reasons.

    8. Re:Android is not always Java by bluefoxlucid · · Score: 0

      Python is a strongly-typed language, which I like; Perl is a mess. I like how Python will compile-check and then runtime-check, is easy to test, and will throw an exception and traceback for the tiniest thing that any sane language should sensibly handle. You mean I can't pass a number as a string to be printed, I have to str() it? Idiot language, Perl automatically knows that! ... but then again Perl applications never work and are impossible to debug...

    9. Re:Android is not always Java by Waffle+Iron · · Score: 1

      Great idea! Let's implement everything on our phone in an incredibly slow, dynamically typed language, whose only relevant implementation has a GIL and a pathetically bad concurrency model! That will be great for performance and battery life!

      Google is dropping Python for a reason.

      If Google had used Sun's Java VM for Android, performance and battery life would have been even worse than you predict for Python. However, Google deployed their own implementation of Java that was specifially tailored for mobile platforms.

      There's no reason they couldn't have done the same thing with Python; there are several independent implementations of Python targeted at different use cases. They have the relevant technologies with their accelerated Javascript engines.

    10. Re:Android is not always Java by IamTheRealMike · · Score: 4, Informative

      NativeActivity doesn't support most of the Android APIs, including most obviously the widget toolkit. It's intended for games that just need an OpenGL context and raw input, all other kinds of apps still need to use Java.

      And you know what? That's not such a bad thing. A few years ago I guess I was basically a C++ programmer who was in the "Java sucks" camp, and I came back to Java only because I wanted to write stuff for Android. Over time I've come to appreciate the whole platform and ecosystem more. Things I especially appreciate:

      • IntelliJ IDEA and the Inspector. My previous experience with Java IDEs was Eclipse, which is not only incredibly slow and resource intensive but also has a very confusing IDE. Over the years this situation has changed - IntelliJ is genuinely helpful, and uses much more reasonable amounts of RAM than such IDE's used to. I find myself very much appreciating the real-time, on the fly static analysis that can find all kinds of issues from basic logic bugs to common API usage errors, like inverting the arguments of assertEquals in a unit test.
      • Most Java libraries are available via Maven repositories. Maven itself is a rather quirky beast that I never truly warmed to, but the Java world has what is essentially a giant apt-get for libraries. IntelliJ understands how work with Maven such that you can write some code that doesn't compile, press alt-enter over the missing class and tell it to go figure it out. It can find the right library, automatically download it and all its dependencies, install it into the local Maven repository and recompile the code, all on the fly within a few seconds. Coming from the C/C++ world where every single project has a uniquely malformed build system and package repositories (when they exist at all) are maintained by Linux distributors who are invariably miles behind upstream releases, it's extremely convenient.
      • JavaFX 8 turns out to be a really nice UI toolkit. Java got a well deserved reputation for awful desktop apps that were clunky, slow, and had UIs only a mother could love. This problem started with AWT that was limited by the lowest common denominator (Motif at a time when nearly the whole world used Windows). Swing was more powerful but was still very ugly and was hobbled by the lack of any truly great UI designers for it (every IDE creator invented their own). JavaFX 8 resolves all these problems: it's designed to be competitive with Cocoa, so the whole thing is an OpenGL accelerated scene graph, it makes it easy to support fancy effects and animations, and it comes with a very straightforward and easy to use Scene Builder app that makes building UIs a snap. I've used the Apple GUI design tools and Scene Builder is even easier. JFX8 seems to make desktop app development with Java actually compelling again.
      • Lots of people know it. That means, for an open source project, lots of potential contributors.
    11. Re:Android is not always Java by Anonymous Coward · · Score: 1

      I never said Python wasn't strongly typed, and Python bytecode is basically nothing more than an AST. Every existing Python implementation, including PyPy, is ridiculously naive and years behind the JVM, the CLR, or modern JavaScript implementations. Languages like Python are also much harder to optimize due to how dynamic they are. Like JavaScript, it would take an absolutely massive investment to make a decent Python implementation and no one with the resources cares enough to do it.

    12. Re:Android is not always Java by Anonymous Coward · · Score: 0

      If Google had used Sun's Java VM for Android, performance and battery life would have been even worse than you predict for Python

      Java might be a shitty language, but the JVM blows away any existing Python implementation and is still significantly faster than any JavaScript implementation. Performance would be far better on the JVM as long as they weren't spawning a new JVM for every process.

      It must just kill you that Google deprecated Python and got rid of Guido.

    13. Re:Android is not always Java by Waffle+Iron · · Score: 1

      Java might be a shitty language, but the JVM blows away any existing Python implementation

      You're right: The JVM blows away almost any other language in terms of megabytes of physical memory wasted and CPU cycles consumed before getting to main(). And you're not going to be able to run the whole system in one JVM to try to combat this.

      and is still significantly faster than any JavaScript implementation.

      Mostly irrelevant. Java needs to be fast because most of its libraries are written in Java. Other languages tend to use native code for most libraries, and that's just tied together with the users' business logic. A high-tech JIT-compiled Python would almost certainly be "fast enough".

    14. Re:Android is not always Java by Hypotensive · · Score: 1

      You may not have noticed but a number of manufacturers are going down the road of using HTML5 web apps as their mobile application platform. JavaScript certainly seems to fit your description. Actually, it doesn't have a concurrency model at all.

      When Java first came out it was also incredibly slow and had a pretty primitive concurrency model. It's taken many years and a crapload of cash to get it to where it is now. Python hasn't had any cash to speak of.

    15. Re:Android is not always Java by angel'o'sphere · · Score: 1

      Python rund fine on Android.

      The Android Java VM and the Android Java dialect are nevertheless helpfull, as you have interfaces to describe services and compile time type safty.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    16. Re:Android is not always Java by Anonymous Coward · · Score: 0

      A high-tech JIT-compiled Python would almost certainly be "fast enough".

      Then get to making it, because the people that have the resources to do it, no longer give a fuck about Python.

      Other languages tend to use native code for most libraries

      This is only true for terribly inefficient garbage like Ruby and Python and that's simply because they have no choice in the matter. This isn't a problem for C#, F# Scala, Clojure, Haskell, ML, Lua, Common Lisp etc.

      This is also extremely limiting because most Ruby and Python programmers simply can't write reliable and secure C.

    17. Re:Android is not always Java by angel'o'sphere · · Score: 1

      Erm, how can your first sentance and the last one fit together?
      Exactly because Python is dynamic typed it is inferior as a systems programming language in regards to Java.
      The obstwcle is the "instead".
      Especially as there are python implementations for android, your rant is obsolet, just take them.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    18. Re:Android is not always Java by X0563511 · · Score: 1

      I've never seen Python do that on my systems. Those files (.pyc) don't appear until I actually cause them to be loaded for the first time. I think you're confusing what python does with what your distribution maintainers do :P

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    19. Re:Android is not always Java by X0563511 · · Score: 1

      I don't appreciate having to pay for the IDE for personal or educational use. IntelliJ can fuck off, back to Netbeans/Eclipse I go.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    20. Re:Android is not always Java by dkf · · Score: 1

      Swing was more powerful but was still very ugly and was hobbled by the lack of any truly great UI designers for it (every IDE creator invented their own).

      I've seen non-ugly GUIs done with Swing. I'm pretty sure they're a demonstration of the fact that pigs can fly as long as you provide sufficient TNT-derived thrust (and that you don't really want to stand underneath as the pieces soar overhead).

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    21. Re:Android is not always Java by IamTheRealMike · · Score: 1

      IntelliJ IDEA Community Edition is both open source and free, so your comment is a pretty epic failure. As it happens I bought the Ultimate edition during their end-of-the-world sale that was in the hours before the Mayan calendar predicted armageddon, so I got it cheap. Best doomsday scenario ever!

    22. Re:Android is not always Java by bluefoxlucid · · Score: 1

      I said the package manager does it. When you run Python, it generates the .pyc and .pyo files for modules loaded:

      Each time you install a Python module, the package manager runs Python to load it as a privileged user

      The .pyc and .pyo files for system libraries are generated at installation time, because a non-privileged user running a Python application wouldn't be able to store those files in a system-wide location (for good reason: you could store malicious ones and jump across security zones by injecting code into other users' applications by replacing some runtime files with new ones that get loaded the next time they use that application).

    23. Re:Android is not always Java by X0563511 · · Score: 1

      Search for "intelliJ IDEA" and try to find any mention of that on their page. Not quite so epic a failure in reality, was it?

      Nice catch on the deal though.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    24. Re:Android is not always Java by bluefoxlucid · · Score: 1

      It's an application programming language, not a system programming language. Android is a Linux system written in C and C++ mostly.

      The argument was that the current Python implementation wasn't good enough; the counter-argument is that neither was Java, since Google wrote their own and use a different bytecode. (Oracle sued Google because Google "java" wasn't real "Java").

    25. Re:Android is not always Java by bluefoxlucid · · Score: 1

      Google wrote their own JVM because the JVM is a piece of shit that wouldn't work. They use a different bytecode completely incompatible with Java JVM bytecode. Uncompressed Dalvik is smaller than compressed JAR for the same Java class. It's also faster, and consumes less RAM.

    26. Re:Android is not always Java by IamTheRealMike · · Score: 1

      Yes, I have too - IntelliJ itself is written using Swing and it's quite appealing on all the platforms I've used it on. But I guess that they had to develop custom themes for it and be very careful to achieve that.

      JFX8 looks great out of the box. It supports hi-dpi/retina displays and has a generic cross-platform theme called Modena which is a lot more tasteful than previous Java desktop themes. It doesn't match any particular platform, but I've been writing an app with it on the Mac and it can actually look better than Aqua sometimes. Still, the theming system is powerful enough that you can also get AquaFX which matches the theme in MacOSX Mountain Lion (it's done by a third party).

      Just to ram home the point about Maven+IntelliJ, enabling AquaFX in my project involved typing in the following code:


                      if (System.getProperty("os.name").toLowerCase().contains("mac")) {
                              AquaFx.style();
                      }

      (you're only allowed to use AquaFX on a Mac because of the art being copyrighted by Apple, etc).

      Of course AquaFx is an unknown class, so I just asked for an auto correct there, told it to find the class in Maven, then did an interactive search for AquaFX in the resulting dialog. Press enter, and it was downloaded+installed in the background. Also the build system definition (an XML file) was updated so people building from the command line or using other IDEs would also see the dependency. A few seconds later the code is no longer red and the app runs.

      It may well be that .NET has something similar, and I know most scripting platforms have this sorted out these days too, but it's nevertheless very convenient to have it so tightly integrated.

    27. Re:Android is not always Java by markhb · · Score: 1

      I just Googled IntelliJ IDEA (didn't use quotes), and two of the links that were neatly arranged for me were "Community Edition" (which seems like a Big Flag to me) and the Download page, which as noted above includes both the full-featured and open-source variants side-by-side. It's also worth noting that Google has adapted IDEA into the "official" Android IDE.

      --
      Save Maine's economy: write stuff down. All comments are exclusively my own, not my employer.
    28. Re:Android is not always Java by Anonymous Coward · · Score: 0

      I think you would find that it's less "the JVM is a piece of shit" and more "the JVM isn't optimized for embedded devices."

    29. Re:Android is not always Java by jonabbey · · Score: 1

      Yes, I have too - IntelliJ itself is written using Swing and it's quite appealing on all the platforms I've used it on. But I guess that they had to develop custom themes for it and be very careful to achieve that.

      JFX8 looks great out of the box

      Agree about the difficulty with Swing. Swing permits different look and feels to differ too much in essentials like ordering of operations, focus, and etc. It makes it very hard to adjust the styling of individual components and expect it to do anything reasonable in different look and feels.

      JavaFX sounds really good, but I've not yet developed against it. Thanks for the link to SceneBuilder, I look forward to playing with it.

    30. Re:Android is not always Java by Anonymous Coward · · Score: 0

      It's also faster, and consumes less RAM

      It uses less memory but it's definitely not faster at anything other than start up time. The JVM absolutely demolishes Dalvik for long running processes where low memory footprint and start up time aren't as much of an issue. This has been tested extensively at Google and all of our internal app servers still use the JVM because of this.

    31. Re:Android is not always Java by Anonymous Coward · · Score: 0

      IntelliJ has a community edition

    32. Re:Android is not always Java by angel'o'sphere · · Score: 1

      You are not mixing apples with pears but with stones. Hint: a stone is not fruit.

      Google implemented its own VM for Java because they had certain goals they could not achieve with the original concepts/implementations of the Sun JVM. Perhaps you might read about the inception and evolution of the Dalvik VM?

      That has noting to do with the language.

      On Android obviously Java is a systems programming language. Or why is it used for most system level programming?

      The argument was that the current Python implementation wasn't good enough
      That is your argument or the argument of an idiot whom you follow. Python simply is not suited for "applications" that interact via interfaces with other applications (like accessing the contacts book and the calendar and sending an automatic birthday greeting text message). Why? Because you can not define typesafe the interfaces in Python to:
      -- the address book
      -- the calendar
      -- the text message system

      Python was always mature, that never was the question. It is just unsuited to certain tasks.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    33. Re:Android is not always Java by ed1park · · Score: 1

      John Carmack @ID_AA_Carmack 26 Sep

      Hardware does get faster more rapidly than software gets slower -- I'm finding Eclipse perfectly usable on modern hardware.

    34. Re:Android is not always Java by IamTheRealMike · · Score: 1

      I searched that, clicked the first link, clicked download, and on the right hand side is "Community edition: FREE". I'm not sure how much clearer they could make it ...

    35. Re:Android is not always Java by X0563511 · · Score: 1

      I don't know what to say. I didn't know it existed until it was pointed out, here.

      Granted, I did not proceed to the downloads pages. Why would I do that when all other indications are that it's pay-for software? I have zero interests in trials or shareware, which is what you'd expect to see.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    36. Re:Android is not always Java by bluefoxlucid · · Score: 1

      What is "system-level programming"? Is the graphics system written in Java? Of course not; it's C++. SMS application? That's in Java; it's an application. Dialer application? Java, it's an application.

      Unless you want to start expanding "System level programming" to include "Web browsers and e-mail applications", Android's system is not in Java.

      That is your argument or the argument of an idiot whom you follow.

      This was the argument made:

      Great idea! Let's implement everything on our phone in an incredibly slow, dynamically typed language, whose only relevant implementation has a GIL and a pathetically bad concurrency model!

      I could argue about whether he's flat wrong about Python being slow or having bad concurrency; or I could cite that Google wrote their own JVM.

      Why? Because you can not define typesafe the interfaces in Python to:
      -- the address book
      -- the calendar
      -- the text message system

      If you try to do this in python:

      apple = "apple"
      apple = 5

      Python throws an error because "apple" is of type "string". Python is strongly typed, but it's dynamically typed: once you define a variable, it gets an unchanging type. Assigning another type to that variable is not allowed.

      class AddressBook:
      name = str("")
      phonenumber = int(0)

      Create a class as so and your class is type-strong. Not to mention Python has a robust implementation of C and C++ binding in both directions, so you can bind C++ APIs to Python in a type-safe manner. Still, the Address Book and Calendar and such are likely written in Java, and thus in our thought experiment would be in Python; you would define the classes to carry certain types of data directly in Python, not bind to a back-end C library.

    37. Re:Android is not always Java by angel'o'sphere · · Score: 1

      The android platform is a linux kernel written in C.

      On top of that are systems that are necessary to run a phone. And bet those are not all written in C.

      I consider interacting with the "platform" like sending an SMS system level programming. And much of that is written in Java. But perhaps you are right and it is more application level programming.

      Regarding your python examples, I know that. But how good is it to have such an exception on a running application on a phone instead of a compile time error?

      You can describe an interface in Python, but you an not enforce correct usage.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    38. Re:Android is not always Java by bluefoxlucid · · Score: 1

      Ah, so the issue isn't that there isn't strong typing; it's that the compiler for a C or Java app runs through the code and cross-verifies types, while in Python you don't have a static checker. Python's duck-typing makes it difficult to write a static checker, and so you would get only limited success: You'd have to follow each possible branch and determine if a value could get initialized to something else, and raise an error on an absolute yes.

      In other words: your argument is that any language with duck typing is inherently wrong for any application that people are expected to use.

    39. Re:Android is not always Java by angel'o'sphere · · Score: 1

      In other words: your argument is that any language with duck typing is inherently wrong for any application that people are expected to use.
      No that is not my argument.

      My argument was as before: in a static typed language you can define interfaces to other parts of the system. And enforce the correct usage.

      In languages like Python you can only describe interfaces (which means you require the human to read carefully) but can not make sure they are used correctly.

      That means it is easy to deploy an application on a phone which fails later to runtime errors due to interacting with other apps/services etc.

      There are plenty successful examples where duck typed languages where used. I'm fully aware of that.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    40. Re:Android is not always Java by bluefoxlucid · · Score: 1

      Duck-typing is a special type of dynamic typing. It's inherently not static typing.

    41. Re:Android is not always Java by angel'o'sphere · · Score: 1

      Sigh, everyone knows that, so is the rest of your post missing or what is your point? Or well, you are only half right, ofc it is not static, but all dynamic typing systems that use dynamic message dispatch are duck typed. Duck typing is only a lay mans term to use that stupid saying: "does it walk like a duck ... etc."
      The only dynamic typing systems that are not "duck typed" are languages like perl.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    42. Re:Android is not always Java by bluefoxlucid · · Score: 1

      Your argument was that static typing is necessary to create a language with restrictions which prevent misuse of interfaces. That means inheritable typing (i.e. class inheritance, where you define and explicitly use a class or its descendents which inherit its interface), but not duck typing (i.e. where you shove something at it, and as long as it reacts in a meaningful and appropriate way to the same way to the same member calls and provides the same attributes and other interfaces then it's correct).

      Duck typing is a piece of technical jargon; it's not a lay-term. Duck typing is a term similar to "Floating Point Unit" and dissimilar from "Math coprocessor" (which is still kind of jargony but eh).

      In any case, you seem to be arguing that the specific set of code verification afforded by a specific subset of static checking (that being compile-time checking) is required for code quality reasons, without accepting any other form of verification.

      To take this down to a risk management level, you're attempting to partially mitigate the risk of improper type usage with standard interfaces (a subset of "bad code" risk) in high-importance applications (SMS application, e-mail application, Contacts, etc.) by using compile-time type checking with a statically typed language. I believe you're over-estimating the risk, as your risk domain is limited to core applications and interfaces which are subject to extra scrutiny including extensive testing and code verification. The resources expended on these applications are high enough that creating and using a static checker and taking up coding practices to enable higher accuracy from the static checker in high-importance code paths would be a reasonable additional expenditure (remember, they did write their own JVM for the Android system), allowing for further mitigation if desired.

      These risk considerations are interesting because you can consider the accessibility of Python as a risk: Python is easy to code in, and easy to debug, and easily portable; this could have marketing impacts or code quality impacts (i.e. if code written in Python by equally skilled parties expending equal resources is more likely to have fewer defects than code written in Java, then Python has lower code quality risk; this is a primary argument against C and C++, with many considering these languages magnets for bugs and feeling that similar skill will produce more defect-free Java or C# or Python code than C or C++ code).

      As a final note: I can convert most strategic arguments (like the decision between which language to use) into risk evaluation; I can't necessarily evaluate that risk, as it requires expert judgment. The evaluation of Python versus Java would require not only a deep understanding of each language, but also of the use of each language: knowledge of strengths and weaknesses in complex programming tasks equivalent to the tasks undertaken in the target environment are required, as well as practical comparisons of defect rate both for similarly skilled programmers and in general (because i.e. maybe Python produces fewer bugs from decent Python programmers; but maybe there's more Java programmers at a reasonable level, and so most programmers would be Python n00bs that write shitty Python code). Further, mitigation may be possible with additional effort, as I've pointed out with the potential to use and even directly accommodate static checkers; this definitely affects risk.

      (I can convert most technical and strategic arguments and decisions into a variety of things--strategic evaluation is something I have a lot of tools for; it helps to examine stuff from every angle you can.)

    43. Re:Android is not always Java by angel'o'sphere · · Score: 1

      Duck Typing is a relatively new term, mainly coming from the groovy community or lets say it appeared at the time when groovy appeared and raised with it.

      Sorry, you seem not to understand what an interface is or what a system description is.

      BTW: I wonder which python version or special flags you use that:
            a = "string";
            a = 7334; // error here? ... yields an runtime error? That is not standard behaviour.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    44. Re:Android is not always Java by bluefoxlucid · · Score: 1

      It was a confusing error for me, as I had just learned Python and wondered why it wouldn't accept being given a new value. Turned out I was assigning an Int type from a String type without int() casting. CPython 2.5 on CentOS.

      New term still counts as technical jargon. Remember when "Graphics Processing Unit" was a new, groovy layman's term when "video card" and "video chipset" had fallen out of style?

    45. Re:Android is not always Java by ahabswhale · · Score: 1

      Are you retarded? It's on the fucking download page for IDEA. The guy even gave you a link to take you straight there.

      --
      Are agnostics skeptical of unicorns too?
  10. The story, as visualized in Python by idontgno · · Score: 5, Funny

    The Dead Collector: Bring out yer dead.
    [a company puts COBOL on the cart]
    Oracle Corporation with Dead Body: Here's one.
    The Dead Collector: That'll be ninepence.
    Java: I'm not dead.
    The Dead Collector: What?
    Oracle: Nothing. There's your ninepence.
    Java: I'm not dead.
    The Dead Collector: 'Ere, he says he's not dead.
    Oracle: Yes he is.
    Java: I'm not.
    The Dead Collector: He isn't.
    Oracle: Well, he will be soon, he's very ill.
    Java: I'm getting better.
    Oracle: No you're not, you'll be stone dead in a moment.
    The Dead Collector: Well, I can't take him like that. It's against regulations.
    Java: I don't want to go on the cart.
    Oracle: Oh, don't be such a baby.
    The Dead Collector: I can't take him.
    Java: I feel fine.
    Oracle: Oh, do me a favor.
    The Dead Collector: I can't.
    Oracle: Well, can you hang around for a couple of minutes? He won't be long.
    The Dead Collector: I promised I'd be at Microsoft. They've lost nine today.
    Oracle: Well, when's your next round?
    The Dead Collector: Thursday.
    Java: I think I'll go for a walk.
    Oracle: You're not fooling anyone, you know. Isn't there anything you could do?
    Java: I feel happy. I feel happy.
    [The Dead Collector glances up and down the street furtively, then silences the Body with his a whack of his club]
    Oracle: Ah, thank you very much.
    The Dead Collector: Not at all. See you on Thursday.
    Oracle: Right.

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
    1. Re:The story, as visualized in Python by Anonymous Coward · · Score: 0

      The Dead Collector: Bring out yer dead.
      [a company puts COBOL on the cart]
      Oracle Corporation with Dead Body: Here's one.
      The Dead Collector: That'll be ninepence.
      Java: I'm not dead.
      The Dead Collector: What?
      Oracle: Nothing. There's your ninepence.
      Java: I'm not dead.
      The Dead Collector: 'Ere, he says he's not dead.
      Oracle: Yes he is.
      Java: I'm not.
      The Dead Collector: He isn't.
      Oracle: Well, he will be soon, he's very ill.
      Java: I'm getting better.
      Oracle: No you're not, you'll be stone dead in a moment.
      The Dead Collector: Well, I can't take him like that. It's against regulations.
      Java: I don't want to go on the cart.
      Oracle: Oh, don't be such a baby.
      The Dead Collector: I can't take him.
      Java: I feel fine.
      Oracle: Oh, do me a favor.
      The Dead Collector: I can't.
      Oracle: Well, can you hang around for a couple of minutes? He won't be long.
      The Dead Collector: I promised I'd be at Microsoft. They've lost nine today.
      Oracle: Well, when's your next round?
      The Dead Collector: Thursday.
      Java: I think I'll go for a walk.
      Oracle: You're not fooling anyone, you know. Isn't there anything you could do?
      Java: I feel happy. I feel happy.
      [The Dead Collector glances up and down the street furtively, then silences the Body with his a whack of his club]
      Oracle: Ah, thank you very much.
      The Dead Collector: Not at all. See you on Thursday.
      Oracle: Right.

      s/Oracle/Sun/g and it's true.

  11. Java won't die. by sirsky · · Score: 5, Insightful

    The reason Java is still alive and well is not because it's a good language. It's not because Oracle does a good job patching security faults with it. It's not because it may be able to run most of it's code on any given OS that can run its VM.

    The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

    1. Re:Java won't die. by Anonymous Coward · · Score: 4, Insightful

      Uh huh. Maybe you're not old enough to remember PASCAL? Which was the overwhelming favorite of colleges and schools back in the late 80s and early 90s?

    2. Re:Java won't die. by HeckRuler · · Score: 0

      butbutbut this way we don't have to teach them anything about pointers, because Java doesn't have pointers!

    3. Re:Java won't die. by Anonymous Coward · · Score: 0

      Perhaps most schools, universities and colleges teach it in their CS classes because it's still alive.

    4. Re:Java won't die. by ausekilis · · Score: 5, Informative

      The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

      Which is both a blessing and a curse. I went through my programming undergrad classes in the last round they offered C and C++. It worked out well because my employer needed those languages and for me to be able to learn others quickly, such as Java and C#. My experience with classes in C++ and lower level bit-bashing in C gave me the knowledge in being able to create custom libraries and handle oddly defined standard binary blobs, such as DTED data.

      This same employer stopped looking at my school afterwards simply because Java was the dominant language. The graduates being churned out had knowledge of data structures and libraries, but knew very little of the ins and outs of binary data streams, binary blobs, memory management, and all those other things that you need in C and C++ that Java gives you for free.

      Yes, it's good to have an approachable basis for such a complicated field as programming (computer science/software engineering/development/etc..). However, going from C/C++ to Java is a lot easier than the other way around. There's a reason my professor called Java a "Training Wheels Language"

    5. Re:Java won't die. by SQLGuru · · Score: 0

      +1 to the above.

      It is alive not because people really enjoy working in the language. It's because there's plenty of legacy code and plenty of corporate standards where it's the language to be used......companies are hiring again. That means there's money out there to go to conventions. There are people that need to learn new things and companies can afford to send people to these events that they couldn't do two years ago.

      I personally hate Java (technically, it isn't Java I hate so much as the ecosystem and tools around it....the language itself is just a language).....but I use it when I have to.

    6. Re:Java won't die. by Anonymous Coward · · Score: 1

      The reason Java is still alive and well is not because it's a good language. It's not because Oracle does a good job patching security faults with it. It's not because it may be able to run most of it's code on any given OS that can run its VM.

      The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

      And the reason most schools, universities and colleges teach Java, keeping it alive and well, is because it's a good language...

    7. Re:Java won't die. by Anonymous Coward · · Score: 0

      Java has pointers - they are just required to point to something real and don't have arbitrary type.

    8. Re:Java won't die. by pak9rabid · · Score: 1

      Horse shit...Java is nothing but pointers (aka "references"). It just hides dereferencing and memory management for you.

    9. Re:Java won't die. by 91degrees · · Score: 2

      Java pointers can be null.

    10. Re:Java won't die. by Aguazul2 · · Score: 0

      Oracle should completely discontinue Java in the browser. It only causes misconceptions about Java's overall quality, and constant bad press which seems to inform almost all Slashdot opinion on the matter.

      Also, I don't agree with your assessment. Java is used because it does a good job. You could say that popularity builds on popularity (e.g. widely-used, means courses, which means more use), but constant exposure means refinement and stability as well, and also mature libraries (Doug Lea concurrent stuff for example). None of this is to be sneezed at.

    11. Re:Java won't die. by ebno-10db · · Score: 2

      Leaving aside its pros and cons, the biggest reason that Java initially caught on was Sun's marketing department.

    12. Re:Java won't die. by slim · · Score: 2

      Pointer arithmetic is missing (good).

    13. Re:Java won't die. by angel'o'sphere · · Score: 1

      Isn't that a chicken egg problem?

      I always thaught Java was taught in universties because it was so widely used in the industries ...

      What other language/platform is out there that could rival Java? AFAIK none!

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    14. Re:Java won't die. by gtall · · Score: 1

      Oracle has too many of its tools built around Java in the browser to let it go. Redoing them would be expensive, their customers would scream bloody murder if Oracle attempted to shake them down for development using...what...Javascript?

    15. Re:Java won't die. by hondo77 · · Score: 1

      There's a reason my professor called Java a "Training Wheels Language"

      This.

      --
      I live ze unknown. I love ze unknown. I am ze unknown.
    16. Re:Java won't die. by gtall · · Score: 3, Insightful

      Nah, it caught on because you could do simple stuff simply without whacking away in C or C++ and that it was cross platform at a time when attempting to do cross platform development usually meant you had to shell out for proprietary pile of stuff which locked you in. Java was good for backends as well where you had a lot of horse power to apply to its programs. Java was also good for universities to use in teaching programming, not that it made for good teaching.

      Sun had a marketing dept? What were they marketing?

    17. Re:Java won't die. by Phillip2 · · Score: 1

      This is demand lead. Students want Java. Many of them think it's good, or that it's a "real" language or something. Even though, it's not actually very good for teaching, it's what people want.

    18. Re:Java won't die. by Anonymous Coward · · Score: 0

      And the dereferencing and memory management being hidden from you means you don't really learn anything about pointers.

      I still prefer the way my highschool computer teacher did things. We started with x86 assembly code, and once we were used to that, moved up to C, often with embedded assembly, because the school was too cheap to pay for/install the graphics libraries for our compiler. If you do it that way, you really understand what's going on when a data structure is being built. (Linked lists in assembly are a pain that I never again want to experience.)

    19. Re:Java won't die. by Anonymous Coward · · Score: 0

      Pascal is what I learned on a VAX back in the mid 90's. It went no where.

    20. Re:Java won't die. by Anonymous Coward · · Score: 0

      You got PASCAL? You're so lucky. My U was stuck on TURING, because one of our profs who should have retired years previous only knew that, Simscript, and BASIC, and they had to have a course for him to teach because he had tenure. As soon as he was gone, they moved up to C.

    21. Re:Java won't die. by benhattman · · Score: 1

      Bzzzzt, wrong!

      Java is still alive and kicking because it's an enterprisy kind of language in a world where all the hip new languages simply aren't that. As much as someone might love them a ruby or python, those languages are not controlled by the kinds of entities who are hesitant to break 12 year old software with new releases, nor are they backed by the kinds of major players who could force a language through the entire industry.

      If you just look at languages that either have enthusiastic big money backers or importance due to legacy, you are generally limited to C/C++, C#, and Java. Companies like IBM, Microsoft, Sony, Google, Oracle, Facebook, or even Amazon don't put an effort behind a language like ruby, which is at least one reason it's more niche. And if you look at what's out there, most of those companies are wedded for one reason or another to one of the languages already in broad use.

      Now, if Google ever made a serious effort to push go, perhaps it would gain traction in a serious enterprise kind of way. Likewise, if Facebook were to ever decide to push a language, they might have the clout.

      And so, we have C/C++, C#, or Java. Neither Java nor C# fill the niches that C/C++ do, so those aren't even direct competitors. So if you want to use a language designed for large software systems with a lifecycle potentially in the range of decades, and you want garbage collectors, you're probably going to choose between which devil you prefer (Oracle or Microsoft).

    22. Re:Java won't die. by geminidomino · · Score: 1

      I used Pascal back in my Senior year of HS, but I don't remember anything object oriented about it. Shit, it was dead and buried before the turn of the century. What does it have to do with Java today?

      Luckily, FSU only made me take 1 Java course (just enough for me to be able to dick around making mods for Minecraft), but used C++ for the "applied theory" courses.

    23. Re:Java won't die. by buddyglass · · Score: 1

      Ditto. You'll know Java's in trouble when the College Board replaces it as the language used in the AP Computer Science Exam. When that happens, it will be because they've identified some other language that has two qualities: 1) considered appropriate in a teaching context, and 2) is actually used in industry or is thought to be on a path to quick adoption. The only possible replacement I see on the horizon is Python.

    24. Re:Java won't die. by wagnerrp · · Score: 1

      Java is used because of rank misconceptions. The only value to Java is that the virtual machine is tied to the platform, rather than cooked into the binary, so you can in theory, run Java applications anywhere with a suitable version of the VM. PHBs making decisions get caught up in this concept, and fail to see the bigger picture.

      When you're talking about software for embedded platforms, like the Bluray menu system, this makes some amount of sense. It allows you to write the software once, and then run it on any manufacturer's player, regardless of the underlying hardware. On the other hand, when you're talking about software for embedded platforms with limited resources, there's all that much more reason to custom tune the application for the hardware.

      When you're talking about software for the server, it makes little sense. At a high level, you want to be able to re-architect your systems to run on whatever hardware or operating system you want, without rewriting your software. At a low level, you're going to invest so much in the management framework surrounding your hardware or operation system of choice, that you're never going to want to switch, but you still insisted on using Java. On top of that, even if you used C[++] for your application, the vast majority, if not all, of the code can simply be recompiled for whatever new platform you want to run on.

      When you're talking about software for the desktop, it makes zero sense. Compiled applications are neat and tidy. They're self-contained. Java requires the user install some 3rd party runtime environment in which to run Java applications. That's a hassle, and a good portion of your user base is simply going to refuse, and use a competitor's software. This wouldn't be an issue if a Java VM can pre-installed, but it doesn't. At least with .NET on Windows, it's bundled in with first party updates, and disguised a bit.

    25. Re:Java won't die. by Wootery · · Score: 2

      What other language/platform is out there that could rival Java? AFAIK none!

      Depending on what you're after, C# (yes, with Mono, it's actually pretty good) or D might work for you.

    26. Re:Java won't die. by VGPowerlord · · Score: 1

      What other language/platform is out there that could rival Java? AFAIK none!

      For good or bad... Java's younger cousin C# / .NET.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    27. Re:Java won't die. by HeckRuler · · Score: 1

      DAT'S DA JOKE

      Or

      Whoosh!

      Or

      Yeah.... That's, you know, the joke. The fact that it hides it for you means that they simply don't teach that aspect of programming anymore.

      Or

      That's the sad state of affairs in college level computer science education. Yes, damn near everything in Java is a pointer and you can make it jump in circles if you really want. But while that's true, it doesn't keep professors from deciding that they can just skip over teaching the students anything about pointers. Because it's Java. I went through ISU's computer engineering program. This was before they had a software engineering degree, and they were co-opting the ComSci departments classes for teaching kids how to code.

      Well I got the lovely experience of them switching from C++ to Java mid-way through. That was lovely. And this is a quoate from the ComSci professor who taught the intro to Java class: "Java has no pointers".

      The engineering department stopped sending students to comSci courses shortly after I graduated and made their own software engineering degree.

    28. Re:Java won't die. by bsdasym · · Score: 2

      Nowhere? Pascal, Turbo Pascal, Delphi (Object Pascal)? Nowhere? I did professional Delphi development for roughly 10 years for companies of every size. Their IDEs were, and still are, a step beyond anything else, and when you had to get applications out the door quickly, it was Delphi or VB. The most visible brand, Borland, screwed up a lot of things. Embarcadero has been doing an admirable job bringing the product up to date and, slowly, back into the public eye. It's still very much alive. The current version can do cross-platform development for just about any mobile device (Win, iOS, Android), producing native code. Delphi (and Java, for that matter) are about as dead as the BSDs, which is to say, not. It's used in basically the same sort of way; quietly, behind the scenes, making things work that you don't think about day to day.

    29. Re:Java won't die. by Anonymous Coward · · Score: 0

      Leaving aside its pros and cons, the biggest reason that Java initially caught on was Sun's marketing department.

      At the time it was released Java was the only language that was all of:

      1. Object oriented from the ground up (makes it good for teaching OO programing)
      2. Cross platform by default (makes it easy to write portable code when you can compile once and run on anything with a JVM)
      3. Could be embedded in a web browser (made it a must learn for people who wanted to make their webpages interactive in the age of tables and blink tags)
      4. Had automatic garbage collection (makes it easier to write code with pointers without causing problems)
      5. Used references for basicly everything (makes it good for teaching how pointers work as you can't ignore the pointers)

      Thus it became a popular "first language to learn" because it would teach you OO programing and how pointers work without beating you over the head with manual memory management, and in addition it was heavily in demand in industry for being cross platform and browser emendable.

    30. Re:Java won't die. by sirsky · · Score: 1

      If you just look at languages that either have enthusiastic big money backers or importance due to legacy, you are generally limited to C/C++, C#, and Java. Companies like IBM, Microsoft, Sony, Google, Oracle, Facebook, or even Amazon don't put an effort behind a language like ruby, which is at least one reason it's more niche. And if you look at what's out there, most of those companies are wedded for one reason or another to one of the languages already in broad use.

      Now, if Google ever made a serious effort to push go, perhaps it would gain traction in a serious enterprise kind of way. Likewise, if Facebook were to ever decide to push a language, they might have the clout.

      You may be surprised if you actually looked it up at how much Google and YouTube use Python. Here, let me do that for you: http://www.python.org/about/quotes/. Facebook is built on PHP, a language designed to solve the same types as Ruby. Other than Oracle and IBM, none of those companies make much if any use of Java as a core language for any of their products.

    31. Re:Java won't die. by ADRA · · Score: 1

      So is Haskell and LISP and where is their commercial penetration? No, Java is everywhere because they have developers, and as long as those developers are effective at making things, they'll be in demand from people wanting to make things. Making things easier and cheaper is important. Having lots of people of varying skill levels is important.

      Commercial assembly developers may have the absolute brightest people in the entire computing world working on development, but when there's only a few hundred and they each cost a fortune to pay for, it doesn't make much business sense to support the language unless its truly the only solution.

      --
      Bye!
    32. Re:Java won't die. by JavaElementOfStyle · · Score: 1

      From the people I know who have worked there and from various pieces about the technology used by Google. Their technology stack looks something like this:

      C/C++ for all the OS/Server development.
      Java for all the messaging and web services.
      Python for the scripting glue.

      What gets used for front end development is all dependent on the team working on it. Gmail and the various Google apps are created using GWT. Which is Java that gets compiled down to a Javascript front end and Java back end.

      Also, Google hired the guy who created Python so he would shape it in the direction that they wanted it.

      Facebook replaced PHP right away. They're all C/C++ now. They function a lot like Google and Amazon do. They create a lot of their own infrastructure using home grown solutions.

    33. Re:Java won't die. by Anonymous Coward · · Score: 0

      Craplets killed your browser and were never very popular. Swing GUIs also were a big flop.

      Java got lucky when external companies such as WebLogic started pushing it as a server-side language. Otherwise it would have faded away as just another 1990s browser gimmick or teaching language.

    34. Re:Java won't die. by Gibgezr · · Score: 2

      No, they started teaching Java before it became really big. It became really big because every student who graduated from uni had a Java hammer, so every problem looked like a nail to them. It was back when everyone was having orgasms over "write once, run everywhere" and it looked like Java was going to be the answer for making things happen on the web.

      Intro programming languages were always "fad of the year" in CS departments. It used to be that students learned some random language, Fortran/Modula-2/Forth/Pascal/Basic/Whatever in year 1, then went on to learn C (and later, C++) in years 2-4 and beyond. Unfortunately, when Java's turn came up in the random year one language slot it invaded years 2-4 as well because it was OO and super-trendy, and way easier to teach. The side effect is still being felt; university CS grads come out of many schools lacking the skill to deal with real-time systems/binary data/memory management etc.

    35. Re:Java won't die. by maccodemonkey · · Score: 2

      The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

      I transferred and finished my degree at a different school than I started at. I knew they were a good school when they refused to transfer any credits for any class that was taught in Java.

    36. Re:Java won't die. by MightyMartian · · Score: 0

      It caught on because Sun put a lot of effort into making it cross platform. The first real project I used Java for was rewriting an AWK script I'd written years before that translated some bizarre mainframe file export into CSV or vanilla SQL. I wrote the the utility on my Windows machine, and thought it pretty damned nifty that I could take the .java bytecode and just run it without modification of any kind on the Linux server.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    37. Re:Java won't die. by ebno-10db · · Score: 1

      Were you around in '95 when Java was first introduced? Seriously.

      As for the marketing department, Silicon Valley style isn't so much about ads and whatnot, as creating hype and buzz (with the emphasis on hype). Sun did that in spades.

    38. Re:Java won't die. by ebno-10db · · Score: 2

      I'm sorry to hear that the acquisition caused you to lose your job in the Sun marketing department. Based on the fantastic job you guys did though, you ought to able to find something else.

    39. Re:Java won't die. by Anonymous Coward · · Score: 0

      Java was explicitly designed for the bad to mediocre developer.

      It is an indisputable fact, but still makes the Java fanboys butthurt

    40. Re:Java won't die. by Anonymous Coward · · Score: 0

      "Nothing but ... just ... hides memory management..."

      That's like "anaesthetics in surgery just hide the traumatizing debilitating pain". It's a pretty big "just".

    41. Re: Java won't die. by Anonymous Coward · · Score: 0

      I dont have a problem with the java language (although I prefer C or C++), but I have noticed that java programmers tend to suck. I figure this is because it is a "training wheels language," so java programmers can be had for cheap.

      At work, I use a complex authentication system written in java. Troubleshooting policy problems is difficult because the product's concept of "debugging" is a log filled with near-meaningless java call dumps.

      In fact, the logs are filled with java errors and call dumps that occur even in the normal flow of operations. Separating non-errors from important errors is difficult.

    42. Re:Java won't die. by angel'o'sphere · · Score: 1

      No, they started teaching Java before it became really big.
      Sorry, your perception is just nonsense.
      The rest of your post is nonsense, too. I spend nearly 17 years at the university. Java started to be the main language for teaching 7 to 10 years after it was broadly getting attention in the industries.
      Universities never have driven language usage in the industry, otherwise we all would program in Lisp, Prolog, Haskel or Sather/Sather K.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    43. Re:Java won't die. by angel'o'sphere · · Score: 1

      C#/.NET does not run on iPhone/iPad/Android/HP Unix, Mac OS X, Oracle Solaris, IBM AIX, Mainframes, Midrange Computers (AS 400 etc.) ... should I continue?

      Neither has C# in any area the open source frameworks or tools Java has, nor a useable IDE.

      So no: there is no alternative to Java unless you want to write closed source desktop applications for Windows.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    44. Re:Java won't die. by angel'o'sphere · · Score: 1

      So you like to suggest that I suggest to the amazon CTO that we do the next system upgrades in D ?

      Because? There are so many D programmers? And we already have a D compiler for the AS400 and the IBM Mainframes? And it gives us over Java ... what exactly? A servlet framework? JPA ersatz which is "better" somehow?

      D is a language, not a platform.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    45. Re:Java won't die. by Anonymous Coward · · Score: 0

      These days schools are mostly teaching jQuery and Motorola 68000 assembly. Nobody is really doing low-level languages like VB or x86 assembly anymore.

    46. Re:Java won't die. by farble1670 · · Score: 1

      translations: everyone is dumb, but me. i see through the fog where no one else can.

      it's used by professors because they like it. it continues to be used by students because they like it. it's used in industry because the people that work therein like it. it was chosen for android app dev because the powers that be at google liked it. i can assure you, most of those people are not fools. in fact, most of the people that made those decisions are above average.

    47. Re:Java won't die. by Anonymous Coward · · Score: 0

      Ah, crap... you mean to say that it is the new Pascal?

    48. Re:Java won't die. by Anonymous Coward · · Score: 0

      Yeah, I learned Pascal in school. It has tainted every line of code I have written since. I still write my programs "upside-down" and eye prototypes with suspicion.

      The difference is that I also learned a number of other languages in the following years...

      sirsky hit the nail on the head with why it is alive. Companies didn't adopt Java because it was better or based on a need for cross-platform support, they adopted it because it was the only language new grads knew. To develop an application in C++ is many times more expensive not simply because it takes longer to develop, but also because your labor pool is much smaller and comprised almost exclusively of senior programmers that demand higher salaries.

      Java is the modern equivalent of COBOL.

    49. Re:Java won't die. by Anonymous Coward · · Score: 0

      Java was explicitly designed for the bad to mediocre developer.

      And it's not very good at that, it doesn't even suck that badly. The problem with it is just as you say: it is designed for bad programmers, so they dont bother to understand fundamental concepts like memory management which are equally important to managed and non-managed languages but in different ways. Most Java programmers have no idea about how heap space is allocated or how garbage collection and generational heaps operate and how/why they are implemented differently across different VMs and consequently across different operating systems. So they naively believe that they dont need to worry about memory management and that they can just "write once, run anywhere". So you end up with shit Java programs.

    50. Re:Java won't die. by Anonymous Coward · · Score: 0

      2. Cross platform by default (makes it easy to write portable code when you can compile once and run on anything with a JVM)

      That was the biggest con of all, it isn't cross platform! The platform it runs on is the Java Virtual Machine which is a machine emulator that then has to be implemented on top of the operating system. So if you take the platform to mean the underlying operating system then it didn't run on any platform, if you take it to mean the JVM then it only ran where the JVM ran and to make matters worse the implementations of the JVM differed on different operating systems in terms of features, performance and all manner of important (yet often overlooked) variables like generational heap sizes. Arguably the most popular place for Java to run is the Dalvik VM, try running your Java programs on Dalvik and Hotspot, suddenly all you can do is "Hello World!" and prove that WORA is just a bullshit con. Java programs are platform-specific, they are written to target a specific JVM on a specific platform, anybody expecting a consistent experience across JVMs and operating systems is an idiot.

    51. Re:Java won't die. by Anonymous Coward · · Score: 0

      C#/.NET does not run on iPhone/iPad/Android/HP Unix, Mac OS X, Oracle Solaris, IBM AIX, Mainframes, Midrange Computers (AS 400 etc.) ... should I continue?

      Java doesn't run on iPhone/iPad/iPod either and while it does run on Android can you run those same Java apps on MacOSX or Windows? No, you can't! Those things you list do not matter to any commercial application developer, they want a good experience on all platforms they develop for and a single native codebase with platform-specific elements where appropriate provides the best solution. Java just provides a crappy experience wherever it goes and it isn't even portable across the most popular platforms (Android to OSX/Windows).

    52. Re:Java won't die. by Wootery · · Score: 1

      So you like to suggest that I suggest to the amazon CTO that we do the next system upgrades in D ?

      "Nobody ever got fired for choosing Java", right? Fair point, but you asked What other language/platform is out there that could rival Java, and I submit that the C#/CLI language/platform pair, and the D language, could. They're by no means a million miles away from Java; if we look at the broader spectrum of programming languages, the three are pretty close.

      There are so many D programmers?

      Again, fair point: D ranks at 37 on TIOBE, where Java is in second place to C. It depends what you mean by could rival Java, really; if you are asking for a language with considerable pre-existing adoption, that's of course quite different from the technical side, which is what I was looking at.

      And we already have a D compiler for the AS400 and the IBM Mainframes?

      For funky platforms, Java will beat D, of course. For the major server/desktop platforms (Lin/Win/Mac), D should work (though it generally focuses on Windows), but yes, Java certainly wins on implementation maturity.

      And it gives us over Java ... what exactly? A servlet framework?

      It gives you a language which rivals Java. Basing my decision purely on language preference, I'd choose D over Java.

      D is a language, not a platform.

      It's a little fuzzy what this means - D doesn't have a security model like Java does, sure, but as I understand it, CLI doesn't have one either. Compilation is fully ahead-of-time, also. This doesn't rule out D from doing some of the things Java is used for, though.

    53. Re:Java won't die. by Gibgezr · · Score: 1

      Java became the intro programming language in unis around here in the late 90's. That's JDK 1.2-1.2 era, so you are saying it was big in industry before then? Hell, the language was invented in 1995...even looking at the unis that didn't adopt it until 2004 it couldn't have been "big in industry" for 7-10 years like you claim, it was only 9 years old (and the first couple of years it didn't even have a reliable implementation).

      Java is a very young language; so young that it didn't have time for industry to "make it big" before unis started pushing down student's throats.

    54. Re:Java won't die. by angel'o'sphere · · Score: 1

      Perhaps the universitied in your country are different than others :)
      Certainly Java was not pushed by unis. They teach it / taught it because it had an easy free to use tool chain runnin gon all majour platforms. AFAICT it was already widely used in the industry when it was used in universities.
      I did my first commercial Java projects around 1995/1997.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    55. Re:Java won't die. by angel'o'sphere · · Score: 1

      You definitely know a lot about D.
      With rivaling I ment "usable for enterprise computing" (at least) and D and also C# simply lacks libraries and frameworks. The main reason C# basically is useless is: MS never tried to make it a cross platform alternative to Java. It only runs on windows. The maturity of Mono does not compensate for this.

      Hm, should check how D is in the area of multi threading. But bottom line I don't like many of the design decisions in D, like having no true MI (ofc I don't like that in Java either).

      Nevertheless you made a very good post and obviously know your stuff :)

      (with language versus platform I mean the broad spectrum of libraries that are focused on special purposes in Java, like JPA or the Java Rest and Soap support via annotations etc. the huge amount of third party frameworks like spring or Aspect/J or hibernate)

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    56. Re:Java won't die. by Wootery · · Score: 1

      You definitely know a lot about D.

      You're too generous - I've just read a bit about it and played about with it a little; I'm certainly no D master :P

      Regarding frameworks/libraries/maturity/practical power, I think you might underestimate what Mono is capable of - I'm no expert, but I don't think you'll have any trouble doing web-dev work with it.

      For D, I believe there are libraries out there for doing web-dev work. This one might do, but looks a bit on the low-level side. For serious production code I'd certainly recommend C# over D (ASP.NET is already out there in the 'real world'), but I'm sure it could be done with D.

      Hm, should check how D is in the area of multi threading.

      I don't know much about this, but I do know that D2 has some thread-safety features built into the language itself: 'global' variables are now by default actually merely 'thread-global'. You have to use a special keyword if you want real process-wide globals. I can see where they're coming from, but I'm not sure I like it.

      But bottom line I don't like many of the design decisions in D

      There are certainly seem to be some warts - I get the impression the const system is a bit broken.

      like having no true MI

      I've never been bitten by not having MI, but maybe that's because I learnt Java before I learnt C++. The arguments for not having MI are fairly persuasive imo: simpler for the compiler, generally less error-prone for the user, and MI is rarely the right solution anyway.

      I never quite got my head around Scala's solution (it looked a lot like MI to me), but people seem to like it.

      (with language versus platform I mean the broad spectrum of libraries that are focused on special purposes in Java, like JPA or the Java Rest and Soap support via annotations etc. the huge amount of third party frameworks like spring or Aspect/J or hibernate)

      Ah, the advantages of bytecode and reflection. Sounds almost like Aspect Oriented Programming is what you're really getting at here. There's not much in the way of AOP for D, from what Google tells me.

    57. Re:Java won't die. by angel'o'sphere · · Score: 1

      There are many good use cases for MI, all the problems I 'read' about are purely academic, I never encauntered any of them in the real world.
      There are clear patterns when to use MI, e.g. Jiri Soukop uses MI in combination with templates (you inherit several times from the same template with different template arguments) or the Talingent frameworks patterns. If you want to extend a class with "completely new/unrelated" behaviour (D extends B, all new functionality programmed in D), it is better to simply write a new class (class E) with only that behaviour (probably as a mixin template class) and then use MI to combine them: D extends B, E.
      That way you can easy reuse E in other scenarios, again via MI ofc.
      Inheritance hierarchies should be somewhat shallow anyway, so in a good structured system MI is no real disadvantge/problem.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    58. Re:Java won't die. by Evil+Pete · · Score: 1

      I was involved in a large ecommerce site. $30 million. All in java, when it was finished we had started using the latest Java 1.1.5. By the time Java 1.2 came out java was very, very popular ... there was a lot of hype about it, but not much in the universities. That changed rapidly but the popularity of Java came first. Everyone knew that at the time. Now think about this image. This is post-hype, it was already waning by the time of the new millennium, but still dominant. That is before the popularity in the universities and colleges.

      --
      Bitter and proud of it.
    59. Re:Java won't die. by anyGould · · Score: 1

      You got PASCAL? You're so lucky. My U was stuck on TURING

      I'll see your TURING and raise you a Modula-2. A language that I've never heard of in any context beyond those two intro classes.

    60. Re:Java won't die. by doccus · · Score: 1

      You got PASCAL? You're so lucky. My U was stuck on TURING, because one of our profs who should have retired years previous only knew that, Simscript, and BASIC, and they had to have a course for him to teach because he had tenure. As soon as he was gone, they moved up to C.

      Hahaha LOL!

    61. Re:Java won't die. by doccus · · Score: 1

      If I hadn't had to learn binary in the 70's, I probably wouldn't have been so turned off computers that I never got back into them till the late 90's

    62. Re:Java won't die. by Anonymous Coward · · Score: 0

      Except schools learned that starting with PASCAL was a fucking waste of time because nobody in industry actually gave a fuck about it, and the people hiring didn't want to pay kids fresh out of college to both learn a new language and actually how to code in the real world.

      If you didn't know a useful language and you didn't attend a top 10 CS school, you were fucked coming out of college.

  12. Long term decline by Anonymous Coward · · Score: 0

    The decline relative to other languages is evident in this data: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

    1. Re:Long term decline by buddyglass · · Score: 2

      One can make a credible case that Java's decline in market share is due to the "market" for programming languages becoming more diverse over time. Let's consider the languages with the largest market share in 2001, which is the farthest back the TIOBE graph goes:

      Java: ~26.5%
      C: ~20.0%
      C++: ~14.0%
      Visual Basic: ~8.0%

      Now let's check out each of those language's current market share:

      Java: 16.15%
      C: 16.98%
      C++: 8.66%
      Visual Basic: 4.84%

      Now we can look at the deltas, both in absolute terms and as a percentage of original share:

      Java: -10.35% (~39% decline)
      C: -3.02% (~15% decline)
      C++: -5.34% (~38% decline)
      Visual Basic: -3.16% (39.5% decline)

      The baseline decline for languages that enjoyed wide popularity in 2001 seems to be 15%. Java is declining, but seems to be doing no worse than C++ and Visual Basic are. (Which is perhaps damning with faint praise.) However, unlike C++ and Visual Basic, Java is declining from a position of dominance (at least in terms of TIOBE metrics).

      IMO, if any language should be worried it's Ruby. Ruby is already less than half as popular (1.5%) as it was at the peak (4%), and it's more-or-less eclipsed by Python. There are some credible reasons to prefer Java to Python/Ruby in certain contexts (e.g. Android, where it's the only game in town). There aren't many strong reasons to prefer Ruby to Python, esp. given the larger Python development community makes it easier to hire devs.

    2. Re:Long term decline by znrt · · Score: 1

      one can also make a solid case that that data is random bullshit.

    3. Re:Long term decline by buddyglass · · Score: 1

      The TIOBE data or my summary?

    4. Re:Long term decline by znrt · · Score: 1

      i was referring to the data, actually.

      nothing wrong with your summary, except it is based on a popularity contest based on some arbitrary counting of arbitrary google searches. even without checking their measurement method (which is pretty dumb, imho), you should see at first glance that there is something fundamentally wrong with a result of [16.15% java vs 4.84% Visual Basic].

    5. Re:Long term decline by buddyglass · · Score: 1

      True that. For more questionable data I just searched for "java", "c++", "visual basic", "ruby" and "python" at LinkedIn, limiting the search to within 50 miles of my residence, which is a "moderately" tech heavy medium sized city. Omitted "C" because it generated too many false positives:

      Java: 273
      C++: 160
      Visual Basic: 52
      Ruby: 82
      Python: 173

      For extra fun:

      Android: 58
      iOS: 67

  13. Scripting / PowerShell by Thyamine · · Score: 1, Interesting

    I'm surprised no mention of PowerShell was listed. It's obviously platform specific, but Microsoft has done a nice job of including it in all their major platforms and products in recent years. I've used it on site for several customers, and I've had customers who are more technical asking about help with it. I'd be interested to see what sort of growth it's seen, and how it is supplanting (one can hope) old vbscript files that still linger.

    --
    I will shred my adversaries. Pull their eyes out just enough to turn them towards their mewing, mutilated faces. Illyria
    1. Re:Scripting / PowerShell by Bill,+Shooter+of+Bul · · Score: 1

      For what its worth, the only Vbscript I've seen has been replaced with Python. Obviously the authors of the original code were just too lazy to actually do a full VB Gui app. I'm sure there are a lot of use cases where python couldn't replace vbscript as nearly as well as powershell. I've also converted a few to bash for cygwin. I don't like using platform specific code.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    2. Re:Scripting / PowerShell by Anonymous Coward · · Score: 0

      at least 80% of my new windows scripts are powershell, the remainder is usually a quick batch script with a for loop and a couple of if statemtents. the batch scripts usually have more variables defined than lines of actual code though...

    3. Re:Scripting / PowerShell by Sarten-X · · Score: 3, Insightful

      The point was to list decent halfway-decent scripting languages.

      Powershell is a batch file on steroids. It is good for automating system administration in a known environment, but not much else. While many Microsoft products do offer modules, there's still a lot of (especially older) ones that don't. Also, since much of the existing API is a direct port from Windows' internal structure, many of the designs are non-intuitive, like having IP addresses almost completely separate from NICs.

      My biggest complain about PowerShell is what I now unaffectionately call "PHP syndrome": Extensible through modules, but there are no namespaces. As the system grows, the list of core commands grows as well, and there is no clear grouping available outside the documentation.

      Yes, it is a nice enough replacement for the dozens of little VBScript files kicking around, because it offers easy access to WMI and .NET. Unfortunately, it also brings over a new "On Error Resume Next", in the form of silently continuing after each error.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    4. Re:Scripting / PowerShell by Sarten-X · · Score: 1

      The point was to list decent halfway-decent scripting languages.

      For what it's worth, I meant that sarcastically. All languages suck. PowerShell, I've found, just sucks more than most.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    5. Re:Scripting / PowerShell by ErichTheRed · · Score: 1

      You may get your wish soon -- I remember when VBS was just starting to become available in Windows, and I also remember one of the things holding back its adoption was the fact that you couldn't guarantee that there was a complete "VBS stack" on the system. WMI was an addon, MDAC was an addon, even the XML parser wasn't guaranteed to be the same version until IE 6 came out. Even the scripting engine itself was an add-on! Therefore, you had to write lowest common denominator scripts until you got all the old stuff up to date. We were still using batch files for quite a while, and knew we could do things faster and easier, but we were stuck in a mixed NT/XP environment. (Yes, this was a while back.)

      I have the same issue with PowerShell and a mixed Windows 7 and XP environment. In a big enterprise you can't absolutely guarantee that a compatible PowerShell interpreter plus the right version of .NET is available. Microsoft has done an OK job of making sure most of the functionality is backported, so we're starting to move away from VBS.

      Honestly, my complaint about PowerShell is its complexity. You get access to vast resources through the .NET Framework, and that's great. But just like any other modern language with a monster prebuilt library, just finding what you need to write and what has been written for you is still a Google operation. One huge improvement is the ability to dispense with thousands of "results parsing" functions. VBS meant you had to do a lot of output reading/interpreting in code, plus access to things like WMI and data services is still kind of a magic incantation thing. Now PowerShell lets you directly work on objects. Example: I wrote a script to edit an XML configuration file for one of our apps the other day, just to make a simple change. It was a huge script in VBS with all the error checking, magic incantations to access the XML DOM and parsing of results. PowerShell lets you directly manipulate the file in memory.

    6. Re:Scripting / PowerShell by Anonymous Coward · · Score: 0

      That is because Python shares a lot in common with VB script, even syntactically. It is very easy to move from VB to Python.

    7. Re:Scripting / PowerShell by MightyMartian · · Score: 1

      Yes, it's platform specific, which means, other than when I need to do some scripting, I could give a fuck about PowerScript. That's like complaining that no one is talking about bash.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    8. Re:Scripting / PowerShell by MightyMartian · · Score: 1

      I use it where I need full exposure from APIs in Windows. What I do find is that it is gawdawful slow when compared to the old CMD.EXE batch scripts I used, even when those scripts had to use third-party tools to do clever things like determine a user's group membership. It has its place, but I find it an awful language. I'd still prefer a native bash-like shell and scripting language that exposed win64.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    9. Re:Scripting / PowerShell by Anonymous Coward · · Score: 0

      > Microsoft has done a nice job of including it

      No. We gave-up on it because our customers had such a hard time finding and installing it. On my Windows 7 development system:
      ---
      C:\>ver

      Microsoft Windows [Version 6.1.7601]

      C:\>PowerShell
      'PowerShell' is not recognized as an internal or external command,
      operable program or batch file.

      C:\>
      ---

      I have VisualStudio and quite a few other Microsoft development applications install including Management OData IIS Extension which Microsoft lies and claims that it includes PowerShell. Microsoft is doing a very poor job. Go away shill.

    10. Re:Scripting / PowerShell by Anonymous Coward · · Score: 0

      That is because Python shares a lot in common with VB script, even syntactically. It is very easy to move from VB to Python.

      That must be why Python code looks like someone threw up on their screen. It is like Perl and VB had frankenbaby or something.

    11. Re:Scripting / PowerShell by Bill,+Shooter+of+Bul · · Score: 1

      At least the upchucker took the time to arrange his vomit such that the indenting was consistent.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
  14. Implying such handicapped thing can be healthy. by Anonymous Coward · · Score: 0

    Implying such handicapped thing can be called healthy.

    Unfortunately it is also breeding some mutant offspring like c#.

  15. Android, Objective-C and Tiobe Index by bradgoodman · · Score: 2
    I think much of Java's *lack* of decline is attributable solely to it's "native support" (use) in the Android platform - just as the sudden rise of Objective-C (See Tiobe index) is obviously attributable to the iPhone and iPad devices.

    Outside of Android - I believe use and acceptance is waning heavily. As a client-side web tool (where it got most of it's early predominance) it has been cockblocked by iOS, and is becoming overshadowed by native HTML5 (JavaScript) stuff. As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.

    1. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      As a client-side web tool (where it got most of it's early predominance) it has been cockblocked by iOS

      Are you high? iOS has fuckall to do with the decline of client side Java. Dynamic HTML+Javascript killed most of the need for that YEARS ago, well before iOS was a stain on Jobs' tighty whities.

    2. Re:Android, Objective-C and Tiobe Index by binarylarry · · Score: 4, Insightful

      I don't think Java and Rails, Python, etc actually compete much. They're very different technologies.

      Rails and Python are great when you don't have significant technical skills and just need to slap some shit together and throw in on a web server.

      Java is better in areas where you need high performance and scalability, but it's also much more costly to do anything with it.

      --
      Mod me down, my New Earth Global Warmingist friends!
    3. Re:Android, Objective-C and Tiobe Index by slim · · Score: 2

      The smart thing to do is use Jython, JRuby, Groovy.

      Then you can write in Java when the problem demands it, and in something more expressive when you're gluing it together. And you have access to all the thousands of libraries Java has.

      I saw a JRuby presentation in which they said they expected JRuby to outperform native Ruby -- because the Ruby runtime is written by a few guys, whereas the JVM has half a campus full of incredibly clever people, just working on making it run Java Bytecode as fast as possible.

    4. Re:Android, Objective-C and Tiobe Index by bradgoodman · · Score: 1

      But people still DO use it. It may not have been a "good" solution, but it was *a* solution. Today however, (just like with Flex), it is *not* a solution, because it would yield a web site which doesn't work with a lot of popular devices. That wasn't the case before iOS.

    5. Re:Android, Objective-C and Tiobe Index by bill_mcgonigle · · Score: 5, Insightful

      Rails and Python are great when you don't have significant technical skills and just need to slap some shit together and throw in on a web server.

      I've seen this from the other side. Java is a *great* language for the middle of the normal distribution. I'm not going to name the languages on the left side of the curve, because the point of this isn't to start a flame war, but if you have a large number of averagely competent programmers, then Java lets you (as architect/manager/etc.) have those programmers be productive for you, produce code that can be read in the future by the same segment of the population, and be reasonably sure the language will prevent them from making hidden catastrophic mistakes. Also there are a large number of existing tools that let you scale their work out both in depth and in breadth.

      The alpha geeks employing Ruby, Python, modern Perl, erlang, etc. are usually at the right side of the curve, doing very efficient, agile, but abstract and terse stuff that takes exceptional (not heroic, just unusual) sysadmin skills to get to work on a grand scale.

      Due to the nature of the available talent pool, it's natural to see projects start with the advanced scripting languages among the startup crowd and then migrate to the Java environment over time. Twitter would be a good example of this.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    6. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      the alpha geeks employing Ruby, Python, modern Perl, erlang, etc. are usually at the right side of the curve, doing very efficient, agile, but abstract and terse stuff

      Python and Ruby are terribly inefficient blub hipster languages. They're only "abstract and terse" when compared to shit like Java. Modern C# is just as expressive, and Haskell, F#, Scala, Clojure etc. all surpass them by miles while maintaining sane semantics, decent performance and superior concurrency models.

    7. Re:Android, Objective-C and Tiobe Index by binarylarry · · Score: 4, Informative

      Twitter didn't switch to Java to take advantage of the mediocre "kind of a programmer" Java talent pool.

      They switched because their "alpha geeks" couldn't make Ruby/Rails perform adequately for the amount of traffic they get.

      --
      Mod me down, my New Earth Global Warmingist friends!
    8. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      >As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.

      I completely agree that Python does not compete server-side. The author of Python says he wrote it as a hacker's language with brief syntax so he could run remote scripts. It was never meant for enterprise code and it has a lot of features that do not scale for large projects, including the fundamental efficiency of no type safety.

      Large corporations not in tech used to use VB6 for massive amounts of their systems, but ran into problems with not having type safety and too much object reflection. Python encourages these flaws.

    9. Re:Android, Objective-C and Tiobe Index by tippen · · Score: 1

      Java is better in areas where you need high performance and scalability

      Now I need a new keyboard! Just spit out my Diet Dr. Pepper when I read that... What's your definition of "high performance"???

    10. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      We can safely stop reading your post after the word "think".

      Java's main use is in server-side development. This is very much not visible to most people apart from those doing such development, because by its nature it's not public.

      The Android stuff is just fluff, it's not really Java except syntactically and for a relatively small number of APIs (compared with J2EE). The UI is all Android-specific.

      In the enterprise nothing really compares to application containers such as JBoss, Tomcat, etc.

      Many companies will use Java and Python for their app dev language and scripting language respectively. The existence of Jython helped that along greatly.

      Kids seem to think that because they installed Etherpad Lite that Node.js is a major web technology, and so on for other language platforms. I'm not saying that these platforms aren't good, nice, etc, but they're insignificant in comparison to Java (and PHP, and C#).

    11. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      ... Modern C# is just as expressive, and Haskell, F#, Scala, Clojure etc. all surpass them by miles while maintaining sane semantics, decent performance and superior concurrency models.

      Not to mention the safety of a compiler verifying your code for you, which shortens your dev and refactor cycles, and frees up time to do actual functional testing.

    12. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 1

      Very true, but most of the replaced code at Twitter was rewritten in Scala not Java.

    13. Re:Android, Objective-C and Tiobe Index by gbjbaanb · · Score: 2

      Why didn't they switch to C++ and do it properly!

    14. Re:Android, Objective-C and Tiobe Index by binarylarry · · Score: 2

      Because they needed it to be fast AND secure AND fairly bug free.

      --
      Mod me down, my New Earth Global Warmingist friends!
    15. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      Bzzt. Rails is a framework, not a language.

    16. Re:Android, Objective-C and Tiobe Index by angel'o'sphere · · Score: 5, Insightful

      Because it would be a dozen times more efford in programming hours, because it lacks the relevant libraries, because the amount of capable C++ programmers is very low, because C++ is a dying language in the enterprise environment, because C++ is not truely portable across platforms, because in the end when it comes down to performance the C++ implementation (which costed you 5 times the money and 2 times the time to develop) will be only 5% faster than the Java implememtation.
      And all arguments above will kill you when you plan to maintain it for the next 15 years.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    17. Re:Android, Objective-C and Tiobe Index by binarylarry · · Score: 1

      Both Scala and Java compile down to java bytecode, so after compilation is done they will have similar characteristics and capabilities.

      --
      Mod me down, my New Earth Global Warmingist friends!
    18. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      The alpha geeks employing Ruby, Python, modern Perl, erlang, etc. are usually at the right side of the curve, doing very efficient, agile, but abstract and terse stuff that takes exceptional (not heroic, just unusual) sysadmin skills to get to work on a grand scale.

      Ruby, Python, Perl

      Agile, abstract, terse, lots of hand holding - ABSOLUTELY.
      But efficiency.. measured in what, lines of code, THAT kind of "efficiency"? =)

    19. Re:Android, Objective-C and Tiobe Index by R3d+Jack · · Score: 1

      Exactly. Java works best for heavy-duty business systems, and there is a steep learning curve. But there are a LOT of heavy-duty business systems. Java won't go anywhere until a new development paradigm comes along (which I haven't seen any signs of yet.)

    20. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      Wow, says the person that know absolutely jack about C++.

    21. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      Again: why aren't they doing it in C++? Your and other Java dood's inability to understand a big-boy language like C++ doesn't

    22. Re:Android, Objective-C and Tiobe Index by bill_mcgonigle · · Score: 1

      But efficiency.. measured in what, lines of code, THAT kind of "efficiency"? =)

      Sort of - time to prototype is pretty high up there for startups. LOC can be a weak approximation to that, but available library size is also really high.

      Ruby is slow, Python is memory hungry. Perl doesn't suffer from those two problems but has fairly poor concurrency without an external dispatcher and a funky object syntax. It's all in the trade-offs for what you need.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    23. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      Twitter didn't switch to Java to take advantage of the mediocre "kind of a programmer" Java talent pool.

      They switched because their "alpha geeks" couldn't make Ruby/Rails perform adequately for the amount of traffic they get.

      They also didn't switch to Java, they switched to Scala running on the JVM. Let's not all lump Java and the JVM together; they're not the same at all. One is a language (Java) and one is a runtime (JVM). Twitter switched to Scala as their language running on top of the JVM runtime. I doubt they would have switched to the JVM if it weren't for Scala, so I don't think it's reasonable to consider Twitter's switch a win in the Java column. It was a win for the Scala language and the JVM.

    24. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      Ruby and Python are both slow, memory hungry and they also have poor concurrency on their primary implementation. JRuby and Jython are also slow and memory hungry.

    25. Re:Android, Objective-C and Tiobe Index by lgw · · Score: 1

      Well, the underlying point was valid: it's damn hard to hire great C++ programmers these days for boring "enterprise software" shit.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    26. Re:Android, Objective-C and Tiobe Index by binarylarry · · Score: 1

      LOL

      --
      Mod me down, my New Earth Global Warmingist friends!
    27. Re:Android, Objective-C and Tiobe Index by binarylarry · · Score: 0

      Scala compiles to Java byte code, runs on the Java Virtual Machine, utilizes the Java standard library, uses Java debugging tools and profilers and uses Java's large assortment of open source and commercial library offerings.

      They switched to Java, you pedantic fucktard.

      --
      Mod me down, my New Earth Global Warmingist friends!
    28. Re:Android, Objective-C and Tiobe Index by ADRA · · Score: 3, Insightful

      I agree that Rails / Python are definitely the more small scale / personal project side projects type solutions out there. Yes they can scale, but I'd argue that they're not good at it.

      Java SUCKS for small scale. EE containers are heavy and require a good set of knowledge to even take crack at a reasonable site, but once that painful layer has been passed, adding more and more to the service becomes as trivial as the business domain requires. The extra leveraging from well architected services and API's makes working on larger scale Java systems a dream in comparison to others (Currently working on a Java Web/Services project single deplyment EAR that's over 3 million source lines BEFORE all the libraries and server container features that we're also leveraging).

      I'd also argue that outside of hosting, you can easily get Java based web service tools/servers/etc.. for 0 dollars. You can't find much Java hosting in the zero dollar number (Redhat's cloud Jboss 7 or the non-standard Google appengine being a notable exceptions) which may be an issue to some enthusiasts who don't do their own hosting.

      --
      Bye!
    29. Re:Android, Objective-C and Tiobe Index by IamTheRealMike · · Score: 4, Interesting

      No, I've seen pretty much that dynamic happen at Google where we use a lot of C++ and Java.

      There are some places Java just can't follow C++ ... the Google core web search serving system is mostly C++ because it involves decoding extremely compact data structures at insanely high speeds, to the extent that the verymost inner code has branch prediction hints in it. Java can't do that nor will it ever be extended to do so. Lots of servers at Google are written in C++ for the same reason. I don't believe it's only 5% faster, the rule of thumb I see is you lose about 2x the performance by using Java when all the costs are taken into account (like constantly re-compiling the same code over and over on the live servers, the GC costs, etc).

      Despite that, lots more code is written in Java, because the cost of using C++ is so high. Sure, when the sailing is smooth there isn't a huge difference between them as long as your libraries and support infrastructure are good, but the moment someone slips up and accidentally double frees memory on an error path you've got a problem that can take an entire team a week or more to track down. I've seen it and partaken in such bug hunts. There's nothing quite like trying to find memory corruptions that only show up in the production environment once a day, when you have thousands of servers.

      Basically any programmer can screw up that way. Java strikes a reasonable balance between safety and performance, which makes sense even when you are a company like Twitter or Google.

    30. Re:Android, Objective-C and Tiobe Index by luis_a_espinal · · Score: 1

      Why didn't they switch to C++ and do it properly!

      Because it is not as economical (in terms of software development efficiency) compared to Java (that's my perspective as a a C/C++/Java developer in the *NIX and Windows, app and embedded arenas.)

    31. Re:Android, Objective-C and Tiobe Index by risingfish · · Score: 2

      I have to disagree with this. I work for a large etailer ( w/ millions of hits a day) that has been switching to Java in recent years. As with all places we have a range of programming skill levels throughout the dev teams, though most I would classify as average/intermediate. The over-all amount of code, the complexity of the code and environment, and work required by the sysops to maintain the code very quickly outpaced the old PHP stack. While our sysop teams focus on trying to keeping tomcat running, we have an old PHP forum quietly humming away in the corner taking almost minimal work to keep running while it serves 60% of our traffic. My experience with it has been pretty negative in this environment with many 'average' developers.

      But, that being said, this argument is mostly subjective, as the quality and quantity of code is less dependent on the language, and more dependent on the people/organization developing and driving it. I think where java shines is it's ability to easily enforce constraints and the inherent security benefits from a compiled language. But it also costs far more to spin up a Java environment and maintain it, so it is something that most startups will not be able to do out of the gates.

    32. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      A compiler is not a debugger

    33. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      There is still a heck of a lot of new enterprise code being written in Java. I wouldn't ditch it from my resume just yet.

    34. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      Ruby and Python also have terrible debuggers compared to all the languages mentioned sans Clojure...

    35. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      Twitter's rails stack didn't start falling down until it has handling more traffic than 99.9% of the websites will ever see.

      Plus, the Twitter devs were morons that used MySQL as a message queue!

    36. Re:Android, Objective-C and Tiobe Index by JAlexoi · · Score: 2

      As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.

      I hope you are kidding here, because that is far from the case. Java is still the de-facto language for most server-side applications. RoR never outgrew it's hipster background. It has been 7 years since RoR had it's hype peak... The hype waned and RoR is still a rarity.

    37. Re:Android, Objective-C and Tiobe Index by JAlexoi · · Score: 1

      C/C++ are great when it comes to highly predictable data flows or very small modules. Otherwise it's extreme cost of constant profiling of the code to actually identify the changing patterns that cause slowdowns. That being said, C/C++ can be much more than 2x performance of a JVM.

    38. Re:Android, Objective-C and Tiobe Index by Kagato · · Score: 1

      Charles Nutter did a presentation on JRuby when it first came out. He runs the Fibonacci sequence over and over again. The JVM does it's optimization magic on the execution and pretty soon it's exceeds the native ruby execution speed.

    39. Re:Android, Objective-C and Tiobe Index by gbjbaanb · · Score: 1

      but the point was : they had already done the development-efficiency thing and needed to update it to something more runtime-efficient.

      So to choose Java is doing a half-hearted job, if you rewrite your entire codebase you could have done it much better with C++ modules in their old code, and then migrate the whole lot if necessary. Doing a whole rewrite in java means they lost out on incremental development (which would have been much more development-efficient) and lost out on the most efficient runtime performance too.

    40. Re:Android, Objective-C and Tiobe Index by bingoUV · · Score: 2

      As you can see the analysis here in the garbage collection, as well as a nice research paper linked,

      Time cost of garbage collection is minimal if you have physical memory 4 times as much as java heap size. I guess satisfying this requirement shouldn't be much for Google. Another limitation of java, the startup cost, shouldn't be much for Google either, as I guess most "servers" keep running for a long time.

      Branch prediction and all is nice, but it is difficult to swallow the 2x estimation of performance over java. Could you give some more details? Too much floating point computation?

      thanks

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    41. Re:Android, Objective-C and Tiobe Index by tibit · · Score: 1

      I don't think "steep learning curve" means what you think it means. If it's steep, it's easy to learn. Did you really meant that heavy-duty-enterprisey Java is easy to learn?

      --
      A successful API design takes a mixture of software design and pedagogy.
    42. Re:Android, Objective-C and Tiobe Index by binarylarry · · Score: 1

      Java is capable of far better cache optimization than C++ (because it can profile, create a new strategy and recompile *at runtime*).

      --
      Mod me down, my New Earth Global Warmingist friends!
    43. Re:Android, Objective-C and Tiobe Index by Anonymous Coward · · Score: 0

      JRuby only outperforms the extremely old and not supported 1.8.

      Once Ruby 1.9 came out, JRuby became slower than MRI and I an currently developing with 2.1-preview1 and it is even faster. JRuby is great if you must work in the Java ecosystem, otherwise it is pretty much pointless.

  16. Java and the JVM by Kagato · · Score: 4, Informative

    People don't understand the difference between Java the Language, Java the Virtual Machine (JVM) and Java the Browser Plug-in.

    What do NetRexx, Groovy, and Scala have in common? They are all languages that are considered production stable running on top of the JVM. There are about a half dozen production ready languages that run on top of the JVM in fact. By running in the JVM these languages automatically pick up all sorts of performance and availability enhancements (JIT, Hotspoting, caching, etc.) the JVM offers. That's a lot of R&D the new languages don't have to invest in. It also allows new languages to be used in existing Java infrastructure with little to no change.

    The reason this is all possible is because Java the language is just an abstraction that compiles to Java Op Code. Java Op Code is very stable. Since Java 1.0 all that's changed with the opcode is a couple new operations and couple deprecations. There's still around 100 codes total.

    So why do people think Java is on the decline? Well the browser plug-in has been getting a bad name as of late. But that plug-in != Java. And frankly very few applications need a Java Plug-in. HTML5 and JS work just fine for the UI. It's not going to be a great loss if peopledisable it. You also get knee jerk reporting on this advising people to get all Java on their machines. Like it's somehow less secure than the VB runtime executors.

    As far as jobs, I work in the java space. There's way more need than people to fill the need. I make extremely good money java programmer.

    1. Re:Java and the JVM by Kjella · · Score: 2, Informative

      Java Op Code is very stable. Since Java 1.0 all that's changed with the opcode is a couple new operations and couple deprecations. There's still around 100 codes total.

      This page seems to indicate it's slightly over 200 in Java 7.

      --
      Live today, because you never know what tomorrow brings
    2. Re:Java and the JVM by Kagato · · Score: 1

      I'm basing it on a presentation Charles Nutter (of JRuby fame) gave years ago when he walked through all the Op Codes, how they functioned, and why it's fairly "easy" to compile languages to work with the JVM compared to .Net. It's quite possible I'm a bit outdated on the number since 1.5 was still stable and 1.6 was pretty new. It's still a very small Op list.

    3. Re:Java and the JVM by Anonymous Coward · · Score: 0

      Geez, you kids and your JVM. Take a look at pCode and sCode; ideas from the olden times from which the JVM was conceived.

      Gosling did his undergrad at U.Calgary at a time when there was research interest in both those older technologies, including Simula as the basis of object languages.

    4. Re:Java and the JVM by lgw · · Score: 1

      The JVM and the CLR are fine if you want to write more managed languages. I'm not sure what need those fill, but yeah, you can.

      CLANG/LLVM gives the same ability to use a "common language core" for a new non-managed language, and I'd surely like to see some new work there. C++ written in modern style can be a joy, but that style is too hard to discover, and the language is so full of cruft. A fresh language design, taking the "coder usability" lessons that can be learned from C#, Java, and Python, but unmanaged and targeting lower-level problems: that would be awesome.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    5. Re:Java and the JVM by Anonymous Coward · · Score: 0

      Have you looked at D recently?

    6. Re:Java and the JVM by Anonymous Coward · · Score: 0

      Oh.. I think there are enough people who understand the difference, well at least enough of them. Its just being used by those that do to further their own agenda in promoting their alternate language of choice, whether it be .NET, python, ruby, scala, etc. to the mass sheeple. The internet is just too easy a medium to propagate propaganda.

    7. Re:Java and the JVM by Anonymous Coward · · Score: 0

      And don't forget Google Web Toolkit (GWT) which lets you transform Java code into JavaScript for the web. Very much ubiquitious.

    8. Re:Java and the JVM by tibit · · Score: 1

      that style is too hard to discover

      I'd say simply by going for the horse's mouth, as in reading Strostrup's C++ Programming Language book, will get you there 90% of the way.

      --
      A successful API design takes a mixture of software design and pedagogy.
    9. Re:Java and the JVM by lgw · · Score: 2

      Actually, for a brand new project with people who have never used C it might not be so bad. People who "only know Java" would find good modern C++ style far more natural than all the bad ways. The problem is people who are C experts who are using a bit of C++ here and a bit there, with coding standards that make good sense in C and are just terrible in C++ - like the Google coding standards (I hear there's significant unrest about this inside Google now, so who knows, they may pave the way to a whole new pool of engineers who know how to do C++ right, but right now it stinks).

      --
      Socialism: a lie told by totalitarians and believed by fools.
  17. Which Java? by i_ate_god · · Score: 4, Insightful

    The JVM or the language?

    --
    I'm god, but it's a bit of a drag really...
    1. Re:Which Java? by Anonymous Coward · · Score: 0

      The island.

      Seriously if you can't tell from the title, then read the summary a bit.

  18. Sudden death by degeneratemonkey · · Score: 1

    A lot of very large users of Java are unhappy with it, not necessarily for technical reasons, but for legal reasons since Oracle set such a negative tone in court.

    The only reason Java isn't dead yet is that it would be expensive to abandon existing infrastructure so abruptly. It will be a around for quite a while still, but it won't be too long before it's relegated to the decaying margins of the software industry.

    1. Re:Sudden death by degeneratemonkey · · Score: 1

      Also, the distinction between the language and the JVM is irrelevant here. Behind both lurks an army of Oracle lawyers waiting to pounce.

    2. Re:Sudden death by Kagato · · Score: 5, Informative

      I consult in a lot of sectors. Banking, Insurance, New Media, Old Media, Start-ups, etc. People who want to leave Java for some new language are doing it because of a set of features. I've yet to come across anyone, let alone an institution, that wanted to leave Java because of Oracles court proceedings (I would assume against Google for Android).

      There was tons of talks on OpenJDK at JavaOne. If Oracle is the next Microsoft you would think they would have put the hammer down on that. I didn't see any of that happening. In fact Microsoft's cloud support of Java is based on OpenJDK and that was a keynote item.

      On the other hand, I do hear a lot of dissatisfaction from the MySQL folks. They are moving to Maria (or other DBs). That has little to do with Java.

    3. Re:Sudden death by Anonymous Coward · · Score: 0

      Companies aren't going to drop a decade and more of Java experience and tested, known-working Java applications anytime soon. And neither are all the third party libraries that they use, that are all written in Java. Nor the complete development infrastructure that Java brings to the table. Number one rule of software maintenance - don't rewrite, and to do it out of some minor, probably unfounded fear? Ridiculous.

      The Oracle issue is a minor buzzing, but nothing major - and at least Oracle is large enough to not go bust. And finally the language is going forward again.

    4. Re:Sudden death by buddyglass · · Score: 1

      Is it possible to objectively measure "relegated to the decaying margins of the software industry"? How might one do that? TIOBE market share? Number of new projects choosing to use the language? Something else?

    5. Re:Sudden death by Anonymous Coward · · Score: 0

      There was tons of talks on OpenJDK at JavaOne. If Oracle is the next Microsoft you would think they would have put the hammer down on that. I didn't see any of that happening. In fact Microsoft's cloud support of Java is based on OpenJDK and that was a keynote item.

      OpenJDK combined with the Google lawsuit is the corporate cease-fire that lets Oracle keep control of Java. If you think OpenJDK is actually open, try implementing it and see how far you get.

    6. Re:Sudden death by Lennie · · Score: 1

      I hear all the SWIFT stuff at the banks still run on Fortran and they are afraid to do large changes.

      So I don't know if banks are a good example. ;-)

      I see a lot of people go with PostgreSQL for new projects instead of MySQL.

      --
      New things are always on the horizon
    7. Re:Sudden death by Anonymous Coward · · Score: 0

      What killed Java for me was what the article described as "long syntactical passages". I was aghast at the length of the instructions, especially after coming out of an IBM assembler environment.

    8. Re:Sudden death by Kagato · · Score: 1

      All? No. We had all sorts of ways a SWIFT message would have been generated. Java, .Net, Mainframe (FORTRAN or COBOL), iSeries (COBOL or RPG). It really depended on the application. Most large banks still use a mainframe for domestic banking and will use a highly customized version of software (i.e. IBM HOGAN). They are unlikely to change working code to something else so long as they are still on the mainframe.

      On the other hand, most mainframe banking applications only talk a single currency. So all the international stuff is newer stuff. It's also pretty common to see credit unions and community banks on newer software.

    9. Re:Sudden death by JAlexoi · · Score: 1

      Banks don't want to leave JVM, they don't care much about Scala or Java....

    10. Re:Sudden death by Anonymous Coward · · Score: 0

      Moving from MySQL to Maria is not moving, its more like rebranding: same shit different name.

  19. I was at the JavaOne 2013 by Anonymous Coward · · Score: 0

    And I do concur. I was also in job market few months back and If I have to believe the recruiters, there were more Java opportunities than the candidates available.

    1. Re:I was at the JavaOne 2013 by buddyglass · · Score: 1

      My employer has had real trouble hiring an Android dev to back me up. Totally anecdotal, but there you go.

  20. Java pays my bills by Anonymous Coward · · Score: 0

    But bitches gonna bitch... I mean, hipsters gonna hipster... or should I say geeks gonna geek?

    1. Re:Java pays my bills by Anonymous Coward · · Score: 0

      What is your point?

      That you make money being an API monkey? Grats?

      Doesn't change the fact that Java the language sucks balls.

      Us programmers will continue to ignore Java

  21. All about the lambda by Anonymous Coward · · Score: 0

    Lambda expressions? Delicious.

    But seriously, very welcome addition to it, so stupidly useful at times where writing some external function/class would be a waste of time and code.

    Of course, you can forget it in ENTERPRISE CODING companies, it's all about the bloat there. If your code doesn't have 50 gigatrillion lines per second quaserbits you are fired so hard you came out the other side of the planet.

  22. The beginning of the end by GeekWithAKnife · · Score: 1


    It's all a matter of perspective, anything alive and well can only get sick and die eventually. Death is an eventuality. So really, Java is dying.

    --
    A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
    1. Re:The beginning of the end by el+jocko+del+oeste · · Score: 1

      Ain't we all!

  23. Bring out your dead! Bring out your dead! by Zecheus · · Score: 1

    CUSTOMER: Here's one -- nine pence.

    DEAD PERSON: I'm not dead!

    MORTICIAN: What?

    CUSTOMER: Nothing -- here's your nine pence.

    DEAD PERSON: I'm not dead!

    MORTICIAN: Here -- he says he's not dead!

    http://www.sacred-texts.com/neu/mphg/mphg.htm#Scene 2

  24. It's only a decline of purity. by Max+Threshold · · Score: 1

    Oracle is doing some really bizarre things with Java 1.8, and one of the major growth areas of Java is on Android, an environment suited only for insane developers. But the core language is doing fine.

  25. Mod -1, Uninformed by Anonymous Coward · · Score: 0

    It always was there, and that's what other JVM-based languages compile/JIT-compile to.

    Compare and contrast to Javascript with Coffeescript et al. transpiling to it.

    1. Re:Mod -1, Uninformed by Anonymous Coward · · Score: 0

      Javascript is completely unrelated to Java other than bracket-syntax and the word 'Java'...

  26. Minecraft by Anonymous Coward · · Score: 1

    Java will not be dead with solid evidence.

    1. Re:Minecraft by PeeweeJD · · Score: 1

      I'll bet all kinds of people are learning Java, just to make mods for Minecraft.

  27. Apple fanboys by rodrigoandrade · · Score: 1

    They reason that Java is dyng because their iPhones and iPads don't support it.

    1. Re:Apple fanboys by angel'o'sphere · · Score: 1

      It is easy to run a Java app on an iPad or iPhone. You only need to bundle the JVM and the relevant libs with it.

      Also JavaFX is comming out end of the year with iXYZ support, completely official from Oracle, so no special hacking/bundling necessary.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    2. Re:Apple fanboys by tyrione · · Score: 1

      Java doesn't get beyond a research project at Sun if NeXT Engineers don't show up and bring Objective-C isms to the Oak Project and call it Java. Seriously, it must suck not having worked for Sun or NeXT [my side] to know the story.

  28. dead and buried by slashmydots · · Score: 0, Troll

    It's bulky, slow, hard to program in, and Oracle made the web plugin the worst thing to happen to computer security in the history of computers. Adding the Ask Toolbar by default to the installer is the software version of jumping the shark. They are so done and over with and dead and buried at this point. I know a lot of fellow programmers and not one of them has anything positive to say about Java. It needs to die as quickly as humanly possible.

    1. Re:dead and buried by Anonymous Coward · · Score: 0

      It's bulky, slow, hard to program in, and Oracle made the web plugin the worst thing to happen to computer security in the history of computers. Adding the Ask Toolbar by default to the installer is the software version of jumping the shark. They are so done and over with and dead and buried at this point. I know a lot of fellow programmers and not one of them has anything positive to say about Java. It needs to die as quickly as humanly possible.

      And the alternative is .NET? No thanks. I program in both and VS2010 is crap. Don't care about the execution environment because both .NET and Java run fine. Just cannot stand Visual Studio.

  29. If there's such a market.. why the Ask toolbar?? by gregmac · · Score: 5, Insightful

    It definitely doesn't help that the JRE installer tries to also install the Ask toolbar. Seriously? Even Microsoft doesn't try to install Bing with the .NET installers, and that's their own property they're desperately trying to push on everyone.

    How am I supposed to take a platform seriously if the fundamental piece that has to be installed by all developers AND users to use it is doing the same sneaky things that half the crappy freeware on the internet is doing?

    Just how much revenue does Oracle make from Ask anyway?

    --
    Speak before you think
  30. shipping java scientific software for 15 years by peter303 · · Score: 4, Interesting

    Over datasets are in the terabytes. Calculations distribute over thousands of nodes and cores. Only in the 1990s was thre concern about efficiency. 64-bit JVMs have been a godsend. Formerly a FORTRAN-90/C++ shop.
    Java allows seamless GUI front ends and web-service control.
    The new features in Java-8 are very interesting.

    1. Re:shipping java scientific software for 15 years by ebno-10db · · Score: 2

      Benchmarks?

      I've heard the "Java can be faster than C/C++" many times, but have never seen benchmarks that back it up.

    2. Re:shipping java scientific software for 15 years by Medievalist · · Score: 2

      Formerly a FORTRAN-90/C++ shop.

      Some of the big banks have been putting Java on top of COBOL backends. You think I'm kidding, but I'm not.

    3. Re:shipping java scientific software for 15 years by peter303 · · Score: 3, Interesting

      Some here.

    4. Re:shipping java scientific software for 15 years by benhattman · · Score: 4, Insightful

      Not just can be, it usually is faster. At least, once it's been JITed. We just ran some XML serialization/deserialization tests, and the java implementation was much faster than the C++ one...eventually. The first several hundred iterations it was slower, but after that the Just In Time compiler optimized it, and it easily won.

      For long running computations, like scientific calculations for instance, Java is really good. The problem is we perceive how fast something is based on our wait time. Every time you boot a java applications it takes a long time for it to get started relative to a C++ applications. A quick command line java application might be orders of magnitude slower than a comparable C++ one. And that delay kind of permeates our intuitions about which is faster.

    5. Re:shipping java scientific software for 15 years by angel'o'sphere · · Score: 1

      Then google for the benchmarks?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    6. Re:shipping java scientific software for 15 years by ADRA · · Score: 1

      " Every time you boot a java applications it takes a long time for it to get started relative to a C++ applications."
      And everyone conveniently forgets that glibc / libc++ are almost guaranteed to already be loaded into ram.. Oh well =) But yes, Java apps are slower to start up, but a well cached java app doesn't actually start -that- slowly, its just that it almost always starts dead cold.

      --
      Bye!
    7. Re:shipping java scientific software for 15 years by Anonymous Coward · · Score: 1

      C++ really sucks for performance, because people tent to use the library as you would expect it to use.

      I remember a usenet post about someone who wanted to port a little bit of Python into C++ to make it faster, problem was it was slower.
      He made a small subset of his application to see what the problem was. His example was a single dictionary with string keys and string values, and inserting into them.

      He wrote it quite straight forward using the C++ string class and a STL map.
      It was 10,000 times (really) slower than Python.

      Some C++ gurus came in and started tweaking the code, so as little as possible copies of the string instances were made (a straight forward implementation, copies a string many times for just a single insertion). In the end they created pretty much the best (from performance point of view) C++ implementation possible. It was about 80 lines of very complicated code. It was complicated because of the amount of casting, const-ing, references and pointers that were needed in combination with templates, it looked liked line noise.

      Now it was only 1.2 times slower than the Python version.

    8. Re:shipping java scientific software for 15 years by Anonymous Coward · · Score: 0

      And another anecdotal piece of "evidence" to prove Java is faster then C++.

    9. Re:shipping java scientific software for 15 years by maccodemonkey · · Score: 1

      Not just can be, it usually is faster. At least, once it's been JITed. We just ran some XML serialization/deserialization tests, and the java implementation was much faster than the C++ one...eventually. The first several hundred iterations it was slower, but after that the Just In Time compiler optimized it, and it easily won.

      For long running computations, like scientific calculations for instance, Java is really good. The problem is we perceive how fast something is based on our wait time. Every time you boot a java applications it takes a long time for it to get started relative to a C++ applications. A quick command line java application might be orders of magnitude slower than a comparable C++ one. And that delay kind of permeates our intuitions about which is faster.

      Lot's of possible factors here... What compiler was used for C++?

      It seems like this post is taking about the advantages of JIT, not the advantages of Java. C and C++ can be done JIT as well. You've got Microsoft's managed version, and things like LLVM. In addition, there are other languages built on top of the JVM.

    10. Re:shipping java scientific software for 15 years by K.+S.+Kyosuke · · Score: 1

      Formerly a FORTRAN-90/C++ shop.

      Some of the big banks have been putting Java on top of COBOL backends. You think I'm kidding, but I'm not.

      Of course. And the protocol involves 3270 screen scraping. It's called Enterprise Integration with Legacy Systems. ;-)

      --
      Ezekiel 23:20
    11. Re:shipping java scientific software for 15 years by ebno-10db · · Score: 1

      As klugey as it is, it may make perfect sense for them. Lots of old COBOL that works, even if nobody knows how anymore. Rewrites, or even refactoring, are not real popular when you transfer a gazillion dollars a day and can't take a day off. This may be the only way they'll ever be able to move away from COBOL.

    12. Re:shipping java scientific software for 15 years by DrFalkyn · · Score: 1

      Not just can be, it usually is faster. At least, once it's been JITed. We just ran some XML serialization/deserialization tests, and the java implementation was much faster than the C++ one...eventually.

      What about pure numerical stuff? I'm wondering how say, a Java implementation of FFT would fair against the FFTW library (coded in C).

      Of course you could make a native call to the FFTW library (MATLAB does this) through Java, but thats missing the point.

    13. Re:shipping java scientific software for 15 years by ebno-10db · · Score: 2

      From your link:

      The Mines Java Toolkit (JTK) is a set of Java packages and native (non-Java) code libraries for science and engineering.

      In other words, there is C/C++ wrapped in Java. That may be a good idea for many applications, but it's not a measure of Java's speed.

      Ye olde Computer Language Benchmarks Game has pure Java vs. pure C++. There is one test where Java is slightly faster than C++ (and even that advantage disappears depending on which of the four processors they tried). Otherwise C++ is up to 3x faster, and an average, from glancing at the graphs, of about 2x faster.

      I tend to trust these benchmarks because anyone is free to defend their favorite programming language by submitting a faster program. Hence you don't get the bias that's all too common in benchmarks, where someone tries to write Java in C++, or vice versa. Those benchmarks are also running pretty up-to-date versions of g++ and the Java HotSpot Server VM, so you don't have "five years ago A was X tines faster than B, but it's changed".

    14. Re:shipping java scientific software for 15 years by JAlexoi · · Score: 1

      Yes... Micro benchmarks are exactly the best way to verify real performance. /s

    15. Re:shipping java scientific software for 15 years by JAlexoi · · Score: 1

      JVM JIT tends to be the best

    16. Re:shipping java scientific software for 15 years by Anonymous Coward · · Score: 0

      That is why the JVMs are mainly written in java, oh wait it's not. (think LISP before dismissing this)
      Okay sometimes they are but then it's not so fast
      http://www.se-radio.net/2009/09/episode-144-the-maxine-research-virtual-machine-with-doug-simon/

      C++ vs Java is like manual vs auto transmission.
      A skilled driver can get better performance, but most drivers are probably better off with an auto.

    17. Re:shipping java scientific software for 15 years by ebno-10db · · Score: 1

      Ok, so where are some better benchmarks? Everybody knows benchmarks have problems, but without them all you've got is hot air.

    18. Re:shipping java scientific software for 15 years by Hognoxious · · Score: 1

      It's hardly moving away from it. It's still there, like a deformed and psychotic half-relative that you lock in the cellar and feed through an interlocked hatchway and don't mention in polite company.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  31. And in 5 years? by pak9rabid · · Score: 1

    ... in the forums where the cool kids hang out is against Java...

    Yeah..and how many of these "developers" are still going to be writing code in 5 years?

    1. Re:And in 5 years? by Hognoxious · · Score: 1

      None. They'll be in management. [shudder]

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  32. Java's problem isn't verbosity by engun · · Score: 5, Insightful

    Java's problem isn't verbosity IMHO. It's the general mindset and community that has grown around the language. Instead of simplicity, they've gone into massive over-engineering, with factory factory factories and the like. A combination of pattern mania, and "enterprise" java, has resulted in turning an otherwise simple language into a veritable nightmare. Contrast this with the python community for example. Language wise, compare Java with C#. C# has done things a lot better in general. It may help that newer versions of Java will achieve some degree of feature parity with it but in the long run, I think it also has to be accompanied by a shift in the general notion of what's "normal" design in the Java world.

    1. Re:Java's problem isn't verbosity by Kagato · · Score: 5, Funny

      There's certainly a lot of factory pattern stuff out there. But your comparison is a bit outdated. Now days development uses a lot of annotations, auto-wiring/dependency injection. If I need to roll out a web service that makes some DB calls it's not that big of a lift. Maybe a half a dozen classes to get the job done (including tests).

    2. Re:Java's problem isn't verbosity by Anonymous Coward · · Score: 1

      Former / current Java dev here. I agree that the Sun/Oracle-blessed Java world was moving towards overly verbose and XML-config-driven everything. What I like about the Java ecosystem is that, at least for server-side Java, there's always some plan B. In the case of Enterprise/server-side Java, the IoC people came out hard and strong against the verbosity and came up with things like Spring, etc as alternatives. What I further like about Java is that the Spring model really won out and the official J2EE direction was changed to be more in line with the approaches that were in Spring and others.

      This has been the history of Java, IMO. A great idea usually starts with "wild" open source, then moves to Apache, and sometimes moves into the Java mainstream. This is how logging, db persistence, and other technologies came about. Yes, Sun/Oracle was the dictator of the ecosystem, but they do seem to listen to demand now and again and go with a better idea if one exists.
      I think the tendency of critics is to focus on desktop Java, of which I'm including both applications and applets. Java never really reached a critical adoption here, and all the criticisms of the desktop ecosystem (slow to start, security-challenged, difficult to *easily* make nice, performant UIs) are completely valid. But it would be a mistake to extend those criticisms to the server side and ignore the real strength of Java. It's a breeze to create REST services that do typical business logic, with lots of shortcuts using annotations instead of XML config files. I've shown this to some Python heads to favorable feedback.

      In the Fortune x00 or x000, it's really a .Net vs Java world, and I much prefer the Java option.

    3. Re:Java's problem isn't verbosity by Dynedain · · Score: 3, Informative

      You know what's fun? When a so-called Java expert runs a PHP project...

      Nothing but him bitching about how PHP sucks, and then discovering his code has factory factory factories in a central component that everything extended from (even when obviously unnecessary). And we wondered why we were having such performance issues.

      --
      I'm out of my mind right now, but feel free to leave a message.....
    4. Re:Java's problem isn't verbosity by Jahta · · Score: 1

      Java's problem isn't verbosity IMHO. It's the general mindset and community that has grown around the language. Instead of simplicity, they've gone into massive over-engineering, with factory factory factories and the like. A combination of pattern mania, and "enterprise" java, has resulted in turning an otherwise simple language into a veritable nightmare.

      That may well have been valid back in the old J2EE days. But I'm guessing you are not familiar with frameworks like Spring (and the evolutions in the core Java platform in response). These days, it's simple POJOs, with annotations and dependency injection; no muss, no fuss. If you're writing a lot of verbose Java code (or you're bogged down in pattern mania) you doing it wrong; and working too hard!

    5. Re:Java's problem isn't verbosity by hondo77 · · Score: 5, Insightful

      Nothing but him bitching about how PHP sucks...

      To be fair, it does.

      --
      I live ze unknown. I love ze unknown. I am ze unknown.
    6. Re:Java's problem isn't verbosity by angel'o'sphere · · Score: 1

      Java is certainly anything but overengineered.
      People claiming so simply have not enough experience.
      Which factory e.g. did annoy you in particular, and why?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    7. Re:Java's problem isn't verbosity by Anonymous Coward · · Score: 0

      PHP does suck.

    8. Re:Java's problem isn't verbosity by sydneyfong · · Score: 1

      The Spring framework is the symptom.

      I spent my idle hours contemplating who on earth would invent such a system, and who on earth would want to use one.

      --
      Don't quote me on this.
    9. Re:Java's problem isn't verbosity by Dynedain · · Score: 2

      Especially when you try to make it operate like Java.

      --
      I'm out of my mind right now, but feel free to leave a message.....
    10. Re:Java's problem isn't verbosity by TheDarkMaster · · Score: 1

      Exact on target.

      --
      Religion: The greatest weapon of mass destruction of all time
    11. Re:Java's problem isn't verbosity by Anonymous Coward · · Score: 0

      Java's problem isn't verbosity IMHO. It's the general mindset and community that has grown around the language. Instead of simplicity, they've gone into massive over-engineering, with factory factory factories and the like. A combination of pattern mania, and "enterprise" java, has resulted in turning an otherwise simple language into a veritable nightmare. Contrast this with the python community for example.

      Language wise, compare Java with C#. C# has done things a lot better in general. It may help that newer versions of Java will achieve some degree of feature parity with it but in the long run, I think it also has to be accompanied by a shift in the general notion of what's "normal" design in the Java world.

      You would find the same patterns in enterprise Python development on the same scale, but Python isn't used across as wide a spectrum as Java.

      It's like a unix shell programmer complaining about fancy object oriented Perl hoopla. In the cases where it is really appropriate, shell is not. It's not really a problem with Perl (lol, or is it), because you can do just fine with lightweight plain Perl.

      You can write simple Java just like you can write simple Perl.

    12. Re:Java's problem isn't verbosity by Anonymous Coward · · Score: 0

      I don't really understand why verbosity is a problem these days. Use a decent IDE (e.g. Eclipse) and with all the autocompletions, quick-fixes, code generation and refactorings, it doesn't really matter if a language has verbose syntax or not. I'd even say that verbosity is an advantage in reading the code, and when it's basically as easy to develop, then there's no issue IMO.

      What I think is Java's big issue is the refusal to make non-backwards-compatible changes to the basic syntax. Anyone who has worked with it for longer periods has to be thinking "who the fuck thought out these access qualifiers"? Default being package-internal, protected meaning inherited AND package-internal. No qualifier for subpackages and therefore no possibility in making package structures. If you're not in my package, there's no difference where you are. So if I want to split a package because it has grown, suddenly I have to make everything public so the entire world can access it. Crap.

      Why not integrate unit testing into the language to e.g. give differentiated access to test classes without exposing things to regular classes?

      And most of all: No chance to return multiple values (at least tuples for crying out loud). Do I have to make a new class if I want to return a pair of ints? Really?

      Why not have "final" as default everywhere and make the user instead add a keyword when something is non-final instead of the opposite. Bad defaults just makes the careless programmer write bad code.

      And why, oh why can't the goddamn language allow support for character-by-character reading from System.in? If it can be done in the GUI classes, are you just messing with us so we can't get the same things if we implement a console. FFS.

      Why not change so that Map#remove take an Object? How many million times have someone accidentally input the wrong type to a map and get unexpected results.

      I don't care much about the lambda expressions and the minor things like the try-with-resources, those make it somewhat easier to write code, but they don't really allow me to do new things. Please break backwards-compatibility and remove the legacy backpack that it just weighing us down.

      And finally: Time to scrap javac and just let ECJ take over instead. There's really no reason to use the former when the latter has about a million more configurable warning levels etc. Either make javac into decent compiler so it at least can match the options of stone-age-compilers like GCC, or drop it.

    13. Re:Java's problem isn't verbosity by ebno-10db · · Score: 1

      Thanks for a good explanation. My day job is low-latency deeply embedded hard real-time (wow, that's verbose) so Java is obviously not my schtick (to anyone who asks, Android apps don't come even close to that situation). Due to the lack of adoption on the desktop, the slow startup, etc., I always wondered if so many people are writing Java, then what are they writing it for? Now I know.

      Too often programmers get very egocentric and think that whatever type of code they develop, it's the be all and end all of programming. They forget about all the areas with different requirements. One size does not fit all, and never will. It's clear why Java may be very appropriate for what you do.

    14. Re:Java's problem isn't verbosity by hraponssi · · Score: 1

      Yes I like the language, the JVM and the great tools+libraries it has. But the most of the most popular ones just make me want to run away when I have to use them. Eclipse is horribly unintuitive unless you used it for years and learned to trick it. IntelliJ is great but nowhere near as popular and well known. If I have to talk to someone and show something in the IDE they are always hugging their Eclipse cause "everyone else does it".. Can't blame people for not liking it if they have Eclipse forced on them.

      Then there are the libraries/frameworks like Spring, Hibernate, the REST stuff, etc. I just don't get the need to hide everything in a factory of this and factory of that and put this annotation there. I try to debug it and figure out what is going wrong and it is way too complicated because it is all hidden under 50 layers of abstraction and it is near impossible to figure out what is really going on. Not to mention when I try to get something simple to run such as a remote call over HTTP/JSON and it takes me a day to browse the docs to see how to set up the weird dependency injects, annotation configurations and whatnot.

      And then the idea of "I need to do a logical expression (such as &&), let me pull in that Apache library with zillion features to do it..". Small projects ends up with some 100+ libraries for the simplest things you could do in a few lines of code, resulting in even more added complexity for no real gain. Then there is the Maven to hide your build and require a pile of configuration files spread out, added to the configuration files for all the dependency injection etc. making it impossible to navigate the code and understand it.

      In some cases the factory pattern is difficult to avoid since it has not been possible to define a lambda/closures thing but hopefully the next version fixes that. Now I just wait for what kind of a mess people will make with the stream API. Some of the reputation for Java being overly verbose it true and it is fashionable for geeks to bash Java for it, but the whole stream API just seem like the perfect opportunity to write weird to understand code. Hopefully I am just too old, resistant to change, and will learn to read/like it..

    15. Re:Java's problem isn't verbosity by felix+rayman · · Score: 1

      Haha POJOs.

      I love that typical developers using Java, an object-oriented language, got so far down the over-engineering path that they had to make an acronym for those obscure corner cases where you might want to just use....an object.

      Although it's true that the Java development community does seem to be header in a much nicer direction lately.

    16. Re:Java's problem isn't verbosity by engun · · Score: 1

      No, I agree that the Java language itself is not over-engineered. I said that the frameworks and community that have grown around it, have a tendency to over-engineer (especially in the enterprise). That is not to say there are no efforts within the community to overcome that, but having shifted from enterprise Java to C/Python and also having worked a fair bit with C#, I do have some experience with the general ethos in each of the communities.

      RE: "Which factory e.g. did annoy you in particular, and why?" Joel explains it better: http://discuss.joelonsoftware.com/?joel.3.219431.12

    17. Re:Java's problem isn't verbosity by stewsters · · Score: 1

      The problem is that there are some old functions in that language that should never have been added, and many of the developers of php apps don't know enough to avoid them. PHP can be a decent language if you have self control.

      http://php.net/manual/en/control-structures.goto.php
      http://php.net/manual/en/function.extract.php
      http://php.net/manual/en/function.mysql-real-escape-string.php
      http://php.net/manual/en/function.eval.php
      Also, have they added multithreading yet?

    18. Re:Java's problem isn't verbosity by angel'o'sphere · · Score: 1

      Yeah, but that is about frameworks and not about factories :D

      I agree that many frameworks completely fail to make clear what problem they solve in which way and why that approach was chosen or is preferred.

      Then they have ten so simplified examples that you have no clue how to grow from that into a real solution for your project.

      Well, Joel wrote many bullshit, but also quite some nice stuff.

      Ah I see at the end he talks about the hammer factory factory builders ... erm ... something like that.

      Well, never encountered that in a Java framework.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    19. Re:Java's problem isn't verbosity by Hognoxious · · Score: 1

      Former / current Java dev here.

      Make your mind up. Which?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    20. Re:Java's problem isn't verbosity by Anonymous Coward · · Score: 0

      I'm thinking one of these days the php crowd will as least learn to use a real database and get the fuck off mysql & similar shit.

      I'm fucking tired of people assuming that open source database means Mysql/minerva, oh please let that POS die!!!

  33. Dude, still on dial-up? by Latent+Heat · · Score: 1

    I am also in th5554444&&&&&&

  34. Google Chrome is killing java by goombah99 · · Score: 2, Interesting

    The thing about Java is that despite flaws it was cross platform. that is it was, up until chrome. Right now you can't run the latest java in chrome. (chrome is 32 bit, and java 1.7 is 64 only.) And then there's chromebook which also has no java. And then there's Dalvik. So google seems to be pulling a microsoft on Java. I've switched away from using chrome to boycott google.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:Google Chrome is killing java by binarylarry · · Score: 5, Insightful

      Java is a lot bigger than Java Applets.

      Java Applets fucking suck and deserve to die.

      --
      Mod me down, my New Earth Global Warmingist friends!
    2. Re:Google Chrome is killing java by Anonymous Coward · · Score: 0

      chrome isn't a platform. Google will drop it in a year or two.

    3. Re: Google Chrome is killing java by Anonymous Coward · · Score: 0

      Java, ObjC, Delphy, Visual Basic, C# are lock-in platforms developed by corporate interest, jolly good luck using those in a long run.

    4. Re:Google Chrome is killing java by GodfatherofSoul · · Score: 1

      Actually, it's not the applets idea it's the fairly recent exploit. I'd been a big user of Java applets previously and was a regular user of Yahoo Games which is a huge online community for all kinds of card and board games. When people bag on applets, they're usually thinking about how terrible performance was 15 years ago. The latest vulnerabilities didn't help much either.

      --
      I swear to God...I swear to God! That is NOT how you treat your human!
    5. Re:Google Chrome is killing java by MattW · · Score: 0

      Do people still write applets? I thought they were actually dead. Any motion is the decomposition taking place.

      Java is a server language of choice for a lot of developers, and if not Java the language, then at least a JVM language (Scala, Groovy, Jython, etc).

    6. Re:Google Chrome is killing java by RaceProUK · · Score: 5, Informative

      (chrome is 32 bit, and java 1.7 is 64 only.)

      Total bollocks. Here's 32-bit Java for:

      Windows

      Linux (tarball)

      Linux (RPM)

      --
      No colour or religion ever stopped the bullet from a gun
    7. Re:Google Chrome is killing java by Anonymous Coward · · Score: 0

      My desktop is 32-bit, yet I seem to be running Java build 1.7.0_25-b17

    8. Re:Google Chrome is killing java by Groboclown · · Score: 2

      Java is a lot bigger than Java Applets.

      Java Applets fucking suck and deserve to die.

      ... except when used in the Java4k game contest. Shameless plug? You betcha. But it's still a great place to find interesting submissions, such as those by _Notch.

    9. Re: Google Chrome is killing java by MightyMartian · · Score: 1

      There are open source Java and Objective C compilers. That strikes me as a pretty weak vendor lockin.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    10. Re:Google Chrome is killing java by angel'o'sphere · · Score: 1

      You can download a Java 1.7 32 bit version from Oracle.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    11. Re: Google Chrome is killing java by kthreadd · · Score: 1

      Indeed. Apple's Cocoa libraries on the other hand. The language is open.

    12. Re:Google Chrome is killing java by DickBreath · · Score: 1

      Java 7 update 25 is no longer current. You should upgrade to Java 7 update 40.

      --

      I'll see your senator, and I'll raise you two judges.
    13. Re: Google Chrome is killing java by Anonymous Coward · · Score: 0

      In fact I'm pretty sure there are only open source Objective C compilers.

    14. Re: Google Chrome is killing java by Anonymous Coward · · Score: 0

      Java, ObjC, Delphy, Visual Basic

      Yup, you really know what you're talking about.

    15. Re: Google Chrome is killing java by Anonymous Coward · · Score: 0

      GNU Java compiler sucks balls. It can't compile anything higher than 1.4.

  35. Hooray! by Greyfox · · Score: 3, Funny

    I'm looking forward to having to support crappily-engineered code in some other language! I'm going to slap the first in-house engineer who suggests we jump on the NetRexx bandwagon.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    1. Re:Hooray! by slim · · Score: 2

      I worked in Rexx on MVS and OS/2 in the early 90s. I'm astonished it's not dead and buried.

    2. Re:Hooray! by NeoMorphy · · Score: 1

      I worked in Rexx on MVS and OS/2 in the early 90s. I'm astonished it's not dead and buried.

      Unless IBM decides to port another scripting language like Perl or Python to Z/OS(OS/390,MVS) and z/VM/CMS, REXX isn't going anywhere.

      I've used REXX on MVS, VM/CMS, and OS/2, it's a lot better than Exec or Exec2. But after moving to UNIX and learning Perl, I never looked back.

  36. CTRL-F ask.com by BigTunaTim · · Score: 0

    0 results found. You're slipping ./

  37. It's shocking by kelemvor4 · · Score: 2

    With Oracle doing everything possible to kill Java, it's shocking that Java persists.

    1. Re:It's shocking by DrEasy · · Score: 3, Funny

      With Oracle doing everything possible to kill Java, it's shocking that Java serializes.

      FTFY. :)

      --
      "In our tactical decisions, we are operating contrary to our strategic interest."
    2. Re:It's shocking by Anonymous Coward · · Score: 0

      OpenJDK lives on regardless

  38. Re:If there's such a market.. why the Ask toolbar? by Anonymous Coward · · Score: 0

    enough to not give a fuck about you

  39. On the verge of using a type twice as wide by tepples · · Score: 2

    Functionally speaking, how important is it to have an unsigned data type rather than having the equivalent data type and enforcing a "no negative values" rule?

    If your application logic's requirements include being able to represent values between 2^((2^n) - 1) and (2^(2^n)) - 1, such as 128 through 255 or 32768 through 65535 or about 2.1 to 4.2 billion, in a cache-efficient array, you usually want to use an unsigned type. This often comes up when trying to represent the native unsigned data types of an emulated machine or the unsigned data types of various SQL databases. You could use a type twice as wide, but that'd fill L2 cache twice as fast, causing capacity misses. And on mobile, it'd fill RAM twice as fast, causing the system to kill your application for having run out of memory.

    1. Re: On the verge of using a type twice as wide by Anonymous Coward · · Score: 0

      As soon as you said "cache efficient", Java went flying out the window. Welcome back to C, my friend! We've been waiting for you!

    2. Re: On the verge of using a type twice as wide by tepples · · Score: 1

      An inner loop written in C (or in another time-efficient subset of C++) is fine as long as your platform's curator allows it. A few platforms that I can think of either require all apps to be in managed code (e.g. Windows Phone 7, some Java ME phones) or have a huge entry barrier to native development that a small shop can't surmount (e.g. Xbox 360, other Java ME phones).

  40. update nagging by csumpi · · Score: 4, Insightful

    I only have two issues with java:

    - the constant nagging from the java updater. (Although to be fair, the updater has been killed on any and all of my devices.)

    - the braindead way of keeping old version of the jdk and jre around. Words can't describe how freaking lame this is. I only want one java directory, with one jre and one jdk in it. The new versions need to replace the old ones and provide backwards compatibility.

    1. Re:update nagging by angel'o'sphere · · Score: 1

      The new versions _don't_ provide backward compatibility.
      And having seperate directories is exactly the rit way to go. You have full control over your installations. If there was only _ONE_ Java installation and it would not work anymore with your age old mission critical application I assume you would be rather pissed!

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    2. Re:update nagging by Anonymous Coward · · Score: 0

      I'm not exactly sure what you mean by no backwards compatibility. From a practical perspective, I can take the java 1.7 jdk, and make a java 1.3 application, that others can use with only the java 1.3 jre. Granted, I haven't tried anything before 1.3, nor have I tired every single class to make sure it works. Maybe what you mean is that if I write everything using only java 1.3 language constructs, but then target a 1.7 jre, then yes, the application won't run, but I'd consider this more "forward compatibility"

      That being said, I don't really care how they handle the java directory. I program in this pretty much every day, and I don't ever have a need to look. why would this really bother anyone?

    3. Re:update nagging by ConceptJunkie · · Score: 1

      That's why so many Java apps are now distributed with, and install and use, their own copy of the JRE, which I think is the logical end-point of the whole Java mentality.

      --
      You are in a maze of twisty little passages, all alike.
    4. Re:update nagging by ADRA · · Score: 1

      "the braindead way of keeping old version of the jdk and jre around."

      I don't know why it bothers, but it certainly isn't required. Usually the only time that happens is in major rev's of the architecture, and to be fair .NET and other major lib changes do the same thing.

      Oracle was in part responsible when they required Java 1.1 a decade after it was dead when you installed OracleDB locally.

      --
      Bye!
    5. Re:update nagging by csumpi · · Score: 1

      The new versions _don't_ provide backward compatibility.

      Now that would just be plain stupid, and it's obviously not true.

    6. Re:update nagging by angel'o'sphere · · Score: 1

      It is obviously completely true.
      Or do you really believe a Java 1.1 AWT applications still runs on Java 1.7? Cross Platform?
      The newer VMs can run older byte code, but many "depricated" APIs no longer exist in the newer "Java (the platform)" installations. Hence the application wont be able to load the requested classes or wont be able to call non existing methods.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    7. Re:update nagging by VortexCortex · · Score: 1

      I think they're onto something.


      6. Installation

          a. Linux:
              Follow add the software repository from the following
              list then install the package named "my-software"

      ...

          b. Windows:
              Install Linux, then see step 6a.

      I should probably just distribute it on a Debian LiveCD...

    8. Re:update nagging by ConceptJunkie · · Score: 1

      Yeah, it's an unfortunate downside of "Write once, run anywhere, but only with this very, exact, precise version of the JRE" that is the reality for too much Java software.

      --
      You are in a maze of twisty little passages, all alike.
    9. Re:update nagging by Anonymous Coward · · Score: 0

      The only fucking way you are getting nags is because you are using that shitty toy called Windows.

      Get a real OS you fuckwit

    10. Re:update nagging by Anonymous Coward · · Score: 0

      You must be using windows, had you been using alternate operating system, there would be no nagging.

  41. Java will never die!!!!! by Anonymous Coward · · Score: 0

    I doubt Java will die in my lifetime and I am only in my 40's. Some people have no clue how many devices use java code.

  42. Re:If there's such a market.. why the Ask toolbar? by Anonymous Coward · · Score: 0

    Yeah, wish I had mod points... that "Ask" bit really been bugging me more and more lately... the presence of "ask-ware" is usually my indicator that some previously nice freeware tool developer has finally decided to cash in and that I should expect more "monetization" schemes to follow... I.E. start looking for a replacement "free" app because this one is about to become nag-ware.
    Now, I have nothing against a small developer trying to cash in a bit on a good idea, but ORACLE?? Really?

  43. Java is the new COBOL by ErichTheRed · · Score: 4, Funny

    - Most CS programs train their graduates in Java.
    - Java is pretty much the enterprisey middleware language these days. I've seen so many J2EE applications alive inside organizations doing mundane but vital tasks.
    - Unless you're a web startup, Java is almost universally used for line-of-business application development. That ugly GUI that collects budget numbers from 500 databases and displays an "executive dashboard" was probably slapped together by an Accenture type outfit using offshore new grad coders and sold to companies for millions.

    It's just too prevalent now for people to say, "Oracle sucks, we're porting everything to C#." I can definitely see a market for Java talent similar to the COBOL market 30 years down the road. People won't need millions of Java coders anymore, but they'll need older expert types to go untangle messes.

    1. Re:Java is the new COBOL by WheezyJoe · · Score: 1

      That ugly GUI that collects budget numbers from 500 databases and displays an "executive dashboard" was probably slapped together by an Accenture type outfit using offshore new grad coders and sold to companies for millions.

      THIS. ('nuff said).

      --
      Take it easy, Charlie, I've got an Angle...
    2. Re:Java is the new COBOL by Teckla · · Score: 1

      People won't need millions of Java coders anymore, but they'll need older expert types to go untangle messes.

      The good news is that Java code is relatively easy to untangle. Thanks to the design of the Java language, it's very easy to navigate and refactor code using modern IDEs like NetBeans, Eclipse, and IDEA.

    3. Re:Java is the new COBOL by znrt · · Score: 1

      i find your post more insightful than funny (it's kind of sad per-se that stating the obvious seems insightful in this context). guess the funny part is "Oracle sucks, we're porting everything to C#.". yeah, made me giggle too :)

    4. Re:Java is the new COBOL by K.+S.+Kyosuke · · Score: 1

      Thanks to the design of the Java language, it's very easy to navigate and refactor code using modern IDEs like NetBeans, Eclipse, and IDEA.

      Which is another phrase for "The language is so chock-full with phrasal idioms and low on signal/noise ratio that we both CAN and HAVE TO automate its editing"...?

      --
      Ezekiel 23:20
    5. Re:Java is the new COBOL by Teckla · · Score: 1

      Which is another phrase for "The language is so chock-full with phrasal idioms and low on signal/noise ratio that we both CAN and HAVE TO automate its editing"...?

      Nope, not at all.

      I think Java found a pretty good balance in terms of brevity vs. verbosity. Most software development is maintenance, so what you really want is readability. Brevity vs. verbosity is a foolish debate that misses the point.

      But it's all subjective, to each his own. Unfortunately, many people want to turn it into some kind of religious debate and hate hate hate the infidels and love love love the true believers.

      Whatever.

    6. Re:Java is the new COBOL by Anonymous Coward · · Score: 0

      Brevity vs. verbosity is a foolish debate that misses the point.

      Many style gurus in the writing department would probably argue that concise writing is readable, and baroque writing needs to be deciphered first. Why would programming languages be any different?

  44. who it is popular with by cascadingstylesheet · · Score: 3, Interesting

    For whatever reason, Java seems to be popular with the work to spec, outsourcing shop types.

  45. That's because the "cool kids" ignore servers by daboochmeister · · Score: 3, Funny

    Java must be dying - when's the last time you saw an applet? Let's ignore that it's hugely popular on servers, for enterprise development.

    --
    "Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh ... never mind." Dave Bucci
  46. Native code produces a security exception by tepples · · Score: 3, Interesting

    But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

    Provided that the platform curator even allows the use of lower-level languages. For example, Java applets have to be written in Java, and Xbox Live Indie Games and Windows Phone 7 applications have to be written in C#.* An applet that attempts to use JNI or an XNA game for Xbox 360 or application for Windows Phone 7 that attempts to use P/Invoke will die with a security exception.

    * Technically, XBLIG and WP7 allow the subset of verifiably type-safe CIL accepted by the .NET Compact Framework. But in practice, languages other than C# either aren't verifiably type-safe (such as standard C++ in C++/CLI) or require library facilities not present in the .NET Compact Framework (such as any DLR language).

    1. Re:Native code produces a security exception by HaZardman27 · · Score: 1

      If you're writing an applet, you're already doing something wrong ;)

      --
      Apparently wizard is not a legitimate career path, so I chose programmer instead.
    2. Re:Native code produces a security exception by tepples · · Score: 1

      The point remains the same nevertheless. MIDlets for Java ME phones have to be written in pure Java for the same reason as applets for browsers supporting Java SE.

  47. Have you seen how much those flying yachts cost? by swb · · Score: 2

    Larry Ellison is just another borderline personality disorder businessman who doesn't give a fuck about anything besides making himself richer and self-aggrandizement.

    He and Ballmer should go to some private island and never be seen again.

  48. The Java platform is an engineer’s dream by Anonymous Coward · · Score: 0

    First there’s the Java platform. The HotSpot JVM is a marvelous piece of engineering. It does stuff the CLR can only dream of and is so heavily optimized that often Java apps can even match the performance of C programs. Also, there is quite a selection of other virtual machines available (such as JRockit, Zing), should your environment have some specialized requirements.

    Secondly there’s a multitude of JVM-based languages, which makes the platform even more amazing. It goes way beyond the famous ones like Groovy, Jython, JavaFX and Scala. Java now includes such treats like invokedynamic opcode and the java.lang.invoke package, making it easier to build dynamic languages for the JVM. There’s already a line up of over 50 JVM-based languages, one of the most interesting ones being php.reboot, which aims to keep the philosophy of PHP but remove its shortcomings. And it also works for Android, too.

    There's another good piece on how java's not quite dead yet

    1. Re:The Java platform is an engineer’s dream by ebno-10db · · Score: 1

      so heavily optimized that often Java apps can even match the performance of C programs

      Benchmarks?

    2. Re:The Java platform is an engineer’s dream by Anonymous Coward · · Score: 0

      You can't utilize benchmarks on /. because everyone will just tear apart how the "benchmarks weren't setup properly" and "these numbers mean nothing it isn't a real world case".

    3. Re:The Java platform is an engineer’s dream by ebno-10db · · Score: 1

      Benchmarks are the worst possible way of measuring program speed, except for all the others that have been tried from time to time.

      -- with apologies to W. Churchill

    4. Re:The Java platform is an engineer’s dream by Ash-Fox · · Score: 1

      It does stuff the CLR can only dream of

      Like what?

      --
      Change is certain; progress is not obligatory.
    5. Re:The Java platform is an engineer’s dream by yacc143 · · Score: 1

      In the artificial benchmark world, yes you can manage to construct cases where a two liner in python can beat a C++ STL program. (Hint: C++ strings are mutable, Python one not. C++ has a strong preference for by-value semantics because it lacks GC. Hence stuff a huge multi-kb const string into a big dict, no matter what, STL map will be slower because it's forced to copy the stupid strings)

      In the real world of commercial development, yes, but it's a complete different pattern:
      experience shows (in at least one contract I had rather exactly the same situation), that the terser-language guys tend to be quite a bit more productive, hence while the C++ guys are happy to have finished their first iteration, the more productive guys are somewhere in their third iteration, yielding improvements in algorithms, data structures, inner-loops implemented in C, plus generally speaking a way better understanding of the problem space.

  49. Java Is Undead by Ukab+the+Great · · Score: 1

    I think of it like a George Romero zombie that has plodded along consuming and destroying brains for the better part of two decades and clumsily getting around the shotgun programming language deficiencies with each new release.

  50. Re: Keep it up - you might just invent assembly.. by Anonymous Coward · · Score: 0

    Yeah (lots(of(hidden($&@#code))) going on behind the scenes. Such constructs are really pleasure to debug and work with!

  51. "Java is dead" is a stupid Slashdot meme by GodfatherofSoul · · Score: 1

    Anyone with any real knowledge of Java knows how wrong that is. But, it's been cool on Slashdot to say so and it's automatic karma whoring when you do.

    --
    I swear to God...I swear to God! That is NOT how you treat your human!
  52. Android's future is bright so Java's future is... by Anonymous Coward · · Score: 0

    We all know that prior to Oracle buying Sun, Sun open sourced Java. So to talk about Java's future is to talk about the JVM and the language and consider both open source and closed source implementations (I see the pair as providing the coherent technology that is Java). The Dalvik VM in every Android device runs Java bytecode. Almost all Android apps are written in Java. Look at Android's increasing market share and look at how many of those apps use Java as opposed to NDK.

    Java in the enterprise has perhaps plateaued, but in most industries when it comes in enterprise technology it's either the Microsoft stack or the Oracle stack (some run hybrid environments even). I would say if anything the trend I've seen in Oil & Gas is moving away from Microsoft/.NET in favor of Oracle's tech

    Also, you can look at various surveys for most popular languages and Java is always at the top.
    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

  53. Scripting Language? by Anonymous Coward · · Score: 1

    Scala is not a scripting language

  54. Re:If there's such a market.. why the Ask toolbar? by Hypotensive · · Score: 2

    How am I supposed to take a platform seriously if the fundamental piece that has to be installed by all developers AND users to use it

    All the ones on Windows, anyway.

  55. In other News Turbo Pascal Surges in Popularity by Anonymous Coward · · Score: 0

    And ProLog and Modula to be updated by Borland International eclipsing Microsoft Visual Studio for the first time

  56. Dweebs hate Java because it is too easy by Squidlips · · Score: 1, Funny

    The same idiots who pushed C++ on us hate Java because it is not verbose and not "powerful"--i.e. it is easy to use and safe.

    1. Re:Dweebs hate Java because it is too easy by Luthair · · Score: 4, Funny

      Quite a few people just hate it because its popular.

  57. Javascript will kill the internet by gelfling · · Score: 1

    No really it will. Apparently there's a law that says to have a website you have to run 45 different Javascripts nested 4 layers deep or more. And because of it basically 99% of the hosts out there are essentially slow junk.

  58. Re:Have you seen how much those flying yachts cost by gtall · · Score: 1

    Noooooo....if they mated, they'd produce Satan's offspring more terrible than either of them alone. No, I think it best if we send them to private islands on different planets.

  59. Java is the new COBOL by Anonymous Coward · · Score: 1

    And it'll stick around for just as long...sadly

  60. Re:If there's such a market.. why the Ask toolbar? by Luthair · · Score: 1

    Microsoft does try install Bing cruft every time one updates Skype however.

  61. almost open source wins by peter303 · · Score: 1

    Oracle offeres it for free on many platforms. Java's similar competitors C# and ObjectiveC cant make that claim.

  62. Hugh Pickens DOT Com writes by nitehawk214 · · Score: 1

    Checklist:
    * Hugh Pickens DOT Com
    * Clickbait summary
    * Absurd premise
    * Trolling conclusion.

    --
    I'm a good cook. I'm a fantastic eater. - Steven Brust
  63. Java was dead back when they sued Microsoft by Anonymous Coward · · Score: 0

    I'm sorry but Java was dead the day they sued Microsoft. I don't blame em for doing so but that just put "lawsuit happy" up on the radar even if it had merit.

    Nobody, absolutely nobody wants to use any operating system, library, or runtime that may for legal reasons be unusable in the future. This is mostly why the GPL/LGPL is avoided in regards to Linux, and why Java is avoided by developers because of Oracle. The entire Android lawsuit is a tragic example of repeating the Microsoft lawsuit. Likewise everyone absolutely hates the Java crap on Android that everyone wants to build using the NDK (Native Development Kit) instead.

    If you are building using the Java language for Android, you're going to face a future where at some point Google throws in the towel and ejects it from Android. That is not a speculation, that is a promise. Start building your apps now for the NDK.

  64. Good by Anonymous Coward · · Score: 0

    Java is for people that find real languages too hard. It's like a person that can't paint using paint-by-number.

  65. "dying" by Anonymous Coward · · Score: 0

    People on Slashdot, and hell even the internet in general, love to say "X is dying!"
    And 99/100 times, they're totally wrong.

    Flash is dying, all hail HTML5!
    Windows is dying, all hail Linux!
    Mac is dying, all hail Linux!

    Among others.
    The biggest problem with these viewpoints is that the items from column B are not suitable replacements for column A.
    But of course, the stuck up nerds can't see that, they only see that whatever they're supporting is clearly superior.

    1. Re:"dying" by funky_vibes · · Score: 1

      Nope, all of these predictions were made before trends were possible. And now the trends are real.
      It's just your expectation of a short timeframe that's wrong.

      HTML5 is a less shitty (but still as annoying) replacement for flash.
      Just about all computer systems are moving toward Linux. Especially now, when the PC has turned into a phone in most homes.
      IT is an area worked many clever people, generating scaringly accurate predictions.

      Fact is, Java simply isn't a suitable replacement for programming. And that's why people think it won't last.

  66. "cool kids"? /. has become corporate by Baldrson · · Score: 1
    This kind of talk, bolstering a platform that is dominant by virtue of its network effect in corporate culture, is, quite simply, corporate.

    Let's be clear on what /. used to be and what it has become.

    /. used to be a place where technology was king.

    /. is now a place where kings are king.

  67. Speed is Everything by LifesABeach · · Score: 1

    If Python, Ruby, PHP, and Javascript were sled dogs, they would be following Java. and the view would never change.

  68. Dr Dobbs... by Luthair · · Score: 1

    Sure has a cutting edge website, readers are no doubt the technical leaders of the world.

    1. Re:Dr Dobbs... by oh_my_080980980 · · Score: 1

      So web sites optimized for tablet viewing are considered cutting edge...wow...nobody said script kiddies were smart....

  69. It's not dead... by Phoenix666 · · Score: 1

    ...it's just compiling.

    --
    Do what you can, with what you have, where you are.
  70. Economy is driving JavaOne? by Anonymous Coward · · Score: 0

    Could it just be that with an improving economy, more company's are willing to fork out the thousands of dallars per developer to go to JavaOne?

  71. sorry but ... by znrt · · Score: 1

    who said java was dying (apart from some of the dozens of clueless tech-tabloids regularly cited on /.) ?

  72. Re:If there's such a market.. why the Ask toolbar? by VGPowerlord · · Score: 1

    How am I supposed to take a platform seriously if the fundamental piece that has to be installed by all developers

    You had me up until said you "all developers".

    Developers need the Java Developers Kit, which notably doesn't prompt you to install toolbars. Nor does the JRE installer on the Java developer site (which used to be java.sun.com).

    Unfortunately, unless you know to grab the installer from there...

    --
    GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
  73. Re:If there's such a market.. why the Ask toolbar? by phantomfive · · Score: 1

    Even Microsoft doesn't try to install Bing with the .NET installers, and that's their own property they're desperately trying to push on everyone.

    They install it with the OS.

    --
    "First they came for the slanderers and i said nothing."
  74. Java has had closures for years by Animats · · Score: 2

    Java has had closures, with all the stuff that does to local variable lifespan, since Java 7. Lambda expressions are just syntactic sugar for writing small closures.

  75. So fix it by Weaselmancer · · Score: 1

    It's an object oriented language. If it's missing a type you need, go make one.

    --
    Weaselmancer
    rediculous.
    1. Re:So fix it by HornWumpus · · Score: 1

      It's a broken OO language. When it supports operator overloading you will be correct. Until then, it sucks.

      You can understand most of what is wrong with Java by reading about int vs Int. Enjoy IAdd and the like. Worse then Cobol.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  76. Re:Have you seen how much those flying yachts cost by lgw · · Score: 1

    Now that's just plain wrong. C'mon: there's nothing about Larry's personality disorders that should be described as "borderline".

    Ballmer at least has the grace to exit - give him credit for that!

    --
    Socialism: a lie told by totalitarians and believed by fools.
  77. JAVA.. by Anonymous Coward · · Score: 0

    Fork it... .NET Framework, hands down.

  78. Re:If there's such a market.. why the Ask toolbar? by IamTheRealMike · · Score: 4, Informative

    The Windows JRE installer is an obnoxious piece of crap. Fortunately modern JDKs ship with something called the JavaFX Bundler, which makes native installers (exe, msi, dmg, rpm, deb) for each platform that bundles a stripped down JRE with the app, so there is no need to install the JRE or keep it up to date. If you are distributing consumer software or don't want to handle the problem of keeping JREs up to date, it's useful.

    There are also tools that can eliminate the need for the JVM entirely, for instance by ahead of time compiling entirely to native (Excelsior JET is one such program), or alternative JVMs that sacrifice some performance for code size, like Avian.

  79. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  80. Java is fine, the JVM is thriving... C# dying by echtertyp · · Score: 1

    Java is evolving nicely. JVM languages, such as Scala and Clojure, are booming, and awesome to work with. C# , and .NET, are going the way of the Soviet Union.

  81. Java will still be used in 1000 years from now by Anonymous Coward · · Score: 0

    The only people that hate Java are either Microsoft programmers (VB,etc) and hard-core C programmers.

    My favourites languages: Java (J2SE, Android) and PHP/Mysql (web).

    My latest Java software: myubank.com/download.php

  82. Confusion by Fnord666 · · Score: 1

    This is what happens when you confuse anecdotal evidence with fact.

    --
    'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
  83. BSD is dying by Nick · · Score: 1

    It is now official - Netcraft has confirmed: *BSD is dying Yet another crippling bombshell hit the beleaguered *BSD community when recently IDC confirmed that *BSD accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as further exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

    --
    Fuck Ajit Pai
  84. Java has a killer enterprise feature by Anonymous Coward · · Score: 0

    Java is alive and stands well against newer alternatives simply because java programs are easier for new developers to get up to speed with reading and modifying existing code than newer scripting languages. This is a killer enterprise feature.

    Majority of LOB apps perform non-glamurous, but neccessary tasks (as some poster already wrote). But these tasks are critical for business and there is often a need (change of business reality, new insights, regulatory changes, ...) for expedient changes in software. People move around, so it's important that new developers are able to quickly grasp the existing code and get to the point where they are able to do working modifications. The software is also often poorly engineered (because it's developed quickly and because of high variability in developer skill in real world), so it's important that enterprise language makes understanding any (even poorly made) existing code easier. Business pays for this kind of advantages, so java is far from dying, even if writing new code might be less productive.

    Static typing and well-defined language enables quick and complete exploration of code from IDE, for example finding all the references to a variable or a method (OK, it won't catch the references done via the reflection mechanism, but that's a trade-off worth having). It's also better suitable for assisted refactoring (important for improving the structure of existing code with minimum hassle) in IDEs with less need for programmer to understand the internals of code, since the IDE has more knowledge about code. Static type checking also gives immediate feedback about the state of codebase at compilation time (or in editor), which simpifies the coordination with multiple programmers on a project and reduces (not eliminates, mind you) the need for running unit tests.

    It is probably worse fit for some things, for example tipical applications for web startups, where quick exploratory development of new functionality is more important and where the talent is more selected and personally invested (stock options).

  85. Java killer enterprise features by Anonymous Coward · · Score: 0

    Java is alive and stands well against newer alternatives simply because java programs are easier for new developers to get up to speed with reading and modifying existing code than newer scripting languages. This is a killer enterprise feature.

    Majority of LOB apps perform non-glamurous, but neccessary tasks (as some poster already wrote). But these tasks are critical for business and there is often a need (change of business reality, new insights, regulatory changes, ...) for expedient changes in software. People move around, so it's important that new developers are able to quickly grasp the existing code and get to the point where they are able to do working modifications. The software is also often poorly engineered (because it's developed quickly and because of high variability in developer skill in real world), so it's important that enterprise language makes understanding any (even poorly made) existing code easier. Business pays for this kind of advantages, so java is far from dying, even if writing new code might be less productive.

    Static typing and well-defined language enables quick and complete exploration of code from IDE, for example finding all the references to a variable or a method (OK, it won't catch the references done via the reflection mechanism, but that's a trade-off worth having). It's also better suitable for assisted refactoring (important for improving the structure of existing code with minimum hassle) in IDEs with less need for programmer to understand the internals of code, since the IDE has more knowledge about code. Static type checking also gives immediate feedback about the state of codebase at compilation time (or in editor), which simpifies the coordination with multiple programmers on a project and reduces (not eliminates, mind you) the need for running unit tests.

    It is probably worse fit for some things, for example typical applications for web startups, where quick exploratory development of new functionality is more important and where the talent is more selected and personally invested (stock options).

  86. Platform constrains language choice by tepples · · Score: 1

    True, I can find another language. But the other language just happens not to have a runtime environment on the target platform, as 0xdeadbeef and I pointed out.

  87. Unsigned money types; ordinals as cardinals by tepples · · Score: 1

    Cardinal numbers indicate a count of objects: "one, two, three".

    Such as a count of each distinct item on an order and a count of cents that the customer paid for each item. For obvious reasons, a negative value would be inconsistent.

    Ordinal numbers indicate an order - a position in a sequence: "first, second, third".

    Ordinal numbers have two mappings to the cardinal numbers. A "zero-based count" represents an ordinal as the number of items that have already been considered: zero, one, two. A "one-based count" represents an ordinal as the number of items that will have been considered once processing of this item is finished: one, two, three.

    1. Re:Unsigned money types; ordinals as cardinals by lgw · · Score: 1

      Now you're diving into set theory. I'm correcting bad elementary school education with appropriate elementary school education. :p

      --
      Socialism: a lie told by totalitarians and believed by fools.
  88. I've never seen a dearth of Java jobs... by bessie · · Score: 1

    I've been working with Java since 1997, and the greatest part of my work since then has been in Java (was doing lots of Unix kernel work and 2-tier/client-server database style projects before that).

    In that entire time, only immediately after the dot-com crash in 2001/2002 and for a year or so after that did I find it difficult to find a job where Java was the main skillset required. It might be highly locale-specific; I live in the San Francisco area, and there are piles of both startups and large multinationals that do Java work (although I *have* noticed startups using more Scala and Groovy lately).

    But I haven't ever gotten the feeling from the job market that Java is dying.

    - Tim

  89. Most people's first language by Anonymous Coward · · Score: 0

    I am a university student and love Java. I believe that Java is becoming more popular because it is a lot of people's first language (mine included) and the one being used the most to teach with. With the terrible job market more and more people are flocking to computer science, thus, more and more people learning Java. Teaching C as a first language will turn people away from CS, while Python doesn't have the textbook support. I believe it's a great language to learn computer science with and I hope it doesn't die any time soon.

  90. Two Words (concatenated) by Anonymous Coward · · Score: 0

    Minecraft... runs on Java... that's got to count for something.

  91. Write once, run away by funky_vibes · · Score: 1

    I have for years tried to find a single redeeming aspect about Java. One of those: I know Java sucks but it has great "something".
    Truth is, that it sucks, period. All aspects of its design are fundamentally stupid and divorced from reality.
    Before Java we had Perl, just as slow and shitty, but a hell of a lot easier to write and run. But I guess it wasn't an ecosystem owned by a big corporation like Sun.

    Java is just one of those overhyped corporate languages, still living off the fumes of past glory. Looking at how quickly a only marginally better language like C#/.net took over, it proves how it was more of a fad than anything else.

  92. Android by Anonymous Coward · · Score: 0

    We develop Android apps and we've had to turn to C++ inside a Java wrapper.

    Java is too f***ing slow for any sort of rendering, transformation, AI or, well, anything that actually calculates anything! Hopefully the NDK will soon eliminate the need for even the wrapper.

  93. Java by Anonymous Coward · · Score: 0

    Def: 1) a specific type of coffee bean, 2) a knock-off of the C++ language, easier to us 3) a coffee drink.

  94. Java has deteriorated by Anonymous Coward · · Score: 0

    In the beginning, it was great.
    Easy to understand, write with, build with and live with.
    There were libraries so I could do stuff.
    OK it was kinda inflexible but who cares.

    These days its a pure wankgasm of cruft.
    "Closures", "Collections", "Annotations", "Weaving".
    There is now so much black boxing, conventions and mind-boggling macro-type shite in there that I can barely understand what a given piece of java does and more. The enterprise stuff is even worse. The project I just got drafted in to rescue is basically unmaintainable at this point. I've been in IT all my professional life and I've seen technologies come and go. If Java came out today nobody would be using it. It only survives due to its installed base.

  95. No, still junk by rs79 · · Score: 1

    Watch the Crockford videos. There's at lease 8 hours of stuff you don't know or else you'd never say such silly things.

    I blackholed java.com, it was all I could do to keep that damn virus from coming back. Loading it transparently is naughty.

    What do I miss? Holy shit, absolutely nothing. And XP stays up for months now. Golly. It's no FreeBSD, but hey anything longer than a day and you were living on borrowed time before.

    --
    Need Mercedes parts ?
  96. Same old same old by __aaqlvv2831 · · Score: 1

    The argument about languages and side taking is for those with a black and white view of the world. The value of a language is in the context of its purpose. Java has survived so long because it is the right fit for a purpose. The hard to read argument often has nothing to do with the language, it's about programmers who write crap programs. People who don't understand OOs or knowledge of common design patterns are going to stuff it up and there is no shortage of them. That I believe is part of the education process. Go to uni, learn a language and get a brief intro to Objects Orientation and maybe learn the MVC design pattern. Go out and start writing code!!!. The language is just a tool. It's how you design your solution before you start writing code that matters. If you can do that well you don't have to invest in a specific language and get all outraged when someone makes a slight against it or try so hard to tell everyone why your language is much better than theirs. Seen too many people get all bitter because their 'chosen language' has had its moment in the sun. Move with the times, learn new languages and keep doing what I think is one of the most satisfying jobs around.

  97. I blame Java for the healthcare.gov mess by rkinch · · Score: 1
    The failure that is currently healthcare.gov is heavily based on a Java implementation for everything including the most trivial and simple things. I've spent two weeks getting nothing but inglorious errors, and the [mis]use of Java appears to be deeply involved.

    It is an astonishing, breathtaking failure when viewed with any expertise in how things should be done. You log in and the screen just turns blank with no error message. Or you get an error message that literally just says "Error!" in red and nothing more. Or it gives an error that indicates what can't be the true cause. Or it says we're too busy ... at 3 a.m. Or try again later (but not how much later). Or a bunch of Java code gets splattered onto the page in literal text. Different errrors in every variety of browser. No evidence of version control or other error tracking. No indication of status, good or bad, no list of active problems, no advice when to expect resolution. There is no documentation or explanation of any of this from the authorities or the contractor. The authorities will not report usage statistics, how many succeeded, or how anyone succeeded if there is a specimen anywhere in the universe to copy. One has to question whether it has worked in a single instance.

    Here is an acid-core example: every single user has to confirm via email. Yet the email is flat-out RFC-violating non-compliant, and can't be read in email readers that don't know how to handle this non-conformity. Specifically, this violation appears in the email headers:

    Received: from . . . service.govdelivery.com
    Content-Type: multipart/alternative;
    . . .
    Content-Transfer-Encoding: base64

    This is not an example of bad Java, but it does show the kind of foolishness passing for system-building everywhere you look. This garbage came from govdelivery.com who are apparently the choke point for the entire system. If they fail, or if you fail to deal with them, you are SUNK.

    They do have a pretty girl smiling at you from the home page. Puh-leeze.

    These are not bugs or glitches or the overwhelm of success. This thing is utterly defective. A FAILURE. One must question whether it will ever work, and if it won't have to be abandoned for a do-over. Nobody expected a smooth rollout, but this is head-slapping incompetence.

    And the law is, you must succeed with it, or ELSE! You cannot mail in forms, or call on the phone, to get this done. It all happens on the Web.

    And when has the federal government ever appropriated non-government technology and property in this way, and used it as the sole means to enforce something against the citizenry? With the income tax, they at least give you the paper and a post office to send it back and forth. The government will depend completely on the Internet now to keep you from being fined or put in jail?

  98. Numbers are not on your side... by p77gin · · Score: 0

    the key comment in the original post is "forums where cool kids hang around". well in case you haven't noticed, these cool kids are probably not even 1% of the total software engineer/developer population out there. and i would thus question the whole premise of this article. its based on a number that, as we say in physics, infinitesimally small and can be safely ignored for all practical puropses! :-)

  99. Java is faster than C++ by Anonymous Coward · · Score: 0

    You are wrong because Java can in theory be faster than C++. The difference between C++ and Java is that you compile only once with C++, with only some optimizations. For isntance, you can not turn on SSE vector instructions when you compile, because the user's PC might not have SSE instructions in his CPU. Thus, you only use some basic general optimizations that work on every PC: no SSE, etc.

    OTOH, Java recompiles every time you invoke your software so the JVM can examine the PC and see that "oh, it has SSE vector instructions, so I will enable that". This means the JVM tailors he optimization for your specific PC. One PC might have SSE, and another not. For instance, there is a project that will allow Java to run on the GPU. So the JVM might choose to run everything on the 5 TeraFlop graphic card instead of a 200 GFlop CPU. C++ can not do these on-the-fly optimizations.

    Also, it turns out that the fastest and largest stock exchanges are often written in Java with extreme throughput and low latency (for isntance NASDAQ with latency of 100 microseconds). Stock exchanges written in C++ are not faster. The secret is to disable the Java garbage collector (i.e. you manage your memory yourself, by preallocating lot of objects and always reuse them - this way they will not die). Several extremely well performant applications (HFT systems etc) are written in Java.

    So, you are wrong. In 10 years time, I would not be surprised if Java always was faster than C++. Today Java is faster only in some cases, and on par in most (majority) cases.

    1. Re:Java is faster than C++ by Anonymous Coward · · Score: 0

      No need to read past the first sentence of the parent post. I'll leave it up to Albert E:

      “In theory, theory and practice are the same. In practice, they are not.”

    2. Re:Java is faster than C++ by RCL · · Score: 1

      You are very optimistic. Right now even C++ compilers (which, believe me, are very much performance-oriented and rather are not memory-constrained) have problems with producing a good vectorized code, but thanks God we have assembly intrinsics and use them a lot. For JVM, that is even harder for multiple reasons (and unfortunate - historical - choice of Java bytecode is one of them). Sure, there's a broad class of software where performance does not matter, but as I said again, that is a boring software I don't want to work on. Writing such software is better to be outsourced somewhere where people crave for money more than I do.

      As for HFT, I don't think that using Java is a good decision. If you can optimize for certain (best in its class) hardware, why do you need to hop through all the extra abstraction layers of Java? Sure you probably can, but it's like artificially limiting yourself.

  100. Re:Have you seen how much those flying yachts cost by Hognoxious · · Score: 1

    It's pretty unlikely the offspring would be able to randomly throw palm trees so that they'd form into working yacht to sail away from their aquamural prison.

    But some chances aren't worth taking. The words "nuke" and "orbit" spring to mind.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  101. Scala? by yacc143 · · Score: 1

    Sorry guys, since when is Scala a scripting language. Anything but?

  102. Java IS dead by candlebar · · Score: 1

    Java IS dead... just like rock and roll.

  103. Java Is Not Going Away Anytime Soon by JBrow · · Score: 1

    No amount of criticism is going to make Java go away so get over it and stop flaming about Java being _______________. I am going to go out on a limb here and state categorically that each and every programming language has its faults. So your choice is simple: either declare that "the glass is half-fiull" or "the glass is half-empty". IMHO Java is an incredibly fantastic language to use for accomplishing your task at hand. Yes, you need to type a little bit more in Java. Shut up and get to work is what your managers are going to say.

    --
    --- You are in a little twisty maze of comments, all different.
  104. Maybe its a zombie by Anonymous Coward · · Score: 0

    Oh look, theres two of them!

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html