
Ask HN: The future of programming languages? - ique
I've been thinking a lot about programming languages lately and I wonder what you guys think about what the future of programming will be.<p>Considering the amount of "new" languages(/dialects) popping up (Clojure) and some languages find new popularity (JS) I wonder how they'll be used.<p>It feels to me like languages are getting more problem specific, I.E. Haskell, Clojure and other functional languages get most attention for research and heavy calculation while some stuff get specialized for web-usage.<p>Will the future of programming be like science; where people get extremely specialized on a small set of problems, or will programmers learn multiple languages and use the best one for the problem at hand?<p>Will game development ever diversify or will it go from C++ to C# to ...<p>How do you view a future world filled with hundreds or thousands of fantastic programming languages?
======
swannodette
Topics that I think will be important:

    
    
      - Functional Programming
      - Logic Programming
      - Managing asynchronicity
      - Managing concurrency / Managing state
      - Pruning bad directions in OO (see the first two)
      - Type Systems
      - Virtual Machines
    

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.

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 _very specific_
focus.

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.

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.

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.

~~~
ggchappell
Both your list and your comments look good, generally, but I have to wonder
about your mention of logic programming.

I think logic programming has a lot to offer the world, in theory, but in
practice it seems to be pretty much dead. True, there is probably more going
on with Prolog now than, say, a decade ago. But widespread use is not
happening, nor is inclusion of logic-programming features into other
languages. Further, I don't see this changing in any truly significant way in
the near future.

Apparently, you _do_ see it changing. Would you care to comment on that?

~~~
silentbicycle
Two visible things to come out of logic programming are Erlang and constraint
programming. Both are very significant, in their own niches.

I don't think Prolog is dead yet, either.

~~~
EdiX
Erlang is not a logic programming language. They started with a logic
programming language and eventually removed every feature that made it a logic
programming language.

~~~
gtani
Correct, what's left in erlang from prolog is the pattern matching syntax for
function definition, where you have multiple clauses to test, sequentially,
whether runtime args match the number and types of parameters in each clause
(and values, if guards are used). No unification/backtrackig involved.

------
silentbicycle
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_.

Edit: Bergin & 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.

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.

~~~
dman
Thanks for the references. I just wanted to take this opportunity to thank you
in general for the high quality of your posts.

~~~
silentbicycle
Thanks. My academic background is in historical research, so I take references
pretty seriously. :)

------
jaen
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.

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.

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.

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.

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.

------
dman
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.

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 -> for all objects in in my program that
match this criteria, do something. Essentially -> for x in
criteria(primitives(program)) do foo.

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.

------
RodgerTheGreat
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.

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.

~~~
silentbicycle
Those VM designs are pretty heavily skewed towards class-based OO languages,
though. Most VMs have some kind of behavior (polymorphic method lookup,
unification, message-passing) that they do very efficiently because of the
language they target, but others are omitted. For example, it isn't possible
to do real tail-call optimization on the JVM without a trampoline, AFAIK. If
it had been created for (say) ML, TCO would be a given, but OO stuff would be
an afterthought.

The Erlang VM is another interesting platform, albeit one heavily skewed
towards fault tolerance, concurrency, message passing, etc.

~~~
dataangel
LLVM is not skewed that way.

~~~
silentbicycle
Very true.

------
tom_b
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.

This aspect of software development was largely missing from my formal
educational experience in programming language paradigms.

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.

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).

~~~
rbranson
I'm surprised you included Rails in that list. While there are quite a few
Rails jobs, it pales in comparison to what's available for .NET and J2EE. Even
PHP blows it away by pure number of jobs.

~~~
tom_b
You know, you're right. Probably a sign of spending more time on HN and
peeking around my local community of devs that reflection of a larger trend.

A quick look around found that Java, C++, C#, javascript, and perl (?) are big
in job listing at Dice.com right now.
[http://duartes.org/gustavo/blog/post/programming-language-
jo...](http://duartes.org/gustavo/blog/post/programming-language-jobs-and-
trends)

And the always friendly tiobe index at
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)
is useful when thinking about current programming language trends.

~~~
rbranson
Unfortunately those search queries are worse than "ballpark" figures as
they're mostly based on keyword matching, not the amount of code the developer
is writing in that language for that job.

There are certain search queries that will always hit high. Of course,
JavaScript is going to be in almost any job posting that's web-related, even
if it's not true hardcore JS coding. Perl is used heavily for development
automation, so it's also going to have a big showing, even if it isn't the
core language. You'll also tend to see lines like "Previous scripting
experience with Perl, Python, Ruby a plus" for Java postings.

If it could be monetized, doing more sophisticated data mining into job
postings for actual popularity trends would be awesome, especially with a
decent granularity. It wouldn't be difficult to train a supervised ML
algorithm with a set of keyword-tagged job postings with weights as to how
significant a certain set of skills would be used at a job for a certain job
posting.

------
BigZaphod
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.

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.

I think that things like OMeta (<http://tinlizzie.org/ometa/>) are an
important piece and the other work being done by Viewpoints Research
(<http://www.viewpointsresearch.org>) could help.

------
nkassis
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.

I can certainly see Clojure in JS pretty soon. This might be wishful thinking
on my part (see bellow for why).

"Will game development ever diversify or will it go from C++ to C# to ..."

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.

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.

------
javanix
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.

The advantages of modern syntax design coupled with a fast native compiler
would be a potent and exciting mix.

~~~
RodgerTheGreat
The good news is that computers seem to be fast enough to allow game
developers to work in less than speed-optimal languages, so long as they are
willing to accept some stylization. Consider Minecraft, easily the hottest
indie title in years, and it's written in straight-up Java. (As far as pure
numerical computation is concerned, Java is actually a pretty good match for
C++ these days, but 3d graphics remain a fairly serious bottleneck.)

If we're shooting for the stars, though, I'd personally prefer something more
ambitious than Go, like GOAL[1].

[1]<http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp>

~~~
tomh-
Game developers don't only use it for speed. Mainly for portability. With
c/c++ they can make (portions of their) code run on xbox/ps3/nintendo
wii/ds/iphone/whatever.

~~~
javanix
Very true.

Syntax doesn't really matter in terms of performance - what matters is
compiler optimizations. Theoretically someone, if they had a mind, could
optimize a Python compiler to run just as fast as C (or at least as fast as a
non-statically typed language can run).

With that in mind, perhaps some sort of modification to the JVM (or a
competing VM that isn't controlled by Oracle) that provides an aggressively
raw metal code would be an ideal future - the advantages of whatever language
you want to use + speed and portability would be awesome.

~~~
grayrest
> Syntax doesn't really matter in terms of performance - what matters is
> compiler optimizations.

Yes and no. Slight semantic differences can close off optimizations. There was
a great discussion on LtU that pulled in a lot of JIT developers. Mike Pall
(LuaJIT) tossed out some optimizations the Tracemonkey developers could
exploit, but Brendan Eich pointed out that js can't use them:

<http://lambda-the-ultimate.org/node/3851#comment-57767>

~~~
javanix
Huh, cool - I never really looked into what goes into doing compiler
optimizations.

What sort of gains would we be looking at with syntactic language differences
taken into account?

For instance, suppose I wrote some program in C, compiled, and ran it with the
latest GCC/LLVM. If I wrote a program in Python (or Lua) and compiled it down
to bare bytecode with a comparably optimized compiler - no interpreter or JIT
happenings - would there be a large number of optimizations that just couldn't
happen for one language or the other?

~~~
silentbicycle
You have to think about what invariants the compiler is capable of recognizing
in your code, and can prove are valid: "If I guarantee X, it can do
optimization Y behind the curtain, but will still run as if things were
compiled normally."

For example, if all variables are immutable by default, they can be inlined at
point of use, skipping a lookup. Functions whose arguments are all known can
potentially be run once at compile time (partial evaluation). Collections can
potentially be handled in parallel if each cell's processing is independent.
Etc. This sort of thing is why languages with strong invariants (such as
Haskell or Erlang) can do really interesting optimizations.

On the other hand, if the language semantics require that everything is
polymorphic and has to be looked up at runtime, that adds extra overhead, and
it's not always provable what those values will be at compile-time. A JIT-
compiler can compile at runtime, when the information is available, but since
they're usually not able to pause execution for long, they can't do extensive
analysis. JIT compilers can also make optimizations not statically available
because they can revert to the non JIT'd code and recompile differently,
whereas static compilation is permanent. (Method lookups can also be cached,
of course.)

Incidentally, normal Lua (i.e., not LuaJIT)'s compiler doesn't do much
analysis - it's tuned for vacuuming up huge dumps of structured data, rather
than trying to generate optimal bytecode. Lua usually still runs significantly
faster than Python or Javascript, but that has more to do with the the clean
language semantics and high-quality implementation.

Also, a good comment by Mike Pall (the LuaJIT implementer):
[http://www.reddit.com/r/programming/comments/badl2/luajit_2_...](http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0)

------
twymer
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.

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.

------
madhouse
The world is already filled with hundreds (and probably thousands) of
programming languages, most of them fantastic in one way or the other.

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.

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).

------
beagle3
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).

~~~
iskander
> J and K would be a better foundation

A better foundation for...what? Many important programming domains don't fit
naturally into the array-oriented model.

~~~
beagle3
The array model fits the relational model way, way better than the object
oriented model (no "o/r impedance mismatch"). I think most domains fit just as
well (if not better) with arrays.

And specifically, the APL/K/J focus on data makes it a better foundation for
optimization, parallelization and reasoning about program behaviour.

~~~
iskander
>And specifically, the APL/K/J focus on data makes it a better foundation for
optimization, parallelization and reasoning about program behaviour.

I'll give you the first two points (though some heavy-weight optimizations
become necessary to eliminate big wasteful temporaries), but certainly not the
last. At least not in general--- recursion is a terrible pain with arrays!
Even stateful object-oriented languages deal with inductive structures better
than array languages.

What does tree processing in APL look like? I'm it's possible and I'm also
sure it's hell. The K/Q approach of nested vectors is a first step towards
making recursion tolerable in an array language, but it's still a kludge.

------
hsmyers
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...

~~~
somejan
They tried that. What came out was Perl. Lots and lots of layers of syntactic
sugar layered on syntactic sugar layered on more sugar, so you now have lots
of sweet ways to do the same thing. But between all the sugar it's becoming
harder and harder to see the real substance which it was about. The computer
doesn't have any problem crunching through the sugar (it doesn't have any
teeth to worry about), but as a programmer it doesn't become easier to
recognize the vegetables if your cauliflower is sometimes covered in
marshmallow, other times drenched in syrup, and the third time someone made a
half hearted attempt to caramelize it. (Of course nobody servers the
cauliflower as just plain cauliflower anymore.) So yes, you cook for the
computer first, innocent bystanders don't need to know what went in to your
program.

In the real world, the innocent bystanders matter, code is written as much for
other people to understand as it is for computers to execute. I think that
instead of plastering over all your content with sweeties, languages should be
designed in such a way that the sugar is not necessary by choosing the right
fundamental concepts, so programmers can understand what's going on. Learn to
cook with the right ingredients, and learn when to add spices. And when not
to.

For another example of a syntactic sugar friendly design, have a look at C
macros.

------
aplusbi
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.

------
davidw
Ok, I thought it was interesting enough to do my own take on it:

[http://journal.dedasys.com/2010/11/10/the-future-of-
programm...](http://journal.dedasys.com/2010/11/10/the-future-of-programming-
languages-economics)

------
xarch
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.

------
beza1e1
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,...)

In terms of programming language features i expect the next hot topics to be:

Dependent types, however, the question, whether a type system should be
turing-complete is not answered yet.

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.

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.

------
steveklabnik
Mandatory: <http://paulgraham.com/hundred.html>

And the... result: <http://arclanguage.com/>

~~~
brlewis
Arc was criticized when it came out for being basically a few macros on top of
Scheme. I don't think that's a valid criticism. I don't know if Arc is the
hundred-year language, but whenever the hundred-year language does come out,
it might easily be some carefully-chosen macros on top of Scheme, macros that
help write other useful macros.

~~~
steveklabnik
I mean, arc hasn't really 'come out,' has it? It's still being worked upon...
the front page of that site specifically says the only reason there have been
releases is to improve the language.

------
vlisivka
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.

In future, we will have something like that:

#... We are wrote large project using HTML7, but HTML8 is just released ...

$ spm update

...

12826 source files will be updated, 2324 new source files will be added, 343
source files will be deleted. Proceed? [Y/n] y

...

Done

#... OK, let continue our development ...

PS.

I have demo. I hate developing in any 3/4GL language now. :-)

