Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I've forked this question from a similar question I made in a comment I made to one of the many great answers I recieved. I was originally asking about AST macros, which mostly provoked very detailed and thoughtful responses from Lispers. Thanks.
Lazy Evaluation vs Macros
The question I made in a comment was whether project-specific DSLs are actually a good idea. Of course, this is completely subjective -- After all, when you are writing in a really expressive language, where do you draw the line between an expressive API and an actual DSL? For example, I think what most Rubyists call 'DSLs' are actually just well-designed APIs and nothing more.
Note that I say project-specific APIs. I don't think many will argue against using regular expressions or SQL where it makes sense to do so.
But despite this, I think we can all draw a vauge, hazy line between an API and a DSL. Of course they're both really APIs, but whatever.
On one extreme you have Lisp, where DSLs seem to be actively encouraged via macros. On the other you have the likes of Java where DSLs are pretty much impossible.
Proponents of DSLs would argue that they increase flexibility, expressiveness, and increase consistency (for example, a custom number object using the same operators as the language's own numbers).
Detractors would say that they can lead to sub-languages that nobody except the DSL writer knows, kills the point of having different programming languages in the first place, and leads to code nobody can understand because the way of interfacing with API is different.
I gotta say, I agree with both sides in many ways. Some Java APIs are just plain nasty due to the lack of expressiveness. Despite this, I can generally always work out what's going on without reading the documentation -- Which can't be said about custom DSLs in the slightest. Maybe DSL proponents argue that you should always read API documentation. I disagree, but I also digress.
But let's look at some of the big languages at the moment. C# and Java, namely. Neither of them really 'do' DSLs, yet they're massively popular. Is this precisely because they don't allow things like DSLs, allowing mediocre coders to churn out code that's still comprehensible?
Is the fact that DSLs allow mediocre coders to produce impenetrable garbage the reason why Lisp is not used as much as it should be, despite what a DSL can look like in the right hands?
There are of course arguments in favor of DSLs and against them, and there's of course a vague line between "a library" or "an API" and "a DSL". That part you've covered well in the question, so I'll avoid those subjective points and focus on just the question of whether they're a liability.
A good project to consider for this is Racket which puts language construction as its main feature. It's easy to slap up a language for any definition of "a language": DSL or not, made up from near scratch via an interpreter or (more commonly) done via macros that define the new language and possibly a parser for a different syntax. As a result, the Racket source tree has a bunch of languages -- some of them have fundamentally different execution semantics. Some examples:
Lazy Racket is what you'd expect the name to mean,
Typed Racket is a statically typed language,
Scribble is a language for writing documentation and other prose,
Slideshow is a language for writing ... slideshows,
RackLog/DataLog are languages that are even more different in both semantics and syntax.
In fact, making up languages is so easy in Racket, that you easily slap up a language even if it's something that fits a very limited use, or even just a single one. For example, we have such "small languages" that are used to create our web pages, decide which files are included in distributed installers, and many many more. See this tutorial for a description of how to come up with a language.
It's true that there's a fine line between a useful DSL that many people can use and one that only one person uses -- but still, the kind of abstractions that you can get when you define a language rather than a library are substantial, to the point that it's a useful concept even when it's a "one-man's language". One hard problem in this are is considering interoperability -- Racket allows each module to be written in it's own language, which brings up issues of what happens when several of these modules are supposed to talk to each other. For example, how does evaluation proceeds when there's interaction of functions in the lazy language and in the default one; or how does the typed make sure that it can interact with the default untyped language and still get the usual benefits of a statically typed language.
DSLs are widely used in Java. Just not 'internal' DSLs. Lisp has, unlike Java, several ways to alter the language syntax and semantics without writing a new external language. In Java, most DSLs are either external (often based on XML) or implemented with a pre-processor.
If you write a new programming language, also a domain-specific programming language, you need to:
specify it
document it
test it
make it robust
make it debuggable
make it efficient
... and more
Lisp is no magic bullet to do all that for you. What Lisp gives you is to include one or more DSLs directly into the language and it allows you to reuse or alter the Lisp facilities to implement parts of your new language.
Lisp had in its history a lot of languages implemented on top of it. Many of them were just research languages without too much effort to follow software engineering practices. Some of these languages had more effort put into them - for example because they were part of a product.
If you develop a language for your project, you need to make sure that you follow good software engineering practices and you have the resources to do so.
Related
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 6 years ago.
Improve this question
I'm building a card game called Tijari (uses 40 Spanish cards deck, quite similar to Bridge) as an Expert System. This is all part of my doctoral thesis.
I'm having a hard time finding a good balance between Prolog code and Java code, what would go where and why. The game must let human players play against the AI as well as against each other, so you can have a team of (Human + AI) vs (AI + AI) or (Human + Human) vs (Human + Human) or anything in between.
While Prolog is defined as being about facts and rules, most uses I see of it are not really what you would call logic programming but actually awkward programming trying to implement sometimes complex algorithms under the constraints and intricacies of the language: shuffles, search and complex list operations. Why?
There are some uses of Prolog that a language like Java cannot provide easily like when it comes to deduction based on existing rules and facts and the ability to query for information, still, I generally cannot seem to be able to justify its use.
Is it the fact that it encodes domain knowledge in logic? Well, any real-world Prolog program seems harder to read than plain Java code because of backtracking, cuts and recursion.
Is it the fact that it doesn't require a software developer to encode domain knowledge, just a domain expert? Well not really, you would still need a domain expert who is well versed in Prolog.
Is it the fact that you can easily modify the rules and facts without needing recompilation? Well, any scripting language can offer that really.
Is it the fact that it can easily evolve as domain knowledge evolves? Well, I believe that domain knowledge doesn't evolve that much for it to be a problem, and when it does, software follows, that is why it has always been.
I honestly have a hard time justifying the use of Prolog as the only language in which an Expert System (and here a game) must be built, and when it's not, when you end up using a combination of Java and Prolog, where should the line be?
Thanks
I think your question is a very good and legitimate question, and I am also quite certain that it will soon be closed as many other interesting and worthwhile Prolog questions already have been.
Therefore, I try to rush in an answer while that is still possible.
First, I would like to point out that many Prolog programs are currently indeed still more awkward than they could be. One of the reasons for this is that the existing teaching material is sometimes decades behind the current state of the language. As a result, many very important declarative features that have become widely available in many systems in the past few years and decades are simple not known by a large fraction of Prolog programmers. With these features, many Prolog programs become a lot less awkward.
One important difference between the two languages is in my experience: In comparison to programming in Prolog, writing Java code is extremely inconvenient. The reason becomes immediately obvious after your first few serious Prolog programs: In Java, you consistently feel at least one step too far removed from the actual task. You cannot simply write down the terms, state, knowledge etc. No, you instead have to first write down a meta-description of the knowledge itself (in the form of classes, types, interfaces), and only then can you talk about what you actually want. But that's not all: The description of both the actual knowledge and its properties is extremely low-level. For example, you cannot conveniently reason about things symbolically via pattern matching.
The benefits of this quite indirect programming style that Java inherently necessitates are in my view very questionable. At least I have yet to see a Java program where I could with a straight face say: "Yes, Java was a great choice for this project." By comparison, I have seen many Prolog programs where Prolog definitely was a great choice for the project.
There are many more differences that make programming in Prolog vastly more convenient than programming in Java. For example:
Prolog code is easy to parse, change and analyse by other Prolog programs, allowing for some very cool shortcuts
Prolog code is very easy to test interactively using the toplevel
Prolog code can often be used in several directions, leading to shorter programs
very importantly, it is extremely easy to formulate extensive test cases using comparatively simple Prolog queries which generate a vast number of tests on backtracking.
These are only a few examples I'd like to mention. Overall, I think that if you regard Java as a "general purpose" programming language, then Prolog definitely also falls into that category. At least I have yet to see a project where someone said "It would be so great if only we could use Java for this task!" I've heard this phrase about Prolog several times already.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm versed in Java, and starting to experiment with Groovy.
Because the two are integrated so well, I find myself writing in Java whatever I can because it's so easy. What specific tips can you offer that would speedup my work with Groovy?
Meaning - in what areas do groovy excel over java, and where should I stick to Java?
Some of the main things I like groovy for:
testing is probably the biggest win. The ability to change behavior at runtime and mock out methods is one of the greatest things about groovy. Convert your test suites to groovy now!
use the builders. Groovy builders have so much more expressiveness than traditional java. In particular, the MarkupBuilder for embedded snippets of XML or HTML is 1000s of times nicer to use than vanilla java
GPars if you're doing any sort of concurrent programming or threading
Also see Hidden features of Groovy and Why would one use Groovy over Java (note: was "removed from Stack Overflow for reasons of moderation").
Where I'd stick with java:
any place where speed really matters, stick with java. You still pay a high cost in performance for groovy's dynamic nature.
The problem with Groovy.
Groovy is a write-easy, but maintenance-nightmare. In my opinion, it should not be used in large projects. Inheriting somebody else's (or your own) code can be problematic, because very often you have no clue of the type of a variable, so you have your due diligence to find out, or use assertions to guarantee the incoming type to a method.
Groovy is a weak-typed language. The type of a variable is frequently ignored, or "conveniently" cast automatically, which leads to many bugs and slower performance.
Even the bests IDE's are lacking, because the practically typeless variables of the language. In many cases the compile just can't know what is the type of a variable. Even if you declare the type of a variable (which helps the editor to make suggestions), many programmers forget to define the variables type.
It has interesting ideas that I would love to see in Java, but stay away from it if your Groovy code will require more than a thousand lines.
* The answers in a nutshell *
Summarizing, here are the answers to both questions:
What specific tips can you offer that
would speedup my work with Groovy?
Use it only for small stuff. Otherwise, you will incur in technical-debt (see the Wikipedia). So far I'm in similar situation. Unit testing, using the console to test pieces of code, etc., are things that will speed up your development, since it's so easy to learn and use. Be sure to master closures, collections, and looping, and to understand what Java features are not available in Groovy.
Don't use pure Groovy for complex or large applications. In the long term the maintenance will slow you down.
Meaning - in what areas do groovy
excel over java, and where should I
stick to Java?
In a large or critical project you need to keep yourself disciplined and use dependable tools. It's like building a house: I are build a doll house, Groovy is fine :-) ... if it's not perfect, it's no biggie. If you build your own house or something bigger with little tolerance for error, you need to use quality tools and materials of better quality that don't let you oversee potential problems (Java, for example).
In any case, Groovy is like duck tape: some here and there may do no harm.
[This is an empirical question about the state-of-the-art: I am NOT asking if Java is cooler or less cool than the dynamic languages that work in the JVM.]
Aside from cases where performance is a main decision factor, do companies/developers still willingly chose Java over Groovy, JRuby or Jython?
Edit: If the answer is "yes," why?
Personal Note: The reason I am asking is that, while I do some subset of my professional work in Ruby (not JRuby, for now), in my personal projects I use Java. While I have written non-trivial apps in Groovy, I prefer Java, but I wonder if I should just get over it and do everything in Groovy. I like Java because I feel that static typing saves me time and aids refactoring. (No, I am not familiar with Scala.) However, I feel that this very empirical, on-topic programming question may inform my decision.
non-statically typed languages don't "scale" well in the maintenance sense. Up to a few tens of thousands of lines of code they are maintainable. Past that they just take more effort to maintain, re-factor or update. This is true of any of the non-static typed languages, Perl, Python, Groovy, Ruby etc. The tools for working with half a million lines of Python code vs the same number of lines of code in C/C++/Java just aren't there. Now it is true that Python is about 1/3 to 1/5 the number of lines of code as an equivalent Java program. So this is never going to be apples and oranges, but there is a cut off point where the number of lines of code in a non-static language will have diminishing returns on maintenance. And everyone knows that maintenance is where the true cost of a software project has always been.
Static typing still is a big thing.
While it has been argued over and over again and proponents of the dynamic approach say that the problems that dynamic typing bring can be reduced (or even eliminated) with sufficient unit tests.
I don't want to argue whether or not this argument is correct, so I'll assume that it is, for this answer.
In that case there is still one problem, which is that many shops don't have the procedures/know-how/rules/management to produce a sufficient number of high-quality unit tests.
And if I have to choose between dynamically typed code without unit tests and statically typed code without unit tests, I'll choose the statically typed one every day.
A similar issue exists with double dispatch:
In Groovy method calls are dispatched based on the actual types of the arguments at runtime (which is almost required, because the static type is unknown and/or Object most of the time). This means that there is no reliable way to know which method is called at any given point at the code, when faced with extensible class hierarchies.
Any code that calls a method with the signature foo(String) most of the time may suddenly call foo(Integer) or foo(SomethingElseEntirely) depending only on the actual type of the argument at runtime. In the Java language that can never happen, because the exact signature of the method to be called is decided at compile time.
Much like other "dynamic" language features, double dispatch is occasionally a very useful tool and the lack of it can produce some ugly constructs in Java, but it has its cost in that it makes it even harder to read, understand and reason about code.
Yes, obviously.
Why are companies still "willingly" using Java?
Because companies are inherently conservative. They don't change technologies because they're cool, or even groovy. They change, reluctantly, when there's a prudent reason to do so. Early adopters pay very heavy penalties for being early adopters.
Edit: this is not "inertia" in the pejorative sense, as in "no reason to avoid change except resistance to change", but in the sense of prudence. It is right for companies to not abandon what's working, until there's something that's provably better.
And not in the "makes developers happy because it's cool" sense of better, but in terms of more quickly and reliably meeting whatever business requirements drive development in the organization.
Java offers:
Large base of trained, experienced developers. It's hard enough finding people who are able to do software development well, without picking a language which hasn't been around as long. And training people in a new language is expensive, in both time and money.
Brand-name recognition and an easily proven track record of successfully completed projects. This is nothing to scoff at: if I tell upper management I'm beginning a project in some groovy new language they've never heard of, I have to educate them on it, and they'll rate that as a risk. With any "established" language, I can skip that step.
Well-established, mature support tools, and third-party support.
These advantages accrue to any comparison between a long-established language and a new one, not just Java and your list. I expect that one day, Groovy, et al, will be the established language, and there'll be people asking the same question about some newer, shinier language. This is the cycle. It's how it's been for longer than I've been in the business.
Aside from cases where performance is
a main decision factor, do
companies/developers still willingly
chose Java over Groovy, JRuby or
JPython?
Yes, and I believe the main reason is inertia, either on the part of the developer or the company:
Company: existing investment in Java (in terms of staff skills and infrastructure), the risks of change are perceived to outweigh the benefits
Developer: there are plenty of Java jobs available, so why bother learning another language?
Lack of available resources is probably another reason, though this is something of a chicken-and-egg problem (or a Mexican standoff, or a self-fulfilling prophecy, or something else). I imagine there are a lot of companies watching Groovy, Jython, etc. but waiting for them to become more widely adopted before taking the plunge. Obviously, by postponing adoption themselves, they're exacerbating this lack of resources problem.
Personal Aside
I spent the last year working as a Groovy/Grails developer. I recently changed jobs and am now working as a Java 1.4 developer and (compared to Groovy programming) it's about as pleasant as gouging your eyes out with a rusty spoon.
Static typing is great in that it facilitates compile-time checking and code analysis tools like FindBugs, but no way does it compensate for the massive amounts of (boilerplate) code it takes to accomplish the simplest of tasks when writing Java (particularly if you're using a version earlier than 1.5).
I can tell you what is going on in my company. Our current application is done in java, but we have started a transition to grails/groovy and this will most probably be the platform for the next generation of our products.
Since you are asking an empirical question, and I assume looking for empirical answers:
Aside from cases where performance is a main decision factor, do companies/developers still willingly chose Java over Groovy, JRuby or JPython?
Yes.
I don't think there is anything else to say.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What is the difference between Java and C++? Are both object-oriented?
This is far too general a question to be answered here.
Java is an explicitly object-oriented language, with the harder-to-use bits snipped off.
C++ is a multi-paradigm language with the safety off. You can do object-oriented programming in it, as well as procedural and generic.
If you had a more specific question, we could be of more help. Why did you ask? If you want recommendations for a particular platform, or project, or whatever, we could be more responsive.
A C++ programmer will tell you that Java is rubbish. A Java programmer will tell you that C++ is rubbish. Therefore I conclude that they are indeed the same thing.
Each language designed with different purposes in mind, so IMO it's not fair to compare the two from one perspective, and ignore the other.
Generally speaking, C++ is an open standard, designed for implementing high performance systems where speed and performance and critical, there are lots of impressing projects designed using this language like Phoenix Lander, Adobe Acrobat Reader and others. C++ gives the developer the ability to program using a very high level abstraction -using generics for example, and, when needed, go down deep to the bare metal of the machine -to handle an interrupt for instance.
Java was designed with other purposes in mind, when Sun was planning Oak (later called Java), it focused on web applications so it supported the language with a bunch of heavy libraries of easy-to-use interfaces considering that. and portability (Compile once, run anywhere) using JVM, which prevents the programmer from coding to specific machine, but instead coding to a sandbox which in turn runs the code on the hosting machine, and this has obviously negative reflections on performance/speed.
Comparison of those two language is a popular cause of debate between programmers, and this is due to their different working demands and nature, IMO every language has made mistakes in order to mature, for example, C++'s exported templates, and Java's lack of procedural programming (Big Mistake). plus, each one has its pros and cons regarding different aspects, hence the one that balance productivity/performance issue IS the right language.
For more information Wikipedia's comprehensive article on Comparison of Java and C++
It might be interesting to take a look at what languages are used (and being used) to create major systems (like Google) from here.
One of the most important differences hasn't been mentioned yet - one is compiled to machine code, the other is compiled to bytecode which is interpreted by a virtual machine.
Everything is Object in Java as everything is derived from java.lang.Object But this is not the case in C++
No pointers in Java whereas C++ has provide support for pointers
No destructors in java (Java has automatic garbage collection) but C++ has destructors to do that
Thread support is built in Java but not in C++
No scope resolution operator in Java
No Goto statement in Java
No Multiple Inheritance allowed in Java but C++ allows that
No operator overloading is allowed in Java but C++ allows that
Java is interpreted for most part and hence Platform independent
Both are object oriented but they are very different languages. This probably isn't the best forum to ask for the differences... I would suggest you look both up on Wikipedia and review the descriptions there. You will be able to see the differences very quickly for yourself.
I love c++ but unless you absolutely need to use c++ then use something else. When you need to use c++ then you will know the difference, Grasshopper.
(hint do not write device drivers, video decoders, encryption libraries, 3-d graphics engines or language run-time engines in java).
Yes, both are object oriented programming languages.
C++ is an evolution to C. Which was a system programming language. C++ Added many features to the language to make it object oriented. It became the mainstream programming language for that reason.
Java is an evolution of C++, with different goals ( cross platform for instance ). It remove some of the features that make C++ so hard to learn. Simplify others and remove others.
The main difference is C++ programs are compiled directly to machine code ( understood by the CPU ) while Java programs are compiled to be run in a "Virtual Machine" the JVM most of the cases. For these reasons java programs were interpreted by another program and at the beginning were veeeery slow programs. Nowadays the VM may optimize this code and make it run very very fast.
See this link.http://www.javacoffeebreak.com/articles/thinkinginjava/comparingc++andjava.html
Gross but accurate oversimplification: Java is easier. C++ is faster.
Just a quick addition to what David Thornley posted. C++ is a procedural language that supports Objects and OO design. Java is pure OO. Java does less but on more.
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