In software development, we often face the same problem over and over again. For example, when designing user-interfaces, we need to specify the layout of components; when designing financial systems, we need to detect various patterns in changing prices. The Domain Specific Language (DSL) approach is to design a language for the specific problem domain and then use it repeatedly to solve multiple instances of the same problem.
In this talk, we look how to think about DSLs in a functional way. This lets us focus on the domain. Rather than worrying about the syntax, we start by understanding what problems we actually want to model and what is the best way to do so. Along the way, we’ll look at three fun examples ranging from a language for building 3D objects to a language for detecting price change patterns.
Get ready for some live coding in F#, but don’t worry if you have not done much F# before! You can use the ideas from this talk in any programming language and I’ll introduce all the necessary F# along the way.
You've heard the arguments in favor of functional languages: they make parallel computation easier, help you reason about your program, let you do more with fewer lines of code, etc. But what about the code? To many it's cryptic, arcane, mind boggling -- and the syntax, dating back in some cases 40 years, can be downright hideous!
Can the value of using functional languages make up for the pain associated with them?
In this talk, Garrett will make the case that, when done right, functional programs are stunningly beautiful. And not to mathematicians and logicians -- to normal folk. To the artist, the poet -- to the software craftsman that lives in all of us!
Using the impossibly dated syntax of Erlang, Garrett will dive into writing beautiful functional code. He'll cover these topics:
API design in a functional language
Function and variable names
Proper use of case and if expressions
Managing complex data structures
Common functional patterns
While examples are in Erlang, the lessons of this talk can be applied to other functional languages. If you're new to functional programming, or a seasoned expert, you will see a side of functional programming that is rarely talked about. You'll learn the fundamentals of functional programming in a novel way -- a method that focuses meticulously on clarity, readability, maintainability -- in short, the beauty of functional programming.
Functional programming has been popular for quite some time, but now we're seeing that not only ninjas, but aso laymen is starting to use some of the functional paradigms. The same with Reactive programming. Reactive data is not only for blue collar spreadsheet experts or hardcore Verilog programmers.
This talk will introduce the two paradigms combined as Functional Reactive Programming (FRP), first from a small theoretical perspective from its rise in the 90's. After the short theoretical introduction, we'll start live coding and showing practical examples of how we can use the FRP library Bacon.js to do functional reactive coding in the real world!
We'll try to implement different examples live on stage, like using WebSockets or an auto complete search field. I will try to convince and show the attendees how incredible fun it is when using Bacon.js and how we can attain state-less code without asynchronus cludder.
When you build real world applications, you are not always on the "happy path". You must deal with validation, logging, network and service errors, and other annoyances.
How do you manage all this within a functional paradigm, when you can't use exceptions, or do early returns, and when you have no stateful data?
This talk will demonstrate a common approach to this challenge, using a fun and easy-to-understand "railway oriented programming" analogy. You'll come away with insight into a powerful technique that handles errors in an elegant way using a simple, self-documenting design.
Software is a mess.
In the last 40 years I and my colleagues have been writing buggy, unspecified, and difficult to maintain software.
By doing so we have created an entire industry. We have collectively created billions of lines of unmaintainable unspecified code that will require millions of programmers to work for thousands of years to correct the mess we've made.
Where did things go wrong? Can we make things work again? Should we admit we were wrong and throw all our legacy software away and start again?
How can we make correct software, that is easy to understand and maintain?
I don't pretend I can answer these questions - but I have some idea as to what went wrong, so maybe we can learn from our mistakes.
In this lecture I'll talk about some of the biggest mistakes we made and what we can learn from these.