We Keep Coding

What exactly is Java?

The question may at first sound silly, but maybe it isn't at all.
Java is not the Java language, most people know that, since you can program Java with lots of other langauges like Scala or Groovy
Java is not a concrete VM implementation since there are other implementation out there, not only SUN's, Microsoft's or IBM's.
Java is not the class framework since many implementation add or leave out classes at will.
It isn't even that a common VM specification or even Java bytecode must be used, see Dalvik VM
Maybe it is just a set of principles they share, whatever this may be. It definitely is not "Write once, run everywhere" since this isn't the case for at least Dalvik and Microsoft VM/J#.
So the question is, what exactly is Java? Is there even an exact definition?
EDIT
Lots of people seem to have the opinion that java only means the programming language. So a java-enabled mobile phone must be a phone which enables the user to use programs consisting of class files created with the java language only. If this would be true, the java virtual machine / java runtime environment / java development kit would be made for java only and other jvm languages would have their own corresponding xvm / xre / xdk.

Java is the Java language, actually. Groovy, Scala et al compile down to equivalent bytecode that can run on the JVM, but they aren't Java.
Formally, I'd say that Java is the JLS.

Java is a programming language. The syntax part.

In my opinion it's the language. I don't think people say they're programming Java with Groovy, or if they do, they are being inaccurate.

Strictly speaking Java is just a programming language. But it's a programming language that includes many, many standards: for example many API’s and JVM specifications. That's why SUN and others refer to it as a platform.
Other languages like Scala, Ruby, etc. are not Java, they just compile to byte code that runs in a Java Virtual Machine. They are just build on top of the Java platform, but are themselves not Java.
The JVM is highly standardized and many companies can and do offer their own implementations for their hardware platforms. This is not Java either, these are just implementations of a part of the Java platform.
The Java VM specification is 100% standardized something that is enforced by Oracle as they claim copyright on Java. That’s why the Android (Dalvik VM) is currently the subject of a court case of Oracle against Google.

Actually, it depends on the context where the word is used. It's all: syntax, technology, framework, programming language.
As a sidenote, Oracle answers this question as follows: What is Java?

You cannot say that Scala is Java any more than you can say that a fork is a comb just because you happen to be brushing your hair with it. Or, if I may bring up the classic analogy, driving nails with your wrench doesn't make it a hammer.
You can make a compiler that compiles COBOL into C++ if you want, but that doesn't mean COBOL is C++.
Many languages have x86 machine code as their target compiled language, so does this mean they are all the same thing?
It doesn't matter if other languages can compile to the JVM's bytecode, nor does it matter that you can compile Java into a specific architecture's machine code. The JVM is still Java's platform; other languages just happen to share it, and Java just happens to be able to compile to targets other than JVM bytecode. The same way as a fork just happens to be able to comb your hair depending on how you handle it.
I think this is a silly question (and has nothing to do with programming besides). Is it possible for someone to act like a renaissance philosopher and try to argue that your fork is actually a comb because you have never, ever used it as a fork and always use it only in your hair? Sure, go ahead and argue, and maybe you'll even have a point, but hopefully nobody wastes their time listening to it. This is all just a game of semantics, and once you start arguing about semantics everybody loses.
(edit)
Bah! I just realized I'm arguing about semantics!

Most people see Java as the programming language (as defined by the Java Language Specification). But there are plenty of others who split it into the Programming Language, the various VMs and the larger ecosystem.
There are also legal definitions of what can be called Java (e.g. The trademark), but I think I'm going to leave that one alone at the moment :-)

Python vs. Java -- Which would you pick to do concurrent programming and why? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Also, if not python or java, then would you more generally pick a statically-typed language or a dynamic-type language?

I would choose the JVM over python, primarily because multi-threading in Python is impeded by the Global Interpreter Lock. However, Java is unlikely to be your best when running on the JVM. Clojure or Scala (using actors) are both likely to be better suited to multi-threaded problems.
If you do choose Java you should consider making use of the java.util.concurrent libraries and avoid multi-threading primitives such as synchronized.

For concurrency, I would use Java. By use Java, I actually mean Scala, which borrows a lot from Erlang's concurrency constructs, but is (probably) more accessible to a Java developer who has never used either before.
Python threads suffer from having to wait for the Global Interpreter Lock, making true concurrency (within a single process) unachievable for CPU-bound programs. As I understand, Stackless Python solves some (though not all) of CPython's concurrency deficiencies, but as I have not used it, I can't really advise on it.

Definetely Stackless Python! That a Python variant especially made for concurrency.
But in the end it depends on your target platform and what you are trying to achieve.

If not Java/Python I would go for a functional language since taking side effects into account is one of the complexities of writing concurrent software. (As far as your question goes : this one happens to be statical typed, but compiler infered most of the time)
Personally I would pick F#, since I've seen lots of nice examples of writing concurrent software with ease using it.
As an introduction : this man is equally fun as inspiring, even a must have seen if you are not interested in F# what so ever.

I don't think the argument is about language choice or static or dynamic typing - it's between two models of concurrency - shared memory and message passing. Which model makes more sense in your situation & does your chosen language allow you to make a choice or are you forced to adopt one model over the other?
Why not have a look at Erlang (which has dynamic typing) and message passing, the Actor model, and read why Joe Armstrong doesn't like shared memory. There's also a interesting discussion about java concurrency using locks and threads here on SO.
I don't know about Python, but Java, along with the inbuilt locks and threads model, has a mesasge passing framework called Kilim.

I would use Java, via Jython. Java has strong thread capabilities, and it can be written using the Python syntax with Jython, so you got the best of the two worlds.
Python itself is not really good with concurrency, and is slower than Java anyway.
But if you have concurrency issues and free hands, I'd have a look at Erlang because it has been design for such problems. Of course, you must consider Erlang only if you have:
time to master a (very) new technology
control on a reasonable part of the production chain, since Erland need some adaptations in your toolbox to fit

Neither. Concurrent programming is notoriously hard to get correct. There is the option of using a process oriented programming language like occam-pi which is based of the idea of communicating sequential processes and the pi calculus. This allows compile time checking for deadlock and many other problems that arise during concurrent systems development. If you do not like occam-pi, which I cant blame you if you dont, you could try Go the new language from google which also implements a version of CSP.

For some tasks, Python is too slow. Your single thread Java program could be faster than the concurrent version of Python on a multi-core computer...
I'd like to use Java or Scala, F# or simply go to C++(MPI and OpenMPI).

The Java environment (JVM + libraries) is better for concurrency than (C)Python, but Java the language sucks. I would probably go with another language on the JVM - Jython has already been mentioned, and Clojure and Scala both have excellent support for concurrency.
Clojure is particularly good - it has support for high performance persistent data structures, agents and software transactional memory. It is a dynamic language but you can give it type hints to get performance as good as Java.
Watch this video on InfoQ by Richard Hickey (creator of Clojure) on the problems with traditional approaches to concurrency, and how Clojure handles it.

I'd look at Objective-C and the Foundation Framework. Asynchronous, concurrent programming is well provided for.
This of course depends on your access to Apple's Developer Tools or GnuStep, but if you have access to either one it's a good route to take with concurrent programming.

The answer is that it depends. For example are you trying to take advantage of multiple cores or cpus on a single machine or are you wanting to distribute your task across many machines? How important is speed vs. ease of implementation?
As mentioned before, Python has the Global Interpreter Lock but you could use the multiprocessing module. Note that while Stackless is very cool, it won't utilise multiple cores on its own. Python is usually considered easier to work with than Java. If speed is a priority Java is usually faster.
The java.util.concurrent library in Java makes writing concurrent applications on a single machine simpler but you'll still need to synchronise around any shared state. While Java isn't necessarily the best language for concurrency, there are a lot of tools, libraries, documentation and best practices out there to help.
Using message passing and immutability instead of threads and shared state is considered the better approach to programming concurrent applications. Functional languages that discourage mutability and side effects are often preferred as a result. If distributing your concurrent applications across multiple machines is a requirement, it is worth looking at runtimes designed for this e.g. Erlang or Scala Actors.

As a Java developer, C or C++? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been writing Java professionally for the last 5 years. Recently, I've had to dig into JNI a bit to call some Windows specific functions.
This experience has highlighted my poor command of the C (or C++ for that matter) language. My only introduction to C was a brief "dummies" book that I read in high school 11 years ago.
I know that both languages have advanced in that time frame, especially C++ and the standard library.
Would it be appropriate for me to learn C or C++? Which books would be best?
Do folks also have any recommendations for Windows programming as well? I can read through MSDN well enough to figure out certain API calls but I have a feeling I'm missing things in regards to the "big picture".
Thanks

Good question. On the surface, it'd be obvious to recommend C++, because "it's object oriented like Java". Only problem is, it's not really true.. C++ allows OOP, yes, but it's just one of several paradigms that C++ supports. Treating C++ like a OOP language (and especially, treating it like Java) will only lead to frustration.
The problem is that Java and C++ don't actually have much in common. Java programmers often believe that Java was inspired by C++, but that's only true if by C++ you mean the very earliest versions of C++, which might more appropriately be called "C with classes".
Since then, C++ has transformed completely into its own language with its own way of doing things. It has probably changed far more since then than Java has. A Java programmer back then would still be able to make sense of today's Java code. Not so for C++. So I'd argue that C is actually closer to Java than "modern C++" is. C is what you get if you take Java and strip away the GC and the concept of classes and a few other abstractions. To arrive at C++, you have to add a similar number of features to our hypothetical stripped-down Java as well.
Further, C++ is a remarkably complicated language, and learning it well takes ages. And if you don't learn it well, you're going to shoot yourself in the foot over and over again.
Finally, it depends on your objectives.
C++ is a much more modern language than C, and once you learn it, very expressive and powerful and, surprisingly, it can even be very elegant and concise. But the learning curve is nasty. So for native programming in the long term, I'd recommend C++ over C.
But if your goal is primarily to interface with the Win32 API (or other native API's for that matter), you won't need C++. Win32 and most other API's are written in C, not C++, and you most likely won't need very complex code to interface between that and Java in any case.
About learning Win32, you're right, all the details you need are on MSDN. If you want the big picture, Petzold is the book on the subject.

I guess it depends on your objectives.
If you want to get closer to the machine, then C.
If you want to supplement you knowledge of a OO Java-like layer above C, then C++.
Accelerated C++ (sanitised Amazon link) is an awesome book to learn C++ from the point of view of C++ and not just C with other bits tacked on,
And K'n'R C (sanitised Amazon link) is still the way to go for learning C IMHO!
BTW For C++ follow up with the wisdom of Scott Meyers in the Effective C++ books! And his Effective STL book as well.
HTH
cheers,
Rob

Learn enough C++ to use it as "a better C". You don't have to try to map all of it onto your understanding of Java. All you want is to be able to use C++ objects as abstract data types, new and delete, etc. If STL comes along for the ride, so much the better.
The real question is: Why do you think that JNI is such an absolute necessity? The Windows calls will ruin any thought of keeping your app portable. I'm sitting next to a guy who's having to dig into a Java app that uses JNI. It randomly brings down a server with a SEG FAULT. His hypothesis is that the heap fills up, a JNI call is made to a routine that calls malloc to allocate space on the heap. It's not available, the routine doesn't check the returned pointer for null, deallocates it, and down comes the server. He's still trying to reproduce the error locally, because it requires precise timing to call the JJNI method just before the GC starts up.
100% sure they're required? Just asking....

If you have a good understanding of Java, I'd recommend that start with C, if you start directly with C++ there're a lot of differences between it and Java, and you probably will dislike it.
If you are serious about learning both languages I'd recommend "The C++ Programming Language" by Bjarne Stroustrup, and "The C Programming Language" by Dennis Ritchie.

I think that C++ would be much easier for you to become proficient in than C.
If you've been using Java, you'd have a hard time doing away with conveniences like classes, exceptions, a form of references, dynamic binding, etc. and of course, decent libraries.
However, you should learn C first to make sure you really understand what's under the hood and get to experience pointers and their use and the feeling of working "with no protective gear".
Once you master that, learn about the inheritance mechanisms in C++ and how it's different from Java (e.g., multiple inheritance).

This really depends on your strengths and weaknesses. If you really like design patterns, then I'd suggest using C++, but if you just have to implement a couple simple methods in JNI, then I would recommend C. Learning C before C++ should give you a better understanding of memory management without having to worry about some of the complexities of C++ (constructor call order, destructors, and other differences between C++ and Java).
I would suggest "The C Programming Language" by Kernighan and Ritchie as the definitive manual for learning C. http://www.amazon.com/Programming-Language-Dennis-M-Richie/dp/0876925964
If you're on a *nix system, there's ample documentation in the manpages for different functions. For example,
bash$ man malloc

If you want an excellent resource for C, "The C Programming Language" by Dennis Ritchie is the book to get.

If your intent is to continue writing JNI code then I'd definitely recommend C++.
In particular, the JNI interface requires you to acquire (and subsequently release) references to Java objects. Using C++ auto variables you can get these references using 'RAII' (Resource Allocation is Initialisation) techniques which makes memory management far simpler.

100% sure they're required? Just
asking....
Unfortunately, yes.
Thanks everyone for your answers.
To answer some of the follow up questions, I'm not looking for a career change to C or C++. I'd just like to learn the fundamentals so I don't feel like I'm flying blind when I do need to write bits and pieces.

In particular, the JNI interface
requires you to acquire (and
subsequently release) references to
Java objects. Using C++ auto variables
you can get these references using
'RAII' (Resource Allocation is
Initialisation) techniques which makes
memory management far simpler.
Thanks, that is helpful. One of the areas that stoked the growing concern in my stomach was dealing with manually managing the memory associated with the JNI objects

If your "main goal" here is to do windows programming, I'd recommend C# over C or C++. However I believe every programmer on Earth, and in Lower orbit, SHOULD know C. Not knowing C++ is acceptable, although you might not get invited to a few parties :) But C is something of a rite of passage, between Applications (high-level) programmer and Library (low-level) programmer.

Why Java programs?

I've had little exp. with java and since now i've worked with c++. what makes this one more special and preferred?
Moreover I would like to know about the use of System.in classes and parseInt classes.

Java is vastly easier to work with, especially when developing large programs.
Debugging: Java generates nice Stacktraces
Stability: You can catch every exception
Development Speed: you need no linker (which can take many minutes in C++); with a modern IDE (e.g. eclipse) you can edit code in-place while the program is running
Garbage Collection and run-time type safety eliminate whole classes of errors
really good free (as in beer) IDEs

In theory (and sometimes in reality) Java programs also run on multiple platforms, "write once - debug, er, run everywhere" type of thing. That makes it very useful for a variety of projects.
In my personal experience, while learning Java shortly after being introduced to C++, Java seemed simpler and easier to learn and understand, hence more productive, as was said before. While program structure and syntax is very similar, there is no need to worry about pointers and other potentially dangerous language features.

This is really very broad and I think these are really 2 or 3 different questions. I'll address the first one very briefly. Java utilizes garbage collection, or autmatic memory management. That is, arguably, the biggest difference between it from a language like C++. There are clearly some potential for increase in productivity in that you don't have to worry as much about memory, although in reality you do need to pay attention to your references. Perhaps you could refine your question a bit.

Java works in browsers! (Milpa for example). You can say Flash too, but with Java you can leverage the numerous classes coming with it (another advantage over C++, even if both languages has a good set of free libraries on the Net) and your knowledge of the language.
As said, Java is supported on many platforms with minimal adjustments, with a fast, efficient VM, from big servers to mobile phones.
OO support is arguably better designed, avoiding mistakes done in C++. Somehow, C# is to Java what Java is to C++ ^_^ (I won't argue on this, I don't know C# enough actually, it is just an historical point).
In the same spirit, Java is slightly more abstract, avoiding pointers, manual memory management and some other low level stuff.
That doesn't mean than one is better than the other, STL helps C++ for some of the issues above, etc.
I am not sure how to answer the last sentence, these are object and method respectively, not classes.
I never used System.in yet, I suppose it is usable if you feed the Java program with < or | on the command line. And parseInt is a static method of Integer class.

The language features have already been mentioned (GC, reflection etc.). But there is another major difference: Libraries. I know there is the STL and Boost and all kinds of libraries out there, but they are not all of a piece, they all feel different. Often you are forced to use all kinds of C-APIs (e.g. threading or sockets, just to mention two things). All the C++ evangelists will now jump in and tell about some kind of cool OO-socket or OO-threading library, but they are not part of the STL. They should be. Its almost 2009 and everything is networked and multithreaded. This ought to be part of the standard library.
Why is it bad to use those C-APIs? Because it is hard to use them in an object oriented programm. Try using Win32's CreateThread() with the listener-pattern (C#-users: read "delegates").
For a "rich client application", where performance is not a big deal, I would always use Java or C#. If I need raw speed (think signal processing or embedded applications), I would rather use C instead of C++.
BTW: I have used all four languages (C, C++, Java, C#) for a long time.

If you like to program really the object oriented way, then you need to go from C++ to Java. One of the problems with C++ is that most programmers actually use it as C and don't exploit all its OO features. Java is here stricter.

With C++ you're programming "on the metal", whereas with Java you're programming towards a virtual machine. The Java software stack all the way down to the VM is constructed to give a highly abstracted programming experience. This is most clearly apparent in the use of datatypes "that just are" (i.e. the programmers need no understanding of how they translate into memory areas), garbage collection "that just works" (the programmers don't have to deal with allocation and deallocation issues) and the ubiquity of exceptions for error handling and propagation. Pointers are not part of Java, the system takes care of where and how things are allocated.
From this, you might see that the design philosophy of Java is very different from C++: Java tries to enforce that the programmer should stick to certain ways of working which are considered to be safe and to make programming easier. Some people hate this aspect of Java, other people love it.

It really depends on what you're trying to do.
For a lot of higher level functionality where optimal performance may not matter, Java is easier and more reliable to use. For example, garbage collection, array checking, etc. It's also sandboxed, of course.
For me, another major benefit of Java is the use of reflection and of run time class loading. I write a lot of plugins within pluggable architectures, and can ensure I can add more new classes to a running program on any platform. Last time I tried to do that in C++, I had to mess with DLLs and COM.

C, C++, Java, what is next and what will it look like? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What do you think the next evolution of languages will look like?

You might assume C and C++ are being "phased out" and that Java/.Net/Python/whatever is an "advance" or the "next stop".
They are all used heavily (see the number C or C++ of tags on this site). The difference is that neither one is the lingua-franca of the programming world anymore. It used to be that the majority of apps were desktop or DOS apps on systems with very limited resources, furthermore all the major desktop APIs were written in C or C++. So everyone learned these.
Now its more complex. Languages are becomming more application specific. C/C++ for when performance is important. Scripting languages for when your main performance hit is db reads/writes. Java and .Net for generic, non-performance-critical desktop apps.
Its the same thing with computer or electrical engineering. In the past these were huge fields at the highest level of abstraction available. Now we have all sorts of higher levels of abstraction. Still, we need people to do this lower-level kind of engineering. They are still in demand. In the same manner, C will continue to be used in many environments, as will C++. You'd be crazy, for instance, to think that you could write a device driver in Java, you'd also be mildly crazy (but perhaps less so) to write a full fledged GUI app in C if you had the choice and ability to do it in Java or .Net.
Each tool has its purpose. I expect C, C++, and Java to evolve and continue to be used for new and legacy development.

I can't speak for C++ and Java, but C definitely ain't goin' nowhere...
It's pretty much unthinkable to write any kind of operating system kernel without most of it in C (well, you can use assembly language entirely if you are really stubborn :-P).
C is basically a thin wrapper of niceness around assembly language. It's so tightly coupled to a standard Von Neumann CPU architecture that no standard library or runtime is required to implement most of its features: pointers, character strings, automatic variables on the stack, integer arithmetic, etc.
For the same reasons, C is great for user-level applications that absolutely demand high performance, things like multiplying huge matrices or parsing complex languages. It may be a pain to write a parser in C, but the speed and efficiency advantages of manual memory management are hard to pass up...

Alan Kay once said "Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."
He is working on changing the future of programming
"The real romance is out ahead and yet to come. The computer revolution hasn't started yet. Don't be misled by the enormous flow of money into bad defacto standards for unsophisticated buyers using poor adaptations of incomplete ideas." source
Well, I might add that Bjarne once said "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Languages evolve to fill a niche problem that is not covered by other languages.
Weather that language gets a foot hold and establishes itself is another question entirely and has a lot to do with popularity.
What comes next?
The problem I see that needs filling is multi-processors (or multi-cores). Currently all the popular languages have very limited ability to exploit the additional cores. Basically all current popular languages give the developer the very basic objects (threads/locks etc) to use the cores and then leave it up to the developer to try and exploit the parallelism available from multi-cores.
It would be a nice to have a language that abstracted away the concept of cores (even threads) and could automatically exploit the enherant parallelism available from multi-cores/multi-processor architecture. Unfortunately all these languages (that I know about) are still research projects at universities and are unlikely to see real adoption any time soon.
You imply that there was a progression C -> C++ -> Java.
That's a bit artificial, each language represents a method of solving problems and each language has inherent problem domains where it is efficient at solve a problem and other problem domains where that language would be a bad choice.
Personally:
I would never write a device driver with Java.
I would probably not write back-end web module with C (you probably can but not me)
etc.

C# ? -- oh, but that is Java :) (sorry, couldn't resist)
The next generation of languages is already here, Scripting ones. Its no mistake that Microsoft is working on the DLR (dynamic language runtime). I think the future will be interpreted (but JITted), dynamic languages that have few constraints and lots of flexibility.
Performance constraints for the majority of languages are not so important nowadays, or no-one would be writing Java or C# apps at all, but considering CPUs are super-fast, and RAM is cheap, we don't notice the inefficiencies of these higher-level designs (eg if you have a 1mhz cpu, you write your code in C, not C#. If you have a CPU running at 3Ghz, you write it whatever you like)
So.. Ruby, Python, "Dynamic-C#"... these are the future. When MS releases the DLR, expect a lot of interest in it, expect a lot of companies to start talking about programmer productivity as the most important part of most application development.
After that.... probably a GUI-driven system where you connect blocks together in a UML-a-like system and add properties to them that produces generated code.

I believe the answer is twofold.
First, client side applications are more and more implemented as browser based applications. To give a browser based application a look and feel comparable to rich desktop application you need something like Javascript. And if you followed the news a bit you see a tremendous effort towards speeding up the javascript implementation in browsers, and a flourishing ecosystem of libraries which help you create a responsive, intuitive GUI with javascript in a browser.
So, for GUIs I believe the future is Javascript.
For the backend, the server, I very much doubt that the near future has a scripted language in store. Server-side software tends to live for years and years, features added, bugs fixed and all. The language in which that is written needs to be not so much fast to write, but easy to read (maintain).
And scripted languages tend to be a bit more difficult to understand if you revisit your code after a year or two to fix that bug. That has (in my opinion) two primary reasons which will not go away in the short term:
IDEs have trouble giving hints with dynamic languages
In the context your working there is by definition less context information available; in Java you know you can only get type X. In a scripted language you should check all referencing code, not easy in a large project
These problems can be mitigated by using very experienced developers, but if, in the future, the only kind of usefull developer is a experienced one we won't need to hire inexperienced ones, which will give trouble in the future.
For those reasons I believe the next-gen server-side language is statically typed. And from the statically typed languages I think C# and Java have the best chances due to the enormous amount of usefull libraries available and the very readable nature of those languages.

As other have mentioned, languages tend to adapt around new technologies and trends. So in order to answer that question, you first have to look at the overall future of computers and see what languages are most suitable for these purposes.
For example, to use your language progression as an example, in the beginning (:-)) there was a need for a language that would make maximum use of the limited resources available, C fit the bill in that regard. As time went on, and the spectrum of software applications incresed there was a greater demand for OO based languages in order to facilitate software reuse, easier design etc. and C++ / Java became popular.
Currently, there is an increased drift in the industry towards server side components that do all the work with thin client UIs (i.e. browsers). So languages that cater for this demand are becomming more popular (Ruby, ASP/Java EE languages).
New languages will become popular when the technology that they are closest to become popular.
Personally (and this is guesswork), I think there is huge scope for a language that truly takes advantage of multi-core systems. This will mean having multi-threading built from the very start and will probably require a change in approach and thinking (like going from procedural to OO).

It's going on a couple years old now, but Tim Sweeney's The Next Mainstream Programming Language: A Game Developer's Perspective is an interesting cogitation on the subject.

What is the future of programming? Away from languages as we know them.
It's 2009 and we're still using text editors? With the project I'm a part of you can build entire applications simply by setting attributes. Outside of (mainly mathematical) expressions and string values, there's not a line of text anywhere.
One of the developers complained that "you can't print out the code," and I replied, "Would a company print out its entire accounting structure? Or would it print out the aspects it wants to see, such as Cashflow Statements and Balance Sheets?" It's only when we move out into new abstraction mechanisms that we can really move ahead.
The future of programming remains to be seen, but I think there are some exciting developments happening that will finally release us from the C/C++/Java harness we've had on for so long.

At some point programs will start writing their own programs making humans redundant as far as programming is concerned. The major disagreement is when this will happen.

If you follow only this branch of programming language history, I think one can write both JavaScript and C#, since they came after the three you mention, share a similar syntax, and took from the predecessors.
Others might mention D or Objective-C (they are already here, of course).
By next language, I suppose you mean "next successful", because there is almost a new language each month...
I think it will be a language with garbage collection, running on bytecode with Jit, highly portable.
I can't tell if it will be object-oriented or functional, with static or dynamic typing, but I would bet on a mix, like does the interesting Fan Programming Language.
Or maybe we are all wrong, it might just a natural language, with spoken or graphical interface: "Take the weather box of this page, change its color and this logo to that, and integrate in my page".

What would be great, in my opinion, is a language like C++ with a more compact definition, better standard library, native garbage collection, and native synchronization constructs. It should be usable by relative novices, but still provide facilities for experts to program in an efficient, low-level way when needed. I believe D meets most of these criteria, but it seems unlikely to me that it will take hold.

On the short term, I expect high level languages to become more powerful and more used. Perl 6 and Javascript 2.0 are good examples of what awaits us.
On the long term, functional languages might make it into the mainstream, but I expect that will not happen any time soon.

D language, especially the 2.0 version has learnt from Ruby, Python and lots of modern languages without keeping source compatibility with C, still allowing for raw access to the metal. The design decisions of this language are a perfect solution for next-generation system and general programming languages, with even functional programming and metaprogramming built-in.

The language question is in my opinion no either or. It allways depends on your application. And since languages have mostly a standard set of libraries that are well suited for this or that application. Languages are tied somewhat to a particular application field.
For Example:
C -> Device drivers
C++ -> Highperformance Computing
Java -> Server side programs (J2EE)
C# -> Server, Client(Silverlight, WinForm, WPF)
Ruby, Python, ... -> WebScripting (Serverside) and helper scripts
ECMAScript (Javascript) -> WebScripting (Clientside)
I think any of these languages are capable to solve any computing program (also performance wise since we have Jits) but they are not used in any field since it is not feasible to recreate every library for every language.
On thing that makes C and C++ special is, that there is a standard library but compared to the others it is a rather minimalistic standard library. To use those languages efficiently 3rd party (non-standard) libraries are needed.
So when choosing a language for a project you look for these things:
Are there the right libraries you can use in your project
Do you know the language
Is it efficient to programm in this language (look at brainfuck)
Does your team know and master the language?
The last thing is also do you like the language? At the end that is the biggest motivation to use this or that language.
So the next step in language evolution will be higher level libraries and concepts to be faster and more expressive. Examples are
Lambda expressions
Linq (C# feature to do sort of sql in the language)
functional programming
variable typing
dynamic typing
not particular language: better IDEs that assists the programmer
Important: Support for easy! parallelism (Axum, Nesl, orca, Chapel, ... ) Here list