Listen Now

Noon has a chat with LaToya Anderson, who recently completed a Tweag Fellowship focusing on open-source software for quantum chemistry calculations. Topics of discussion include LaToya's prior education as a dancer, her interests and passions for quantum computing, what interested her in the field, thoughts on how the quantum computing ecosystem should harness their public interest, and how to pursue a career in this space! Special Guest: LaToya Anderson.

With the news that Simon is leaving Microsoft Research, and now joining Epic Games, we've taken the opportunity to sit down and do a retrospective of his time at Microsoft Research and the various collaborations that have come about as part of that journey.Special Guest: Simon Peyton-Jones.Links:An Epic future for SPJ

In this episode Noon is joined by Chris Granade, from Microsoft, who talks about their background, their research path, and what brought them into quantum computing. We discuss Chris' journey to the Q# development team, and the book they have co-authored with Sarah Kaiser. We also cover Chris' vision of the necessary skills to get engaged working in the field, and some pitfalls to watch out for. Tune in for an exploration of a very interesting person and field, and to get some hints as to where functional programming and type theory might play a role in future quantum programming languages!Special Guest: Chris Granade.Links:Q# Programming LanguageQ# CommunityRobin Blume-Kohout — A list of lectures from Robin available on PIRSA.Carl Bender - Mathematical Physics - Sequences - PIRSA — This is the lecture series on convergent and divergent sequences.Nielsen & Chuang Textbook on Quantum Computation — A classic now but still, I believe, the bible. Michael Nielsen has since put out some more accessible introductions: https://quantum.country/.Alan Geller - Why do we need Q#?Learn Quantum Computing with Python and Q# — Book by Sarah Kaiser and Chris Granade.Unitary FundUnitary Fund - Discord

Noon and Isaac have a chat about the state of front-end development and Isaac's motivations in bringing a new player to the market: Shpadoinkle, written in Haskell. Isaac discusses some of the issues he has with other approaches and how he and the Shpadoinkle team have been working to resolve them!Special Guest: Isaac Shapira.Links:shpadoinkle.orgPlatonic SystemsMisoReflex FRPSketch.systemsjsaddleAsteriusA city is not a tree by Christopher Alexander

Apostolos Chalkis is a PhD student from the University of Athens. As part of his recent Tweag fellowship, he developed dingo, a Python package to analyze steady states of metabolic networks—networks of biochemical reactions that take place in any living cell—using geometric random walks and other methods from computational geometry. In this episode, Apostolos explains what metabolic networks are and how he applies Markov Chains Monte Carlo methods to understand them. Also check out Apostolos's blog post, where he shows a particular application of his package to the search for potential COVID-19 treatments.Special Guest: Apostolos Chalkis.Links:Searching for COVID-19 treatments using metabolic networkshttps://github.com/GeomScale/dingohttps://github.com/GeomScale/volume_approximationhttps://geomscale.github.io/

Rickard Nilsson is a founder of NixBuild.net, a cloud service that runs your Nix builds. He is a long time Nix user and contributor. His company - Immutable Solutions - helps companies design, develop and deploy server systems and software. Everyday he uses Nix in production.Special Guest: Rickard Nilsson.Links:NixBuild.netThe NixBuild.net blogNixBuild.net User SurveyNixBuild.net Twitter

In this episode, Robin Bate Boerop talks to Mathieu Boespflug, the founder and CEO of Tweag. Tweag is a company that specializes in functional programming and was founded in 2013, when this technology was still perceived as a niche tool for early adopters. Since then, Tweag has grown into a mature software consultancy with a wide variety of industry projects, always keeping the core principles of functional programming at heart that promote composability, reproducibility, correctness and many other desirable properties for software. Mathieu and Robin talk about the founding of Tweag and what Mathieu wanted to work on and bring to the software industry. In particular, we hear about Mathieu's interest in a diversity of programming languages, Tweag's work towards interoperability of languages via build systems, and other interests that inform the R&D that Tweag undertakes. We wrap up with some perspectives on the future of the programming industries and some trends that the industry is working on, and thoughts on interesting areas of programming-language research that are coming to the languages we know and love!Special Guest: Mathieu Boespflug.Links:Tweag's websiteTweag's engineering blog

Kicking off the first "Community Chat" session, Noon chats to Melbourne-based Hasura engineer Lyndon Maydwell (aka "sordina") about his journey into functional programming, and a recent blog post where Lyndon advocates for the philosophy of avoiding success at all costs via an incremental process. Lyndon founded the Melbourne Haskell Meetup in 2013, has organised several workshops around teaching Haskell, is the President of the Melbourne Functional Programming Association and one of the Co-Founders and chief organisers behind the successful Compose :: Melbourne conference. Lyndon presently works at Hasura on the Cloud team.Special Guest: Lyndon Maydwell.Links:Succeeding While Avoiding Success at All Costs — Blog post about Hasura project run with a "avoid success at all costs" philosophy.Hasura — Instant GraphQL APIs.~ Bows and Arrows ~ Composition as Expression — Lyndon's blog.Parse, Don't Validate — lexilambda's thoughts on how to think about functional programming.Christopher Alexander — An architect famous for promoting an "incremental" building style.Compose :: Conference — The overall website for the Compose :: Conference event.Melbourne Functional Programming Association Incorporated — Melbourne-based organisation for managing local events related to FP/Haskell.Coffin Corner — Don't get trapped here!EsolangsAdobe Cold FusionD-WaveGridLAB-Dπ-Base — Website from which Noon learned how to build a Haskell website, way back in the day!

Domen Kožar is the founder of Cachix, a popular caching service and one of the first products exclusively targeting the Nix ecosystem. He is also behind various community initiatives such as, for example, most recently a open collective fund to improve Nix' MacOS support. In this episode, Rok talks to Domen about how he came to work with Nix, his experiences with it and thoughts on how it evolves.Special Guest: Domen Kožar.Links:Domen's homepageDomen's Cachix - Never build software more than once.The Nix dev tutorialsThe Nix MacOS fund on open collective

Three core developers from the Haskell linear types team are on this show: Arnaud Spiwack, Richard Eisenberg and Krzysztof Gogolewski. They have conceived, reviewed and implemented the Haskell linear types extension that is shipped with the latest compiler version. Linear types allow to express that a function uses an argument exactly once in its type signature which opens all kinds of possibilities. In this episode, Arnaud, Richard and Krzysztof give a short introduction to linear types and then answer community questions that have been asked on reddit. The questions that are answered are outlined below. Links and further material are available on the episode website on compositional.fm/linear-types-ama . Thank you for contributing the questions and happy listening! MP3 Chapters: [00:00:00] Introduction Questions: [00 : 12 : 40] Will using linear types throughout my program improve performance? [00 : 16 : 14] If I see a function with linear type in it's type signature, what kinds of things might it tell me about the purpose or use cases for that function? [00 : 20 : 51] How might LinearTypes pave the way for an alternative to conduit,pipes, and other streaming IO libraries? [00 : 23 : 31] Are linear types inferable with the Hindley-Milner algorithm? [00 : 24 : 54] Are the current boxed linear containers the first step or all that is planned for now? [00 : 26 : 31] Are nested linear containers possible? [00 : 30 : 37] There were plans for a safe coerce-style freezing api, does that still seem workable? [00 : 31 : 44] What is the state of the linear case/let/if/where mechanism? [00 : 35 : 15] Are there any thoughts about ressource guarantees or RAII types in some far utopian future? [00 : 41 : 17] How do the Haskell linear types compare to the Rust equivalent? [00 : 48 : 02] What are the scenarios where the use of linear types makes a lot of sense? [00 : 51 : 19] Will we get linear functions taking and returning a state token that can effectively replace IO? [00 : 59 : 10] What benefit will linear types bring to a garbage collected language like Haskell? [01 : 02 : 13] Is an automatic "C-like" memory management separate from Haskell's garbage collector on the linear types roadmap? [01 : 02 : 58] Could strictness analysis results be used to suggest extra linear arrows with an optional warning? [01 : 04 : 04] What are limitations and recommendations concerning migration of existing code? [01 : 04 : 58] To what extent can a package mix code that uses linear types with code that does not use linear types? [01 : 07 : 50] What is the recommended practice for migrating existing libraries to use linear types? Special Guests: Arnaud Spiwack, Krzysztof Gogolewski, and Richard Eisenberg.Links:Call for community questions on redditThe original paper that outlined how linear types could be implemented in HaskellThe linear-types GHC proposalAll Tweag linear types blog postslinear base - a standard library for developing applications with linear types[00 : 15 : 30] GHC ticket about using linear types[00 : 18 : 40] Parametricity theorems and linear logic[00 : 33 : 00] GHC ticket about linear types and rebindable if then else[00 : 34 : 00] Workaround for linear case in 9.0[00 : 34 : 20] GHC ticket about linear let[00 : 46 : 30] Blog post about destination passing style[00 : 53 : 20] Critique of the IO Monad explanation 1[00 : 53 : 20] Critique of the IO Monad explanation 2

This episode's guest is Doug Beardsley, also known as mightybyte, director of engineering at Kadena, a blockchain company that uses Haskell in production. Doug is one of the few software engineering leaders who have used Haskell and advanced functional programming techniques in production systems for a long time at various companies. If you are interested in how he came into this position, as well as how he sees functional programming evolve and now positioned in the wider software industry, this episode is for you! In this series, Robin Bate-Boerop talks to industry leaders of the functional programming world. A decade ago, functional programming was still perceived as a niche tool for early adopters. Since then, it has grown into a mature option for the software industry and has been used in a wide variety of influential projects, demonstrating the enormous value that core principles such as composability, reproducibility, correctness can bring. Other ecosystems adopted related ideas such as elaborate type systems that were once only appreciated by academics. Robin's guests have experienced and shaped this thrilling evolution of the way we write computer programs, discussing industry trends, community insights and various technologies on the show.Special Guest: Doug Beardsley.Links:Kadena — Kadena, where Doug is director of engineering, is a hybrid blockchain platform partly written in Haskell. It consists of a public blockchain, a permissioned network, and the Pact smart contract language.Doug's homepage

We often use pre-built software binaries and trust that they correspond to the program we want. But nothing assures that these binaries were really built from the program's sources and reasonable built instructions. Common, costly supply chain attacks exploit this to distribute malicious software. Trustix, a tool developed by Tweag's Adam Höse, establishes trust in binaries in a different, decentralized manner increasing security and opening up exciting new models for distributed software supply chains and reproducibility checking. In a nutshell, Trustix verifies the build process that maps build inputs (source code, build instructions, build dependencies) into build outputs (e.g. software binaries) via consensus-based comparison of build logs from several providers. This comparison is only meaningful in ecosystems with a sizeable amount of reproducible packages such as Nix or Guix that recently gain a lot of traction. A byproduct of Trustix is, that reproducibility of software can be tracked on the large scale, across a wide range of hardware and systems. In this episode, Rok and Adam shine light on the inception, internals and various use cases of Trustix. Check it out and don't forget to look at the support material linked on the Episode's website on compositional.fm.Special Guest: Adam Höse.Links:NixOps PR — As promised, here is the link to the NixOps PR that was discussed.Trustix Introduction — Blog post on Tweag that gives an overview of Trustix.The NLNet project page — Trustix is funded by the NLNet foundation via the European Comission's Next Generation Internet program.Merkle Tree — As promised, the Wikipedia article about Merkle trees.SpectrumOS — Discussions about the particular security model of this operating system initiated the Trustix idea.

The Haskell Language Server (HLS) has shown how powerful the wealth of compile time information is that Haskell brings combined with instant feedback. For many, it is now a standard component of their development workflow. The HLS runs a complex, finely tuned machinery that handles large amounts of data about files, expressions, types and more, syncing it with the editor and continuously providing relevant information that can be displayed to the user. In this episode, Roman Cheplyaka talks to Zubin Duggal who contributed to HLS for years, personally, through various Summer of Code projects and recently as a Tweag Open Source Fellow. He explains how HLS emerged from various predecessors. the role the Language Server Protocol played in reducing the implementation efforts and then dives deep into the inner workings of this tool. If you want to understand what is happening when your editor shows information about your code, or if you want to get involved yourself to contribute to HLS or similar tools this episode is for you! Special Guest: Zubin Duggal.Links:The Haskell Language Server repositoryThe Language Server ProtocolA blog post about Zubin's work as a Tweag Fellow

In this episode, Rok Garbas interviews Théophane Hufschmitt who is implementing a content addressed storage for Nix. Théophane explains why this feature is so useful to have for build systems and why he started working on it. He also gives a glimpse into what working with the core Nix C++ codebase feels like. Nix packages are usually addressed by the hashes of all build inputs from which they are derived and not by their content, the build output. This makes a lot of sense for a package manager because we can identify and retrieve a package precisely by the sources, build instructions and dependencies that it corresponds to. However, there are situations where it is advantageous to access a package by content. For example, to avoid unnecessary recomputations when packages produce the same build outputs even when their build inputs vary - a feature called early cutoff. More information in the links below!Special Guest: Théophane Hufschmitt.Links:Tweag blog: Towards a content-addressed model for Nix — A brief overview and introduction of the why and how of the content addressable store in Nix.Tweag blog: Self-references in content-addressed Nix — This post goes into details why the combination of a build input addressed store with a content addressed store is not as easy as it seems.The original RFC that proposes to implement a CAS for Nix — New Nix features are proposed in a RFC (request for comments) document on GitHub and then reviewed. This is the original proposition for implementing a content addressable store with the associated discussion.Build Systems à la Carte — This research paper gives an overview of a variety of build system the features they support. The ability to "early cutoff" computations when certain output targets already exist will be unlocked by the content addressable store in Nix.An introduction to content addressable storage — This article gives a short introduction to content addressable storage using the example of IPFS which is also referred to in this episode.The section in the original Nix PhD thesis that already proposes a content addressed store model — This so-called intensional store model aims to make guarantees about internal properties of software packages model such as file content. This is opposed to the common extensional model in Nix that aims to only make guarantees about relevant external properties.

Subsumption, the process of figuring out whether one type is the subtype of another, is fundamental to GHC's type checker and was recently changed. In this episode, Richard Eisenberg explains what subtypes are, how subsumption works, and why some previously accepted programs will soon start to be rejected by GHC. He then talks about how these changes help with inferring impredicative types, an advanced form of polymorphism that basically allows you to put forall statements anywhere in a type signature such as inside of a list. Music by Kris Jenkins.Special Guest: Richard Eisenberg.Links:The Wikipedia article on subtyping and subsumption — "[...] a subtype is a datatype that is related to another datatype (the supertype) by some notion of substitutability, meaning that program elements, typically subroutines or functions, written to operate on elements of the supertype can also operate on elements of the subtype [...] In type theory the concept of subsumption is used to define or evaluate whether a type S is a subtype of type T. "Explanation of Levity Polymorphism on StackOverflow — This concept is briefly touched in the episode.The GHC proposal arguing for stricter subsumption judgement. — This proposal initiated a large part of the work that Richard is talking about. The changes that it brought about will be included in GHC 9.0.A short explanation of Impredicative Types on the Haskell Wiki — "Impredicative types take this idea to its natural conclusion: universal quantifiers are allowed anywhere in a type, even inside normal datatypes like lists or Maybe. [...] However, impredicative types do not mix very well with Haskell's type inference [...]"The Quick Look Impredicativity GHC proposal. — The goal of this proposal was to significantly enhance the current state of impredicative types in Haskell. It has been accepted, implemented and will also be available in GHC 9.0.

Haskell's random library has provided an interface to pseudo-random number generation for non-cryptographic applications since the Haskell 98 report. Over the last years there hasn't been much development activity on the library despite well-known quality and performance problems. Alexey Kuleshevich's blog post comparing the performance of pseudo-random number generator packages showed that even when used with a fast pseudo-random number generator, the interface provided by random slowed down the generation of random values significantly. So a little group consisting of Alexey Kuleshevich, Alexey Khudyakov as well as the two guests of this episode got together to improve the random library both in terms of quality and performance. This work culminated in the release of version 1.2.0 of the random library in late June. In this episode, we talk about the work that went into this release, and some of the things we discovered along the way. Music by Kris Jenkins.Special Guests: Dominic Steinitz and Leonhard Markert.Links:"random" in The Haskell 98 Library Report — The description of Haskell's random library as it was used for a long time.Benchmarks of "random" — The benchmarks in this blog post were one reason to consider moving to a new standard pseudo-random number generator in Haskell random.blog post on Tweag I/O — This article goes step by step through the motivation and technical details of the changes that are discussed in this podcast episode.the new version of "random" on hackage