Ask HN: The future of programming languages?

Topics that I think will be important:<p><pre><code> - Functional Programming - Logic Programming - Managing asynchronicity - Managing concurrency / Managing state - Pruning bad directions in OO (see the first two) - Type Systems - Virtual Machines </code></pre> Languages/technologies that I would look at more closely given these are Haskell, Scheme, Prolog, Clojure, Qi, LLVM. I love JS but as far languages go, I would not look there for new ideas. At best I see it becoming a fantastic compile target.<p>I also don't see Haskell and Clojure being particularly specialized. They are very general purpose and suitable for tackling any kind of programming problem - simple to complex, JS on the other hand is a language with a <i>very specific</i> focus.<p>I don't see the importance of being able to read and understand C/C++ diminishing anytime soon as those languages are intimately tied to our operating systems.<p>EDIT 2: I added Type Systems above. I think Haskell has shown the power of an expressive type system. However it has it's problems. I look forward to see the distinction between languages w/ strong type systems and those without being abolished. Languages should support turning the type system on and off - see Qi. Type systems also should allow the typing of a much richer set of values - Qi's sequent calculus types is eye-opening in this regard.<p>EDIT: I'm opinionated about this, but the constant announcement of new languages that simply continue the traditional stateful OO paradigms (perhaps tacking on a couple of syntactic niceties or a crippled static type system) seem like complete dead ends.

Decades ago, lots of programming languages were created that hardly anybody knows now, including some that would definitely be considered very specific, research-oriented, etc. This isn't really a new thing. See for example Jean Sammet's _Programming Languages: History and Fundamentals_.<p>Edit: Bergin &#38; Gibson's _History of Programming Languages, Volume 2_ is pretty good, too, but that one covers more recent languages: Prolog, C, Forth, Lisp, Icon, etc.<p>It's not a bad idea to read about old experimental designs, particularly those that didn't work out because of limited hardware. I think there's a lot of potential in the APL and concurrent / constraint logic programming families.

A lot of research has not made its way into any language yet. In particular, the data models and optimizers of current languages are woefully inadequate. Most mainstream programming languages are still in their infancy, being nothing more than glorified assembly.<p>The future will be more about declarative programming - write down a mental model of the program, and the language/compiler will do the rest. A simple restricted example is SQL - you write what data you want and the optimizer figures out the best "program" for the query, using even genetic optimization in the case of PostgreSQL. Another example is data binding - you write down what data connects to what part of the GUI, and the framework figures out what to update and when. The problem with SQL, data binding etc. is that they are not tightly integrated into a general purpose language, and do not have clear theoretical underpinnings.<p>A good language will have simple, compact theories and abstractions as general as possible to reduce the mental baggage necessary for programming - instead of remembering hunders of special cases, you should only work with a couple of general constructs.<p>Optimizers for these languages will have to be far more advanced - remember state between compilations to reduce the impact of whole program optimization, have advanced specialization and type checking capabilities using abstract interpretation etc.<p>Data models will have to grow too - they will have to be high-level and low-level at the same time to cope with the onslaught of data. The semantic web provides a fairly universal data model with RDF/OWL, but this again could be simplified and abstracted. A data model should also have the capability to specify the physical layout of the data down to the bits, but also at the higher level, such as distribution between disks and machines. Ah, finishing now to avoid tl;dr.

I for one wish that implementations of future languages provide the following features a) Some extension mechanism for the language like clos etc, where hooks are provided for executing code. b) Code walkers c) Documentation about the internals. I dont mind the language implementation being a tad slower because of simplicity but in the core has to be grokkable and extensible by the end programmer.<p>Existing languages suffice for most easy problems. For the hard problems that ive been tackling lately ive wished I could overcome some logical impedance between what I am doing and the language in a sane way. A few examples where additional flexibility would help a) Opengl is a state machine. Being able to take the graph of my program and write assertions that critical setup functions are called before other GL functions would help detect invalid logical states. b) Before, after functions (which exist in lisp) would be nice. EDIT: c) Being able to say -&#62; for all objects in in my program that match this criteria, do something. Essentially -&#62; for x in criteria(primitives(program)) do foo.<p>EDIT: A common thread to all the times I feel trapped as a programmer is when I have a knowledge of the meaning of my program which I want to express, or perhaps a question about its existing implementation which I would like answered. Many languages lack the introspective power to help me as a programmer to tackle these situations. Others simply make it inconvenient to do so.

I think VMs are the future of application programming, especially as manufacturers become more amenable to using "unconventional" architectures like ARM to host full-featured computers. LLVM, the JVM and the CLR all have benefits- I don't see any reason to believe there will be a convergence in the near future.<p>Environments like .Net and the JVM stack will slowly allow tighter and finer-grained interoperability of the languages they host. We currently have class-level blending of languages, and in the future we will probably see method-level blending. The best DSL for the job.

I think (hope?) that the next wave in hacking will be understanding programming paradigms better as hackers - the specifics of language choice will probably matter a little less. I like the idea of languages that support multiple paradigms internally (e.g., you can embed logic programming into your functional programming language). A while back I spent some time reading Concepts, Techniques, and Models of Computer Programming and I wish I had found this book earlier in my career. I probably wasn't ready for it though.<p>This aspect of software development was largely missing from my formal educational experience in programming language paradigms.<p>What I am trying to do now is develop a better "taste" for what is "easy" using one programming paradigm compared to another. I'd ultimately like to have a better problem to paradigm mapping internalized. I've toyed with the idea of putting together a seminar or undergrad course to do flesh this out.<p>The elephant in the room is more market based - what programming languages will someone pay you to use in the future? We already have a number of interesting programming languages. But when you do your job search these days, I see a small number of large buckets. The .Net/CLR C# world, Java in the enterprise, Ruby (really the Rails framework, but even so), and a strong side of the data storage backend of your choice (RDBMs or NoSQL or sexps - kidding on that, pg keeps our own forum in files full of sexps).

I think that eventually some programming tasks will become highly specialized, yes, and use custom and very specific languages depending on the field and the problem at hand and may end up with their own degree programs, etc. There's already hints of this sort of thing right now. It's very hard to transplant a programmer from (for example) web development to 3D game engine development - it has nothing to do with language, though. There's just a huge set of knowledge required for each that has very little overlap - even if the languages used happened to currently be the same in some cases.<p>It doesn't make sense to forever expend the effort required to force every problem into just a handful of languages' structures - even if it is theoretically possible to do so.<p>I think that things like OMeta (<a href="http://tinlizzie.org/ometa/" rel="nofollow">http://tinlizzie.org/ometa/</a>) are an important piece and the other work being done by Viewpoints Research (<a href="http://www.viewpointsresearch.org" rel="nofollow">http://www.viewpointsresearch.org</a>) could help.

Aside from programming paradigms, my frankensteinian view of the future is as follow: Javascript VMs become so good, other languages start being built on top of it. The future V8/Rhino... instead of JVM for new languages.<p>I can certainly see Clojure in JS pretty soon. This might be wishful thinking on my part (see bellow for why).<p>"Will game development ever diversify or will it go from C++ to C# to ..."<p>Yes, WebGL is in my view a game changer (pun intended). I'm pretty bias considering I use it currently a lot. But I'm replacing scientific application in C++ with WebGL version online.<p>Finally, I don't see a slow down in new languages popping up any time soon. I think it's important that they can run on some generic VMs to allow for multi language apps to be possible.

I really hope that game and other performance-dependent development moves to Go or something like it, rather than being stuck in C/C++ land.<p>The advantages of modern syntax design coupled with a fast native compiler would be a potent and exciting mix.

For game development, I think it will diversify with the increasing ease of developing and selling indie games that do well. There are lots of languages getting perfectly good game development libraries that can definitely be used for the (often simple looking) indie game market.<p>However I don't think the big players in the industry will be able to. To deliver games of great scale (WoW) or intense graphics/effects you're going to need something that can deliver the absolute best performance.

The world is already filled with hundreds (and probably thousands) of programming languages, most of them fantastic in one way or the other.<p>Some people will prefer to stick to one language, some will dabble in others, but... most of the time, if the language is not radically different from everything you knew before, learning a new one isn't that hard.<p>I don't see this pattern changing in the foreseeable future. I mean, some areas always had their niche programming languages (heck, most areas do, anyway).

The language of the future is Lisp. always has been, always will be. (which is a shame, because APL and its children J and K would be a better foundation).

As Sir A. C. Clarke said (or at least to paraphrase)-- predicting the future is at best a crap shoot. That said I know what I'd like to see. As suggested elsewhere, much of what we see in 'new' languages is syntactic sugar bolted on to existing approaches; new on the outside, same old on the inside. I'd like to suggest that, that is not necessarily a bad thing. Consider what 'syntactic sugar' is--- a tweak or rephrase of an older approach to accomplish some task in the language in question. What if these were recognized as less sugar and more substance. The purpose of a computer language is to communicate with the computer first, innocent bystanders second. SS preserves the one and enhances the second, a win-win if you will. I'd like to see a language designed from the bottom up with that approach in mind. See if we can't come up with something that more clearly bridges the gap between programmer and machine. By now we know the variety of things that should be built in, now lets concentrate on the interface...

I think we'll see greater use of type-inference in statically typed languages. I hope that we get rid of the "kinda strong" type systems (like C++). While I appreciate the convenience of such type systems, I think greater type safety is a worth the trade-off.

Ok, I thought it was interesting enough to do my own take on it:<p><a href="http://journal.dedasys.com/2010/11/10/the-future-of-programming-languages-economics" rel="nofollow">http://journal.dedasys.com/2010/11/10/the-future-of-programm...</a>

I don't know how the future of programming language will be, but I hope functional programming will take over the world, more and more people will try to prove their algorithms are correct (with Coq, for exemample) and cool type systems like System F or Dependent Types will be used more.

The trend of niche-languages (e.g. Objective-C for iPhone) isn't actually a new trend. For example the high performance computing (HPC) community uses Fortran nearly exclusively for decades. The number of niches increases, though, so i expect further diversification of languages. E.g. game development is not C++/C# only. Most games include at least a scripting language (Lua, Python, Javascript) and many feature some online league, which may be implemented with typical web languages (Java,PHP,Python,Ruby,...)<p>In terms of programming language features i expect the next hot topics to be:<p>Dependent types, however, the question, whether a type system should be turing-complete is not answered yet.<p>Optional types for dynamically typed languages. Common Lisp had this for centuries of course, but now Python introduced the syntax and Clojure etc. also support this.<p>Various mixes of concurrency related concepts. There are lots of ideas currently (see X10, Clojure, Go, D, Haskell, ...), but no sweet spot is found yet.

Mandatory: <a href="http://paulgraham.com/hundred.html" rel="nofollow">http://paulgraham.com/hundred.html</a><p>And the... result: <a href="http://arclanguage.com/" rel="nofollow">http://arclanguage.com/</a>

The language(s) of future will be fifth generation languages. Current languages are not able to support more than 100M lines of code in one project and more than 10-20 years of continuous development.<p>In future, we will have something like that:<p>#... We are wrote large project using HTML7, but HTML8 is just released ...<p>$ spm update<p>...<p>12826 source files will be updated, 2324 new source files will be added, 343 source files will be deleted. Proceed? [Y/n] y<p>...<p>Done<p>#... OK, let continue our development ...<p>PS.<p>I have demo. I hate developing in any 3/4GL language now. :-)