These are two big questions with equally big questions. How familiar are you with Java? How familiar are you with computer languages in general?

Regarding your first question: why are there so many programming languages?

Because different languages have different advantages. Some algorithms and problems are more readable and easier to code in one language than the other. For each problem there will be a fitting language and tool. Secondly, it is also down to taste. Some programmers like dynamically typed or untyped languages. While others will prefer statically typed languages. Also, modern languages allow you to use higher level constructs that were simply not feasible on older computers and languages.

To your second question:

Java powers lots and LOTS of web servers and services. Those will already be millions of devices. Furthermore every Android smartphone runs Java. That will probably around a billion or so devices. On top of that millions or billions of TVs and other smart devices will also run some kind of Java. Some will run something else, but a lot are probably powered by Java.

I thought the main selling point of java was to be portable across architectures, by using the java VM and bytecode. Which facilitates the development of software on one architecture that can then be implemented (ie run) on another. Which means that what's probably running on most of these billions of machines isn't human-readable java as such, but byte code spewed put by the java compiler.

*waits for someone who actually knows what they're talking about to correct my amateurish explanation*

ratfink wrote:

I thought the main selling point of java was to be portable across architectures, by using the java VM and bytecode. Which facilitates the development of software on one architecture that can then be implemented (ie run) on another. Which means that what's probably running on most of these billions of machines isn't human-readable java as such, but byte code spewed put by the java compiler.

Pretty much.
The concept of using a VM and bytecode to be platform-independent was so good, that Microsoft 'borrowed' it and based their .NET platform on it. C# is also a language that is very much inspired by Java.
And Android is based on an unofficial clone of Java (for which Google got sued). Originally with the alternative Dalvik VM, later replaced with ART (Android RunTime).

Other interesting selling points of Java include automatic garbage collection, type-safety, memory-safety, and a security model integrated into the VM and language itself.

I suppose there are many language where you can ask 'why does it exist', but I wouldn't place Java among them. Its designers had some clear targets in mind, and the language has left its mark.

Edited out because OP doesn't care for answers to his questions.

This seems to be happening often lately.

.

doaks80 wrote:

Java and C# are utter garbage, but the average programmer at a big enterprise is even worse so they trade off performance for employee "productivity". There just aren't that many people smart enough to write C/C++ to go round, so they employ hundreds of grunts to build average websites costing millions of dollars and taking years - if they are ever delivered. People said exactly the same thing about COBOL programmers 30 years ago.

I would agree about Java. I don't have enough experience with C# or any of the other # languages to comment on those.

C/C++ is by far my favorite though.

I took COBOL in college. Never wanted to touch it again after those classes.
Teacher: make this and make it so that my test cases will not cause it to fail.

Me: Ok.. programs for hours on end and making as many test cases that I can possibly think of in the time I have to dedicate this class.

Teacher: BWAHAHAHAHA.. I made your program fail with my such and such test case.

Me: 😢 😢 😢 😢

Muz wrote:

I know billion devices run Java, but where are these billion devices?

I dont think thats been true for a very long time, maybe once, but pre 'smart' phone, WAP was a thing, and a lot of WAP phones had a JVM. Nobody wrote apps for it, it was a super pain in the ass.

I think Oracle are trading off the whole android stole java schtick to claim billions of devices.

doaks80 wrote:

Java and C# are utter garbage, but the average programmer at a big enterprise is even worse so they trade off performance for employee "productivity". There just aren't that many people smart enough to write C/C++ to go round, so they employ hundreds of grunts to build average websites costing millions of dollars and taking years - if they are ever delivered. People said exactly the same thing about COBOL programmers 30 years ago.

Yes I'm one of the average programmers at a big enterprise - we're all worse than utter garbage 😵

Try harder 😀

doaks80 wrote:

Java and C# are utter garbage, but the average programmer at a big enterprise is even worse so they trade off performance for employee "productivity". There just aren't that many people smart enough to write C/C++ to go round, so they employ hundreds of grunts to build average websites costing millions of dollars and taking years - if they are ever delivered. People said exactly the same thing about COBOL programmers 30 years ago.

What is so "garbage" about Java or C#? Does the syntax or the garbage collector bother you? Do you realize the amount of boilerplate code that it would take to write a typical enterprise application in C/C++? It's not about being smarter, it's about getting things done, and those languages are more appropriate for enterprise software, not because of the syntax itself which is not that different to C/C++, but because of the tools and frameworks that provide stuff that is essential to those types of applications.

By the same reasoning I would choose C/C++ if I had to implement something with more direct hardware access, like embedded or dedicated machines. In fact, I once implemented a library in C that interacted with industrial equipment, but that library was called by a Java based web application. It's all about choosing the right tool for each job.

If there's one thing I learned in about two decades of software development is that it's pointless to be a "fan" or "hater" of a certain language, the key is finding what is ideal for each application.

Also, I don't think good C/C++ programmers are necessarily smarter than the good Java/.NET ones.

Both Java and C# have software engineering features built in that lend them to building large, robust applications on top of extremely powerful modular libraries. C++ includes most of those same facilities, but it's a much more complex language. This makes development of compilers, libraries, and other tools very burdensom and expensive.

I'd say Python goes even further providing a streamlined feature set that is extremely powerful and intuitive without being as overbearing as C++. Performance, on the other hand, can be a problem depending on your application.

gdjacobs wrote:

Both Java and C# have software engineering features built in that lend them to building large, robust applications on top of extremely powerful modular libraries. C++ includes most of those same facilities, but it's a much more complex language. This makes development of compilers, libraries, and other tools very burdensom and expensive.

I'd say Python goes even further providing a streamlined feature set that is extremely powerful and intuitive without being as overbearing as C++. Performance, on the other hand, can be a problem depending on your application.

On top of that Java and in fact all the JVM languages (Scala, Clojure, Groovy, Kotlin and more) already can leverage the vast availability of libraries and frameworks that were built for the Java world, incorporating them using standardized build and dependency tools (maven, gradle). This is something that is extremely hard to do in the C++ world, since the C++ ABI is not standardized across compiler manufacturers, let alone operating systems. Also no standardized build and dependency system exists that comes even close to gradle and maven.

That said, I earn my money with C++ at the moment. But I also was paid for doing Java. 😉

root42 wrote:

This is something that is extremely hard to do in the C++ world, since the C++ ABI is not standardized across compiler manufacturers, let alone operating systems.

Or even between major revisions from the same manufacturer!
The 'solution' to that is that many libraries still use a flat C interface. An alternative is a standardized ABI such as COM or CORBA.

Mind you, in practice, Java, C# and similar languages suffer the same problem: most OSes and low-level libraries are written in C/C++, and cannot be interfaced directly with other languages. You need some special wrappers/bindings that translate the C/C++ interface to Java, .NET or whatever... Or import the functions and define the datatypes yourself.
I found that in practice, C/C++ are by far the easiest languages to get access to any kind of OS, CPU, or library. Nearly everything out there is either written in C/C++ itself, or has an interface that is compatible with it. With Java, .NET and other environments, you are often reliant on obscure, unsupported third-party wrappers, if they even exist at all.
For example, I write DirectX code for a living. Way back in the early days, Microsoft had a thing called Managed DX for .NET. But they dropped support. Ever since, you can only use unofficial wrappers like SlimDX or SharpDX. And these have bugs, inconsistencies, lack support for ARM architectures etc.
Just doing it in C++ (like Microsoft does with its examples, C++ to wrap to .NET) is far less painful and error-prone.

That makes sense given the original domain of C. It remains great at providing a thin linguistic layer on top of metal.

TheMobRules wrote:

What is so "garbage" about Java or C#? Does the syntax or the garbage collector bother you? Do you realize the amount of boilerp […]
Show full quote

What is so "garbage" about Java or C#? Does the syntax or the garbage collector bother you? Do you realize the amount of boilerplate code that it would take to write a typical enterprise application in C/C++? It's not about being smarter, it's about getting things done, and those languages are more appropriate for enterprise software, not because of the syntax itself which is not that different to C/C++, but because of the tools and frameworks that provide stuff that is essential to those types of applications.

By the same reasoning I would choose C/C++ if I had to implement something with more direct hardware access, like embedded or dedicated machines. In fact, I once implemented a library in C that interacted with industrial equipment, but that library was called by a Java based web application. It's all about choosing the right tool for each job.

If there's one thing I learned in about two decades of software development is that it's pointless to be a "fan" or "hater" of a certain language, the key is finding what is ideal for each application.

Also, I don't think good C/C++ programmers are necessarily smarter than the good Java/.NET ones.

I'll just hate on JAVA for the time being.

Here are a few reasons:
1. Horribly inefficient. True, it has gotten better over the years, an application running in a virtual machine is never going to be able to match the speed of a well programmed pre-compiled application running natively.
I did some simple tests back in the day, and a C program doing simple math was at least 5 times faster than JAVA doing the same exact thing.

2. Compatibility problems between versions. Not sure if this is a real thing anymore, but the last time I worked at a place that used a bunch of different applications that were written in JAVA, we had to use a JAVA version switcher to switch to the version of JAVA that was compatible with each different application. That is a complete and absolute joke right there.

3. Massive number of security holes. I just love JAVA release updates every few weeks to fix even more security holes.
https://www.java.com/en/download/faq/release_dates.xml

The only redeeming feature of JAVA in my view is the cross-platform compatibility.

cyclone3d wrote:

1. Horribly inefficient. True, it has gotten better over the years, an application running in a virtual machine is never going to be able to match the speed of a well programmed pre-compiled application running natively.
I did some simple tests back in the day, and a C program doing simple math was at least 5 times faster than JAVA doing the same exact thing.

While a native application written in C will certainly run faster than one running over Java VM or .NET framework, in a real case scenario other things far outweigh the VM's inefficiencies, namely: network latency, database access time, and misc. I/O. When all that is taken into account, native vs. virtual becomes insignificant. Again, I'm talking about the typical use of Java/.NET at the server side, not even mentioning that the amount of C code (and effort) necessary to implement that same server side code would be much larger when you factor in networking, clustering, DB access, multithreading.

cyclone3d wrote:

2. Compatibility problems between versions. Not sure if this is a real thing anymore, but the last time I worked at a place that used a bunch of different applications that were written in JAVA, we had to use a JAVA version switcher to switch to the version of JAVA that was compatible with each different application. That is a complete and absolute joke right there.

I don't quite understand what you mean by that, but normally each Java application runs on its own environment with the appropriate VM (whether it is a traditional application server or a standalone application with embedded server). Unless you're talking about Java based client side apps? That's not really a common thing since the early 2000s.

cyclone3d wrote:

3. Massive number of security holes. I just love JAVA release updates every few weeks to fix even more security holes.
https://www.java.com/en/download/faq/release_dates.xml

Again, that may be true for Java applications running on the client side, but they're uncommon. When the Java code is running on server side security concerns are mostly web-oriented, not really having much to do with the underlying VM.

Don't take this the wrong way, but it seems to me that you haven't done much real work with it. And take it from someone who has basically learned programming in C (Borland Turbo C along with Pascal in the mid '90s), so I'm aware of the differences. Yes, you can "hate" a programming language all you want, but there's a reason certain things aren't written in C anymore (how many CGI based websites have you seen lately?).

Yeah, I haven't done a lot with JAVA... mostly because I never felt the need to even though I did take a JAVA class in college years ago.

The cluster of code I had to deal with then also turned me off to it.. as in - find the bugs in this program and fix it - was one of my assignments. It was so horribly coded that it pegged the CPU at 100% and was not even useable even though that was not one of the problems we were supposed to fix. Had to fix that before I could even work on the other bugs.

The JAVA switcher was for client apps. This was about 10 years ago or so on multiple manufacturing production lines. If I remember correctly, the JAVA version switcher changed some settings to make a specific version of the JRE active. I literally wanted to take a sledge hammer to those systems every time we had to fix something that had to do with JAVA on them.

And stuff like DVD players, smart TVs, etc. with JAVA on them... uggghhhh just kill me know because I felt like I was going to grow old and die because they were so slow... the worst was a Sony DVD player.

And VOIP phones with JAVA running them.. Cisco. sure they work fine most of the time, but when they screw up it is easiest to just do a factory reset and then let them spend 15-20 minutes to re-download everything and re-register with the CallManager system.

cyclone3d wrote:

1. Horribly inefficient. True, it has gotten better over the years, an application running in a virtual machine is never going to be able to match the speed of a well programmed pre-compiled application running natively.
I did some simple tests back in the day, and a C program doing simple math was at least 5 times faster than JAVA doing the same exact thing.

Well, I beg to differ. Back in the early 2000s, I wrote a software 3d renderer in Java:
http://www.pouet.net/prod.php?which=10808
http://www.youtube.com/watch?v=_jEzAOdYFQU

It contains many advanced features for the time, such as bilinear texture filtering, multitexturing, dynamic lighting, environment-mapped bumpmapping, etc. In terms of features and render quality, it is somewhere between a GeForce2 and GeForce3 in many aspects.

Can't really say it's just 'simple maths', and I doubt a C program would be able to do the same 5 times as fast.
Sure, C will be faster, but the difference won't be all that dramatic.

I would also like to bring up the HP Dynamo project, since you say a virtual machine can never match a pre-compiled application:
http://www.hpl.hp.com/techreports/1999/HPL-1999-77.html
HP Dynamo proves you wrong: HP developed a virtual machine with a dynamic recompiler, which basically emulated itself. The idea is that a regular static compiler can only optimize based on knowledge that is available at compile-time. The dynamic recompiler could analyse the application while it was running, and optimize code on-the-fly. They found that even well-optimized native applications would often get a considerable performance boost from the extra optimizations that the VM could make.
A simple example is function inlining. A static compiler can only inline functions that are available in static libraries at compile-time. Any DLL calls will always have to be external. A dynamic recompiler can choose to inline any DLL call it sees fit, removing the calling overhead from your application.

My 3D engine above actually takes advantage of that sort of thing: it supports multiple materials (even in the same scene), which are stored as a form of vertex and pixel shaders (I inspired my design on DirectX 8 at the time). This is implemented via two interfaces, which are implemented by the various classes, acting as a sort of 'plugin'.
The scene is encoded in an XML, where you can configure which vertex and pixel shader you want to use for each material. These shaders do not even have to be known at compile-time, as long as they implement the right interface, it will work.
However, at runtime, the JVM can inline their code, unroll loops, and optimize them any way it wants, so the efficiency of the engine is hardly affected, even though it is completely configurable at its core, with this setup.

Ironically enough, software emulation of vertex shaders in DirectX (or the entire DirectX in SwiftShader) is also done with dynamic compilation of the shaders to x86 code.

Looking at the OP's history, are we participating in a field Turing test or are they just spaced out on a lot of mind altering drugs?

The questions are usually very open, random in topic, and lacking in basic background knowledge such as one might get with five minutes' research. The OP's responses in thread are usually shallow and vacuous. It all seems very strange.