Conference Time
Local Time

Code Beam Lite

Thu, Mar 24
Timezone: Asia/Kolkata (IST)
14:00
14:30
15:30

    Tea/Coffee Break - 30 mins

16:00
17:00
18:00

    Tea/Coffee Break - 30 mins

18:30
  • Added to My Schedule
    keyboard_arrow_down
    Greg Mefford

    Greg Mefford - Living the XKCD 927 Dream with OpenTelemetry 1.0

    schedule  06:30 - 07:15 PM IST place Zoom people 40 Interested star_halfRate

    Have you ever experienced vendor lock-in from your observability tooling? Don't you wish you could instrument your code once and send telemetry data to multiple vendors to see what their platforms have to offer before signing a contract and investing a lot of engineering time?

    The future is now, with OpenTelemetry!

    OpenTelemetry has finally reached general availability, with the Erlang and Elixir library leading the way as one of the first official implementations to be compliant with this new industry specification. Now is the time to start thinking about how to get your services instrumented using this exciting new vendor-neutral instrumentation.

    This talk will quickly cover the basics you need to know to get started and send data to both open-source tooling and vendor platforms, so that you can get the observability you need, without being locked into a specific vendor's instrumentation library!

19:30
  • Added to My Schedule
    keyboard_arrow_down
    Brooklyn Zelenka

    Brooklyn Zelenka - BEAM to the Future: Old Ideas Made New

    schedule  07:30 - 08:15 PM IST place Zoom people 37 Interested star_halfRate

    Languages and ecosystems are more than simply syntax; they’re ways of thinking. They have features, idioms, and community standards that drive us towards certain ways of doing things. Erlang is over 30 years old, and has a very mature way of doing things. Elixir came on the scene, bringing with it some new ideas from other ecosystems. We’re seeing even more of this with BEAM languages from LFE to Alpaca to Erlog.

    Ideas come in and out of fashion. Some of them are lost and aren’t given a chance again. But as technology continues to evolve, perhaps there’s space for what’s old to be made new again! This talk will explore a few idea lost to time that perhaps have their chance to shine again. It asks what could languages would look like if history had gone slightly differently, and what depths we can plumb for the next 30 years and 50 languages on the BEAM.

Applying FP

Fri, Mar 25
08:00
09:00
10:00
10:30

    Coffee/Tea Break - 30 mins

11:00
12:00
13:00

    Lunch - 60 mins

14:00
14:30
15:30

    Coffee/Tea Break - 30 mins

16:00
  • Added to My Schedule
    keyboard_arrow_down
    Evie Ciobanu

    Evie Ciobanu - Writing Great Tests With Haskell

    schedule  04:00 - 04:45 PM IST place Zoom people 47 Interested star_halfRate

    Program correctness has always been an important topic in computer science, and is only showing growth as software becomes more complex. Statically typed functional programming provides compiler guidance and guarantees. Advanced typing features can provide additional ways to restrict and formally prove properties within the constraints of the original program.

    This has even (half-seriously) popularized remarks about how it's enough to get a program to compile to be sure it is correct. While there is some degree of truth to this (Haskell programs can escape some classes of bugs by merely enabling all warnings and having a reasonable coding standard in place), this is obviously not true for all but most trivial software.

    Formal verification can help whenever that is not possible, but it is still impractical for all but small and critical systems. We still rely on writing automated unit, property, and integration tests to ensure our programs behave in the way we expect them.

    At Hasura, we run these tests automatically in continuous integration (CI) services, and they often take up the majority of CI time. We dedicate a significant amount of time writing and maintaining these tests.

    What is a good test? How do we write good tests? How do we organize them? What's important to consider when writing tests?

    I describe common patterns and recommended style guides for writing tests that optimize for ease of reading and understanding rather than writing or modifying. It should be apparent what it is that we're testing, what are the assumptions of the test, what is being set up or arranged before the test, as well as what it is we are testing and what is the expected response. We should strive to maximize the domain information and minimize accidental complexity, such as particularities of the testing framework or programming language we're using.

    In a language as expressive as Haskell, we should be able to write unit and integration tests that are understandable and modifiable by domain experts (such as power users or product owners), not only Haskell developers.

    This can generally be achieved by focusing on getting the domain-specific data together in a record, thus making the test-relevant information easily readable and understandable.

  • Added to My Schedule
    keyboard_arrow_down
    Ayush Mittal

    Ayush Mittal - Type classes in Scala 3

    schedule  04:00 - 04:45 PM IST place Zoom people 21 Interested star_halfRate

    Type classes are a powerful tool in functional programming to enable ad-hoc polymorphism without using object orientated programming based constructs like sub typing. In this talk we look at how to create type classes using Scala 3 constructs such as ‘Givens’ and ‘Extension’ methods.

  • Added to My Schedule
    keyboard_arrow_down
    Rodrigo Girão Serrão

    Rodrigo Girão Serrão - Why APL is a language worth knowing

    schedule  04:00 - 04:45 PM IST place Zoom people 54 Interested star_halfRate

    “A language that doesn't affect the way you think about programming, is not worth knowing.” ― Alan Perlis, in “Epigrams in Programming”

    Following Alan Perlis's words, this talk will show why APL is a language worth knowing. In other words, I will devote the talk to showcasing characteristics of APL that are likely to, on the one hand, influence the way you use other programming languages, and, on the other hand, understand concepts of computer science.

    By listening to this talk, I hope to convince you that learning a language that is radically different from all the other languages you know isn't harmful. Learning a language that is radically different from all other languages you know won't scatter your knowledge or spread your brain too thin. In fact, learning a language that is radically different from all other languages you know will cement your programming  knowledge, helping you build bridges between topics you didn't even know were connected.

    To drive my point home, we take a closer look at two characteristics of APL: the fact that Boolean values are represented by the integers 0 and 1, and the fact that APL is an array-oriented language. In studying these two things, we draw connections to the traditional if statement and to list comprehensions, deepening our understanding of those.

17:00
18:00
  • Added to My Schedule
    keyboard_arrow_down
    Dean Wampler

    Dean Wampler - Lessons Learned from 15 Years of Scala in the Wild

    schedule  06:00 - 06:45 PM IST place Zoom people 74 Interested star_halfRate

    Scala 3 was introduced last year. It introduced significant changes to the language, many of which were motivated by the lessons learned from the past 15 or so years of actual use in many open-source and commercial applications.

    I'll explore these lessons and how Scala 3 addresses them. Many revolve around the pros and cons of implicits. Also, changes to the type system make it more "regular", robust, and expressive. Finally, the new, optional, and controversial "Python-like" syntax promotes even more brevity. It also acknowledges how influential and pervasive Python has become across our industry.

    But there are many practical areas where future work is required, many of which are larger than the scope of Scala itself. We still live in "dependency hell". We still use too many obsolete idioms that hide accidental complexity, rather than forcing us to fix it. What should we do about these issues? 

19:00
  • Added to My Schedule
    keyboard_arrow_down
    Dave Yarwood

    Dave Yarwood - Clojure through the lens of music

    schedule  07:00 - 07:45 PM IST place Zoom people 33 Interested star_halfRate

    You may be familiar with what map, filter, and reduce do. But have you ever heard how these functions sound?

    The Alda language is centered around the idea that music can be represented as data. alda-clj is a Clojure library that maps Clojure data structures to the music theory concepts in the Alda language, including notes and chords. The library serves as an interface that takes Clojure code as input and produces music as output.

    In addition to the basic functions that you will find in the standard libraries of most functional programming languages, Clojure's standard library offers a wealth of interesting and useful functions that facilitate working with immutable data. In this talk, we will explore the Clojure standard library by applying interesting functions like cycle, mapcat, partition and reductions to transform data that represents music. Using the alda-clj library, we will not only see the result of each function call, we will also hear the results and observe how they can help us understand how each function works.

  • Added to My Schedule
    keyboard_arrow_down
    Bob Armstrong

    Bob Armstrong - CoSy, evolved from APL via K in open Forth

    schedule  07:00 - 07:45 PM IST place Zoom people 21 Interested star_halfRate

    CoSy is a new paradigm in computing language and interface . CoSy implements the abstractions of APL , evolved from the notation of applied mathematics , winnowed thru K , in open Forth . Forth is uniquely minimal and open to the underlying hardware . In fact a Forth processor takes up just a small amount of space on an FPGA .  All in an computational notebook , log , environment for dealing with the everyday business of life , written itself in CoSy .

    While at the two poles of the computing language spectrum , APL and Forth share a number of attributes :

    • Both are interactive and interpretive at the user level .
    • Both are oriented for the creation of words , vocabulary , which work together in sentences .
    • Both are functional : words are generally structured take the result of previous words and return results to be used by following words .
    • Both tend to be extremely succinct . Definitions are delimited by just a single character .
      • K |  name : { def ... }
      • Forth |  : name  def ... ;

    Forth's goal is the minimal vocabulary necessary to create a dictionary capable of extending itself .
    It is as simple as language can be :

    • a ` word is any non blank string of characters .
      Space is the prime delimiter .
    • The syntax is noun noun verb aka: RPN

    CoSy adds plurals to Forth .

    • all nouns are lists . At the Forth level they have a 3 cell header
      `( Type Count refCount )`
       
      Lists are allocated . When  ` refCount returns to 0 they are freed .
    • Indexing is modulo -- like counting on your thumb & fingers : 0 1 2 3 4 0

    CoSy's next step is attracting the fresh heads and resources to clean it up in a Forth available across the various current chips and operating systems , and to interface thru browsers and the Web

  • Added to My Schedule
    keyboard_arrow_down
    Quy Dai Nhan Thai

    Quy Dai Nhan Thai / Christopher Anand / Curtis D'Alves - Build and solve type-safe optimization models

    schedule  07:00 - 07:45 PM IST place Zoom people 46 Interested star_halfRate

    Mathematical optimization has vast applications, e.g., image processing, machine learning. It has a huge impact on the current state of computer science and software engineers.


    Solving optimization problems involves many challenges. First, we need to build and encode the models correctly. Second, almost all useful models are computationally expensive and we need to speed them up. Finally, we need to be able to feed the model to optimization solvers to get the final numerical results.

    Fortunately, we find that Haskell, with its powerful type system and abstraction power, is perfect for this type of problem.

    We introduce HashedExpression, a Haskell-embedded domain-specific language that allows us to build and solve optimization problems. It provides users with a type-safe, correct-by-construction interface that uses Haskell type-level programming to express constraints on correctness which the compiler uses to flag many modeling errors as type errors (at compile time).


    The library implements symbolic expressions with the "hash consing" technique to achieve common subexpression elimination. We will show how using monadic type class instances help us abstract away details of the underlying lookup table and implement symbolic reverse-mode differentiation on top of it.


    For high-performance purposes, we generate low-level C/C++ code for symbolic expressions and provide bindings to open-source optimization solvers such as Ipopt or L-BFGS-B.

Mastering FP

Sat, Mar 26
09:45
10:00
11:00

    Coffee/Tea Break - 30 mins

11:30
12:30
13:00

    Lunch - 60 mins

14:00
  • Added to My Schedule
    keyboard_arrow_down
    Tony Morris

    Tony Morris - Type-hole development

    schedule  02:00 - 02:45 PM IST place Zoom people 51 Interested star_halfRate

    In this presentation, we will see coding problems, similar to those which can be found at https://github.com/system-f/fp-course/ using the Haskell programming language.

    Solving problems such as these can be daunting for many reasons and especially for beginners. A common stumbling block to these types of problems is coming up against unfamiliar problem-solving methods. For example, everyone knows how to add up the numbers in a list with a for-loop. This is a well-understood method of solving this particular coding problem.

    And then you hear the functional programmers, "just use the types" and "well you just do the only obvious thing to solve it." While true, this is not particularly helpful to someone who is not already fluent with this approach to problem-solving.

    You may have heard of using type-holes to solve coding problems. We'll be using type-holes, and a few other techniques, with the Haskell programming language to live-solve coding problems. We will solve both trivial and not-so-trivial problems while "thinking out aloud." Feel free to follow along! You'll just need Glasgow Haskell Compiler (GHC) and a text editor installed.

  • Added to My Schedule
    keyboard_arrow_down
    Anupam Jain

    Anupam Jain - Type reification with PureScript

    schedule  02:00 - 02:45 PM IST place Zoom people 21 Interested star_halfRate

    PureScript is a Haskell-like language that compiles to JavaScript. If you like Haskell, you will find yourself completely at home with PureScript. However there are a few interesting typelevel things from Haskell that are not provided by the PureScript compiler. The Type reification machinery is one of them.

    In this talk, we'll understand the concept of type reification and its implementation using the Typeable typeclass. Essentially, using Typeable we can take a runtime value and get a value level representation of its type called a Typeref, this process is called type reification, which we can then compare with other known typerefs. We'll discuss indexed and unindexed typerefs and some real world problems that can be solved by this sort of type reification.

    A significant part of the talk will involve details of how Typeable is implemented in Haskell, and how it can be approximated in PureScript even without compiler support (available as a library https://github.com/ajnsit/purescript-typeable/). We'll also discuss some alternatives approaches and their pros/cons.

15:00
  • Added to My Schedule
    keyboard_arrow_down
    Simon Thompson

    Simon Thompson - Language-independent refactorings through language-specific rewrites

    schedule  03:00 - 03:45 PM IST place Zoom people 56 Interested star_halfRate

    Programming language may share much in common, but each language has its own particular syntactic and semantic features. For example, a function application in Haskell can be an operator section, while in Erlang it can be an application of the apply function. This talk presents generic, language-independent refactoring schemes that are realised in each language by a particular set of rewrites, and is illustrated by examples from Erlang, Haskell and OCaml.

  • Added to My Schedule
    keyboard_arrow_down
    Joydeep Banik Roy

    Joydeep Banik Roy - Free Based DSLs For Distributed Compute Engines

    schedule  03:00 - 03:45 PM IST place Zoom people 32 Interested star_halfRate

    At Zeotap, we manage over 1000 data pipelines, many interlinked, across its 1st and 3rd party data assets, both in batch and streaming mode. These data pipelines were written using various compute engines like Apache Spark, Dataflow(Apache Beam), BigQuery, etc. At times, many of these pipelines would run on clusters that would face performance bottlenecks or would block due to resource unavailability(spot nodes). At those times we wished we could take a framework code and run it using another, say Spark onto Bigquery. But alas, the coupling of the domain with the platform at the code level would preempt this. We saw value in a unifying language, more precisely DSL, to combine all these data processes and make them interoperable.. Zeoflow is the result of creating such a unified data processing DSL. It is based on Free Monads and works as a high-level programming model and hence compute engines like Spark, Beam or any other can become plug-and-play interpreters. Additionally, data pipelines have other requirements it has to address like  data read/write, data quality & metric reporting, and writing easily testable & debuggable code. Hence, we went ahead and created an ensemble of applications to better manage and decouple all of the above aspects based on Free Monads and Applicatives. 

    The presentation will take you through the journey of what started as a small library with reusability and ease of modeling business rules in mind and the design principles, requirements, and functional domain modeling we followed while choosing constructs like Free and State Monads. This helped it grow into an extensible DSL-based application suite that can operate over simple SQL engines to complex Beam-based pipelines. This is a production system at zeotap and the project is in its final stages of getting open-sourced. We try to show the beauty of pure FP constructs which have been used to solve a complex real-world use case of data pipelines and data processing, in general. 

16:00

    Coffee/Tea Break - 30 mins

16:30
  • Added to My Schedule
    keyboard_arrow_down
    Grahame Dixon

    Grahame Dixon - Extending Railway Oriented Programming in Elm to Make Complex User Flows Simple

    schedule  04:30 - 04:50 PM IST place Zoom people 48 Interested star_halfRate

    What do you do with a multi-step function with different kinds of user input that may be required at different steps? 

    I'm using Elm to build a game client for Codex, a complex strategy board game by David Sirlin with lots of interesting side effects in the game design. The pure functional programming of Elm is very powerful for managing these side effects, but how should I handle when there are many different kinds of user input required to complete the behaviour of a single feature?

    There’s a “railway oriented programming” metaphor to understand how to handle multiple-steps of errors. I’ll extend this metaphor – with stations – to show how to make what looks like a complex functional problem into a simple pattern of abstraction.

    Some familiarity with functional programming idioms is recommended, though the examples themselves are easy to follow. Attendees will walk away seeing functional programming applied in a fresh way, perhaps opening their mind to alternative perspectives to approach the complicated problems in their projects.

  • Added to My Schedule
    keyboard_arrow_down
    Shakthi Kannan

    Shakthi Kannan - Fast and Curious: Benchmarking (Multicore) OCaml

    schedule  04:30 - 04:50 PM IST place Zoom people 25 Interested star_halfRate

    An oft overlooked aspect of programming language development process is benchmarking. While popular CI/CD tools such as Azure pipelines, Gitlab CI, Circle CI, Drone.io and Github Actions are regularly used for continuous testing and deployment, there is a dearth of such tools for continuous benchmarking. This is because benchmarking well is challenging due to the care needed to choose appropriate benchmarks, the complexity of modern OSes and hardware that makes it hard to obtain reproducible results, and a powerful dashboard needed to surface resultant metrics in a useful manner that can be explored interactively by the developer.

    For benchmarking the compiler of the OCaml [1] programming language, we have developed Sandmark [2]. Sandmark is a (a) suite of well chosen benchmarks aimed at exercising different performance axes including CPU, memory and IO (b) a tool to run the benchmarks, building the compiler and its dependencies under varying configuration settings and (c) a dashboard [3] to interactively explore the results of the benchmark runs. Sandmark was originally developed for supporting the Multicore OCaml [4] project, which aims to add native support for concurrency and parallelism to OCaml, and has undergone significant improvements since the initial release [5]. 

    We have learnt several useful lessons in building a continuous benchmarking infrastructure that we would like to share in this talk, which may benefit developers who work on projects where performance is critical. In this talk, I will describe the Sandmark tool, illustrate the quirks of modern OSes and hardware and how we overcame them, highlighting useful takeaways for setting up continuous benchmarking for your own projects.

    References:

    [1] OCaml: https://ocaml.org/
    [2] Sandmark: https://github.com/ocaml-bench/sandmark
    [3] sandmark-nightly: https://github.com/ocaml-bench/sandmark-nightly
    [4] Multicore OCaml: https://github.com/ocaml-multicore/ocaml-multicore/
    [5] Tom Kelly. Benchmarking the OCaml compiler: our experience, OCaml Workshop 2019, https://icfp19.sigplan.org/details/ocaml-2019-papers/3/Benchmarking-the-OCaml-compiler-our-experience

17:00
18:00
19:00
help