Future Of Programming Languages

There are several pages (FutureOfSmalltalk, FutureOfJava) discussing what may come to the aforementioned languages in the future.

Here, we get to stick our fingers in the air, and engage in wild speculation (or informed prediction) as to what the future will be like for programming languages in general. (And this can include things that are decidedly non-traditional; a "programming language" can include any way that a human programs a computer, not just the sorts of things we commonly think of today...)

Each person, submit their thoughts in their own section.

The most one can expect from a GeneralPurposeProgrammingLanguage is for it to become unobtrusive. -- adapted from a quote at LambdaTheUltimate

It may be that the most we can hope for from the language itself (not considering community and development environment) is for it to not get in the way of our work. There is a certain amount of EssentialComplexity in our work. No matter how good or how high-level the language, we as programmers and software engineers will be left with the tasks of figuring out what to say and how to say it. And, chances are, even if we have ConstraintLogicProgramming and GoalBasedProgramming among our programming staples, we're still likely to need to spend time saying how or what it means to go about doing what we said to do. The job of the programming language is to reduce as much AccidentalComplexity as possible, leaving us with a high EssentialComplexity/(EssentialComplexity + AccidentalComplexity) ratio, and keeping this ratio high even as NonFunctionalRequirements increase.

That ratio is quite low today; there are a great many causes of AccidentalComplexity left that 'obtrude' on our programming: Violations of OnceAndOnlyOnce are forced by lack of value composition (forcing repeated parameter groups), lack of implicit context (forcing threading of context parameters... see ExplicitManagementOfImplicitContext), lack of pattern-matching (forcing repeated efforts at value decomposition, lack of modularity or extensibility (forcing efforts to be repeated in combinatorial variations for each project). We are also forced to consider details below our immediate level of concern to meet various NFRs imposed by the environment such as resource management (file-descriptors, memory), optimizations, security, safe concurrency, realtime, etc. Often we must make irrelevant decisions, such as naming small one-off functions in languages that lack first-class functions. Sometimes we find the language obtrusive if it doesn't give us enough access to the low-level actions (e.g. to interface with new hardware). Many programming languages force us to write all sorts of boiler-plate code once per project to perform initialization and destruction, to interface with frameworks, etc.

Most of these problems are resolvable, but tackling them all in one language is far from trivial.

In any case, the LanguageOfTheFuture will be unobtrusive.

The following prediction is offered up for the near future (the next 10-20 years or so). Beyond that and we start getting into the realm of ScienceFiction - which isn't bad, but that's extrapolating the curve well beyond the dataset.

-- ScottJohnson (with other contributors)

The language of the future will be the OS of the future. After all, the LanguageIsAnOs. It will need to support highly distributed and concurrent programming, and should support both very low level (bit manipulation) and very high level things (e.g. functors on coinductive types, artificial intelligence, object browsers, etc.)

I'm not sure all of these features in one language would be all that good an idea.(*) Things might begin to get cluttered. However, I don't like the idea of offloading everything to libraries. Maybe the LanguageOfTheFuture will have a macro system similar to Lisp's (RealMacros), and a library of standard "language extensions" that would allow you to pick and choose what you wanted. This way, the language itself could remain uncluttered, and you wouldn't need to worry about things that you didn't need. -- DaveFayram

(*) I contrarly think we can unify everything from low level to high level, and it is still feasible as a bit or a byte may well be conceptualized as objects. However, and this is where the language and the compiler have much to do, if I use objects to describe my bits, bytes, registers, etc., the resulting code should not add objects layers to the compiled code but should give a clean code that fits tight the processor language -- ColinLorrain?

Scott, it's like you read my mind. :-) -- DougMerritt

Me too! -- RobertChurch

Eventually, the language of the future will evolve beyond edit-compile-run-debug and move in a to commercial special-purpose systems like VB and LabView - programming in which the procedural and declarative code may not be in pure text form (in VbClassic, the declarative code is graphical, while in GeeLanguage of LabView, the procedural code is graphical).

As the need for hyperthreading code becomes more apparent, traditional procedural coding will become unviable because of the panic of concurrency issues. Languages that have easy, intelligent threading metaphors will be successful. Likely the compiler will handle determining where to spawn new threads and where to couple coroutines and repeated deadlocks into a single thread. Ultimately, the solution will resemble GeeLanguage, where any function that returns or passes-through more than one value is effectively creating a pseudo-thread, however the thread may not physically exist if all of the return values simply rendezvous into another function call or concurrency check. Spawning a thread will be as simple as forking a variable path. The language will support traditional text-based logic for places where it is appropriate (eg. arithmetic) which will be abused by hold-outs. High-power IDEs will become more necessary, as edit-time coupling to live systems (such as DB tables) will help automated code-maintainers keep tabs on the compatibility of the access templates to the structure. Such mapping will effectively make databases work as native members of the language, with database queries being indistinguishable from template-style function calls, and databases simply handled as objects with tables handled as inner-classes.

Top-level meta-programming concepts will be handled as local extensions to the IDE, similar to a hybrid of VB Visual Studio macros and FireFox extensions, except not executed at compile-time but instead always-on (like the .NET properties editor). These IDE extensions will be managed as part of the project, within the project's namespace.

Typing will be static, but the system will be pleasant enough that nobody will notice (as in: not Java) - as much inferencing as possible is done, with declarations or dynamic typing available where inferencing is impossible. Exception specifications will exist as auto-generated metadata instead of hand-written code, where they belong.

The language/IDE/platform will initially be implemented proprietarily, however in the interests of capturing the diverging market it will have the spec opened up and it will be cloned by opensource nerds.

Non-deterministic garbage-collection-as-panacea will fade from popularity as coders get sick of bloated "finally" blocks and inapplicability for high-performance, resource-limited, or real-time purposes. Instead, objects will be optionally instantiated into the collector, or onto the pseudo-stack, which will allow for handling similar to an auto_ptr with WeakReferences? for use in the place of pointers.

Because code-maintenace/generation is handled with IDE tool assistance, the traditional subclassing of implementation will disappear, except as just one more tool. This will be replaced with a system of template-style code-generation combined with mixins, ultimately implementing the desired classes interface (and most classes will be declared as a substitutable form, in which all methods are virtual and the class need only be replaced by another class that implements the same interface, not necessarily a direct subclass).

Most filetypes will die in favour of NimbleDatabases?.

And everyone will bitch about how much better Python was.

-- MartinZarate

How far into the future do you want to look?

Given enough time, I predict this:

The language of the future will be so unlike any of the languages that we know, that it's syntax will not be familiar to any of us. It will be difficult for any programmer today to identify source code in the future language, (if it will have anything that could be called source code). While actual text will likely still appear somewhere within what could be called the source code, the vast majority of the source will not be text, but something else. As a backwards compatibility feature, it might contain a tool to represent code as text, but that tool will not be able to represent *all* of the code, and will likely not be accurate on most of the code.

The language will be so different from everything we know that questions such as "is this language OO or functional" will be moot. Some activities will seem like OO programming and some like functional programming, but the similarities will be so slight that we would find it difficult to recognize them as such. The problems and the important issues related to programming languages in the future will be such that (1) people programming today will not be able to recognize them as issues and (2) we likely will not understand the differences between point of views on what the issues are.

There will be a way to check correctness and verify suitability for a purpose. But it may not (and ultimately probably will not) require anything like the writing of test cases that we do today.

Computers will likely play a much larger and much more active role in programming. Humans will likely do a whole lot less, and computers a whole lot more. We will manage to automate away most of what we already do. Of course. But do you have any idea what sort of 'scripts' we'll be writing to accomplish this? You've written the basis for your run-of-the-mill 300 page pop-programming book, but an example, just a rough idea even, would take up a lot less space.

AlexAusch?

In future SovietRussia?, source code is you!

Even if you are right, it is supremely unhelpful to say "the future is ineffable". How does that help? Pull your horizon in close enough, to the point where there is something to talk about.

Your final paragraph, saying that more will be automated, is less vague but also not exactly a risky prediction. More automation? Of course.

And don't be so sure of what can and can't be imagined. I've been reading ScienceFiction for decades; it has expanded the limits of my imagination considerably. :-)

-- DougMerritt

I'm not sure the future of programming languages is even a "language." I imagine that we'll be connecting components on a bus architecture. We'll rely on visualization, because the layout of the code will be much more schematic than it has been. ... -- LionKimbro

(moved to GraphicalProgrammingLanguage)

I'm going to be contrary, and say that the primary representation of programming will continue to be textual, though there may be visual views that are useful in certain circumstances or other alternate views. ... wild visualizations that may even be helpful; my point is not that no visualization progress will happen but that for serious programmers, the text representation will continue to be the "real program".

...

I'm not sure the world needs any more programming languages!

Do I give you a hard time about your interests?

So OK - maybe I just haven't fallen in love with one yet :-) -- pm

(moved to GraphicalProgrammingLanguage)

Sensafrustration: looking at the various lists of requirements, I am struck by how many of them are provided by FlowBasedProgramming: Ron's "melting pot"; connecting components on a bus architecture; GraphicalProgramming; nice simple, safe, multithreading model (so I've been told); black boxes with clean interfaces between them (data); mini-languages. You could theoretically write components using FunctionalProgramming (see http://www.jpaulmorrison.com/fbp/recurs.htm). IMO any sequential coding technique can be used within (as) a single FBP component, so FBP adds an additional dimension, and doesn't take away any functionality. Could it be that we already have the LanguageOfTheFuture, and it's been around all this time, waiting to be noticed?! -- PaulMorrison

Of course we have the LanguageOfTheFuture already, in fact, many of them. That's what makes it so uninteresting to talk about the features of the LanguageOfTheFuture, rather than the FutureOfProgrammingLanguages. -- PanuKalliokoski

Two realizations have happened over the past decade or so:

1. Managed, VM-run code is good.

2. The language and the implementation should be identical.

The first point is that `managed' (poorly defined, that), VM layers *can* be good. The second point is just wrong.

Two fights that are and will continue to be ongoing:

1. DynamicTyping vs. StaticTyping

2. OpenSource vs. Proprietary

Interestingly, the two left-hand choices tend to correlate, as do the two right-hand ones.

Why is that?

[Possibly because StaticTyping works well in a corporate environment with lots of programmers, exactly the type of organization that can afford to pay someone to develop a language. DynamicTyping works well for one-man (or small group) hacker projects, exactly the type of people who want their languages to be OpenSource. -- JonathanTang]

SoftTyping gives a possible resolution for 1. There are some technical difficulties with doing TypeInference in a multi-language VM, but they are not insoluble. -- DavidSarahHopwood

Right now we've got two major closed-source runtime platforms targeted at StaticTyping languages (DotNet, JavaPlatform) and one OSS clone (Mono); there will be a couple of more OpenSource contenders in a few years, and the proprietary ones will continue to evolve. Languages will tend to group themselves around one VM or the other. VM holy wars will largely replace language holy wars.

[[No way: you're ignoring the power of good languages to infiltrate niches. Python's already good on the JVM (and the PSF is financing a project to make it even better), and Jim Hugunin (who once initiated Jython, i.e., Python for the JVM) was hired last summer into Microsoft's DotNet Common Language Runtime (CLR) group on the strength of his IronPython (Python for .NET) prototype, to make DotNet even better for dynamic languages. Meanwhile, the Parrot VM is targeting Python too, not to mention PyPy. Python will keep being everywhere; often just outside the blinkered sight of management, sure, but doing its highly pragmatic job nevertheless! -- AlexMartelli]]

Languages clustered around one platform will come to resemble one another more and more: if Bloop has continuations but Floop doesn't, and they both run primarily on the Gurgle VM, it will be easier to port continuations to Floop. It may not be elegant, but it'll be ported. OOP has already become well or poorly integrated into just about every language; FunctionalProgramming idioms are following and will continue to follow.

I'd say the major innovation in terms of actual features will be increasingly refined syntax for dealing with heavily structured data: e.g. XML. It's already there, but it can be better integrated; just as dictionaries and even strings used to be considered wild and crazy datatypes, so XML-type parsing will move toward the center of basic language features.

[[Please... XML is overhyped crap! The languages of the future are already here... Lisp and SmallTalk, everything else is just a re-implementation of those.]]

That's why I said "XML-type". It's not the ideal implementation of what it does. It may or may not be the final mainstream implementation of it.

SemanticSubtyping is an interesting approach along these lines. The current implementations XDuce and CeDuce are targeted at XML, but it applies equally to other data models like EssExpressions and TermTrees?. -- DavidSarahHopwood

I'm going to do two lists, one for my ideal future and one for the future I think will actually come to pass:

In which reality bends to my wishes:

All of these points except the last are compatible with each other. I'm unconvinced that being able to interoperate seamlessly with some existing languages, such as C or C++, is compatible with the rest. To do that you might have to support only restricted dialects of C/C++, and it is not clear that this would be accepted by most C/C++ programmers, or that it is worth the effort. -- DavidSarahHopwood

In which I face the grim facts:

-- JonathanTang

We shall all be using the Language Of The Future by 2075, because by then Perl 6 will have been released. -- EarleMartin

"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." -- Tony Hoare [CarHoare], apparently on a card distributed during the 1982 AFIPS National Computing Conference.

But if there was any single "language of the year 2000", it wasn't called Fortran.

Simple: The language of the future will have all the HolyWar features I like, and banish those that I don't. -- FillInTheBlankWeenie?

In the future, we'll take RichText? and extend the concept to RichSource (see IntentionalProgramming). You'll be able to freely mix the source code, comments, graphics, and the Graphical UI parts of the program in one non-ASCII document.

Why non-ASCII? Wouldn't an XML application suffice for such a thing? While I wouldn't want to hand-edit such a beast on a regular basis; there are many reasons that PowerOfPlainText should be considered.

Or, we could use EssExpressions rather than XML (since XmlIsaPoorCopyOfEssExpressions).

You'll then work with a BidirectionalCompiler, which will allow you to view and edit the symbol table, resulting in automatic updates to the source. (In essence, a RefactoringBrowser on steroids) It'll make debugging a bit easier too. -- MikeWarot

[Finding the existing terminology to fit my internal GrandVision is proving to be much tougher than I thought]

The language of the future will be like a chemist's version of AssemblyLanguage, because we'll mainly be programming nanomachines, and the available resources and sophistication of the CPU will once again be sparse. Farther in the future, we'll figure out new and entirely different high-level languages to simplify the task.

Without looking (much) at the other entries:

Short term:

Long term: Having now read some of the other entries: -- PanuKalliokoski

The things which a future programming language could provide -

  1. Semantic clarity
  2. Database Independence
  3. User Interface Independence
  4. Communication Interface Independence
  5. Evolutionary Development - needs based - when you need it, find it and use it, or build it.
  6. Introspection - the ability to produce alternate views of 'source code' - the ability to extract relevant information from the code.
  7. Ecumenism - allowing pragmatic inclusion of other languages.

I believe that fulfilling these requirements means that whatever form the future languages take, it will be simpler than now.

And the first element in a list of items will be referred to as position 1, not offset 0.

Blech. <http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html>

And a comparison will return true when the first and only element of an array is equal to a scalar element. 

   {"Spade"} = "Spade"
   {""} = ""             ; * An empty array is equal to null
-- PeterLynch

I expect that type checking will be moved from compilers in the future. But that is only my opinion. The current paradigm is still that the type checking at compile time is beneficial, so from that perspective, OK, I see why you would object to comparing apples to oranges. But these are Tools, in the dataset named "Tools", and "Spade" is one of them. When I compare a bag containing a Spade to a Spade, in terms of Tools, I have equality. A Spade in one hand, and a Spade in the other.

The examples above are more about Singularity/Plurality than Datatyped or not Datatyped. In a future language, I can imagine atoms becoming arrays when the second value is entered. Plurality, like lists, will be a natural consequence of the operations performed.

Because I have used MultiValued languages, I see this differently. Plurality and Singularity are separate from datatypes. Any Datatype can be stored in singular or plural form. An item becomes plural when it contains more than one element. It may be a member of a plural data base column, but if the item within the instance has only one value, and that value is the first value, then it is an atomic value. 

  a = "Dog"
  b = ""     ; * Initialize b to the null string
  b<1> = "Dog"  ; * Set the first element of b to "Dog"
  Print a
"Dog" 
  Print b<1>
"Dog" 
  Print b
"Dog" 
  Print a = b
True 
  Print b<2>
"" (Null)

That's PickBasic, son! It's been "usefully" dead for quite a few years now.

I think this problem is to do with semantics. It is not possible to compare an apple with a banana, but conventional languages accept that you may want to. Typecast is the mechanism. 
 I read the statement -
    If a = b
 as "If the contents of a are the same as the contents of b".
 The above example is consistent with that view.
There is something I don't understand about this argument. You're talking about the fundamental difference there is (or there is not) between a lion and a lion in a cage. Great, sounds funny. But [Lion] is NOT a lion in a cage; it is a cage that happens to contain a lion. It could contain something else, or nothing. You can feed a lion, you can open a cage, but I wouldn't recommend to open a lion, and feeding a cage could be an interesting experience. In short, I can imagine a call to [Lion].open(), I can imagine a call to Lion.feed(), but Lion.open() is just plain nonsense! -- PhilippeDetournay

Other than a vet, I see no reason to want to open a lion. Whatever programmer tried to open a lion should have been ignored (open could do nothing), or maybe fired.

AIUI, this is inspired by the treatment APL, Matlab, *Lisp, and similar auto-parallelising languages use - although I think it takes the idea a little too far, as you want to be able to operate on the collection as a whole (or a set of dimensions from it, since the LanguageOfTheFuture will have native multidimensional collections, I think, at least for array-like collections), and the runtime need to be able to tell whether you're looking at the object itself or a reference for the sake of core functions (especially reduce... functions). I'm a strong believer in exposing the runtime to the application (or, in practice, to the libraries, perhaps like LaTeX does it with @-commands but more elegantly).

I suggest that in the future no human will write code. It will be done by the machine. AS we move onwards and compilers become better and allow for more abstraction and as we build more and more intelligence into the compilers you will achieve the StarTrek "Computer - show me the status of the ship". The computer will then work out what you mean and deliver the information. Programmers will no longer be required as programs will write programs.

But see TeachMeToSmoke.

I was going to say the same thing, well I didn't hope for such help as StarTrek computer, because that also "thinks", creates holograms that can come out of the special room etc, but at least I would like to say "make a loop here" or even better "extract this interface and make an abstract base class with this and that", a sort of "junior developer" that can implement most of what you say you would like to without hating you. -- MicheleVivoda?

It is amazing how close this page comes to the ideas of LanguageOrientedProgramming as described in http://www.onboard.jetbrains.com/articles/04/10/lop/.

I see a possibility for macro contraction, or other forms of idiom translation. People love and/or hate macros because you can end up programming in your own custom language. What if when I got a piece of code from someone else, I could expand all the macros that were somehow designated as part of the author's personal set, rather than specific to the problem domain. Then I run a macro contraction tool to replace matching code with my personal macros. Probably bored compiler optimizers would be the best candidates for writing this tool.

You know, there might be the germ of a great idea here - I am starting to get fed up with all the different ways of saying, e.g. while (for, do while), break vs. leave, etc. After a bit, all the languages run together in my head! So, if we could come up with an Esperanto of programming languages, everyone could translate them into their favorite syntactic sugar! I know, we'd still have to agree on the Esperanto... Oh well...

That sounds very much like Syn:

I hope for some SeparateMeaningFromPresentation. Thus whether a language uses semi-colons or not or uses curly-braces instead of end-x syntax may be a personal choice such that the view can be altered for personal preference. -- top

This topic has also been talked about at LambdaTheUltimate: 

  http://lambda-the-ultimate.org/node/687
Of interest is in particular the comment by FrankAtanassow?: SomeWordsOfAdviceOnLanguageDesign.

Repeated interest in JulyZeroFive

See also PerfectLanguage, IssuesForLanguageDesigners, QuestForThePerfectLanguage, ProgrammingParadigm, LanguageTrends, LetsDesignProgrammingLanguage, IdealProgrammingLanguage

CategoryProgrammingLanguage

EditText of this page (last edited November 8, 2014) or FindPage with title or text search