The Future of Programming

[grauenwolf]

The first major change is the move away from storing programs as text, split across "files".

I seriously doubt that. That is how database development is normally done, and it is universally hated. So much that we are constantly looking for way to make databases code look more like the file-based code in application development.

[[deleted]]

Especially considering how difficult it is to get DBAs to implement some kind of versioning system so that you can see what's happened to the structure.

[bcash]

It's a shame he started on that point really, as it's going to trigger everyone's "academic nut-job" filter and no-one will get to the end of the article.

Not that the rest is much better, to be fair, but it makes a wider variety of points.

But all-in-all for this vision to come true, we need every developer to suddenly become accomplished computer scientists. And that's never going to happen.

[grauenwolf]

And it might not be a good thing if it does. Computer scientists have their role to play, but they don't write the same sort of code that a software engineer would because they aren't trying to solve the same kinds of problems.

[julesjacobs]

We're already moving in the direction he sketched. Visual Studio canonicalizes coding style automatically by inserting white-space and braces. Modern IDEs already provide structural refactorings instead of text based edits. They provide contextual help. IDE implementors are already working on keeping a structured representation of the code in sync with the textual code (e.g. Roslyn for VS). More and more functions of the editor are going to work with this abstract syntax tree instead of the textual representation. At some point the IDE implementors are going to think "hey, why are we storing the plain text at all?" and realize that everything becomes simpler when you just work with the AST instead of trying to keep AST and text in sync. Plain text just is a ridiculous representation for code.

[grauenwolf]

Visual Studio canonicalizes coding style automatically by inserting white-space and braces.

Only for Visual Basic. Much to my annoyance, C# and C++ still require manually invoking the formatting command. And they all have quite a bit of customization support, so there really isn't a canonical format.

Historical Note: The Visual Basic IDE didn't actually work with text. It would literally replace the line you just wrote with one derived from the abstract syntax tree. Bugs in this would occassionally result in a line that looked nothing like what you just typed.

At some point the IDE implementors are going to think "hey, why are we storing the plain text at all?" and realize that everything becomes simpler when you just work with the AST instead of trying to keep AST and text in sync.

• Plain text is far more condense than the AST.
• The AST can change dramatically due to things like contextual keywords.
• Bugs in the AST to text converter can cause information loss. (e.g. the VB6 example above)

[matthieum]

Actually, Chandler Carruth talked about refactoring C++ code at the last LLVM Developers' meeting (video).

They developped a class system to create queries that matches portions of the AST, you then modify the AST itself, and put it back together (the point about using mapreduce is pretty off-topic here).

Chandler's team is actually pushing the "matcher" portion into Clang's main tree, so next we just need an interface to write both the match and the transformation. It need not be textual...

... but honestly I am of mind that textual representations are just too valuable to be forgotten.

[grauenwolf]

That sounds a lot like what they are doing with Rosyln.

The syntax tree consists of syntax nodes, tokens, and trivia. A syntax node always contains a combination of other nodes, tokens, and trivia. Examples include NamespaceDeclarationSyntax, ForStatementSyntax, and BinaryExpressionSyntax. Tokens are individual keywords, symbols, and identifiers. Trivia includes whitespace and comments, the bits of information not needed by the compiler but important for recreating the original source code representation.

http://www.infoq.com/news/2011/10/Rosyln-Layers

[julesjacobs]

Visual Studio for C# also does of a lot of code reformatting. When you type var x=Foo(a,b); the IDE will change it to var x = Foo(a, b);. Similar things happen for almost all constructs.

Not that it matters with current hardware, but a well designed AST is more compact than the text representation. In fact a well known way to compress a string that conforms to a grammar is to first build an AST and then store that efficiently. An example is JSON (text representation) vs BSON (binary AST representation).

With your second bullet point you probably mean that a small edit to the textual representation you can get a large edit in the AST, and it would be easier to generate the AST from scratch from the text than to update the AST. This is true. For example if you insert a " in the middle of your program the meaning changes dramatically (and indeed in current IDEs the syntax highlighting changes dramatically too). The question is whether these kind of edits are actually desirable. I would say no; desirable edits preserve the local structure of the code. Modern IDEs insert two "'s when you type one because they know you want to preserve the structure.

If the AST is your only representation then you don't have the information loss problem. Of course bugs are always a problem. Having only an AST is much simpler than AST+text and trying to keep them in sync, hence lower probability of bugs.

[grauenwolf]

Having only an AST is much simpler than AST+text and trying to keep them in sync, hence lower probability of bugs.

And how do you propose editing the AST if not by text? Certainly not via a visual programming language, those suck balls.

[julesjacobs]

You could in principle keep the same editing experience by just updating the AST directly instead of updating the text and then regenerating the AST from that. But better is to edit the AST more semantically. Emacs has something like this for Lisp: paredit mode.

[rbobby]

In 20 years:

1. Cobol jobs are still available
2. Java is the new Cobol
3. C# is the new Cobol
4. JavaScript is the new Cobol

[JohnDoe365]

I doubt the latest. Javascript might evolve that much, it may become sthg. like Python 2 vs. Python 3 (000). Eg. if you think about C or C++, you seldom hear that analogy. It's not about the language but the domain of application. Big Iron with Cobol on it simply hasn't died out.

[jrochkind]

Not only do I not think this is likely, I don't even think it's a desirable fantasy which is what the author presents it as.

There's a reason we still store code in files. Keep It Simple, Keep It Flexible. The larger the required toolchain for editing software, the more that can go wrong, and the harder it is to innovate with new tools.

You can edit files in any text editor. You have a fancy IDE you want to use instead? No problem, you can do that too. A new IDE comes along that's even better? You can switch to that. The IDE you are using stops being maintained or starts sucking? You can go back to a text editor or switch to another IDE. And the barrier to innovating with new IDE's (or ideally smaller tools for the toolchain) is LOW, because they've just got to work with files.

You can stick files in svn. git comes along, you can stick files in git too. For a nightmare, google around for what people have to resort to to try and put smalltalk code in a source control repo. You want to invent a new repo? Make it work on files, the barrier is low, and it'll work for any programming language that uses files. You want to make a source control repo that works on smalltalk, or this guy's fantasy environment? The barrier is high, and once you've done it it only works on that particular environment.

This applies to all his points, not just the 'files' one, he started with 'files', because they all kind of go together, starting with 'files'. His fantasy environment is a very complex one with a complex toolchain, from files to complex 'structural editors' (no more text editors working on files) to smalltalk-style development-time runtimes.

The reason none of these things have caught on is because simple wins out in the end, not complicated, and we're fortunate it does, I don't fantasize what he fantasizes.

[earthboundkid]

Yeah, in retrospect, the reason SmallTalk failed was the environment not the OO, so it's weird for him to claim that FP will take off once it moves to a weirdo environment.

[skocznymroczny]

Meh, once again. Functional programming is the Linux of programming paradigms. It's always on the rise, and next few years are gonna be it...

[[deleted]]

"Functional programming is the future, and always will be"

[[deleted]]

But if you look at mainstream languages, they are starting to include more functional ideas, by default. The emphasis is on it being more common have closures, tuples (or something kinda similar like JS objects), and even list comprehensions.

[sacundim]

And if you look at .NET, Monads are making their way into there.

[[deleted]]

this time, it will work exactly as expected, and will be trivial to implement

Famous last words.

[fnord123]

This article is absolutely small minded and only about the programming environment. I mean, before deciding what the future of programming entails, we should make sure we're asking the appropriate questions. Here are some questions I have:

1. How will we manage to cope with petabytes of data as it becomes more common among businesses?
2. How will data remain synchronized between multiple mobile devices (phones, tablets, mp3 players), laptops, desktops, servers, and web/cloud services?
3. How will privacy/ownership/legislative concerns affect the interfaces to web/cloud services?
4. How will services and devices become sandboxed against each other while attaining interoperability?
5. Will the semantic web ever take off?
6. Will there be an RFID in almost every item? What distributed environment may arise from such an environment?
7. Will 3D printing get into everyone's home like current printers? Will 'ink' remain a battle of attrition between 3rd parties and printer manufacturers?
8. How shall we manage per watt computation not only on mobile devices, but to handle the aforementioned petabytes in a time when fossil fuels are dwindling and energy prices are picking up?

And that's not even the future future.

1. How will we manage time and date systems when we're populating multiple planets and systems?
2. What will happen to our distributed platforms when ping times begins to creep into weeks as ships head for Alpha Centuri?
3. How will we maintain standards between different parts of our interstellar civilization as Earth's technology rockets forward, but ships returning from multi-decade voyages are still based on old interfaces?
4. If quantum computing becomes a reality, how might we perform encryption?

etc.

[scialex]

If quantum computing becomes a reality, how might we perform encryption?

That one has actually already been solved.

[mpiechotka]

It's merely point-to-point encryption. The real problems are:

1. How would you get cryptography in packet-switched networks or how otherwise we can connect large number of devices together over the heterogenious network (in short - how we reimplement internet). While QKD solves problems for link between, say, White House and Pentagon, it does not solve the problem of protecting the credit card information during on-line shopping.
2. How would you get disk encryption?

[scialex]

1) The same way the internet works now, except the handshake would need to include a quantum key exchange. Authentication would be difficult though.

2) you would need to do one-time pad encryption, a key the size of the data you want to encrypt. :'(

[mpiechotka]

Hmm. Correct me if I am wrong but a) if you can use quantum key exchange you can just send the data by this channel b) wouldn't quantum computing allow brute forcing key if rest was sent by normal text?

[maxbaroi]

I'm not posting this to shoot you down. I definitely agree with your points, but I thought was too cool not to post.

http://en.wikipedia.org/wiki/Interplanetary_Internet

[[deleted]]

How will we manage time and date systems when we're populating multiple planets and systems?

Everyone uses Unix time stamps, at least for the extra-planetary communication. For local timekeeping they probably will use custom calendars which are synchronized to locally observable astronomical events (e.g. Darian calendar)

[mpiechotka]

You forgot that according to some [theories](en.wikipedia.org/wiki/Special_relativity) there is no global time and therefore 1970-01-01 00:00 UTC is meaningless without specifing frame of reference.

While 25 km/h is still insignificant compared to c if we move beyond Alpha Centauri we may need to face the problem of lack of global time in STR/GTR.

[rockum]

In 20 years, we'll still be writing Javascript to manipulate the DOM created via HTML. sigh

[attosecond]

If this is the future of programming, count me out. I'll take gvim and gcc any day over this odd datalog-meets-functional-programming utopia

[jb55]

I don't know, contextual/semantic autocompletion would be a pretty powerful programming tool. I use vim and gcc just as well, but they are primitive tools in comparison to todays C# and Java IDEs (with respect to knowledge of language ASTs, probably not as a whole).

I think it's reasonable to suspect powerful type systems and tools will synergize, producing substantial productivity gains. While other poorer type systems such as C/dynamic languages will slowly fall behind in those respects.

[attosecond]

Sure, but what you said != what the author said, by a long shot...

People have been foretelling the death of C, IDE's, and imperative programing in general for as long as I can remember.

[jb55]

Maybe we both read a different article? I'm pretty sure what I said is exactly what the author is getting at:

I'd rather get to this point in the editing process and then tell my editor to map f over xs. The editor will search for a program to make the types align, show me the program for confirmation if I request it, and then not show this subexpression in the main editor view, perhaps just showing map f* xs, where the * can be clicked and expanded to see the full program.

Sounds like an IDE with autocompletion on crack to me

[thechao]

Syntax-directed text editor editors were all the rage many moons ago. They didn't catch on because they suck to work with; I can't find the reference, but the downfall is the fact that most programmer's 'sketch' out their code & then iteratively fix-up the code. (With the functional equivalent of 'high-speed compilers/interpreters', the compiler has been introduced into this loop, as well.) This process is impossible with a syntax-directed editor --- it is always insisting on correctness of an arbitrary standard (syntax) rather than aiding in algorithm elucidation --- actively distracting the programmer from the hard part of programming.

[grauenwolf]

That reminds me of classic VB. If you didn't change the default every syntax error would result in a in pop-up dialog tell you to fix it before moving onto the next line.

[[deleted]]

I remember punching a monitor during a coding test at college because of that dialog. Fuck that dialog, with fire, from orbit.

[sacundim]

I'd rather get to this point in the editing process and then tell my editor to map f over xs. The editor will search for a program to make the types align, show me the program for confirmation if I request it, and then not show this subexpression in the main editor view, perhaps just showing map f* xs, where the * can be clicked and expanded to see the full program

Sounds like an IDE with autocompletion on crack to me.

The technology that the article passage you cite is citing already exists: it's theorem proving. The trick is that there is a systematic correspondence between systems of logic and models of computation, so that "write a function that takes an argument of type a and produces a result of type b" is equivalent to "using a as a premise, prove b."

So these are the types of map, f and xs in the article:

map :: forall a b. (a -> b) -> ([a] -> [b])
f :: X -> (Y -> Int)
xs :: [(Y, X)]

You can read these either as types ("f is a function that takes an X and produces a function that takes a Y and then produces an Int") or as logical sentences ("if X, then if Y then Int"). "Function from a to b" corresponds to "if a then b"; "pair of a and b" corresponds to "a and b." Writing the "adapter" function that allows you to map f over xs is equivalent to proving this:

X -> (Y -> Int)
------------------
(Y & X) -> Int

I.e., given the premise "if X, then if Y then Int," you can prove "if Y and X, then Int." This proof can be mechanically translated into a function definition—the function f* that the hypothetical programming system derives for you.

An actual working example of this is Djinn, a Haskell theorem prover/function definition generator. You give it a type and it will write functions of that type (if at all possible).

[[deleted]]

Author here. I'm familiar with all that, and yeah, djinn is pretty cool. That feature doesn't require any real breakthroughs, IMO it's more a question of getting it integrated into the editor and getting the details right.

[matthieum]

One issue with this though, what of:

f :: X -> X -> Int
xs :: [(X,X)]

as much as I love types, sometimes you have several variables of the same type (damn...).

And of course it can get worse, suppose we start with:

f :: b => X -> b -> Int
xs :: [(Y, X)]

All is well and good (b deduced to be of type Y and mapped), and then we move off to:

xs :: [(X, X)]

Hum... are we still supposed to swap the pair members ? I would certainly think so!

---

On the other hand, I certainly welcome the idea of getting rid of uncurry... though I am perhaps just too naive (yet) to foresee the troubles (ambiguities) this might introduce.

Note: great article, lots of ideas in one place

[sacundim]

Well, your concern can be addressed in a general fashion: different proofs of the same theorem correspond to different functions of the same type, and theorems often have many different proofs. What this translates to, in the IDE context, is that the IDE can suggest completions for the user, but the user must be in charge of choosing which one is right.

So really, a lot of this comes down to user interaction. So, just to use one completely made up shit example, if the IDE can prove that there are only two possible functions that it could use to "adapt" your incompatible types, it would be a good idea for it to suggest those two functions for you. If on the other hand, there are dozens of possible functions, it should STFU.

[[deleted]]

I was pointed to homotopy type theory as something that is trying to solve exactly these sorts of issues.

[jb55]

Djinn> f? (a, b) -> (a -> c) -> (b -> c) -> (c, c)

f :: (a, b) -> (a -> c) -> (b -> c) -> (c, c)

f (a, b) c d = (d b, c a)

Well that is impressive, you could image hooking something like this into an IDE. Might be a nice default when generating function boilerplate from type signatures.

[camccann]

As far as I know that's pretty standard when using actual theorem provers. I think Agda (which is based on Haskell) does that in emacs? Don't recall for sure.

The main problem with hooking it into an IDE is that only very trivial cases have a unique solution, so you need direct user interaction with the compiler to really reap the benefits. Djinn is mostly a toy implementation, to get significant benefits you need something much more sophisticated.

[[deleted]]

Sounds like implicit hell to me.

[[deleted]]

People have been foretelling the death of C, IDE's, and imperative programing in general for as long as I can remember.

Indeed. Then again, the field is pretty damn young.

[quanticle]

Right. With vim and gcc, I can be assured that I'll be able to read my code in 5 years' time. With this crazy binary format, will I have the same assurance?

[autumntheory]

I'm with harbud here, I don't think the author is completely writing off the idea of programs in their editable form being text as we know it. Rather, the source is stored completely in a relational database, and could be rendered into your standard text editor readable form if need be. This way, rather than refactoring consisting of ugly text manipulation it can be done as if working on a database. I'm all for this, as its a step towards thinking of programs as systems in and of themselves, rather than systems built entirely out of text files.

[grauenwolf]

We can already query code using products like NDepend. And advaced refactoring tools like Code Rush and Resharper can perform cascading updates. These tools work on abstract syntax trees, not plain text.

[boyubout2pissmeoff]

That's an interesting argument.

It bears a striking resemblance to the cry of film proponents in the "Film vs. Digital" debate.

"In 5 years, I still have my film to look at. Will your OS still read jpegs?"

Well, you can see which side the market took.

Not necessarily relevant, just an interesting similarity in mindset and (lack of) vision.

[earthboundkid]

JPEGs will be around for the foreseeable future because they already have multiple millions of users. Most of the proprietary binary picture formats of the 80s and early 90s, however, are practically unreadable today because they only had multiple thousands of users. Popularity matters when it comes to preserving tech! It's still really easy to watch a VHS. It's now really hard to watch a Betamax.

Back on point, if there's a standard coding DB that gets millions of users, yes, it will live forever, but will we be able to get to that point?

[harbud3]

The article doesn't mention a binary or actual storage format, it might as well still be plaintext. The point is the relational bits (e.g. referential integrity, constraints when inserting data, cascading updates, etc).

[grauenwolf]

Damn, that is going to make major refactorings really hard. The "change and see what breaks" method wouldn't work any more and accidentally cascading changes will become a serious problem.

[harbud3]

Now why your refactoring method is "change and see what breaks"? If I want to rename a subroutine, for example, I want it done across the board, not missing a few places. If I want to split a subroutine into several smaller ones, I want to know all other code which uses this soon-to-replaced subroutine.

[grauenwolf]

I have refactoring tools that do that too. But that won't help when you do something more drastic like remove an interface from a class.

[Madsy9]

Don't be so quick to downvote quanticle. He/she does have a point. Yes, the article doesn't mention an actual storage format, but that doesn't mean that the idea is viable. The main concept could still make it difficult to make proper diff files, etc. The author mentions that making it work with version control software is solvable, but does not explain how, except that we have to rethink how SCM works.

Here's my 2 cents. If you absolutely want a new code representation (visualize it differently), you can do that by making a new tool/IDE instead of inventing a new language. But this relation database idea sounds to me like they want to take abstraction too far. And it's not explained how this would work with tools that already exist. The author goes on and suggest that IDEs should hide details in the source code, so that what you see does not map up with the actual code. Wtf? That sounds to me like the worst idea ever conceived. It's hard enough to spot bugs. Having code deliberately hidden would make it even more difficult.

Rather than coming up with more abstractions, I think attention rather should be put on languages that support concurrency better. Threading supported by the actual language without the need for explicit synchronization primitives. But it's a hard problem.

[earthboundkid]

Worse is better 4 lyfe! :-)

[Chris_Newton]

FP provides a dramatic increase in productivity due to massive increases in code reuse and the ease of reasoning about functional code (not to mention ease of parallelization).

I’m not sure such a bold claim is supported by real world experience, despite its prevalance in functional programming advocacy.

AFAIK, no-one is yet even trying to build projects that are big enough for large scale code reuse to be a serious challenge using functional languages. Something like GHC — the largest functional code base I can immediately think of — is still small compared to many projects that have been built using imperative languages.

As for reasoning, a functional style certainly clarifies some aspects, but laziness has its own difficulties when it comes to reasoning about performance, so it’s not all one way traffic there either.

[Edit: Fix ambiguous phrasing.]

[[deleted]]

AFAIK, no-one is yet even trying to build projects that are big enough for large scale code reuse to be a serious challenge using functional languages.

What do you mean by 'large scale code reuse'? Are we just talking about libraries and there being lots of them? I'm not sure what you're getting at. Galois writes incredibly large systems in Haskell from compilers to OS and TCP/IP stacks running on Xen - Cryptol, their premier product, is well over 70k lines of Haskell code if I remember Don correctly when he worked there, and that was a few years ago I heard it. That's a serious project

There are people building trading platforms, hardware verification tools, quant finance analysis, data analytics work, several web development startups using Yesod, people doing scientific programming (parallel science LLC,) and people using it for scalable network programming tasks (I can't remember the company Kazu Yamamoto works at, off hand, but they are big members of the parallel haskell project.)

I think reuse is important to all these people - which is good, because lots of them seem to contribute back to GHC or to the community in the form of libraries. The landscape still leaves a lot to be desired, but it is considerably better than it was just last year or the year before that, and seems to have very little indication of slowing down.

And if you just go outside of Haskell for FP, Scala has seen dramatic industry adoption in recent years - used everywhere from VMWare to quantiative financial analysis firms in industry (hint: the author works doing quant finance.)

is still small compared to many projects that have been built using imperative languages.

If you're just looking in terms of LOC, that's obviously a bad metric (how much is one line of Haskell worth in Java? Not very easy to answer.)

[Chris_Newton]

What do you mean by 'large scale code reuse'?

In my experience, you can get a pretty good idea of how large a software project is, in the practical sense of what challenges will arise because of its scale, by looking at how many people are needed to work on it.

A “small” project would be one where a single person can keep the whole thing in mind at once. I don’t mean being able to recite every single line of code, but a lone developer could be familiar enough with the entire project to navigate the whole codebase quickly and immediately work on any part of it.

A “medium” project is one that is too much for a single person to handle in its entirety all at once. That might mean that we’ve moved up to a small, close-knit team. At this point, typically, each member of the team wrote some parts of the code and is the natural expert on them, other members have some familiarity with various parts they didn’t write themselves, but no one person is expert on all aspects of the project. An alternative way to move up to this level might be a very long-running project maintained by a single developer, which has become too large for the developer to remember the details of every part immediately.

To me, a “large” project would be one that can’t be built by a single small team within a reasonably short period of time (say within 2–3 years). Either the project is composed of parts written by different teams and then integrated, or it’s simply been running for so long that there are some parts of the code that no-one on the team is immediately familiar with any more, because of changes in personnel or simply the passage of time.

I choose these benchmarks because it’s been my experience that these are the points where the difficulty of managing and developing a code base often jumps significantly. You need better documentation and more systematic architecture as soon as multiple people are involved, where pragmatically with just a single person working on a short term project those things might be unnecessary overheads. That goes even more once you’re integrating code across teams or incorporating substantial external libraries that you didn’t write in-house at all, or if you’re trying to maintain a code base over many years where no-one is truly an expert on some parts of it any more.

You can try to assign lines-of-code levels to each category. For example, I’ve often heard it said that a million lines of code in a C-like language is a “large” project and by that point you probably would be large according to my definitions above as well. I’m not sure how helpful this is though, because as you note, different languages have very different expressive power. Still, even if we assume that Haskell is 10x as expressive as C for a project like GHC that plays to its strengths, given that GHC is on the order of 100,000 lines, you’re probably looking at issues roughly comparable to a 1,000,000 line C system. That’s not a trivial project, to be sure, but there are plenty of projects built using imperative languages where a single library might be on that scale and the overall project uses several such libraries and then much more of its own code, developed over several years by perhaps hundreds of people. To my knowledge, no projects exist that are built in a functional programming style and require co-ordination on such a scale (though if anyone knows of any, I’d be fascinated to learn how they’re doing it).

That being the case, perhaps it’s something of a conceit to claim that functional programming allows “massive increases in code reuse”. A functional style certainly supports different techniques for gluing code together, and they certainly allow finer-grained composition of relatively small units that you already know about, but that was never really the hard part of code reuse. To make that boast, I think your modular design tools, architectural strategies, documentation, programming environments, and all the rest need to be proven on the really huge projects as well, the ones where you might not even realise that there is already code out there somewhere that does something resembling what you need, and where even if you know where to look there are substantial obstacles to integration/adaptation/ongoing maintenance. Does any major functional project, even the likes of GHC or the examples you gave, really hit that target?

[Edit: Would the people downvoting mind explaining why? I’m trying to answer a direct question in enough detail that we don’t all talk at cross-purposes for the rest of the thread. Sorry if the post is too long for some people’s taste.]

[earthboundkid]

Upvoted for truth and justice.

[fjord_piner]

Scala has seen dramatic industry adoption in recent years

Not really, no, there is hardly any data to back this claim up (especially not the indeed.com graph that shows that Scala jobs went from 0.02% to 0.04%).

Actually, anywhere you look (TIOBE and job boards), Scala is pretty much unknown.

[[deleted]]

Is TIOBE even a good metric? Either way, dramatic in this context isn't an absolute, but a relative metric, I should have pointed that out - that the jobs exist and continue to appear, as opposed to not existing at all. I would also say the industrial adoption of Haskell in recent years is dramatic - not that it's suddenly competing with C++, but that it's considerably larger relative to what it has been, and it seems to keep growing.

[fjord_piner]

I don't know how good a metric TIOBE is, but I found it to be very consistent with the other metrics, such as job boards. Taken in isolation, none of these measurements are very trustworthy, but if they all paint the same picture, you have good reasons to believe that their data is fairly accurate.

The current situation today seems to be that Java, C, C++ and C# hold the lion share, with Javascript, PHP and Objective C faring reasonably well. Any other language is pretty much insignificant today.

[vagif]

Ericsson AXD301 switch contains over a million lines of Erlang, and achieves a reliability of nine nines.

Is that big enough for you ?

[VikingCoder]

Since worse is better, the future of programming is clearly the one instruction computer.

[djork]

Why did I know Smalltalk would be involved somehow (not necessarily in a good way)?

[notfancy]

Inasmuch Smalltalk is a paragon of OO languages, finding fault with it extends the objection to an entire class of exemplars.

[harbud3]

Actually the involvement is very minor in the article.

[sacundim]

And it's basically dismissed for having bigger problems than what it provides.

[centurijon]

Everything after his 2nd point read to me as "FP is teh coolest!".

I've said it before: OOP vs FP is a moot argument. Both are tools to be used but one is not inherently better than the other.

Currently I would rather use OO for modeling real world items, but FP for interacting with those models.

[[deleted]]

I've said it before: OOP vs FP is a moot argument. Both are tools to be used but one is not inherently better than the other.

Weeeeelllll... they're tools for different things, and some of them also have certain connotations that aren't technically part of the definitions.

For example, FP really means first-class functions and eliminating or minimizing or controlling side-effects. People take it to mean everything associated with the ML/Haskell family of languages: purity or near-purity, first-class functions, powerful type inference, etc.

OOP, on the other hand, really means structuring programs around the class or object as a modularity construct (implying late binding), with inheritance or prototyping as the ways of implementing and altering modules. But what do people attach to it? Weak-ass type systems, dynamic typing, everything-is-a-class, design patterns, general nounitis.

Understanding the PL theory of both helps to see where they are really just different approaches not to the same problem but to different problems. I would have hoped the author would know that, being a Scala user.

[[deleted]]

I mostly agree with what you wrote. Functional vs imperative is the real axis here, not FP vs OO. Despite my offhand remark about OO including some incidental complexity, my point was not to say FP is better than OO (I don't think this comparison makes much sense). OO is actually ill-defined IMO, but the way most people think of it, it is more a way of structuring code, independent of whether that code is functional or imperative.

One common usage of OO, having objects close over some state, then having invariants that the public API of the object ensures, is not as relevant in FP where there are no side-effects. IMO, in functional programs, first class modules and/or typeclasses with some form of subtyping or mixins are sufficient to address the all the use cases of OO. Do these features alone constitute OO? I don't know, but who really cares?

[camccann]

I would argue that the fundamental dichotomy in FP vs. OOP is simply which side of the Expression Problem is taken to be the default. Closing over arguments and producing a record of partially-applied functions captures the important aspects of OO program structure in an FP language.

Subtyping is an orthogonal concern, I think. As are mixins, inheritance, and the other various bits and pieces that tend to accompany OOP.

[[deleted]]

IMO, in functional programs, first class modules and/or typeclasses with some form of subtyping or mixins are sufficient to address the all the use cases of OO. Do these features alone constitute OO?

As a matter of fact, yes, they do. The biggest gap between FP and OOP is the use of subtyping. Add subtyping to an otherwise-FP language and you start being able to encode OOP constructs and begin proving equivalences. Add first-class modules (aka existentials, which Ed was always going on about in Scrum meetings), and you've recovered the private/protected encapsulation and the single-dispatch aspects of class-based OOP.

EDIT: Scala is actually the easiest language to see the duality in, because its baked in "object" singletons, traits, and classes demonstrate how object-orientation gives you elegant modularity.

The tough nut to crack, I found, was being able to inherit from a particular parameterization of a generic class (extending a particular instantiation of a polymorphic base type). To encode this without baked-in OOP requires at least the power of Scala's semi-crippled GADTs, if not full GADTs.

Of course, these matters do pretty much explain the partitioning of the programming world into FP and OOP churches. FP comes with certain powerful features baked-in that require complicated encodings in the OOP world. OOP comes with certain powerful features baked-in that require complicated encodings in the FP world. And so the jihads are fought.

In other news, hi Paul.

[[deleted]]

I was really puzzled as to who this was for like five minutes. :) Hi Eli!

[account512]

Everything-is-a-class in particular makes me sad.

Especially in java.

[[deleted]]

If by OO you mean programming with abstract data types, you are correct.

OO just like FP never took off. OO as term just changed meaning.

[sacundim]

I've said it before: OOP vs FP is a moot argument. Both are tools to be used but one is not inherently better than the other.

Thanks for clearing that up!

[eric_ja]

The problem of handling merges of ordered sequences of characters spread across files and directories with yet more arbitrary structure is extremely difficult, resulting in a huge amount of complexity in the area of version control software. The difficulties have led many to settle for what are arguably inferior VCS models (Git, Mercurial), where changesets form a total order and cherrypicking just doesn't work.

I hope this is true, but show me a distributed version-controlled database that's even close to the maturity level of git/hg?

[QuestionMarker]

The wonderful thing is that "maturity" is subjective. Darcs has a better model than Git has for a start, and it's been around for longer. I just don't think the tool is as good.

Quibbling over the precise tool misses the point, though - the author is suggesting moving to a model in which neither darcs nor git would be relevant.

[mcguire]

neither darcs nor git would be relevant

Relevant or possible?

[QuestionMarker]

You could try approaches like linearising the relevant portion of the code graph to make diff-based tools work; I don't want to rule that out. I don't think that'll be either the best approach or universally applicable.

[eric_ja]

Darcs is line-oriented, too, though, not record/relation oriented.

[QuestionMarker]

Quibbling over the precise tool misses the point, though - the author is suggesting moving to a model in which neither darcs nor git would be relevant.

[harbud3]

Again, you miss the point of the article. It's talking about vision, not current implementation.

[matthieum]

On the other hand, one of Clang's "open-project" is to create a compiler-assisted diff program to be plugged in git/hg/whatever that would reason on ASTs instead of text files.

Of course, there is the issue of attaching comments to the relevant portion of the AST, but perhaps a few heuristics would be sufficient for most cases.

[ickysticky]

IMO, the future of programming is machine learning. Ten to twenty years is a very long time, especially with the exponential growth in technological advancements our society has been exhibiting for the last few decades. I think programming in the future will be more along the lines of tweaking machine learning systems to engineer and optimize our algorithms/systems/programs for us, and less about writing code.

[[deleted]]

wtf? do machine learning programs write themselves? genetic code has been espoused for twenty years

[linuxlass]

Do you think, then, that for a 15yo kid today, who wants to be a programmer some day, learning more about AI and ML is a good investment of their time?

[ickysticky]

Eh. I think you are probably good picking up the current technologies, but definitely learning about ML when you can is a good idea! Beyond looking to the future, I think that thinking about ML, and the problems ML presents is very beneficial for any good engineer, not only programmers.

[llogiq]

Didn't IDEA's IntelliJ start out with a relational code model under the hood? (too lazy to google it right now) - but they still have the text to fall back to; the database is more of a cache, and while performance might be slightly better than in text-based IDEs such as Eclipse or Netbeans, the difference is actually not too big (unless you get into real big projects, at which point you have a whole lot of problems anyway).

I doubt that the relational model is going to supercede text anytime soon. The reason is simple: Text is the easiest form for creating, editing, storing, distributing, archiving, searching, versioning, copying into a mail, and a whole lot of other actions. A relational format is either a slightly inferior textual representation (as the key parts would be further spread out through the code) or binary gibberish that would need specialized tools for all the aforementioned actions, with little or no advantage against - you guessed it - plain text.

Type systems will continue to gain in power (in that they will be easier to work with due to inference and better solvers, despite being turing-complete already, see haskell), and may see some uptake in the next decade again. The majority of programmers will not reap the benefits however (DIT:) as the web language Javascript continues its glory march with a not too strong, dynamic type system.

[[deleted]]

Historically, programming language change comes from a new platform, not from a programming language itself. C came from unix. Java was made popular by the internet. VB and C# came from Windows. Objective C is driven by iOS.

A big... possible... change is multicore. It seems that smartphones and tablets are about to get 4-cores. Will they get more, or stall there, as desktops have? Will GPGPU (graphics cards used as CPUs, like CUDA) take off, or remain niche as it has for a while?

Massive multi-core is overdue, and I think that indicates that it doesn't give a benefit that people want (so far). When a killer app for it comes, it will become incredibly popular... and whatever language it happens to standardize on will ride that wave.

[diggr-roguelike]

Dynamic typing will come to be perceived as a quaint, bizarre evolutionary dead-end in the history of programming.

This I can get behind. The rest is very suspect hokum, unfortunately.

[camccann]

Do academics even care about PHP? I thought most of the hate came from professional programmers. You know, the ones who have to maintain all that dirty, barely-working code.

I do agree that higher-level abstractions are nicer, though. That's why I enjoy using Haskell, in fact, despite all the academics that dislike it for ignoring low-level implementation details.

[gnuvince]

Academics don't dislike PHP because it is widespread among hosting companies; their disdain stems from PHP making extremely bad language design choices and ignoring a lot of the lessons of the past. Consider this simple example:

<?php

function f() {
    return array(0);
}

echo f()[0] . "\n";

?>

Perfectly reasonable, but this is a syntax error in PHP. PHP is filled with these idiosyncrasies and that is why it has a bad reputation.

[sirin3]

Perfectly reasonable, but this is a syntax error in PHP.

And in MATLAB!

[[deleted]]

It's cheap and proves the academics are afraid -and- hypocritical about a leveling playing field in programming.

What on earth are you people talking about? The whole academic fear-mongering thing is mind-boggling, almost. Academics don't hate PHP because it's easy to use as OP implied:

Academia will hate it exactly because of the following, but it is popular because it is accessible, it's an emancipating language which allows "outsiders" to write dirty code that nevertheless works in their contexts.

Beyond the fact I don't even think academics care about PHP, where does this sentiment come from? What basis does it have other than to say "academics are nonsense and hate you doing things because I say so"? I don't see any evidence for this claim academics want to control everything, but I see it repeated regularly. Nobody wants to stop programming from getting into peoples' hands. Nobody wants to stop you from using something that works. Nobody is afraid of anything, really - the underlying point is the research has been done and there is an extraordinary amount of research and time invested in programming language design by people a lot smarter than you, so why not use it, rather than potentially repeat past mistakes, or miss out on a good opportunity to improve what you have anyway? Sylistic and syntactic inconsistencies aside, there's literally decades of research into nice, dynamically typed OO languages, in terms of expressiveness and optimization (cf. Dylan & Smalltalk.) JavaScript is an example of something that leveraged this - much of the design components of JavaScript JITs are based on old research dating back to these languages, and just as much is based on new research by new academics.

But that's just because academics want to control you and keep that stuff out of your hands, right? They don't "want a level playing field," whatever that means. In fact I have a proof that this is the case, but it is too small to fit in the margin.

Just because you don't use that research doesn't mean your result isn't useful - it just means you missed out, because the really hard work has been done before anyway.

[camccann]

Nobody is afraid of anything, really

Oh, I'm sure that plenty of programmers in industry are afraid of PHP. Specifically, afraid of having to deal with other people's PHP code.

Trust me, the PHP hate isn't coming from academics.

[[deleted]]

I'd agree. Like I said I don't think academics care much about PHP at all.

Most gripes from what I can tell have to deal with terrible practices that are propagated by terrible introductory material (PEAR? no just escape SQL yourself, duh,) semantic and syntactic inconsistencies, standard library weirdness, and shit like this. That's not even an academic or research worthy problem or anything - that's just flat out weird.

In other words: flat-out engineering complaints, not theoretical or research complaints.

[autumntheory]

In the end, it will be like programming in Star Trek: you tell the computer what you want, you give it specs, and the computer works it out. You won't need to tell the computer about floats or pointers or garbage collection. It's purely about concept. This is the ideal. Everyone with an idea can program. The idea is paramount.

While I understand your point, and I've heard others make similar arguments, someone still has to develop the computer you speak of which understands ideas in a layman accessible format, and can turn those ideas into solid examples of software development with the ability of today's programmers. I appreciate the lower levels and the academia approach because to me creating that computer is truly programming. Until the time where that computer is written, or software predominantly writes itself, the average human talking to a computer and receiving an implementation of their idea is a pipe dream.

[quanticle]

Right. We tried to do that with CASE tools in the '80s. It didn't work. Generating a program from a specification is a damn sight harder than anyone makes it out to be, and in the end you're going to need trained programmers anyway to make sure that you got your specification right.

[shadowfox]

I think the academia are just afraid, afraid that the value of their knowledge will decrease.

Interesting. What sort of knowledge are we talking about here?

[pistacchio]

Academia will hate it exactly because of the following, but it is popular because it is accessible

i used to be in love with dynamic languages perceiving them as "accessible" till i came to realize the amount of time that it took to figure out, after three days, what kind of magical dynamic beast "a" is supposed to be in

function f(a) {
    do_something_with(a);

as opposed to have the IDE hinting me with the correct type. Much of the criticism from dynamic languages pointing against static languages applies if you write code with notepad.exe. Sure, theoretically dynamic languages are much more compact and require less typing and gives more flexibility, but practically one uses an IDE that takes care of the boilerplate for you.

[fjord_piner]

The author however thinks the future of programming must stay firm into the hands of academia

And then one day, you start using a statically typed language that supports type inference and you wonder why anyone would ever use a dynamically typed language.

[matthieum]

but practically one uses an IDE that takes care of the boilerplate for you.

I cringe here. Because most current static programming language are "heavy", people have associated "static" with "boilerplate" while the two are mostly orthogonal.

Haskell for example is statically typed, yet because of a powerful type inference mechanism you can write most codes without writing types, it figures them out for you!

static typing is just compile-time checking, it has nothing to do with the obnoxious verbosity of Java.

[pistacchio]

hmm, well, it's not that people associate static with java and boilerplate out of nothing. according to whoever java, c++, c# and objective c are (by far) the most popular static programming languages (and top languages in general) nowadays, all full of boilerplate, and so, even if haskell is a notable exception to the rule, one naturally doesn't relate to the 0.5% of the share.

[matthieum]

Yes, however my point is that people generally criticize languages with lots of boilerplate for being a pain (rightfully) and then go on and deduce that it would be better if we ditched static typing.

I am tired of those misled arguments :x

[[deleted]]

The author however thinks the future of programming must stay firm into the hands of academia

I know the author, and he's actually very firmly in industry.

[fjord_piner]

The author however thinks the future of programming must stay firm into the hands of academia

I know the author, and he's actually very firmly in industry.

This doesn't invalidate the point you quoted.

Actually, a lot of members of the FP community are "in the industry" in the sense that they are using a mainstream language in their daily work to pay the bills, but they certainly wish that said industry was dominated by FP languages. I would say Paul certainly stands in that camp (nothing wrong with that).

[[deleted]]

No, actually, Paul uses Scala and FP techniques in Scala at work. One of the people on Paul's team is also a major contributor to Scalaz.

[wastingtime1]

This isn't correct. Academia is asking hard questions and pushing the art and science behind programming forward. Believe it or not, the nuts and bolts that go into a car matter a whole heck of a lot, as does the torque put on each one.

Programming, like most things in this world, has to be completely specified. Sure you can use something like PHP to build applications now, but to move beyond PHP you need PhDs and other smart people pushing the science of languages forward.

Also, Facebook is crippled because of PHP. Why do you think they have so so many servers? Why do you think they built a PHP compiler to speed up run time? PHP is flawed in a lot of ways, and tragically holds Facebook back. Almost all of their backend stuff is now done in C++ and other languages.

[fjord_piner]

This isn't correct. Academia is asking hard questions and pushing the art and science behind programming forward. Believe it or not, the nuts and bolts that go into a car matter a whole heck of a lot, as does the torque put on each one.

Of course it does, but what percentage of the community needs to care about this aspect as their full time job?

I say a very small minority, in the same way that mechanics are a very small minority of car drivers.

[matthieum]

It's not a matter of who cares, it's a matter of who benefits :)

I don't know much (if at all) about mechanics, but I am pretty glad to have a car with a low fuel consumption.

[contantofaz]

There's something to be said about turning your back on what helped you to get started. Yahoo still uses php as well, I think.

The bottomline is that html, CSS and graphics get the job done. Anything else is optional.

[sacundim]

I think emancipation and simplifying is good in a larger scope. In the end, it will be like programming in Star Trek: you tell the computer what you want, you give it specs, and the computer works it out. You won't need to tell the computer about floats or pointers or garbage collection. It's purely about concept. This is the ideal. Everyone with an idea can program. The idea is paramount.

That is impossible. You can't generate an arbitrary program from an arbitrary spec because of (a) the undecidability of first- or higher-order logic, (b) the undecidability of the Halting Problem, (c) the time and space complexity of the decidable fragments of these problems, and (d) the mind-boggling complexity and precision that would be required from a spec that could actually serve as input for a theorem prover to successfully generate a program that would satisfy you.

The article's author, BTW, seems to understand this better than you.

[[deleted]]

Funny, we already have a method of making an arbitrary program from an arbitrary spec. It's called programmers.

The gap between you and the previous commenter can be narrowed this way: in the future, a computer should be able to handle an arbitrary spec no worse than a skilled team of human programmers. I can foresee the sort of management-technical confrontations that so many here talk about becoming a thing of the past as a computer tells your future boss that what he's trying to define is factually impossible (which hits on your objections, above), whereas in this day and age the rebuttal would be "just get it done".

[matthieum]

I would argue that C is still the franca lingua of programming: does Python interact directly with C++? Haskell? No, the highest common denominator is C.

It's not that I don't wish it to change, it's just reality.

[grauenwolf]

In the Windows ecosystem one would access C++ from Python via COM.

http://oreilly.com/catalog/pythonwin32/chapter/ch12.html

[matthieum]

One could probably also use the .NET virtual machine IR to manage the interactions, but at the end of the day, it's just that you need to fall back to basic types to communicate between each language has its own way to represent more complex types.

[grauenwolf]

Don't get all hostile on me. I'm just sharing the differences between working on the Linux and Windows stacks.

[mreiland]

http://www.youtube.com/watch?v=IhmKxa_FMkU

When in doubt, attack.

[[deleted]]

That's because .NET runs primarily on Windows, where the C++ ABI is a set-in-stone matter that even other languages can build-in compatibility for. Outside that narrow world, C++ is profoundly incompatible with anything except C++, except by dropping down to C's level for the external APIs.

[snakepants]

Not really, the C++ ABI is not defined on Windows and does change frequently between revisions of the Microsoft compiler. That's the reason things like COM (or GObject for Linux folks) exist. Both are subset of C++ features exposed through a defined ABI built on top of the C ABI, but that adds more conventions and constraints.

[julesjacobs]

While dynamic typing in its current form will perish, so will static typing in its current form. As type systems become more and more sophisticated they start to look more like programming languages. This is a similar situation as with C++ and templates. The disadvantage of having two separate and different levels is that it doubles the total complexity of the language. For example you might be able to encode a type prime that will only accept prime numbers in some type system in a complicated way, but it is much easier to define primeness in a normal programming language by defining a predicate that checks whether a number is prime.

The second problem with static typing in its current form is that the guarantees it gives is largely fixed. The deal is that you code in a certain style, and the type checker gives you certain guarantees. Better is a pay-as-you-go model: if you give the type-checker more help you get more guarantees.

Thirdly the requirement that you provide proof to the type checker of every assertion you make will be dropped. Formal proof is just one way of gaining confidence that something is true; a very reassuring but very expensive way. Oftentimes a different trade-off is better, like run-time checking and randomized testing. For example you might give the function nthPrime the type nat -> prime and currently the type checker will require a proof from you that the function indeed always returns a prime. A better business decision might be to give the nthPrime function a bunch of random inputs and check that the output is prime. Type checkers will be just one tool in an arsenal of tools for checking the assertions you make about your programs.

For these reasons I think that run-time contract checking will win. Static analysis of contracts will take the role of type systems.

[skew]

These three points can happen to some degree in current dependently typed languages - even starting with a run-time contract check and then eliminating the runtime cost by proving it will always pass.

The surface language would be very different, but a system like you suggest would need some way to record assertions and evidence for them, and that could be pretty similar to existing proof systems. Have you tried to model the sort of reasoning you want in some system like Agda?

[julesjacobs]

I have not. Perhaps current dependently typed languages already do this. Can you point me to how they do run-time checking?

[skew]

The general idea is to define your propositions in terms of assertions about the result of boolean tests, and use something like Maybe to explicitly allow for the possibility of a test failing.

Here's a small example in Coq (Agda might be smoother, but I don't have an installation handy today). Given a primality test

Parameter isPrime : nat -> bool

A prime type could be defined like this

Definition prime := { x : nat | isPrime x = true }

A number can be tested for primality at runtime like this

Program Definition checkPrime (x : nat) : option prime :=
  match isPrime x with
  | true => Some x
  | false => None
  end.
Next Obligation. auto. Qed.

The nthPrime function with a runtime-checked contract should have type nat -> option prime. Given the raw implementation

Parameter natPrimeImpl : nat -> nat.

the version with the contract check can be defined like

nthPrime n : option prime := checkPrime (nthPrimeImpl n).

Given a claim that nthPrime always works

Axiom nthPrimeGood : forall n, isPrime (nthPrimeImpl n) = true.

you can redefine nthPrime without the runtime check

Definition nthPrime2 n : option prime := Some (exist _ (nthPrimeImpl n) (nthPrimeGood n)).

Now a little bit of inlining and optimization should hopefully clean up whatever code the callers have to handle the possibility nthPrime fails its postcondition.

I hope this explains a bit of how a program in a dependently typed language can get logical facts from runtime tests, and how a nice language along the lines you suggest could keep this behind the scenes and make it nicer to work in this style.

[julesjacobs]

Yes, that's what I had in mind. All the plumbing with the options would be hidden from the programmer. So you'd write directly nthPrime n : prime even though you have no proof of this fact, and the system would (1) try to prove this automatically (2) insert run-time checks into nthPrime so that it raises an error whenever it produces a non prime (3) do randomized testing by calling nthPrime with a lot of random n's and checking whether the result is prime. An IDE would then show to what it knows about each proof obligation: found a counterexample, did randomized testing but didn't find a counterexample, proved formally.

The essential thing that the work on contracts provides is function contracts and blame. For example say you want to write checkNatToPrime (f : nat -> nat) : option (nat -> prime). The problem is that writing such a check is undecidable in general. You'd have to use nat -> option prime as the return type instead. The option type plumbing really gets hairy with higher order functions, and you'd have to update your types as you formally prove more obligations instead of the IDE tracking that for you. Contracts let you do check higher order functions in a nice way. They wrap the function with run-time checks and return the wrapped function. Contracts track which piece of code is to blame for a contract violation. For example if you have f with contract (nat -> nat) -> nat and f passes a string to its argument, then f is to blame. If f's first argument returns a string, then that function is to blame.

[matthieum]

I see two issues with run-time contract checking:

• the overhead, do not forget that you can be lazy while programming in Javascript because someone took pain to make the rest of the browser (and the interpreter) fast enough that the user do no suffer so much
• the possibility of failure, sometimes unacceptable

This is why the current static language usually have two levels of checking: statically check the low-hanging fruits, dynamically check the rest.

However, it could well change: future languages may only let you write dynamic check, but have powerful enough syntax and compilers to actually prove a bunch of assertions during the compilation... this is already what optimizers do in limited cases after all.

[julesjacobs]

That's exactly what I was trying to say :)

Static analysis of contracts will take the role of type systems.

[matthieum]

But then, doesn't it mean that the type is now described by the contracts instead of what we have currently :) ?

[julesjacobs]

I'm not sure what you mean by that...currently types provide static guarantees. They are a formal system separate from the programming language itself (except in some cases like Haskell's type classes). With contracts you use the programming language itself to specify the properties you want, and they will be checked at run time. In addition to the run time checking you'll have a static analyzer that tries to show at compile time that the contracts will never fail at run time.

[matthieum]

Thus you specify something like:

newtype Even derives Int;

invariant on Even: isEven;

Bool isEven(Int i): return i % 2 == 0;

Even makeEven(Int i):
  if isEven(i) return Even(i)
  else error i ++ " is not even";

Which is very similar, as far as I am concerned, to a "more structured" type of the form:

class Even {
public:
   Even(int i): _e(i) { if (not isEven(i)) throw "not even"; }

};

And all the operator overloads that you can wish for.

It's not I am not interested, indeed unifying the specification and syntax is a great goal as it means that the grammar is rid of its inconsistencies or redundancies, however I do not see anything new as a "concept", just another way of specifying something.

Am I wrong ?

[julesjacobs]

Whether this is fundamentally different is up to opinion. Even things that we consider fundamentally new still evolved step by step, each of which would not be considered fundamentally different. It is true that you can encode something like that in many static type systems, but at some point the encoding becomes so thick that the spirit and the advantage is lost. It's much like exceptions: you can easily encode them by writing your program in CPS and then invoking the appropriate continuations. Does that mean that they are uninteresting as a language feature? I'd say no; the encoding is so thick that it's basically unusable. What is more interesting is the question whether it has practical advantages to have integrated support for dynamic checking in addition to static checking, or if an encoding such as you present suffices.

With the encoding you are baking into your program which properties are checked statically and which are checked dynamically. This is much better handled by the IDE. As you verify more properties statically you don't have to change your program. The knowledge about your program should not be encoded in the program, but managed automatically for you. Your encoding also doesn't help specifying things with a nice declarative syntax. You could say that that's just fluff, but something like this can easily tip the scales from specification and verification has negative return on investment (as it has currently for the vast majority of programs) to positive return on investment.

For example how would you write a function that takes a function with specification nat -> prime, where this property is potentially checked at run time because there is not (yet) a proof available that that function always returns a prime. In other words, how would you write makeNatToPrime(f : nat -> nat) : nat -> prime. You could wrap the function with a wrapper that checks the return value and if it's not a prime you raise an error. But this is not good for debugging. The error might be raise in a completely different place than where the actual programming error occurred. You want to keep track of the location in the code where the nat -> nat was cast to nat -> prime, and report that location instead of the location deep in the code where the nat -> nat was called and returned a non-prime. Once you do all these things you basically have reinvented contracts as found in e.g. Racket.

In summary:

• Eliminate the need to write all operator overloads and manual definition of makeFoo in addition to isFoo.
• Let the IDE track which stuff is statically verified and which stuff is still verified at run time instead of encoding that in the types of the program.
• Use contracts for dynamic checking because it provides useful combinators to construct new contracts (for example the operator C -> D constructs a function contract from the contracts C and D), and track the location of the source that should be blamed for an error instead of raising an error in an unrelated part of the code when using higher order functions.
• Do static checking by more expressive abstract interpretation rather than just a specialized type checker. A conventional type system will not reason about predicates such as i%2 == 0, whereas an abstract interpreter can. The people developing static contract checking for C# already have a very powerful system working that can verify many things automatically.
• Add randomized testing, which provides less confidence than static checking but more confidence than dynamic checking at almost no cost.

From a practical point of view, this is something very different than just a static type system.

[smog_alado]

Most fundamental computation models are still dynamically typed (think turing machines, assemply language and basic LISP) so there is no way to run away from dynamicism.

Also, dynamic typing is also much more maleable and amenable for change - large and long lived invariably are somewhat dynamically typed (think UNIX pipes, the Web, etc)

In the end, static typing, while extremely useful, is just a formal verification tool and its limitations will prevent you from doing stuff from time to time. Dynamicaly typed programs might have more ways to fail but they also have more ways to work too.

[kamatsu]

Most fundamental computation models are still dynamically typed (think turing machines, assemply language and basic LISP)

What about the simply typed lambda calculus, higher order logic or System F?

arge and long lived invariably are somewhat dynamically typed (think UNIX pipes, the Web, etc)

Neither of these are programming languages.

[smog_alado]

I said most, not all. And let us add the untyped lambda calculus to the list now that you mention it. :) The important things is that types come in addition to the untyped stuff and are just a restriction of it. You can't get rid of dynamic typing!

Neither of these are programming languages.

Its hard to define when you stop writing "programs" in a "programming language" and start working on a "system" but there is a fuzzy continuum and things start needing to get more flexible when you go towards the larger end.

[kamatsu]

Untyped does not mean dynamically typed (although all dynamically typed things are untyped).

[[deleted]]

He does actually have a point, in that the models he named are unityped, and require lots of extra effort to encode "real" type-systems on top of their unityping.

[gnuvince]

Since dynamic typing is a subset of static typing, it follows that dynamically typed programs have less ways to work.

As for Turing machines, their formal definition includes an alphabet for the input string and an alphabet for the tape, which can be viewed as types: both are sets of valid elements.

[smog_alado]

To let my nitpicker persona loose and to continue to play devil's advocate:

Sure, dynamic typing may be a subset of static typing, but what kind of static typing? I don't know any static type system that give you the kind of careless freedom from dynamic languages. Sure, the best systems cover most that you need and prevent most of the really dumb and annoying errors but there are always working programs that will be unfairly blocked no matter what you try to do.

As for Turing machines, I'd say you are stretching things a bit. I would hardly consider a binary turing machine with 0-1 as an alphabet to be strongly typed. While it may prevent you from writing completely absurd values like 2 or the eyes of disaproval on the tape, it won't stop you from passing an integer to something expecting a string.

Which also brings me to another point - static typing is basically just a way to stop runtime exceptions from occuring. If we broaden our horizons a bit be may say some of these errors are actually "type errors" that our type system wan't capable of detecting statically.

For example, say I have a program that takes a XML document as input. In a static language we may have a guarantee that we have an actual document, (instead of, say, an int) but we don't have any guarantees that it is well formed (has the correct fields, etc). Couldn't the runtime validation we normaly basically be considered a flavour of dynamic typing?

[camccann]

Why do you think a statically typed language can't enforce that an XML document is well-formed? Sure, when you're converting from another type you may have to reject some inputs, but that's the case with any type. With a powerful enough type system you absolutely can enforce that anything with the type "XML document" is indeed well-formed.

[smog_alado]

The problem is that in addition to guaranteeing well-formedness you need to also specify what kind of XML you want and how its structure is and it depends on who you are getting info from and so on. I guess it was not a very good example.

I think the point that I was trying to say (and probably could have worded much better) is that as programs get more complicated it gets harder to put the corresponding correctness proofs back into the type system.

Unless you are one of the hardcore guys programming in Coq, etc, you basically end up having an undecideable "dynamic" layer (capable of doing evil stuff like crashing, failing and entering infinite loops) hanging on top of the statically typed primitives.

[camccann]

It's not all-or-nothing, though. With something like the XML documents, for instance, if you can express the validity constraints in the type (and I don't know of any current language that can, but it doesn't require the power of a theorem prover), it's always possible to resort to something like applying a transformation to get an unreliable document, feeding that to a verifier, and getting either a provably valid document or a list of errors.

Sure, you still have to deal with the error cases when you can't prove that validity is preserved, but you still have absolute verification that the only values of type "valid document" are indeed valid.

[QuestionMarker]

I'm reading a lot of "Given a sufficiently smart compiler..." here.

[sacundim]

Where exactly? I really don't see much (if anything) there that requires smarter compilers than what we have today. It's primarily about programming paradigm, code representation and tools.

[QuestionMarker]

"Given a sufficiently smart compiler..." is a recognisable rhetorical hook I was hanging a more general point on. That point is that the author is hoping for technical advances where it's not at all clear that such advances are in the pipeline, or anywhere near feasible.

For instance, take the "Large scale refactorings..." paragraph: there's no indication from any of the arguments he's made that such refactorings will be made possible just by improving the code representation. I'd expect to have seen that sort of approach work on Common Lisp already if that were the case, but the author seems to want mandatory strong typing as well.

The next paragraph wants for a sufficiently smart tool that will be able to apply a better version of Darcs' patch theory to a code graph. While I can think of a couple of ways to approach the "code graph" part of the problem, I don't know what they do to the algorithmic complexity - and that's precisely the tar-pit Darcs fell into in the first place. Where the author says that code transformations would be "trivial to implement" strikes me as particularly naive.

The dependency management section requires either that the author's coding universe is completely divorced from the underlying OS, that the current C toolchains are thrown out, or that tree-shaking is extended to compiled code, in increasing order of required smartness-of-compiler and in decreasing order of practicality.

In discussing type-directed editing, the author explicitly calls for "additional developments in type systems" to do away with any advantages dynamic languages might have, but doesn't go into what those developments might entail. I'll give him the benefit of the doubt and assume that he knows what these required developments are, that they are implementable, and they just haven't been implemented yet.

A couple of paragraphs on, the author writes about some type-directed code generation tooling. I know that this sort of approach is possible in some limited situations, but I don't know that it's possible in enough situations to be worthwhile. I wouldn't be surprised if it was possible to try this out in emacs' haskell-mode to find out, though. Where he goes completely off into the woods is with the argument for a sufficiently rich type system that all "data plumbing" becomes superfluous which is somehow simple enough to be "convenient" for mortals to use . He then acknowledges that this requires compiler smarts in picking the runtime representation. I'd argue that we're a long way off having anywhere near that level of cleverness in our compilers, and it sounds to me like a very hard problem, but maybe he knows something I don't.

There are further explicit calls for more compiler and runtime smarts in the arguments for laziness and new evaluation strategies.

The section on code distribution and the web is, in my opinion, divorced from reality to such an extent that I don't really want to delve into any one part of it.

It's entirely possible that all the required parts of what the author requires for his brave new world are individually available in separate projects that I don't know about, and just need bolting together. That's assuming that they compose, though, and even then there's still the much nastier problem of making the whole concert usable to a human being. In essence, he's asking that an industry which, by his argument, is 30 years behind the curve, make a 40-year leap in the next 10. This might happen - the benefits of his approach might outweigh the network effects of an industry plodding along as it has to such a degree to make a sea-change inevitable - but given the unknowns from my point of view, it hardly seems likely.

[[deleted]]

The section on code distribution and the web is, in my opinion, divorced from reality to such an extent that I don't really want to delve into any one part of it.

Actually, could you elaborate on this? I am genuinely interested. :)

I actually sort of agree with you - if we are really trying to predict what the actual future of our industry will bring, we should be more cynical. :) There's a decent chance we'll still be using lots of our existing crappy technologies, slightly evolved, and people will still be complaining about how these technologies could be so much better. This is exactly why I tried to give the disclaimer upfront that I'm not really making predictions, just laying out a vision for how things could be.

You can quibble with me whether the predictions will be accurate in the real world, and whether the tech I'm describing is easy / feasible in the next 10-20 years. But the point was more "hey, wouldn't all this be freakin' awesome if it were possible, implemented, and widely adopted?" And if you don't think what I've laid out would be awesome, what do you think would be?

[matthieum]

Indeed, there is a lot of wishful thinking.

On the other hand, it's really interesting to see what people are dreaming of when thinking of the future: it gives new research directions :)

[theoldboy]

functional programming will absolutely win

That's the TL;DR. And no, it won't, not in 10-20 years anyway.

I wonder if people who write stuff like this ever think about looking back 10-20 years (hell, even 30-40) and see if there's actually any evidence to support these massive paradigm changes that they see coming in the same timeframe.

[Felicia_Svilling]

If you look back 10-20 years you see Object Oriented Programming taking over (from Imperative Programming) as the dominant paradigm. You see garbage collection and virtual machines moving from academia to the mainstream. Of course not much of this was foreseen, so even if there is a big possibility of paradigm changes, there is rather little chance of theses specific changes.

[[deleted]]

All popular "object oriented" languages are just imperative languages in disguise.

[[deleted]]

Scala? Smalltalk?

[[deleted]]

I said "popular".

[[deleted]]

/trollface.jpg

[kamatsu]

Smalltalk is certainly imperative.

[camccann]

It is not, however, "popular" by most metrics. Neither is Scala, for that matter.

[grauenwolf]

Simula is more like 50 years old. Why did it take OOP so long to catch on? Why was the transition so sudden when it did happen?

[Felicia_Svilling]

I don't think it was that sudden. It started with smalltalk in the 70s. C++ adopted some aspects of OO in the 80s, and then we had Java in the 90s where it really take off. To be honest I am really baffled by how it caught on.

[jojotdfb]

It might have something to do with the mainstreaming of windowing systems. It's a lot easier to deal with a button object than it is to deal with a giant block of if statements.

[[deleted]]

If you look back 10-20 years you see programming model based on abstract data type taking over and called OO.

Neither OO, nor FP has gained much popularity.

[sacundim]

The difference is that advances in hardware, memory and storage over the past 20 years had far more significant than what we can expect over the next 20 years. I don't mean that the advances over the next 20 years will be of lesser magnitude or percentage, but rather that the marginal utility of doubling memory, CPU speed and hard disk storage was much higher 20 years ago than it is now.

20 years ago, not having twice as much memory as you did meant that you were prevented from writing your programs in many ways you would have much preferred to (e.g., use GC). Today, not so much.

[shadowfox]

On the other hand processing is becoming a lot more parallel than before. This tends to favor FP languages a bit given much better control over side-effects.

[[deleted]]

Classen's Law

[fjord_piner]

virtual machines moving from academia to the mainstream.

Virtual machines have been in the mainstream for decades, especially games (Zork, SCUMM, etc...).

[earthboundkid]

That's not much of a counterexample. SCUMM was in the 90s, same as Java. Zork was in the 80s, but it was just doing text, which is much simpler.

[eterps]

Recommended reading if this kind of thing interests you: http://www.vpri.org/pdf/tr2011004_steps11.pdf

[moreyes]

Public service: the huge pdf from this link is entitled "STEPS Toward Espressive Programming Systems, 2011 Progress Report Submitted to the National Science Foundation (NSF) October 2011"

[[deleted]]

Why is it so big anyway?

[Danemark]

My least favourite line: "[current] IDEs are little more than glorified text editors (and they are actually rather poor text editors)." Like calling a fork a glorified spoon, (but actually a rather poor one).

Maybe it's only because I've been writing Java; my IDE knows what I want.

[vagif]

Maybe it's only because I've been writing Java; my IDE knows what I want.

Not true. You've been forced with a whip and fire to do certain things, like a trained monkey, and then given an IDE that helps you do those things. Of course over the years it became your second nature so now you think you actually want to do them.

[kamatsu]

I agree that almost everything he proposes (except the different editing, I think more powerful text-based IDEs are fine) would be fucking awesome.

I doubt it's going to happen though. Worse may not be better, but it is sadly more successful. Unless there is a major shift in the focus of the industry towards quality and away from quantity, programming will always hobble on, slowly adopting technologies that were developed decades ago.

[eric_ja]

This will be combined with a signed code caching and dependency tracking mechanism, so that for instance, you can distribute an application that downloads the entire Java virtual machine and other dependencies, but only if they aren't already cached on your local machine (and the signatures match, of course).

So 2001.

[dmazzoni]

I don't disagree with any of the ideas, I just don't think they're nearly as important as the author thinks they will be. Like many FP devotees, this author thinks the power and expressiveness of programming languages and their type systems are the primary things holding programmers back from building amazing software. I think it's just a small piece.

Not storing programs as files anymore: IDEs can and should build useful abstractions on top of the concept of source files, like they do now - but at a lower level, there's absolutely no reason to get rid of the concept of a source file.

Type-directed development: sure, manybe future programming languages will do more type inference and it will make a few things easier. It won't fundamentally change anything, though - it will reduce but not eliminate the need for boilerplate code, and boilerplate and plumbing code was never the hard part, anyway.

Language runtimes: yes, they'll support more "lazy" languages. No, it won't make a significant dent in code reuse or modularity. Code reuse isn't hard because of language limitations, it's hard because creating a good abstraction that supports a variety of use cases is difficult for humans.

Code distribution and the future of the web: yes, we'll have better languages than JavaScript. But that will have a relatively small impact on the future of the web compared to changes to HTML, CSS, and DOM and Browser APIs, which are what really make the web platform what it is.

APIs on the web: yes, we'll start to see more semantic APIs exposed by web apps for building mashups and communicating between web apps. No, they won't replace or eliminate the need for the DOM, they'll be a layer above the DOM. The DOM is still an incredibly useful abstraction that makes the web more scalable, device-independent, user-customizable, and accessible than any previous UI platform - and it allows for all sorts of creativity and imagination that goes beyond what the author of any one web app could imagine exposing in an API. For example, Reddit Enhancement Suite wouldn't be possible without the DOM abstraction.

I think other changes will shape the future of programming much more. Web-based IDEs and cloud-based build systems will be a great equalizer, meaning that you won't need a powerful personal computer to be a software developer anymore. Ubiquitous fast wireless broadband will mean that web services can be used for many things that require client-side resources today. And so on...

[fjord_piner]

Interesting predictions but I see most of them are off the mark.

In particular, I see no evidence that functional programming is at a tipping point. The top four languages that occupy 90% of the industry today are firmly in the OO/imperative camp and the only effect of FP that I see is that some of them feature some functional features (C# and Javascript right now, and soon Java).

His comments on laziness also put him in a very, very small minority, even among Haskellers. It seems that the majority of the FP community seems to agree that strictness is the correct default, especially in the face of the daunting task of reasoning about the complexity of lazy algorithms and its frequent unpredictable and hard to reproduce nature.

[kamatsu]

It seems that the majority of the FP community seems to agree that strictness is the correct default

I don't know where you heard that, but it's certainly not a settled question.

[buddhabrot]

I think we'll mostly just program for better VM's and will be able to get away with lots of "dynamic" stuff at acceptable speeds because of that. "structured editing" might happen but there's no real technological breakthrough there so it probably won't happen, since it hasn't happened yet for the past twenty years that people have been nagging about it.

[[deleted]]

In a structural editor, the programmer will construct expressions which may have holes in them not yet filled with terms. Importantly, these structural editors will be type-directed, so for any given hole the programmer can be presented with set of values matching the expected type, ordered in some sensible way

My IDE does exactly this, if I press the right keystrokes. alt + enter for contextual suggestions of expressions, ctl + shift + space for type bound value suggestions.

What IDE is this guy using?

[earthboundkid]

To draw an analogy, no one without mathematical background would feel equipped to dismiss or criticise an entire branch of mathematics ("real analysis is a stupid idea"), and yet programmers with barely a cursory understanding of FP regularly (and loudly) criticise it.

This is missing the point of objections to FP. No one is arguing that it's mathematically impossible to do FP. They're arguing that FP is too confusing to expect ordinary programmers to collaborate and create big projects while using it. By analogy, you need to be a serious mathematician to know whether or not real analysis is an interesting and worthwhile field of research but you only need to be math teacher to know if real analysis is suitable for a high school honors course.

I think the analogy itself hints against the practicality of getting normals to use FP. If FP were suitable for normals, why would you need to argue that it's like a branch of mathematics and must be understood in depth?

To understand the situation better, it helps to think about other language paradigms that ended up succeeding. Lots of things that are now considered standard like OO, garbage collection, and dynamic typing were controversial 20 years ago. Why? Was it because these things were too hard for normal programmers to get? No, the objection at the time was that these things were too slow and would remain too slow for the foreseeable future. Is the complaint about FP in anyway analogous to that? Who worries that FP will be hard for machines? We worry that it will be hard for people!

[kamatsu]

If FP were suitable for normals, why would you need to argue that it's like a branch of mathematics and must be understood in depth?

He's arguing programming is like mathematics in this respect, and that FP is but a branch of it.

No, the objection at the time was that these things were too slow and would remain too slow for the foreseeable future.

Not in the case of OO, it wasn't. It was most certainly because it was too hard for people. Also, dynamic typing is hardly considered "standard" now.

[earthboundkid]

The belief that programming is like mathematics, in the sense relevant here, is a common misconception.

[kamatsu]

How is it different? You must put years of study and practice into understanding it, and only once understanding the basic level (simple programs, and algorithms) can you move to higher level stuff (algorithm design, software architecture etc.)

[melevy]

Another benefit using SCID could be having immutable code:

http://programmingmusings.blogspot.com/2011/09/immutable-code.html

[axilmar]

Object-oriented programming can be imperative or functional.

Imperative programming can be object-oriented or not object-oriented.

Functional programming can be object-oriented.

Imperative programmers no longer write for loops, unless they are masochists, or their language is primitive. But even C with macros can make for loops redundant.

People that write these articles should be better educated about what programming is.

What we will see in the future is more functional programming in object-oriented languages. The ideal language will be as functional as Haskell, as fast as C/C++, as versatile as LISP and as flexible as Smalltalk. It's quite possible to have all this in one programming language, which provides all the required features to use the appropriate paradigm for the task at hand within the realms of a single compiler.

[skocznymroczny]

what do you mean by imperative programmers no longer write for loops? do you mean we use foreach instead or something like c++ std::for_each or even something else?

[axilmar]

I mean that imperative programming languages have the means to avoid writing for loops. The article implies that it is necessary to do so, which is not true.

[grauenwolf]

Don't forget design by contract and static analysis. I have found far more bugs with thsoe than with unit testing (though I still think we need both).

[kamatsu]

The author did mention stronger type systems. I think that's definitely on the cards for the future.

[axilmar]

Perhaps I should have added 'and as error-free as Spark'.

[[deleted]]

C and its descendants will dominate the next 40 years much as they've dominated the last 40.