There’s no such thing as the perfect programming language. I’m sorry, but there isn’t, and I’ll explain why.

On the other hand, if you were set the task of designing the perfect language, how close could you get, how would you go about it, and what would it look like in the end? We’re going to explore this problem space with a tour along the bleeding edge of modern language design, giving you some insight into what’s already out there, what tradeoffs each new idea comes with, and what sort of tools you might be working with in a future where programming is slightly less awful than it is today.

There’s no such thing as the perfect programming language. I’m sorry, but there isn’t, and I’ll explain why.

On the other hand, if you were set the task of designing the perfect language, how close could you get, how would you go about it, and what would it look like in the end? We’re going to explore this problem space with a tour along the bleeding edge of modern language design, giving you some insight into what’s already out there, what tradeoffs each new idea comes with, and what sort of tools you might be working with in a future where programming is slightly less awful than it is today.

The ECMAScript 2015 specification introduced iterators, which generalize iteration over common data structures, as well as providing an interface for allowing you to iterate over any custom data structures using common language constructs. ES2015 also introduced generator functions, which make writing arbitrary iterators a lot easier and less boilerplatey.

But generators aren’t just for making simple iterators over data structures. Because they’re bidirectional—they don’t only produce output, they can also take input—they’re actually coroutines, which means there’s no end to the sort of fun you can apply them to. We’re going to explore how we can use them to make asynchronous programming in JavaScript a lot more elegant—to chart a path out of callback hell. And then we’re going to take a look at what we’ve really discovered: one of the most fearsome mysteries of computer science, suddenly laid bare before us.

The ECMAScript 2015 specification introduced iterators, which generalize iteration over common data structures, as well as providing an interface for allowing you to iterate over any custom data structures using common language constructs. ES2015 also introduced generator functions, which make writing arbitrary iterators a lot easier and less boilerplatey.

But generators aren’t just for making simple iterators over data structures. Because they’re bidirectional—they don’t only produce output, they can also take input—they’re actually coroutines, which means there’s no end to the sort of fun you can apply them to. We’re going to explore how we can use them to make asynchronous programming in JavaScript a lot more elegant—to chart a path out of callback hell. And then we’re going to take a look at what we’ve really discovered: one of the most fearsome mysteries of computer science, suddenly laid bare before us.

The ECMAScript 2015 specification introduced iterators, which generalize iteration over common data structures, as well as providing an interface for allowing you to iterate over any custom data structures using common language constructs. ES2015 also introduced generator functions, which make writing arbitrary iterators a lot easier and less boilerplatey.

But generators aren’t just for making simple iterators over data structures. Because they’re bidirectional—they don’t only produce output, they can also take input—they’re actually coroutines, which means there’s no end to the sort of fun you can apply them to. We’re going to explore how we can use them to make asynchronous programming in JavaScript a lot more elegant—to chart a path out of callback hell. And then we’re going to take a look at what we’ve really discovered: one of the most fearsome mysteries of computer science, suddenly laid bare before us.

In the space of only 45 minutes, we’ll attempt to introduce asynchronous functional programming in JavaScript with RxJS, apply it to solve the problem of callback hell once and for all, and write a complete game using RxJS, JQuery and ponies.

The programming paradigms that served us so well through the 80s and 90s are failing us. Building systems the way we're used to building them always seems to end in the inevitable death march towards exponential complexity. But once you stop to ask the right question- "what's really causing all this complexity?" - you realise the answers have really been staring you in the face all along. Debugging is only hard when you can't reason about your code. Concurrency is only hard when you can't predict the state of your code. Reusability is only hard when your components aren't naturally composable.

Fortunately, languages addressing these issues specifically are popping up all over the place. In many cases, it turns out we've had the solutions to our problems for a long time, we've just forgotten about them, or never really bothered to look. Let's take a moment to explore some of these languages, not as exercises in syntactic details, but looking at the inherent properties in their design that enable us to defy decades of OO tradition and write honest-to-Dijkstra bug free, fault tolerant software without even trying. After half a century in the wilderness, functional programming seems to finally be gaining some ground on the barbarians. Let's examine why.

In this talk, we'll explore why some technologies end up inexplicably dominating our field while others fade away despite their obvious merits. What will it take for the languages we care about to succeed, and what are the consequences of success? Let's apply a broad perspective to the mess we've made of modern computer science, and explore our options for getting the situation back on track through a careful examination of history, science and ponies.