Live data from Hacker News

If Java Is Dying, It Sure Looks Awfully Healthy

drdobbs.com

221–230 of 327 posts

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#221

Earlier quoted context omitted.

You're doubting that Javascript is a popular language for people pushing the forefront of software development? I'd cite for you a ton of the work being done on node, ember, knockout, backbone, jquery, even some embeddable hardware thing I read about on here the other day. There's a huge amount of energy in that area, lots of extremely smart people. Or are you just being snobbish about javascript? It's a pretty solid…

My friend, JS has a virtual monopoly on what it does. If there are other client-side browser languages, i have not heard of them. >It has built-in interpreters (read "Browsers") on every computer. JS is pretty slow (It uses an interpreter!). The notion of using it on the backend is debatable. "A lot of people are putting a lot of effort in to it" isn't a valid argument. u said it yourself: "people are told to/forced…

>> JS is pretty slow (It uses an interpreter!) The notion of using it on the backend is debatable.

It is pretty fast. It has a world class VM with an optimising JIT compiler. V8 is considerably faster than many other interpreted language, Ruby, Python etc. It's being used on the backend by many smart companies.

>> As for the hardware thing [...] It just a way to let web devs do something on the hardware without bothering to learn an actual low level language.

I know C. I use it when necessary but I'd rather write JS. Apparently so would plenty of other people. It's not about laziness.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#222

Earlier quoted context omitted.

Android doesn't really count as java, as it doesn't use the JVM. But even if you do choose to count it, it's only a very small part of the java ecosystem. Applets are dead, and java desktop applications unpopular, but without you necessarily seeing it, enormous amounts of server side software are made with java. If it hadn't been Java, it would have been some other language, but the fact is that there is such an enor…

I don't agree that something isn't Java if it doesn't run on Oracle's JVM. I can write Java that runs on Kaffe, etc. Personally I really like Java - coming from a C++ developer (11 years in the games industry). I wouldn't mind working with it everyday...

I didn't mention the word Oracle. Kaffe is still a JVM! It runs java applications unchanged.

Dalvik is not. It can't run java classes compiled with a regular java compiler

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#223
post #89

Earlier quoted context omitted.

MSFT could shut down Mono anytime it wants.How many business use mono (to build web apps) in production? Scala,Groovy,Xtend,etc... there is enough languages on the jvm one doesnt have to use any MS related tech.

How so? C# is a standardized language.

Only partially. Microsoft has stopped submitting language updates to ECMA.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#224

Earlier quoted context omitted.

Yes. However, C# uses the convention that capitalized "fields" are actually properties, and lowercase ones are true fields. For example, Foo.X might be an x position, returned from a getter method, and set with a setter method. Internally, the class make use the Foo.x field to store it, in which case the getter and setter are trivial. In fact, C# will write them for you The property could look like: int X{ get; set;…

"However, C# uses the convention that capitalized "fields" are actually properties, and lowercase ones are true fields." If only. In http://msdn.microsoft.com/en-us/library/vstudio/ms229043%28v... , Microsoft advocates: "The PascalCasing convention, used for all identifiers except parameter names, capitalizes the first character of each word"

The UI in MonoDevelop / Visual Studio will show the differences during autocomplete. Also, fields should NEVER be public in a class.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#225
post #55

Earlier quoted context omitted.

> I'm not particularly persuaded to the "you have to type a lot" complaints. I haven't used Java in anger in a long time, but my beef was never that you had to type a lot, but that it was verbose. Verbosity impacts on typing, sure, and as you've said, IntelliJ makes typing it out painless. The flip side of verbosity, though, is reading the code. There's no "hit tab" or "Cmd-J, fori, return" to increase comprehension…

Well, there are programming languages and then there are conventions. I think a programming language is more like an alphabet, and programming conventions are the real languages. I can scroll through code at high speed and understand it at a mere glance once I "get" both the language and the convention that was used (if only the doc and comments didn't get in the way all the freaking time...) Things that feel out of…

> Well, there are programming languages and then there are conventions. I think a programming language is more like an alphabet, and programming conventions are the real languages.

I like this. As a thought experiment, consider the idea of transforming a convention into another "letter" in the alphabet. A simple example would be the natural numbers. If our alphabet is "a", then we can represent 1 as "a", 2 as "aa", 3 as "aaa", and so on (unary). If we expand our alphabet with a "b", then we basically have binary. And in the case of "aaaaaaaa", "baaa" is a an improvement. But there will be a an optimal point somewhere, where the load of expanding the alphabet is greater than the benefit of the more compact representation. This explains to a small extent why we (programmers) use hex, and didn't really go to higher bases (digits + alpha could get us to base 36!)

The analogy starts to fall apart when we think about the ability to add to the alphabet, using the conventions. We can't invent new letters, but we can create/repurpose words that encapsulate a lot of meaning.

I'm not really sure where I was going with this anymore!

> I can scroll through code at high speed and understand it at a mere glance once I "get" both the language and the convention that was used.

The issue for me is that the boilerplate is noise. I don't want to see the similar parts, I want to see the parts that differ. Pseudo-C example:

    x = [1,2,3,4,5]

    product = 1
    for (int i = 0; i 
vs pseudo-Haskell:

    x = [1,2,3,4,5]

    product = fold (*) x

    sum = fold (+) x
With the latter example, there are objectively less places for bugs to be present. Sure the definition of fold is somewhere else, but there's only one implementation, whereas the pseudo-C has two implementations. Of course, I'm sure modern Java is much better than this, but it's still a step down.

I'm pretty sure we could configure an editor to expand the second one into the first, but then we come back around to writing-vs-reading.

An interesting experiment would be to have your raw input, eg. msluyter's example of "cmd-J, fori, return" as the editable source file rather than the generated Java output.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#226
post #186

Earlier quoted context omitted.

Sigh. This again? A good garbage collector will always reach a higher throughput than "manual" dynamic allocation/deallocation in C/C++. Pauses are a different matter, and can impact latency; in cases where latency is crucial, Java programs either resort to manual memory management or use a commercial low-latency GC. If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know…

C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency. You shouldn't really use the term "always" either. You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delet…

> C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction.

Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing.

> Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.

Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements.

A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects)

> You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.

You have the same option in Java, too, and it's pretty much the same amount of work.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#227

Earlier quoted context omitted.

Comparing Java to Cobol is ridiculous. I'm in the cool kids category and I like Java. If you don't want to / can't use C#, there's simply no alternative for bigger projects. Groovy - slower, much worse toolability Scala - less readable, slower, slow compilation, worse toolability, too complex.

What are these bigger projects which can only be implemented in java? The linux kernel? Photoshop? Facebook? Or some kind of godawful tiered corporate thing that's big and unwieldy precisely because it's implemented in java?

Enterprise projects with minimum of three development places, 30 to 100 developers on project, with two to three year duration, lots of off-shoring and attrition among developers.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#228

Earlier quoted context omitted.

You're doubting that Javascript is a popular language for people pushing the forefront of software development? I'd cite for you a ton of the work being done on node, ember, knockout, backbone, jquery, even some embeddable hardware thing I read about on here the other day. There's a huge amount of energy in that area, lots of extremely smart people. Or are you just being snobbish about javascript? It's a pretty solid…

My friend, JS has a virtual monopoly on what it does. If there are other client-side browser languages, i have not heard of them. >It has built-in interpreters (read "Browsers") on every computer. JS is pretty slow (It uses an interpreter!). The notion of using it on the backend is debatable. "A lot of people are putting a lot of effort in to it" isn't a valid argument. u said it yourself: "people are told to/forced…

Expect it doesn't use an interpreter these days, it is JIT compiled (a la V8). It's quite fast now.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#229
post #214

Earlier quoted context omitted.

Haskell?

Haskell has multiple concepts that are so compelling that I do not understand why most of the new languages make no use of them. Very handwavy, here are a couple of them. - Type inference: strong typing at the convenience of weak typing. (Some languages are moving towards this. C++ stapled on `auto` keywords, Rust is designed using it) - Type classes: unifying things that "can do X", allowing the programmer to write…

C# has had type inference for a long while. It's a pain using Java, which doesn't.

C# also sort of implements type classes. For your example, there's IComparable in C#; implement it and a List can be directly sorted.

For pure functions, there's the [Pure] attribute, but it isn't enforced by the compiler, it's just a contract, a promise.

Re: If Java Is Dying, It Sure Looks Awfully Healthy

#230
post #8
post #3

Any talk of Java "dying" is just nonsensical Java hands down is the most obvious choice for any applications that require performance, yet are too complicated to write and support in C/C++/other lower level languages. Java JIT is very mature unlike JITs for most other languages, which largely remain at the level of experimental projects and fall short on key production requirements. Given that the entire Hadoop ecosy…

Yes, that's why kernels are written in java. If you're writing complex code java is rarely the answer as it requires so much complexity itself. Hint: Most java projects just appear to be complex because of the poor quality of the language (and developers). Java is hands down the choice for simple projects written by way too many poor quality developers. The JVM can barely manage 12 GB of memory, Java is a piece of cr…

You seriously don't know what you're talking about.

Virtually all serious software that uses complex concurrent data structures is written in Java nowadays, because the JDK is pretty much the only runtime that supports state-of-the-art, envelope-pushing, concurrency.

Here's my previous discussion with haberman on the subject: https://news.ycombinator.com/item?id=6505853

Post reply on HN