views:

221

answers:

5

This might be a silly question, but still I am going ahead and asking it. Nowadays I see new dynamic languages like Groovy being developed for the JVM, and languages like Ruby gaining prominence.

Each of these seems to be solving different shortcomings in the existing languages.

Is there any one or set of problems that are not addressed by any of the current languages?

+5  A: 

New languages come into existence for a number of reasons:

  • as an exercise for the inventor;
  • because of perceived shortcomings in existing solutions;
  • to introduce new ideas that are awkward or impractical to transplant into existing languages.

There is no defined list of problems. Someone simply decides, usually based on their own experience, that nothing quite does all that he wants and then tries to create something that does. Sometimes it works, sometimes it doesn't. Sometimes it becomes popular, more often than not it doesn't.

Edit: It's important to remember that when it comes to "problems", it is often subjective. Many consider memory management a problem that prompted the rise of garbage collecting. Not everyone agrees.

Also, the features that come into languages and at least in part prompt new languages come into being aren't necessarily related to problems. They're more about what's possible and what's fashionable.

Closures, first-class functions and the like are currently fashionable, even though they've existed in Lisp for decades. That's why most modern languages either have them or are getting them.

What's possible is also important. Computer power is no so cheap that the overhead or things like garbage collection is considered to be so small that in most cases the productivity gains outweigh any implementation costs.

Lastly, no language is suited to all tasks. As what we want to do with programs changes, so do the languages. Now Web development is a huge force in programming. It wasn't 10-15 years ago. Useful features for Web development aren't necessarily the same as writing heavyweight desktop apps so languages evolve too.

cletus
But surely there will be a certain kind of problem(s) that keep recurring in all langauges, memory management for example or the ease with which we can work with a list in pytho as opposed to Java. I just wanted to collate a small list of such problems.
Hari
+7  A: 

Strictly speaking, no. If a language can be proven to be turing complete, it can do anything a computer can, after all one could program in assembly if one wanted to. The reason new languages evolve is for several reasons:

  1. New programming paradigms, e.g. object oriented programming, aspect oriented programming, etc.
  2. Domain specific languages, e.g. web development, hardware design languages, etc.
  3. Personal preferences

Any language has shortcomings, no language can be perfect. C is low level, so is usually not the nicest language to program say a website in, on the other hand, I wouldn't want to program an OS in php, it'd be a disaster, etc.

wich
Ok, so procedureal led to OOP so that we can overcome the problems of maintinaing large code bases and write code that mirrors every day abstractions. So, it could be possible that a new language evolves so that it maks it easy to program for the cloud or lets says distributed systems?
Hari
For distributed systems, look at, say, Erlang.
Roger Lipscombe
@Hari it is not the case that OOP is strictly better than procedural, for some problem domains OOP is very good, but for others it may be a very bad fit. It is also a matter of taste really.
wich
+1  A: 

I think this is mostly for convenience. Let's take C++ or Assembly for example; as far as I know any problems can be solved using them, but more complex problems can be difficult, since for example when you're building a Windows forms application, you naturally don't like that you have to play around with pointers; it just takes much of your valuable time and energy.

Another very good example is the experimental programming language for .NET, Axum, aiming to make threading really convenient.

Also, specialized programming languages make for more efficiency in their certain areas; think of SQL (I know it's not a 'real' programming language, but I think it's a good example) for instance.

By the way, it's all fun for those who do it for joy (as well as money of course); I often find myself experimenting with other programming languages other than the ones I need, because they're simply different and interesting. Building compilers and interpreters is also a really exciting and challenging task for some people.

ShdNx
What is not real about SQL? Oracle and MS made it real 'Select 2+3 into sum' ;->
Kugel
+2  A: 

The overall trend is that programming language raise the abstraction level more and more. The tendency is to go away from plain procedure call. This is good and bad at the same time. Higher abstraction level can be powerful but can also be harder to use at the same time. Consider for instance AOP. Very powerful, but also hard to use correctly.

We also see a tendency to mix paradigms together, e.g. more and more object-oriented languages now incorporate elements from functional paradigm as well. This requires lots of trial and error until the perfect blend is found. Consider for instance Scala which incorporate a lot of ideas in one language. Or Clojure which brings transactions right into the language itself.

Such a perfect blend will probably never exist, will be subject to opinion and taste, and we will hence continue to propose new abstractions to deal with programming.

ewernli
What has happened to the FOOL languages? In the beginning of the '90s there was supposed to be a language called "Paradise" that would combine Functional, Object-Oriented, and Logical (FOOL) paradigms.
Kensai
A: 

In some cases, new programming languages are usefull to make use of new hardware architectures. For example, harnessing the massive-parallel power of a GPU is much easier with a language especially made for that purpose.

ammoQ
is there any language out there to harness the power of the GPU?
Hari
look out for libraries like CUDA (for nvidia) these are not unified in any way.
Kugel