I was thinking of the next generation programming languages may contains an adaptive behavior and self-repairs features, in which it can adapt itself to any environment or platforms or problem (if loop that automatically changes into for loop when needed, etc. ), whereas self-repairs refers to a programming language that learns to improve itself further without the need of human interference (debugging itself and retrieve errors, where repairs can be perform automatically), respectively. That will open up a whole new level of programming language where developer can spend much more time developing rather than spending tedious time on debugging and repairing minor coding problems in huge or massive lines of code.

In my opinion, a future programming language should handle parallel computations better. Dealing with locks, threads or callback functions for asynchronous operations in todays languages can be difficult. A future programming language should help the programmer to express parallel operations in a clear way without any unexpected race conditions, side effects or deadlocks.

Each language have their own way to plan user's threads execution, but in my opinion, the future programming language should allow the programmer create kernel's threads. That allow the programmer choose either implement their own planner or let the operating system do that. Some times this is very usefull to implement a proper planning of users threads.

May be simulate the human brain pattern of making decision

Well there is a difference between good threading support and parallel programming support. Threading support is well supported in C++11 and Java and even in C11. By the way, creating OS threads is something solved in C++11.

Just a very simple example:

void myfunc(int x, float y);

...

thread t1(myfunc, 3, 2.5);

...

However I think we still need to achive a good parallel programming model which is a higher level thing. There are several sub-models there as task-based parallelism and data parallelism.

And of course, we need something better that the bunch of pragmas given by openMP.

yes its platform independent . And the language is very simple to understand ,the same language can used to design/programming ,Run time high speed compiler included in SDK packages.

Go is a compiled, garbage-collected, concurrent programming language developed by Google Inc.[6]

The initial design of Go was started in September 2007 by Robert Griesemer, Rob Pike, and Ken Thompson.[2] Go was officially announced in November 2009. In May 2010, Rob Pike publicly stated that Go was being used "for real stuff" at Google.[7] Go's "gc" compiler targets the Linux, Mac OS X, FreeBSD, OpenBSD, Plan 9, and Microsoft Windows operating systems and the i386, amd64, and ARM processor architectures.

Description

The syntax of Go is broadly similar to that of C: blocks of code are surrounded with curly braces; common control flow structures include for, switch, and if. Unlike C, line-ending semicolons are optional, variable declarations are written differently and are usually optional, type conversions must be made explicitly, and new go and select control keywords have been introduced to support concurrent programming. New built-in types include maps, UTF-8 strings, array slices, and channels for inter-thread communication.

Go is designed for exceptionally fast compiling times, even on modest hardware.[10] The language requires garbage collection. Certain concurrency-related structural conventions of Go (channels and alternative channel inputs) are borrowed from Tony Hoare's CSP. Unlike previous concurrent programming languages such as occam or Limbo, Go does not provide any built-in notion of safe or verifiable concurrency.

Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic.[2] Of these, the Go authors express an openness to generic programming, explicitly argue against assertions and pointer arithmetic, while defending the choice to omit type inheritance as giving a more useful language, encouraging heavy use of interfaces instead.[2] Initially, the language did not include exception handling, but in March 2010 a mechanism known as panic/recover was implemented to handle exceptional errors while avoiding some of the problems the Go authors find with exceptions.

@Tarique: My question is that what are the new features that we are expecting from next-generation programming languages.

I am feeling a new programming language, we or someone will be able to develop a language parallel decoding of a human mind and and robot mind. The imitation intelligencey may help a big part of programming language. Is not it?

I am feeling a new programming language, we or someone will be able to develop a language parallel decoding of a human mind and and robot mind. The imitation intelligencey may help a big part of programming language. Coding will be only a trigger to operate imitation intelligencey.

I think your answer lies..

our expectation would be like this

Safety: Type-safe and memory-safe.

Good support for concurrency and communication.

Efficient, latency-free garbage collection.

High-speed compilation. from the future gen programming language.

Strong support for high concurrency, strong support for highly effective and efficient verification, superior usability and high programmability, etc. Also being easy to port across different platforms and bounded with compilation/interpretation-level security would also be among the highlights of those promising features, I suppose.

Another question to go along with the one you ask is: what mis-features can we expect new languages to leave out? Go, for example, leaves out pointer arithmetic, because that can get you into trouble. Java leaves out goto, because it's considered harmful. When you are coding, what other programmers can't do is just as important as what you can do, because what you can do might not work as expected if other programmers can screw things up. There is a lot of interest in functional programming lately, focused mainly on nice features it gives you like higher-order programming. But just as important, and less appreciated, is what it doesn't give you, like destructive update, because the lack of destructive update is what makes higher-order programming behave sensibly.

Future programming languages will be model driven and less machine based. Support for meta-data, static and dynamic reasoning will become standard. Essentially type systems on steroids... bit-lengths for hardware, units checking for modelling languages are simple instances that are used today, but the future involves computing with services and effective interoperability.

I think visual programming with coding support......

rest modules user can generate ;)

Future programming languages should retain the benefits of proven paradigms such as object-oriented programming and design by contract and should be able to seamlessly support formal reasoning and other core principles of modern software engineering (incrementally, compositionally & reusability etc).

An article about auto-threading compilers: http://developinthecloud.drdobbs.com/author.asp?section_id=2284&doc_id=255275&

I think it will be the sense representation and all we can today name as CS trends only attempt to resolve the problem not nothing else.

What if a language is able to give us a program on the basis of a block diagram or on verbal instructions instead of doing all the stuff with our hands? :)

I was thinking of the next generation programming languages may contains an adaptive behavior and self-repairs features, in which it can adapt itself to any environment or platforms or problem (if loop that automatically changes into for loop when needed, etc. ), whereas self-repairs refers to a programming language that learns to improve itself further without the need of human interference (debugging itself and retrieve errors, where repairs can be perform automatically), respectively. That will open up a whole new level of programming language where developer can spend much more time developing rather than spending tedious time on debugging and repairing minor coding problems in huge or massive lines of code.

The programming language evolution can be (partly) find out from the next compiler and link steps;

1 Standard compiler (source files-> object files +libraries-> to execution file)

2 Like llvm (clang, CUDA as example) based compilers (source files-> virtual machine special format files->virtual machine +libraries -> not obvious execution files, but obviously vm emulations)

3. As @Khalid mentions we can introduce additional evolution like steps

3.1. Compiler of compiler stage (so called supercompiler) - it create the ability to automatically update and adopt the compiler to the domain specific problems.

3.2. Bi-direction compiler - compiler works not only from source to execution directions but in the reverse direction also, of any level (from execution or from virtual machines levels). This create the possibility to resolve @Khalid problems :)

3.3 Now exist only tools to generate code during compile time (template programming), but the same code! But in principle we can define the strategy of code changing and the future tools for the problem of such kind lead to the ability of generating not the same code for strategy services. Life circle of soft may be realized much more easily. It can be used for embedding hard standard for program life circle.

4. But all the above only specification for the next generation language. We can extend the problem list with the changing execution environment (OS or vm for example) also. Do we have sufficient theory for the problems of such level? If so, it can be only on the modern algebra base only. And the programming language of future will be not only for computer problems only, but the new language of science (especially human oriented) also. We are today on the stage like starting to speak with nature not only with computer!

There is an interesting article on this topic:

Guerraoui R. : "Strategic directions in object-oriented programming", available at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.5980 .

Even being written in 1996, some trends are still actual. Guerraoui has identified some disciplines as possible successors of OOP paradigm, like Aspect-Oriented Programming (AOP).

From my point of view, the future is in Automatic Programming, including GP (Generative Programming, frames technologies, AOP, advanced Generic Programming and other disciplines that lead to building of Software Product Lines (SPL). Why do we make our programs manually when we can build our software automatically?

Of course, there some prerequisites to achieve such productivity, flexibility and optimization, like open computing and high-level and very flexible languages like python.

Danijel: software will never really be built automatically, it will always be necessary to specify programs in some manner. To me the keys are the level of abstraction at which we specify the program, and the level of compositionality of the programming constructs we use. A high level of abstraction allows the programmer to avoid giving unimportant details, which is obviously a good thing. But people often underestimate compositionality: it is essential that programmers be able to anticipate how the parts of the program they are developing will interact. Better still, parts of a program should only interact through clear, simple interfaces. This is why garbage collection is such a productivity improvement: you don't have to worry that this bit of code over here will hold on to memory that is about to be freed by that code over there. It's also why people are advised to make instance variables private, to make classes immutable whenever possible, and to avoid global variables. So I expect the trend in programming languages will be toward greater abstraction and less possibility of hidden interaction.

Existing programming languages are much too complex with too many features. The next programming language should reduce the features of existing programming languages to a set that fully supports at least one widely useful paradigm (e.g., object-orientation), provides as much support for the programmer to avoid mistakes as it can, and supports abstraction and control structures well.

I think the next area that needs new programming languages is multiprogramming.

@Magel: I agree to the complexity part. If you have a look at LUA's success, a simple, bare-bone language with minimum runtime environment requirements definitely has its use.

On the other hand, there is the trend of ever more complex libraries. A language which does not support (directly or indirectly) typical use cases (e.g., client/server architectures and common protocols) is mostly academic.

And that's the problem: There is significant effort involved in creating those libraries beyond the language core. This effort will only be invested above a certain critical mass.

Currently used precise languages are now behind what was designed at IBM 40 years ago on 6 leading edges:

1. Simplicity of expression.

2. Fluency of expression.

3. Generality of subject matter.

4. Flexibility of data structures.

5. Modularity of basic data objects.

6. Durability of underlying design.

All these should be improved. See users.rcn.com/eslowry .

Hi there, dear all!

There are 5 generations for programming languages.. but, attention please: foldoc.org constatates that the 5th GL is "a myth the Japanese spent a lot of money on. In about 1982, MITI decided it would spend ten years and a lot of money applying artificial intelligence to programming, thus solving the software crisis. The project spent its money and its ten years and in 1992 closed down with a wimper." http://foldoc.org/fifth+generation+language

So, what we have are the 4GLs, that are called now "domain specific languages".

So before to speak about a new language we ought to specify the domain.

And it seems to me new languages will look like C-childs (have a look at C++, Java, C#, object-C, etc.) :-)

With best regards, Vladimir E. Zyubin

The features of any programming language make only small part of its success. The biggest part of success is made by libraries, IDEs, support, documentation, training, third parties involvement, tools available…- by whole ecosystem. And this ecosystem includes support for all phases of SDLC – beside coding it is design and testing. Better said: design and testing is on first place, because cost of these phases many times exceeds the cost of coding.

Our world is full of systems with complexity exceeding the complexity of software ones. These systems have a lot of features – I mention only three:

- They are hierarchical and heterogeneous

- They are massively interconnected, mutually influencing each other

- They never last forever.

Continuing with features of development ecosystem is out of scope of the question.

I think parallelism support in a way that caters for assorted parallel hardware- and software-level architectures and technologies will be a big part of the future features to be expected.

Also, since multi-core era is being threatened by power-efficiency challenges, something helpful in that regard, the streaming programming model for instance, might be another prospective ingredient of next generation programming languages.

Finally, but not clear enough right now, a programmer-friendly built-in support for code safety and quality would be very promising and competitive!

I agree with Haipeng that parallelism should be built into the language - especially in this day and age where 4,8,16, ... core chips are being produced, with many more to come in the future. Of course, that leads to the question as to whether user API threading should be available, or only compiler generated threading. Should the user worry about the additional complexity or should that be left to the language compiler?

Along those lines, GPU code generation (whether it be CUDA or OpenCL) should also be seamless.

For those of you who are unaware, there was a 'holy grail' of programming languages that solves many of these issues, it was developed by the US Gov't in 1983 - Ada. See what features it has vs what everyone *thinks* should be in the next language - http://en.wikipedia.org/wiki/Ada_(programming_language).

Ada did have a lot of nice features. Unfortunately, it faded out when the US Government quite requiring it on systems. Some of the new features in the more recent versions of Fortran were "borrowed" from Ada. In addition, Fortran has parallel programming built in. Perhaps that is a place to look for an alternative that is still thriving and evolving.

Bill - "Fortran has parallel programming built in"? I assume you're referring to OpenMP? Those directives aren't unique to Fortran - as both C/C++ provide OpenMP also. High Performance Fortran (HPF) was a specification that included parallel constructs, some of which were implemented in OpenMP.

I know of variants to Fortran that have parallelism implemented directly in the language, but they're not portable (vendor lock in).

Introducing a new language is problematic. You'll have to convince folks using current languages why this new language is better/faster, and provide a way to translate from their language of choice to the new language. C++ became successful because it compiled existing C code. Java is successful because it solved a new problem, and looks a lot like C/C++.

The base ISO Fortran standard now includes SPMD parallelism using coarrays and synchronization statements. Fortran is also supported by the OpenMP spec, though as you correctly point out, that is not part of the language itself, and OpenMP works equally well with C and C++. HPF was an experiment from several years ago - it fared even worse that Ada, mainly because it was too complicated for users (my opinion). In addition, it was largely directive based, and not really part of the language syntax. My previous comment was specifically in regard to the native parallelism in Fortran 2008, which is the informal name for the current standard.

BTW, I also agree that a completely new language is a hard sell. It is much easier to evolve a current language so that existing codes can incrementally incorporate the new features rather than being completely rewritten.

Please may we have languages with fewer features. The current ones with attendant libraries that do everything are turning us all into "configurators" rather than programmers. Simple is best. Bring back the joy in writing code.

PS could we have a ban on any new languages? They are not needed. Besides I have only just got to grips with the ones that I regularly use! (ancient developer)

+John Sanders: Don't ask for a ban on new languages! If you're happy with the languages you already know, you don't need to learn a new one. But I really can't believe that there could never be a language that's substantially more productive and produces more maintainable code than the best languages we have now.

+Bill Long: you can incrementally add new features to an existing language, but it's much harder to incrementally remove old mis-features. For example, you could add automatic memory management as evolutionary improvement to FORTRAN 66, but it would be much harder to remove GOTO and COMMON sections. So if you have a big FORTRAN 66 system with deep-seated architectural problems, you need to either just live with them, or else completely re-engineer your system in a more modern language.

It's often not that hard to remove obsolete feature like GOTO (use block structured execution constructs) or COMMON (use modules instead). That might be a re-engineering of the code, but the more modern language you are migrating to is the modern version of Fortran, so parts of the code can be improved over time, rather than rewriting everything all at once. This sort of migration is quite common and successful.

It may not be hard to remove a feature from a program, but it often produces storms of protest if you remove a feature from a language, because that requires all uses of that feature to be removed immediately. Which is why languages tend to accrete features over time, but seldom remove them.

For example, Java made an early decision to treat primitive types differently from object types. Many more recent languages don't draw such a distinction, and now Java has automatic boxing and unboxing to try to reduce the inconvenience of this distinction. So how difficult do you think it would be for Java 9 to remove the primitive types from the language and only use the wrapper classes? Or remove the wrapper classes, and turn the primitive types into classes (and live with the inconsistency of having 8 standard class names begin with lower case letters)?

Competition for the best languages of the future can be determined essentially by the evolution of hardware models, which depend on technology. It is much less likely that a new language with superior features demonstrated in the laboratory, to impose a hardware architecture. It looks like that the hardware architectures, now in crisis of new ideas, have a trend, at least for a time, to move towards multi-cores. The next languages will be of success because of their ability to meet the requirements for use in the most efficient multi-core architecture models, due to concurrent programming. But the concurrency is not native to the languages like C / C + +, Java, Fortran. Here stands now, among others, a functional concurrent language competitor, Erlang. Someone even had the courage to call it "next Java". There are arguments that the Erlang programs are clearer, simpler, more compact and robust than those written in other languages, mainly those advantages come from the quality of functional language. The downside of having a more difficult assimilation for beginners at the early stages of learning of the language is outpaced by the ability to write complex applications with fewer errors.

Actually, concurrency is native to Fortran. It was added to the language syntax for exactly the reason you explained - that new hardware is all parallel. Fortran has both SMP ( do concurrent ... end do construct) and distributed memory SPMD parallelism built in.

Silicon based hardware and essentially boolean arithmetic based logic has driven the computational world so far. Now, there will be rise of quantum computing and hence new generation of programming language should include constructs to take full advantage of underlying hardware. It is pretty early to predict anything right now as far as feature set is concerned but momentum should go in this direction keeping the best of existing paradigm intact. I also echo the concern of complexity. And yes, we can expect next generation languages to become simpler. And the program may look more like short prose or poem in human languages (atleast as seen by programmer before translating to machine code).

If all you wish to used is concurrency. Then many languages have sufficient library extensions now. OpenMP, MPI, Clip/Blueprint, Tbb, Opencl, pthreads, Vector libraries (Altivec etc) Vectorisation (compiler option Intel) , Cilk etc. The future is beyond parallelism... and perhaps less deterministic ... for example, real-time environmentally orientated systems might need to handle associative interactions... what sort of language extensions might that need?

As it is, the easy access to compilers and testing options have made a lot of people to create more buggy and bad programs, due to the reduced need to spend more time thinking when writing code. If syntax is not right, compiler will tell... A self-repairing language will make it worse. One will only write the "main" function, and expect the self-repairing mechanisn to gradually fill in the whole code!

I also agree that most of "coding" today is just drag and drop. They should be called "designers", rather than "developers".

The challenge ahead is to build more power into the language to reduce the chances of errors cropping in (e.g. type definition and declaration made a lot of run time errors into compile time errors and therefore detected earlier and easier). As software size becomes larger and larger, and more softwares are built through integration of pieces than totally from scratch, we need the language to support such activities. Integration of modules across languages, platforms and OS could be supported in a native way. Code re-use is still a major challenge, despite much being talked about. Service oriented model of development offers what appears to be a reasonably good solution. But this is, now, a layer outside the language.

The trend to configuration rather than coding ignores the complexity overhead of understanding what it is you are configuring. There is a limit to code re-use. That limit is the same one for the drag n drop style of code development. Nor can ever increasing levels of language sophistication be immune to complexity overheads. These all are limiting factors - so whats to stop a computer-only solution? Needs and goals - computers don't have in the correct manner with which to write programs. It is all very well trying to insert a textual model of goals and needs but these need to match against the reality of the empirical domain. Perhaps you think we can create an artificial reality (MODEL) in which the feedback is totally consistent with our own real world. To do that would require programming beyond our levels of complexity management. The only way is to give the computer the same experience of sensed reality that we have, and this includes our nature, goals and needs. This might just be foolish? But we are now firmly in the world of so called artificial intelligence and that implies non-deterministic and unprovable. This then is the wrong paradigm for which computer languages were invented. There is a limit.

I am insure that today statement of programming (planning and create anything) is one of possible way of representation this activity by the help of programming language (the other way may be, so called, connectivity) is only a start point of more general activity of constructing human interface with the Reality (physical and virtual or mental of any nature ). Science research only supply the "hardware" are needed for this phenomena and its technical realizations.

Today theoretical research in this field include mainly the solving only the problem of one-to-one mapping specific of domain into the symbolic expressions and do not include of anything from such kind of problems.

And programming languages differ one from the another with the way of computational models of this mapping (for example: rvalue and lvalue in Phyton and C++ 11, mathaprogramming and methaclasses and so on)

It is clear that this interface must be able to include the main part of mathematical and physical sciences as an essential part.

Do you see any steps in this direction today?

New computing platforms are interrelated to their physical execution environment through all kinds of sensors that are able to measure location, orientation, movement, light, sound, temperature, network signal strength, battery charge level, and so forth. At the logical level, even traditional desktop and server platforms are getting exposed to richer environments in which they can find network services of all sorts. Both at the physical and logical levels, the live environment in which applications execute is acquiring a central role, and end-users expect their software systems to adapt gracefully to this changing environment. If equipped with higher levels of context-driven adaptability, software systems can become smarter with respect to their environment and to user needs, exhibit emergent properties, be resilient in the face of perturbations, and generally fit better in the technical ecosystem in which they are used.

Unfortunately, most software systems do not meet the high adaptability expectations that stem naturally from their connectedness to their environment. Most applications exhibit fixed functionality and are seldom aware of changing contexts to adapt their behaviour accordingly. Many chances of delivering improved services to users and network peers are thus missed. We believe that a major reason for this lack of adaptability is the unavailability of appropriate context-aware programming languages and related tool sets. Current programming technology does not put programmers in the right state of mind, nor does it provide adequate abstractions, to program context-aware applications.

Starting from this observation, Context-Oriented Programming (COP) is being researched as a novel programming paradigm which eases the development of adaptable behaviour according to changing contexts. COP offers an alternative to hard-coded conditional statements and special design patterns to encode context-dependent behaviour. By helping to avoid such statements, COP renders code more reusable and maintainable. Several research teams around the world have started to investigate context-oriented programming languages features or context-oriented extensions of existing languages.

I believe that the next generation of programming languages could benefit from having an explicit way of dealing with contextual adaptations and hope that such context-oriented features will be adopted and will appear in the next generations of programming languages.

You may want to start from here: http://golang.org/

and here:

https://groups.google.com/forum/?fromgroups=#!forum/golang-nuts

I have learned basics of Go within a week (and I am not a good programmer) :-)

HTH,

Peter.

Mind reading and intelligent code completion (generation) would be nice.

I would say, the next generation languages be geared towards running IN THE CLOUD. If you look at C, Java, Python, C#, they are all geared towards a PC (i.e., local). Best case, a cluster with an ADD-ONs like the MPI function calls, or OpenMP ... In all of these languages, the RESOURCES are VARIABLES, i.e., LOCAL ... also, TCP sockets, which are LOCAL (although they listen to packets in the LAN or WAN, they are strictly created and managed locally by API calls using the local OS). I can count many more features ... So, COMPILE-TIME resources are completely geared towards local ones ... Also, currently the RUNTIME is assumed to be handled by the OS which is LOCAL.

The next generation languages should significantly broaden the resources, and redefine variables, memory, disk, everything to be CLOUD-WIDE resources, not just local. Although the distinction between LOCAL and CLOUD-WIDE should be fairly visible to the programmer, the connections should be seamless ...

Although this functionality exists right now with massive add-ons, it should be an integrated part of the language.

Also, the OS that is executing your PROGRAM should be a CLOUD-WIDE OS, not just a computer-wide one ... I should be able to bring in heavily distributed resources as if they are local, and define them as ridiculously easily as CL1=New.Cloud; Threads should be easily allocated cloud-wide, as well as data.

This is the only way we will be able to beat BIG DATA. Otherwise, we will be eaten alive by the DATA-ZILLA . !!!

We expect simply genetic programming language

Just intelligent programming language

Because we don't wanna to start once again from alphabets

Kadal, I definitely think so ... If you look at what C# is , it is very much like C, with many useful features integrated into the language. I think C# could be expanded to include cloud features ...

The ability to access memory associated with remote processors is already embedded in PGAS languages (mainly Fortran and UPC, though C++ template libraries also exist). MPI conceptually supports the same ability. The same code could run in the CLOUD without source changes, although changes in the underlying run time libraries and program launching mechanism would be needed.

So, why is this not already common, particularly for BIG DATA problems? Partly because the memory sizes in large (local) systems are quite large already, and could be expanded further by using local disks as pseudo-memory. Even paging out to disk is dramatically faster than CLOUD accesses. Accessing remote data on a CLOUD system involves truly horrible performance in both latency and bandwidth. With enough money or technology breakthroughs the bandwidth problem could be addressed. But the latency problem is bound by speed-of-light limits, and hence unsolvable. To compensate, the code would have the be written to be extremely latency tolerant. That is possible for some algorithms, including some used in the BIG DATA area. And latency-tolerant variants of C have been developed for this purpose. But for most problems, at least in scientific computing, this is sort of algorithm redesign is not practical. So, I'm not convinced that this is the key feature for "next generation programming languages" in general.