
Future of Programming Languages - jfaucett
http://c2.com/cgi/wiki?FutureOfProgrammingLanguages
======
overgard
It seems like most languages are converging on a pretty standard feature set
-- to the point where what "the" language is might not really matter because
all its competitors will probably be roughly similar. I think we're at the
point where almost every language will have:

\- Lexical scope & closures

\- Reflection

\- Functions-as-objects

\- The standard map/filter/reduce functions (sometimes under different guises
and names)

\- Immutability mostly by default, with the ability to override it

\- Some hybrid of dynamic and static typing

The last one is probably a sticking point for a lot of people, but as far as I
can tell it doesn't seem clear that either dynamic or static typing is
obviously better in every context, and it seems like a lot of languages are
recognizing that, either by introducing duck typing into a static context (IE,
Go, or to an extent templates/generics), or introducing optional type
constraints into dynamic languages via hints or asserts or just doing some JIT
magic.

Anyway, I just see a lot of convergence. In 2000, different programming
languages were really a lot different, in 2014... most of them have a pretty
similar feature set.

~~~
tomp
They are all converging on these features because they have proven universally
useful. But there is still a lot of work going on about other, new features.
Some examples that interest me:

\- effects and exceptions - should we use monads (Haskell), macros (Rust),
handlers (Eff, algebraic effects), extensible rows (Koka)

\- memory usage - how should we handle deallocation - using reference counting
with infrequent GC (Python) or by being very careful (C++), using just GC and
allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using
uniqueness semantics (Rust, ATS), using memory pools and great care (Objective
C) - none of these approaches is perfect and optimal for all situations, and
it's very frustrating that they don't really fit together

\- safety and security - I'm really interested about provable programs, either
dependent typing (Agda) or refined types (Liquid Haskell, ATS). Both require
quite a bit of "static knowledge" \- immutable data structures, or unique
mutable data structures, and effect annotations for functions (plus, there are
additional problems in lazy languages).

All of the above seem really hard to do using a dynamically typed language,
but hopefully we can devise a way to have both a dynamic and a static provably
efficient and secure code in the same program, same language, with clear split
between the two.

~~~
tel
Theorem proving doesn't require immutability it anything like that—its
requirements are far more severe. Your language must have at least some
fragment which is the internal proof language of a complete and consistent
type theory! This is why, for instance, these languages are always Turing
incomplete.

~~~
tomp
Hm... I'm not so sure about that. Of course, if we're speaking about dependent
types, then yes. However, theorem proving could also be done automatically, by
an external theorem prover, which would only need the refined type annotations
on your variables to prove stuff (using the whatever theories the theorem
prover knows about, such as linear integer mathematics, logic, real nonlinear
math, vectors, datatypes, etc).

~~~
tel
That can happen sometimes for some theories. It's super easy to run into
places where proof search fails magnificently.

------
al2o3cr
Everyone knows the language of 10 years in the future will be a Lisp.

In ten years, everyone will STILL know the language of 10 years in the future
will be a Lisp. ;)

~~~
CmonDev
Lisp is a language? I thought it was a round bracket based ASCII art :S.

------
sanxiyn
The most interesting language design I have seen is Noether. It is a language
built on multiple layers. Inner layers guarantee more invariants (say,
immutability) but forbids constructs you may want to use. Outer layers are
more expressive but guarantee less invariants. Importantly, inner layers are
not different languages but sublanguages of outer layers, and inner layers
keep guaranteeing invariants even when used in outer layers.

[http://www.infoq.com/presentations/noether](http://www.infoq.com/presentations/noether)

~~~
tel
That's essentially what you get from monad transformers in Haskell.

------
progman
The LanguageOfTheFuture is already there.

There is a language that fulfil all requirements. It borrows from Lisp, is
neither C/C++, Java, nor any DotNet, supports dynamic typing with type
inference, suitable for small and large applications, easy to do Meta
programming, and write DSLs, is capable of both ahead-of-time compilation and
interpretation; including the compilation of code at runtime, is Open source,
is both OO and functional, supports Prolog, supports design by contract (by
DSL extension), has several unit testing frameworks, supports relational DB
features, and likely also the rest of the list.

Guess what that language is: It is called Lisp :-)

A classical version is SBCL. Modern versions are NewLisp, clojure and Shen
(shenlanguage.org).

------
tomcam
This just seems like a giant incoherent wish list with no central vision or
any sense of the inevitable compromise required for any language of stature.

~~~
brudgers
That's a feature of the original wiki [aka 'wikiwikiweb' and 'ward's wiki'].
It is not a bug.

[https://en.wikipedia.org/wiki/WikiWikiWeb](https://en.wikipedia.org/wiki/WikiWikiWeb)

------
david927
The future of programming should be one language for all layers of the stack,
from the database to the model to the UI. I think that hints that it should be
a form of declarative.

And if it's declarative, it should be focused on managing state.

And if it's a thin syntactical representation of its VM, instructions/code
could be interpreted immediately at entry and be managed as state, so you
wouldn't be working with a text file but querying the AST equivalent of what
you wrote.

And if you do that, you can create the management tools and structures to
truly understand and manage both data and code.

And if we do that, the future of programming would look less like today's
mangle of a thousand wires to something more like sculpting and architecture.

~~~
creadee
> The future of programming should be one language for all layers of the
> stack, from the database to the model to the UI.

[http://www.red-lang.org/](http://www.red-lang.org/) (a Rebol-like language)
promises to do that. And perhaps right down to the OS (if I've understood it
correctly).

~~~
draegtun
Yep... Red can compiled down to Red/System or be interpreted (with JIT).
Red/System can be compiled down to machine code, bytecode (for select VMs) and
I believe Javascript.

Red claims to be _the world’s first full-stack language_ \- [http://www.red-
lang.org/p/contributions.html](http://www.red-lang.org/p/contributions.html)

~~~
david927
The problem is that it's still letting hardware dictate the terms. There
should be a meeting of the two: the VM.

Anything that compiles to assembly is doomed to be a reheating of C leftovers.

~~~
draegtun
_> Anything that compiles to assembly is doomed to be a reheating of C
leftovers._

Thats what Red/System is aiming at, ie. an alternative to C -
[http://static.red-lang.org/red-system-specs-
light.html#secti...](http://static.red-lang.org/red-system-specs-
light.html#section-1)

PS. Hmmm... who/why downvoted my parent comment? The comment is factually
correct, non-opinionated and with no added embellishments :(

------
ludamad
My person vision is lots of tiny languages that work together in such a way
that you don't have to get out of their sweet spot. Of course, I'm not sure if
its possible to do this nicely.

~~~
jared314
> My person vision is lots of tiny languages that work together

I personally can't work deeply in more than about 4 languages at once. This
might be my memory, my experience level, or it could be a human limit, like
the short-term memory 7±2 limit.

~~~
pakled_engineer
There is an interview with Don Knuth somewhere where he talks about having to
work in numerous low level languages simultaneously to write compilers for
different machines in the 1960s. He added that learning MIXAL/MMIX is no big
deal compared to the days when every computer had a different architecture you
had to learn, sometimes with little documentation.

------
10098
I think the "language of the future" will be the one that will allow people
get results fast with little or no training. In other words, something that
requires low skill. People hate learning and all they want is a magic button
that just makes things happen (for the record, writing this doesn't make me
happy at all).

Also, I predict something similar to the industrial revolution in software
engineering, when high-skill difficult manual labor is replaced by factories
operated by cheap low-skill workers.

~~~
taeric
I disagree with the idea that people hate learning. As a parent, it is quite
clear that people _love_ learning. They hate being reprimanded. Which is what
a lot of people mistake for teaching.

------
JulianMorrison
This whole language of the future concept is just mistaken. The era of being
able to _choose_ a language, for most operations, is over. That's because the
future will be (already somewhat is) the disappearance of PCs, the
minimization of overt gadgets, and the rise of ubiquitous, invisible, small,
smart, with no user serviceable parts. And in most cases with no option on
programming languages. Embedded? You'll probably have a choice of C, C++ and
maybe Rust. Android? Java. Apple? ObjC. You don't like the tools? Suck it up,
there's too much momentum to re-invent the wheel even if you think square is a
terrible shape. They already laid the roads in inverted catenaries.

~~~
pjmlp
This is nothing new. I learned more than 20 years ago that it is less pain to
just use the languages that are part of the OS vendor SDK than spending
development time writing yet another FFI wrapper.

This is how C got where it is now, as the language got adopted by OS vendors
outside the UNIX world.

~~~
mpweiher
This is one of the great lessons from Objective-C, IMHO: layering additional
functionality in such a way as to be completely compatible with the platform
ABI.

There are other compromises you make as a result, but that one feature is a
huge win. (And yes, Objective-Smalltalk tries to extend that lesson of
connectivity to other areas).

------
fithisux
The language of the future is a language that allows the creation of DSLS per
task. A DSL for compiler construction, model checking,driver construction,GUI
programming. This language could compile to C or Assembly and be self-hosted.

------
bane
I think whatever the language of the future will be, it's likely that we're
going to have to give up editing a bunch of text files. Much of modern
programming these days is really about workflow of large teams. It'd be nice
to have richer editing areas that allow for things like embedded diagrams and
videos as comments, annotations, hypertext links out to documentation and from
documentation into code, review comments (similar to MS-Word), font size;
colors; background colors etc. time-tracking for payroll, etc.

IDEs try to provide some of this layer on top of the piles of text files we
use today, often supplemented with out-of-band config files and folder
structure littering stuff all over the place. But there continues to be a
proliferation of hacked on comment systems to handle things like method
descriptions, code changes, reviews. People make changes in some code, then
leave a comment _in the code_ with the change they made, their name and email
address so 2 years later somebody can try and track them down to remember the
2-line change they made 2 years prior. It's kind of absurd.

Imagine if I could just draw a box around a section of code, make the box
dashed and fill the background with red and have a call-out annotation around
it that says something like "highly performance sensitive, do not touch, see
bane for problems" and "bane" was a link to my bug tracker page where you
could immediately file an issue with that code?

And you knew the code had a problem because right above it, instead of some
vague interpretive ASCII art describing the algorithm as a comment, there was
a familiar vector graphic diagram and a set of equations all of us domain
expert programmers know by heart. Only you noticed an error in the way I
translated it from the textbook to code. You also tagged the couple lines I
screwed up and wrote up a review comment in the sidebar (like in MS-Word)
letting me know what you thought was wrong, that way when I go to my bug
tracker, click the link that takes me directly to the code you wanted me to
see, I see your review comment right next to the code in question, only it's
not mixed up in the rest of the code comments explaining how the code works
since it's semantically a separate thing.

I check out the problem and see that you're correct, I leave a response
comment (which automatically notifies you via e-mail with a link to the bug
tracker and to the code in question. When I go back out to the bug tracker the
amount of time I was reviewing the issue is automatically logged, a diff is
stored for review so everybody knows what I changed and the review comment and
reply are automatically filled out in the tracker. My boss wants to check out
the entire exchange, clicks my reply, is taken directly to the block of code
in question and sees that I spent a reasonable amount of time doing the change
(which he can see since the changes were tracked in the diff). I close the
case and the review comments disappear from the code, leaving behind only good
clean code and explanatory comments.

Now a year later, somebody turns on "see old bugs" and they see there was a
problem there, the discussion, what the bug tracker #s were (with links they
can follow), they can even play back time and see the 3 other edits that
happened since then by simply moving a slider left to right.

~~~
ajuc
Version control system commit comments are already very useful for many common
development tasks, if done right (jira ticket number in each commit, commits
divided properly, good commit messages with reasons for change). I wish there
was more metadata there (like which tests failed during automatic build after
each commit).

But I disagree using text as underlying data format is a problem. It's
godsend. Text can be grepped, copy-pasted, diffed and versioned easily.

I cringe when I have to work with versioned word or excel documents. Working
with versioned code is much easier.

you may think big red arrow would be nice to put in code, but how do I later
search for all red arrows related to X, added by John between 3 and 4 months
ago?

I have specification divided into 100s of versioned office documents. When I
want to grep I have to know where to look (or zipgrep the underlying xml,
which sometimes work sometimes doesn't).

If it was in a text format I could grep and see real differences, not edit
history.

If it had embedded video I would need to watch the whole thing. And no -
adding keywords isn't much help. I want to be able to search by content.

------
kristianp
The Language of the Future may be influenced by Alan Kay's VPRI.

[http://www.vpri.org/html/work/ifnct.htm](http://www.vpri.org/html/work/ifnct.htm)
[http://lambda-the-ultimate.org/node/2483](http://lambda-the-
ultimate.org/node/2483)

------
mattxxx
From the article:

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

^ Only reasonable response. _laugh_.

There's questions all around about where domain-specific stuff is going.
Regardless, I think there will be a lot more testing and program-proving.

------
jbzz
Language of the future will be call by value quantum lambda calculus with a
linear type checker... QCaml

------
blt
PanuKalliokoski's short-term predictions were pretty prescient if they are
more than a couple of years old. I wonder when he wrote them. Is there a way
to view edit history on c2?

~~~
Marazan
[http://c2.com/wiki/history/FutureOfProgrammingLanguages/](http://c2.com/wiki/history/FutureOfProgrammingLanguages/)

------
sgt101
If you'd like to see something really radical, and because of an intellectual
agenda, and founded on some solid principals have a look at Church.

Prepare for your mind to be blown.

------
cromwellian
The language of the future is Omega
([https://code.google.com/p/omega/](https://code.google.com/p/omega/))

------
merdreubu
Basically, the language of the future will be 90% Julia.

------
CmonDev
Future programming languages will be about tooling, not syntax. Look at C#
with ReSharper and Roslyn to get the taste.

------
acd
Is there a language with Pythons beautiful syntax and the speed of C plus
concurrency?

~~~
brvs
Haven't used it myself, but Nimrod comes to mind.

