Podcasts about OCaml

Dangerous Dilettantes vs. Toyota Way EngineeringCore ThesisThe influx of AI-powered automation tools creates dangerous dilettantes - practitioners who know just enough to be harmful. The Toyota Production System (TPS) principles provide a battle-tested framework for integrating automation while maintaining engineering discipline.Historical ContextToyota Way formalized ~2001DevOps principles derive from TPSCoincided with post-dotcom crash startupsDecades of manufacturing automation parallels modern AI-based automationDangerous Dilettante IndicatorsPromises magical automation without understanding systemsFocuses on short-term productivity gains over long-term stabilityCreates interfaces that hide defects rather than surfacing themLacks understanding of production engineering fundamentalsPrioritizes feature velocity over deterministic behaviorToyota Way Implementation for AI-Enhanced Development1. Long-Term Philosophy Over Short-Term Gains// Anti-pattern: Brittle automation scriptlet quick_fix = agent.generate_solution(problem, { optimize_for: "immediate_completion", validation: false});// TPS approach: Sustainable system designlet sustainable_solution = engineering_system .with_agent_augmentation(agent) .design_solution(problem, { time_horizon_years: 2, observability: true, test_coverage_threshold: 0.85, validate_against_principles: true });Build systems that remain maintainable across yearsEstablish deterministic validation criteria before implementationOptimize for total cost of ownership, not just initial development2. Create Continuous Process Flow to Surface ProblemsImplement CI pipelines that surface defects immediately:Static analysis validationType checking (prefer strong type systems)Property-based testingIntegration testsPerformance regression detectionBuild flow:make lint → make typecheck → make test → make integration → make benchmarkFail fast at each stageForce errors to surface early rather than be hidden by automationAgent-assisted development must enhance visibility, not obscure it3. Pull Systems to Prevent OverproductionMinimize code surface area - only implement what's neededPrefer refactoring to adding new abstractionsUse agents to eliminate boilerplate, not to generate speculative features// Prefer minimal implementationsfunction processData(data: T[]): Result { // Use an agent to generate only the exact transformation needed // Not to create a general-purpose framework}4. Level Workload (Heijunka)Establish consistent development velocityAvoid burst patterns that hide technical debtUse agents consistently for small tasks rather than large sporadic generations5. Build Quality In (Jidoka)Automate failure detection, not just productionAny failed test/lint/check = full system haltEvery team member empowered to "pull the andon cord" (stop integration)AI-assisted code must pass same quality gates as human codeQuality gates should be more rigorous with automation, not less6. Standardized Tasks and ProcessesUniform build system interfaces across projectsConsistent command patterns:make formatmake lintmake testmake deployStandardized ways to integrate AI assistanceDocumented patterns for human verification of generated code7. Visual Controls to Expose ProblemsDashboards for code coverageComplexity metricsDependency trackingPerformance telemetryUse agents to improve these visualizations, not bypass them8. Reliable, Thoroughly-Tested TechnologyPrefer languages with strong safety guarantees (Rust, OCaml, TypeScript over JS)Use static analysis tools (clippy, eslint)Property-based testing over example-based#[test]fn property_based_validation() { proptest!(|(input: Vec)| { let result = process(&input); // Must hold for all inputs assert!(result.is_valid_state()); });}9. Grow Leaders Who Understand the WorkEngineers must understand what agents produceNo black-box implementationsLeaders establish a culture of comprehension, not just completion10. Develop Exceptional TeamsUse AI to amplify team capabilities, not replace expertiseAgents as team members with defined responsibilitiesCross-training to understand all parts of the system11. Respect Extended Network (Suppliers)Consistent interfaces between systemsWell-documented APIsVersion guaranteesExplicit dependencies12. Go and See (Genchi Genbutsu)Debug the actual system, not the abstractionTrace problematic code pathsVerify agent-generated code in contextSet up comprehensive observability// Instrument code to make the invisible visiblefunc ProcessRequest(ctx context.Context, req *Request) (*Response, error) { start := time.Now() defer metrics.RecordLatency("request_processing", time.Since(start)) // Log entry point logger.WithField("request_id", req.ID).Info("Starting request processing") // Processing with tracing points // ... // Verify exit conditions if err != nil { metrics.IncrementCounter("processing_errors", 1) logger.WithError(err).Error("Request processing failed") } return resp, err}13. Make Decisions Slowly by ConsensusMulti-stage validation for significant architectural changesAutomated analysis paired with human reviewDesign documents that trace requirements to implementation14. Kaizen (Continuous Improvement)Automate common patterns that emergeRegular retrospectives on agent usageContinuous refinement of prompts and integration patternsTechnical Implementation PatternsAI Agent Integrationinterface AgentIntegration { // Bounded scope generateComponent(spec: ComponentSpec): Promise; // Surface problems validateGeneration(code: string): Promise; // Continuous improvement registerFeedback(generation: string, feedback: Feedback): void;}Safety Control SystemsRate limitingProgressive exposureSafety boundariesFallback mechanismsManual oversight thresholdsExample: CI Pipeline with Agent Integration# ci-pipeline.ymlstages: - lint - test - integrate - deploylint: script: - make format-check - make lint # Agent-assisted code must pass same checks - make ai-validation test: script: - make unit-test - make property-test - make coverage-report # Coverage thresholds enforced - make coverage-validation# ...ConclusionAgents provide useful automation when bounded by rigorous engineering practices. The Toyota Way principles offer proven methodology for integrating automation without sacrificing quality. The difference between a dangerous dilettante and an engineer isn't knowledge of the latest tools, but understanding of fundamental principles that ensure reliable, maintainable systems.

Malcolm Matalka, founder of Terrateam, joins host Giovanni Asproni to talk about the reasoning behind choosing a not-so-widespread language (OCaml) and (almost) totally avoiding frameworks for the development of Terrateam. While discussing the reasons for choosing this specific programming language and the advantages and disadvantages of using external frameworks, they also consider a range of related topics, including static vs. dynamic typing, the use of monorepos, and the advantages of choosing a single language that can be used both for web front ends and server back ends. The episode ends with lessons learned that can be applied to other contexts and projects. Brought to you by IEEE Computer Society and IEEE Software magazine.

Edition française: Nous sommes ravi d'accueillir Florian Angeletti d'INRIA, qui est très connu pour son travail sur OCamL (anciennement Objective CamL), le langage multi-paradigme. OCamL est Open Source et très utilisé dans le métier de la recherche. Mais aussi dans certains secteurs industriels. https://ocaml.orghttps://dev.realworldocaml.orghttps://perso.quaesituri.org/florian.angeletti/https://gallium.inria.fr/blog/https://github.com/Octachronhttps://github.com/coq/coqGet in touchThank you for listening! Merci de votre écoute! Vielen Dank für´s Zuhören! Contact Details/ Coordonnées / Kontakt: Email mailto:peter@code4thought.org UK RSE Slack (ukrse.slack.com): @code4thought or @piddie US RSE Slack (usrse.slack.com): @Peter Schmidt Mastodon: https://fosstodon.org/@code4thought or @code4thought@fosstodon.org Bluesky: https://bsky.app/profile/code4thought.bsky.social LinkedIn: https://www.linkedin.com/in/pweschmidt/ (personal Profile)LinkedIn: https://www.linkedin.com/company/codeforthought/ (Code for Thought Profile) This podcast is licensed under the Creative Commons Licence: https://creativecommons.org/licenses/by-sa/4.0/

What are Adam and Dax - and Terminal - doing in NYC this week? And what do they need to build for it? Why is OCaml involved? Adam realizes he hasn't been using AI in regular life, watching YouTube to sort out trauma, and did we all waste our 20's?Want to carry on the conversation? Join us in Discord. Or send us an email at sliceoffalittlepieceofbacon@tomorrow.fm.Family Feud Game OverviewTanner LinsleyKent C. DoddsJSNation 2025React SummitKen WheelerWes Bos DeveloperScott Tolinski's HomepageCarson GrosschantasticLizTerminal Initial CommitOCamlSentryahrefsReScript LanguageUser ManagementJane StreetPodcast HostingMythical Kitchen RecipesReddit DiscussionsTopics:(00:33) - 3rd time's the Terminal charm (09:31) - What do we need to build for the thing? (24:19) - OCaml and Jane Street (29:19) - Dax explains steaks to Adam (37:00) - Do you ask AI in normal life? (46:42) - Where would you go on your first visit to NYC (49:33) - Watching YouTube to sort out trauma (51:25) - Did you waste your 20's?

Fredrik talks to Evan Czaplicki, creator of Elm about figuring out a good path for yourself. What do you do when you have a job which seems like it would be your dream job, but it turns out to be the wrong thing for you? And how do you escape from that? You can’t put the success of something you build before your own personal and mental health, no matter how right the decision may be for the thing you build. Is there ever a reproducible path? Aren’t most or all successful things in large part a result of their circumstances? Platform languages and productivity languages - which do you prefer? Thoughts on the tradeoffs of when and how to roll things out and when to present ideas. Evan’s development mindset and environment, and the ways it has affected Elm’s design - all the way down to the error messages. Finally, of course, the benefits of country life - out of the radiation of San Francisco. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Evan Elm Prezi Guido van Rossum Brendan Eich Bjarne Stroustrup Hindley–Milner type inference Gary Bernhardt Talks by Gary SIMD Standard ML Ocaml Haskell Lambda calculus Algebraic data types Type inference Virtual DOM Webbhuset Dart Safari’s no performance regressions rule Sublime text GHC Nano Emacs Titles The personal aspects A culture clash I wasn’t supposed to be here This numb feeling I’ve never really been to the real world Is this even real? The path that Guido did This is you This isn’t for me, and it’s your fault Valuing my own health Reckless indifference A dispute between colleagues A nice solution will come out if you’re patient enough Here’s your error message: good luck Farmer’s disposition These are good years Getting paid in chickens for web development Finding a place

OCaml has one of the best-loved compilers available, and parts of it are surprisingly pluggable, so it's not surprising that someone would eventually try to wed OCaml with JavaScript and the web browser. In fact, the ecosystem has gone further, and there are now a bevvy of options for people who want to write OCaml and run it in the browser, or want to write OCaml in the browser, or want to write something that looks like JavaScript but runs OCaml on the backend.Joining me to explore the OCaml-meets-JavaScript world is Antonio Montiero. He's a key maintainer/contributor for Melange and ReasonML, as well as several other interesting OCaml web projects.We kick off by discussing the benefits of OCaml and how it clicked with him personally, before we dive into how and why the compiler is being adapted and tweaked to take it to a whole new audience of web-hungry developers.–Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinSponsor Antonio's Work: https://github.com/sponsors/anmonteiro/–The OCaml Platform: https://ocaml.org/platformOCaml on Discord: https://discuss.ocaml.org/t/ocaml-discord-server/1884ReasonML: https://reasonml.github.io/en/What is Melange? https://melange.re/v4.0.0/what-is-melange.htmlMelange for React Devs: https://react-book.melange.re/The Melange Playground: https://melange.re/v4.0.0/playground/js_of_ocaml: https://github.com/ocsigen/js_of_ocamlFUN OCaml Conference: https://fun-ocaml.com/Kris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins

In this episode of ACM ByteCast, Harald Störrle hosts ACM Fellow and Software System Award recipient Xavier Leroy, professor at Collège de France and member of the Académie des Sciences. Best known for his role as a primary developer of the OCaml programming language, Xavier is an internationally recognized expert on functional programming languages and compilers, focusing on their reliability and security, and has a strong interest in formal methods, formal proofs, and certified compilation. He is the lead developer of CompCert, the first industrial-strength optimizing compiler with a mechanically checked proof of correctness, with applications to real-world settings as critical as Airbus aircraft. In the past, he was a senior scientist at INRIA, a leading French research institute in computer science, where he is currently a member of the Cambium research team. His honors and recognitions also include the ACM SIGPLAN Programming Languages Achievement Award and the Milner Award from the Royal Society. Xavier shares the evolution of Ocaml, which grew out of Caml, an early ML (Meta Language) variant, and how it came to be adopted by Jane Street Capital for its financial applications. He also talks about his interest in formal verification, whose adoption in the software industry is still low due to high costs and the need for mathematical specifications. Harald and Xavier also dive into a discussion of AI tools like Copilot and the current limitations of AI-generated code in software engineering. The conversation also touches on ACM's efforts to become a more global and diverse organization and opportunities to bridge the gap between academia and industry.

@kerollmops, the technical brain behind the open-source search engine Meilisearch, joins me for a nerdy chat about all things search. I've been using this blazing fast tech for my own business, podscan, and kero has helped me through a few challenges over the last few weeks. I really want to dive into the economics of building a business on top of an open-source piece of software. Let's chat about self-hosted search engines today!This episode is sponsored by Podscan.fmThe blog post: https://thebootstrappedfounder.com/kerollmops-from-hackathon-to-success-the-meilisearch-story/The podcast episode: https://tbf.fm/episodes/340-kerollmops-from-hackathon-to-success-the-meilisearch-storyCheck out Podscan to get alerts when you're mentioned on podcasts: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

In today's episode, we welcome Matt Pocock, an educator, content creator and engineer who used to be a voice coach. Now, he teaches Typescript on his YouTube channel and is building Total Typescript, the most comprehensive TypeScript course available out there. We talk about his transition from a completely unrelated field into tech, the importance of great communication, TypeScript's future, AI tooling and job hunts! A lot more else is covered in this video, so get cozy and tune in into this gem of an episode! Learn back-end development - https://boot.dev Listen on your favorite podcast player: https://www.backendbanter.fm Matt's X/Twitter: https://x.com/mattpocockuk Total Typescript: https://www.totaltypescript.com/ Timestamps: 00:00 Intro 01:15 What did Matt do before becoming a dev? 03:15 Career Transitions from a non-math background 04:02 What makes a good programmer? 06:46 Math knowledge > great communication? 08:55 On writing elaborate PR's 09:58 OCaml my Typescript 11:00 What is Typescript's Future? 14:21 Python type hinting and JSDoc 20:36 null vs undefined 25:02 interfaces vs type aliases 32:35 Does Matt have any rules of thumb when working with types? 37:14 How do you build nice encapsulated components with no external dependencies? 43:43 AI tooling integration 46:15 Will there be fewer jobs? 52:00 How often do you use classes? 54:29 Where to find Matt

For our 25th episode of the Software Freedom Podcast we are happy to welcome Hannes Mehnert, one of the MirageOS core developer. Matthias Kirschner, president of the FSFE, and Hannes talk about MirageOS. This episode gives an overview of everything from the basics to the future of MirageOS. Join the FSFE community and support the podcast: https://my.fsfe.org/support?referrer=podcast

In today's episode, we welcome Ken Wheeler, a dope programmer, who creates cool projects and just gives them away for free, helping thousands of developers worldwide, a based beatmaker and just in general a cool person. In this episode, we talk about AI, React, OCaml, why stressing over specific frameworks is not worth it, advice for new developers, HTMX, SPA's and a LOT of other stuff, so stay tuned! Ken's X/Twitter: https://x.com/ken_wheeler Timestamps: 00:00 Introduction 00:25 Do you hate AI? 02:10 How diffusion works 17:47 First impressions with writing Go 18:29 Where's the line between Backend Development and DevOps 24:11 Does anyone version their REST? 24:57 urql 25:38 Offloading the data work to the other side 29:55 Wordpress is 80% of the websites 31:15 HTMX 33:12 Single Page Apps 34:02 Is React still your go-to 36:38 Is it hard to switch from React to Vue? 39:37 Picking a first language to learn 40:43 OCaml 43:12 HEX and raw Binary Data 44:42 Bluetooth powered crossbow 52:20 What got Ken into doing talks 58:45 Where to find Ken

Taylor Otwell and Ryan Florence join us to talk about whether "full stack" is a term worth using in 2024, how Laravel differs from Rails, why there isn't a real JavaScript community, what Taylor would like to see from the Remix community, and whether Laravel is like Canada. Want to carry on the conversation? Join us in Discord.wip: terminalButcherBox: Meat Delivery SubscriptionCloud Monitoring as a Service | DatadogConnect, Protect and Build Everywhere | CloudflareAdam Wathan (@adamwathan) / XWhat is Amazon API Gateway? - Amazon API GatewayInertia.js - The Modern MonolithReason · Reason lets you write simple, fast and quality type safe code while leveraging both the JavaScript & OCaml ecosystems.Topics:(00:00) - Filthy JavaScript developers (00:30) - What does full stack mean? (10:46) - How Laravel different from Rails? (16:17) - Is the frontend and backend team divide real? (18:47) - Why isn't there a JavaScript community? (36:32) - Are JavaScript frameworks in the best position to be the fullest stack? (46:18) - What about Blitz.js? (49:34) - What would Tayor like to see from the Remix community? (54:41) - Is Rails worse than building an app with Cloudflare? (56:38) - Is the top of funnel for web development JavaScript? (01:07:17) - Is Laravel like Canada?

Este episódio do podcast "Fronteiras da Engenharia de Software" com Rui Maranhão Abreu aborda a localização de falhas de software e suas aplicaçõe. Rui, professor catedrático em Engenharia de Software na Universidade do Porto e Research Software Engineer na Meta, compartilha ideias sobre esse campo da Engenharia de Software. No episódio, são discutidos conceitos fundamentais, como a diferença entre falhas e bugs, bem como os desafios enfrentados na detecção de falhas em sistemas complexos e distribuídos, especialmente em ambientes de integração contínua, como na Meta. Rui também explora o papel da inteligência artificial, machine learning e deep learning na localização de falhas e destaca avanços recentes na pesquisa de reparo automatizado de programas. Além disso, são abordados artigos recentes de Rui e seus co-autores, incluindo o "Remoção de Código Morto na Meta", que apresenta o Framework de Remoção Sistemática de Código e Ativos (SCARF), e "Depuração de Erros de Tipo Alimentada por GPT-3", que descreve uma técnica para corrigir automaticamente erros de tipo em programas OCaml, utilizando o GPT-3. A conversa também explora a carreira de Rui na Meta, sua experiência como General Chair do ICSE 2024 em Portugal e suas visões sobre a próxima fronteira da engenharia de software.  Site de Rui: https://ruimaranhao.com/ Outros links: https://sigarra.up.pt/feup/pt/func_geral.formview?p_codigo=466651 https://dei.fe.up.pt/pt/blog/2023/04/10/rui-maranhao-toma-posse-como-diretor-do-prodei/ Artigos: "Remoção de Código Morto na Meta: Exclusão Automática de Milhões de Linhas de Código e Petabytes de Dados Obsoletos" "Dead Code Removal at Meta: Automatically Deleting Millions of Lines of Code and Petabytes of Deprecated Data" https://dl.acm.org/doi/10.1145/3611643.3613871 Localização de características baseada em espectro: um estudo de caso usando o ArgoUML. Spectrum-based feature localization: a case study using ArgoUML https://dl.acm.org/doi/abs/10.1145/3461001.3473065 Depuração de Erros de Tipo Alimentada por GPT-3: Investigando o Uso de Modelos de Linguagem Avançados para Reparo de Código GPT-3-Powered Type Error Debugging: Investigating the Use of Large Language Models for Code Repair https://dl.acm.org/doi/abs/10.1145/3623476.3623522  Mentat (ferramenta) https://figshare.com/articles/software/GPT-3-Powered_Type_Error_Debugging_Investigating_the_Use_of_Large_Language_Models_for_Code_Repair_SLE_2023_/23646903  The bumpy road of taking automated debugging to industry https://arxiv.org/abs/2212.01237  Outros links:  ICSE 2024 https://conf.researchr.org/home/icse-2024  FSE 2024 https://conf.researchr.org/home/fse-2024 ICSE 2026 https://twitter.com/rafaelpri/status/1543318975043383296 Mais informações em ⁠⁠⁠https://fronteirases.github.io/episodios/paginas/46⁠ Entrevistadores: Adolfo Neto (PPGCA UTFPR) ⁠⁠⁠⁠https://adolfont.github.io ⁠  e Maria Claudia Emer Nosso site é: ⁠⁠https://fronteirases.github.io⁠   Extreme Energy (Music Today 80). Composed & Produced by: Anwar Amr. Link:⁠ ⁠⁠⁠⁠https://www.youtube.com/watch?v=8ZZbAkKNx7s⁠⁠  Data de publicação: 15 de maio de 2024. Como citar este episódio FRONTEIRAS DA ENGENHARIA DE SOFTWARE EP. 46: Localização de Falhas de Software, com Rui Maranhão Abreu (Universidade do Porto e Meta). [Locução de]: Adolfo Neto e Maria Claudia Emer. Entrevistado: Rui Maranhão Abreu. S. l.: Fronteiras da Engenharia de Software, 15 mai. 2024. Podcast. Disponível em: ⁠https://fronteirases.github.io/episodios/paginas/46. ⁠Acesso em: 15 mai. 2024. --- Send in a voice message: https://podcasters.spotify.com/pod/show/fronteirases/message

In today's episode, we bring Leandro Ostera, a seasoned software engineer, who's currently leading the OCaml build system team, with the mission of making OCaml SaaS ready! Join us as this episode is packed with a variety of topics, where we mainly focus on the OCaml ecosystem, compare it to other languages and frameworks, but also dabble into very obscure topics such as Idris (hint: it's a programming language), and explore concepts such as routine blocking, scheduling, types, and other issues. Learn back-end development - https://boot.dev Listen on your favorite podcast player: https://www.backendbanter.fm Check out Riot: https://riot.ml/ Leandro's Twitch: https://www.twitch.tv/leostera Leandro's Twitter/X: https://twitter.com/leostera Timestamps: 00:28 Leandro's Background01:37 How Leandro got involved with OCaml02:50 What the heck is Idris???07:03 When Leandro started working with OCaml11:34 ReasonML15:48 The Riot Library and OCaml issues18:00 Type Inference in OCaml23:10 What allowed Riot to move so fast24:17 The ecosystem of a language28:14 Is Riot a Concurrency Library or a Web Framework?31:01 Goroutines refresher33:02 How Riot implements the actor-model38:34 Cooperative Scheduling vs Preemptive Scheduling41:30 How to fix routine blocking43:14 What has Leandro and other contributers shipped?46:25 How does Leandro manage his time to work on all of these projects?49:45 Where to find Leandro

Erlang wears three hats - it's a language, it's a platform, and it's an approach to making software run reliably once it's in production. Those last two are so interesting I sometimes wonder why those ideas haven't been ported to every language going. How much work would it be?This week we're going to dig right down into that question with Leandro Ostera. He's been working on Riot - a project to bring the best of Erlang's runtime system and philosophy to OCaml. But why OCaml? Is it possible to marry together OCaml's type system with Erlang's dynamic dispatch systems? And what is it about the recent release of OCaml5 that makes the whole project easier?–Leandro's Blog: https://www.abstractmachines.dev/Why Typing Erlang is Hard: https://www.abstractmachines.dev/posts/am012-why-typing-erlang-is-hard/Riot: https://riot.ml/Riot source: https://github.com/riot-ml/riotReasonML: https://reasonml.github.io/ReScript: https://rescript-lang.org/Leandro on Twitter: https://twitter.com/leosteraKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins--#podcast #softwaredevelopment #erlang #ocaml #softwaredesign

Fredrik is joined by Emil Privér and Leandro Ostera for a discussion of the OCaml ecosystem, and making it Saas-ready by building Riot. First of all: OCaml. What is the thing with the language, and how you might get into it coming from other languages? The OCaml community is nice, interested in getting new people in, and pragmatic. And it has a nice mix of research and industry as well. Then, Leandro tells us about Riot - an experiment in bringing everything good about the Erlang and Elixir ecosystems into OCaml. The goal? Make OCaml saas-ready. Riot is not 1.0 just yet, but an impressive amount has been built in just five(!) months. Emil moves the discussion over to the mindset of shipping, and of finding and understanding good ideas in other places and picking them up rather than reinventing the wheel. Leandro highly recommends reading the code of other projects. Read and understand the code and solutions others have written, re-use good ideas and don't reinvent the wheel more often than you really have to. Last, but by no means least, shoutouts to some of the great people building the OCaml community, and a bit about Emil's project DBCaml. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlundand @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Emil Leo Leo on Twitch Previous Kodsnack appearances by Emil Riot Sinatra Backbone.js Ember.js Angularjs React Erlang Tarides - where Leandro currently works OCaml Robin Milner - designer of ML Caml Javacaml F# Imperative programming Object-oriented programming Pure functions and side effects Monads The OCaml compiler Reason - the language built by Jordan Walke, the creator of React Standard ML React was prototyped in Standard ML Melange - OCaml compiler backend producing Javascript OCaml by example The OCaml Discord The Reason Discord Rescript Jane street High-frequency trading The Dune build system Erlang process trees Caramel - earlier experiment of Leandro's Louis Pilfold Gleam Algebraic effects Continuations Pool - Emil's project Gluon Bytestring Atacama - connection pool inspired by Thousand island Nomad - inspired by Bandit Trail - middleware inspired by Plug Sidewinder - Livewire-like Saas - software as a service DBCaml Johan Öbrink Ecto Mint tea - inspired by Bubble tea Autobahn|Testsuite - test suite for specification compliance Serde - Rust and OCaml serialization framework S-expressions TOML Dillon Mulroy Metame - community kindness pillar welltypedwitch Sabine maintains ocaml.org OCaml playground OCaml cookbook - in beta, sort of teej_dv ocaml.org Pool party Drizzle SQLX SQL Join types (left, inner, and so on) dbca.ml internet.bs The Caravan Essentials of compilation Reading rainbow Titles Few people can have a massive impact Impact has been an important thing for me It's a language out there A very long lineage of thinking about programming languages Programs that never fail The functional version of Rust Melange is amazing This is not a toy project Yes, constraints! Wonders in community growth Arrow pointing toward growth Programs that don't crash A very different schoold of reliability Invert the arrow Very easy on the whiteboard Multicore for free An entire stack from scratch Built for the builders A massive tree of things Make OCaml saas-ready Leo is a shipper Standing on the shoulders of many, many giants Learn from other people I exude OCaml these days Sitting down and building against the spec You just give it something Your own inner join We build everything in public The gospel of the dunes

Fredrik is joined by Emil Privér and Leandro Ostera for a discussion of the OCaml ecosystem, and making it Saas-ready by building Riot. First of all: OCaml. What is the thing with the language, and how you might get into it coming from other languages? The OCaml community is nice, interested in getting new people in, and pragmatic. And it has a nice mix of research and industry as well. Then, Leandro tells us about Riot - an experiment in bringing everything good about the Erlang and Elixir ecosystems into OCaml. The goal? Make OCaml saas-ready. Riot is not 1.0 just yet, but an impressive amount has been built in just five(!) months. Emil moves the discussion over to the mindset of shipping, and of finding and understanding good ideas in other places and picking them up rather than reinventing the wheel. Leandro highly recommends reading the code of other projects. Read and understand the code and solutions others have written, re-use good ideas and don’t reinvent the wheel more often than you really have to. Last, but by no means least, shoutouts to some of the great people building the OCaml community, and a bit about Emil’s project DBCaml. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Emil Leo Leo on Twitch Previous Kodsnack appearances by Emil Riot Sinatra Backbone.js Ember.js Angularjs React Erlang Tarides - where Leandro currently works OCaml Robin Milner - designer of ML Caml Javacaml F# Imperative programming Object-oriented programming Pure functions and side effects Monads The OCaml compiler Reason - the language built by Jordan Walke, the creator of React Standard ML React was prototyped in Standard ML Melange - OCaml compiler backend producing Javascript OCaml by example The OCaml Discord The Reason Discord Rescript Jane street High-frequency trading The Dune build system Erlang process trees Caramel - earlier experiment of Leandro’s Louis Pilfold Gleam Algebraic effects Continuations Pool - Emil’s project Gluon Bytestring Atacama - connection pool inspired by Thousand island Nomad - inspired by Bandit Trail - middleware inspired by Plug Sidewinder - Livewire-like Saas - software as a service DBCaml Johan Öbrink Ecto Mint tea - inspired by Bubble tea Autobahn|Testsuite - test suite for specification compliance Serde - Rust and OCaml serialization framework S-expressions TOML Dillon Mulroy Metame - community kindness pillar welltypedwitch Sabine maintains ocaml.org OCaml playground OCaml cookbook - in beta, sort of teej_dv ocaml.org Pool party Drizzle SQLX SQL Join types (left, inner, and so on) dbca.ml internet.bs The Caravan Essentials of compilation Reading rainbow Titles Few people can have a massive impact Impact has been an important thing for me It’s a language out there A very long lineage of thinking about programming languages Programs that never fail The functional version of Rust Melange is amazing This is not a toy project Yes, constraints! Wonders in community growth Arrow pointing toward growth Programs that don’t crash A very different schoold of reliability Invert the arrow Very easy on the whiteboard Multicore for free An entire stack from scratch Built for the builders A massive tree of things Make OCaml saas-ready Leo is a shipper Standing on the shoulders of many, many giants Learn from other people I exude OCaml these days Sitting down and building against the spec You just give it something Your own inner join We build everything in public The gospel of the dunes

Malcolm Matalka is the Co-Founder of Terrateam and is a trailblazer in the world of software engineering. Malcolm has deep expertise spanning Bioinformatics, Aerospace Software, and Infrastructure-as-Code. Malcolm can be found coding around the world in his home office which happens to be aboard an Amel Sharki Sailboat, where he brings adventure along with the journey.Where to find MalcolmYouTube: https://www.youtube.com/@BoringSailingLinkedIn: https://www.linkedin.com/in/malcolm-matalka-a6527382/Slack: https://terrateam.io/slackFollow, Like, and Subscribe!Podcast: https://www.thecloudgambit.com/YouTube: https://www.youtube.com/@TheCloudGambitLinkedIn: https://www.linkedin.com/company/thecloudgambitTwitter: https://twitter.com/TheCloudGambitTikTok: https://www.tiktok.com/@thecloudgambit

For the final episode of Elixir Wizards' Season 11 “Branching Out from Elixir,” we're featuring a recent discussion from the Software Unscripted podcast. In this conversation, José Valim, creator of Elixir, interviews Richard Feldman, creator of Roc. They compare notes on the process and considerations for creating a language. This episode covers the origins of creating a language, its influences, and how goals shape the tradeoffs in programming language design. José and Richard share anecdotes from their experiences guiding the evolution of Elixir and Roc. The discussion provides an insightful look at the experimentation and learning involved in crafting new languages. Topics discussed in this episode What inspires the creation of a new programming language Goals and use cases for a programming language Influences from Elm, Rust, Haskell, Go, OCaml, and more Tradeoffs involved in expressiveness of type systems Opportunistic mutation for performance gains in a functional language Minimum version selection for dependency resolution Build time considerations with type checking and monomorphization Design experiments and rolling back features that don't work out History from the first simple interpreter to today's real programming language Design considerations around package management and versioning Participation in Advent of Code to gain new users and feedback Providing performance optimization tools to users in the future Tradeoffs involved in picking integer types and arithmetic Comparing floats and equality checks on dictionaries Using abilities to customize equality for custom types Ensuring availability of multiple package versions for incremental upgrades Treating major version bumps as separate artifacts Roc's focus on single-threaded performance Links mentioned in this episode Software Unscripted Podcast https://feeds.resonaterecordings.com/software-unscripted Roc Programming Language https://www.roc-lang.org/ Roc Lang on Github https://github.com/roc-lang/roc Elm Programming Language https://elm-lang.org/ Elm in Action by Richard Feldman https://www.manning.com/books/elm-in-action Richard Feldman on Github https://github.com/rtfeldman Lua Programming Language https://www.lua.org/ Vimscript Guide https://google.github.io/styleguide/vimscriptfull.xml OCaml Programming Language https://ocaml.org/ Advent of Code https://adventofcode.com/ Roc Language on Twitter https://twitter.com/roclang Richard Feldman on Twitter https://twitter.com/rtfeldman Roc Zulip Chat https://roc.zulipchat.com Clojure Programming Language https://clojure.org/ Talk: Persistent Data Structures and Managed References by Rich Hickey https://www.youtube.com/watch?v=toD45DtVCFM Koka Programming Language https://koka-lang.github.io/koka/doc/index.html Flix Programming Language https://flix.dev/ Clojure Transients https://clojure.org/reference/transients Haskell Software Transactional Memory https://wiki.haskell.org/Softwaretransactional_memory Rust Traits https://doc.rust-lang.org/book/ch10-02-traits.html CoffeeScript https://coffeescript.org/ Cargo Package Management https://doc.rust-lang.org/book/ch01-03-hello-cargo.html Versioning in Golang https://research.swtch.com/vgo-principles Special Guests: José Valim and Richard Feldman.

In this episode, Andrew and Julie chat with guest John Crepezzi, a veteran in the Ruby community, founder of All Aboard Bootcamp, and currently a Software Engineer at Jane Street.  Today, they discuss John's experience running a coding bootcamp, share insights on teaching programming, and emphasize the importance of community in learning.  Additionally, they explore functional programming in OCaml, highlighting how functional programming can be implemented in Ruby.  Also, John dives into the potential impact of AI, particularly language models like ChatGPT, on education and software development, and there's a discussion on resume writing for new coders and future trends in AI and automation. Hit download now to hear more! [00:01:08] Julie introduces John, her former bootcamp instructor, and he tells us about himself and his extensive experience on the Ruby community. [00:02:14] Andrew asks John about the gem he is most proud of creating, and he explains his pride in the “ice_cube gem” for recurring date math. [00:04:30] John discusses the technical challenges and community contributions to ice_cube. [00:05:25] Julie discusses her positive experience with All Aboard Bootcamp and how the bootcamp helped her connect different programming concepts.  [00:07:26] John describes his teaching philosophy for covering a broad amount of material quickly and he stresses the importance of learning to ask the right questions. He uses a metaphor from the movie “Tommy Boy” to emphasize teaching practical skills.[00:11:26] John relates the approach to teaching with the usefulness of ChatGPT and Julie expresses her preference for receiving explanations in small chunks and using bullet points for clarity. John discusses how LLMs can assist in refining questions before providing answers. [00:12:49] Andrew asks about AI's role in teaching and its potential impact. John, an AI professional,  offers his perspective on AI in the short and term, specifically its ability to understand and respond to human language. He speculates on the future of human computer interaction, where structured systems may become unnecessary as LLMs bridge the communication gap. [00:16:03] Andrew agrees with John's vision of the future, acknowledging the inefficiencies in current user flows. John compares the evolution from programming VCRs to using DVRs to the potential of LLMs simplifying interaction with technology. [00:16:55] John describes the motivation behind starting a bootcamp and the realization of the industry's selection bias towards already skilled programmers. He shares the story of how the high cost of bootcamps and their screening processes inspired him to teach a more accessible camp. [00:21:10] Julie is impressed by John's ability to manage the bootcamp alongside his full-time job, family responsibilities, and other commitments. She also talks about the final project of the bootcamp, where John acted as a project manager and provided structure and guidance. [00:23:31] Andrew inquires about what John thinks is the number one mistake new programmers make on their resume.  John emphasizes the importance of highlighting projects on a resume, especially for those transitioning from another industry, and advises focusing on the outcomes and transferable skills gained from previous experiences.[00:25:35] John considers formatting critical for resumes, suggesting less content with more white space and a clear hierarchy can be more effective than too much information.[00:26:44] Another thing John advises is keeping resumes to one page unless there's a compelling reason for more, like academic positions or extensive project work.[00:27:18] Reflecting on the bootcamp, John wishes he had sought more assistance with grading and feedback to reduce the workload. [00:28:34] John praises the students, particularly Julie, for fostering a supportive community outside of the classroom.[00:31:07] Discussing programming languages, John expresses his favor for OCaml and functional programming, arguing that functional patterns can be beneficial even in languages like Ruby. [00:32:13] Find out where you can follow John online. [00:32:58] We end with John reaffirming his love for Ruby and expresses enthusiasm for its future and mentioning his work with Eileen on Active Record and Rails' influence on web frameworks in other languages. Panelists:Andrew MasonJulie J.Guest:John CrepezziSponsors:GoRailsHoneybadgerLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteJohn Crepezzi X/TwitterJohn Crepezzi GitHubice_cube 0.16.4All Aboard BootcampAbout the bootcamp (John's story)RailsConf 2023-Functional Patterns in Ruby by John Crepezzi (YouTube)OCaml (00:00) - Introduction to the Episode (01:08) - Meet John Crepezzi: Ruby Community Veteran and Bootcamp Founder (02:14) - John's Pride in Creating the "ice_cube gem" for Date Math (04:30) - Technical Challenges and Community Role in Developing ice_cube (05:25) - Julie's Transformative Experience at All Aboard Bootcamp (07:26) - John's Teaching Philosophy: Quick Learning and Practical Skills (11:26) - ChatGPT's Role in Teaching: Enhancing Question Refinement (12:49) - AI in Education: John's Perspective on Future Trends (16:03) - From VCRs to AI: Evolution of User-Technology Interaction (16:55) - The Genesis of John's Bootcamp: Addressing Industry Biases (21:10) - John's Journey: Balancing Bootcamp with Personal Life (23:31) - Common Resume Mistakes for New Programmers (25:35) - John's Tips on Effective Resume Formatting (26:44) - Importance of Conciseness in Resumes (27:18) - John Reflects on Bootcamp Challenges and Workload Management (28:34) - Fostering a Supportive Community in the Bootcamp (31:07) - John's Advocacy for OCaml and Functional Programming in Ruby (32:13) - Discover Where to Follow John Online (32:58) - John's Ongoing Passion for Ruby and Its Evolving Impact

Connect with Malcolm Matalka: https://www.linkedin.com/in/malcolm-matalka-a6527382 Full episode on YouTube ▶️ https://youtu.be/htpxkxyCX9I Beyond Coding Podcast with ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

Lane chats with Sabine, one of the primary maintainers of OCaml.org, about how she built web apps in Django on the side, only to land her first programming job working close to the OCaml ecosystem, and quickly become enveloped in the project. Her backstory about skipping grades, dropping out of school, and teaching herself various web languages is fascinating, give it a listen.Learn back-end development - https://boot.devListen on your favorite podcast player: https://www.backendbanter.comSabine's Twitter: https://twitter.com/sabine_s_OCaml Homepage: https://ocaml.org/

In this week's roundup episode, learn why Chance Strickland still chooses to use React, why Amy Dutton uses Storybook for design-driven development, and how to use Reason and OCaml to natively render React apps. Links Apple Why I still choose React with Chance Strickland: https://apple.co/46Tf2Of Remix, Svelte, and robots with James Quick and Amy Dutton: https://apple.co/474SxWW Reason's native React SSR with David Sancho: https://apple.co/40krVhQ Spotify Why I still choose React with Chance Strickland: https://spoti.fi/3sd9j6Q Remix, Svelte, and robots with James Quick and Amy Dutton: https://spoti.fi/3FKOCT4 Reason's native React SSR with David Sancho: https://spoti.fi/3QjUOGy Google Why I still choose React with Chance Strickland: https://bit.ly/3FGf3Jw Remix, Svelte, and robots with James Quick and Amy Dutton: https://bit.ly/49DJXAb Reason's native React SSR with David Sancho: https://bit.ly/3QH7kRV We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guests: Amy Dutton, Chance Strickland, and David Sancho.

In this supper club episode of Syntax, Wes and Scott talk with Chris Lattner about Mojo, a new programming language for AI developers. Should developers learn Python? Where does Mojo run? What is Chris excited about in AI's future? Show Notes 00:31 Welcome 01:05 Introducing Chris Lattner Chris Lattner's Homepage Chris Lattner on Wikipedia Chris Lattner on GitHub Chris Lattner on Twitter Modular (@Modular_AI) / X Modular: AI development starts here Swift.org - Welcome to Swift.org 03:50 What's the history behind the hardware? 08:10 What's the difference between a compiled language vs an interpreted language? 12:13 Is Mojo a programming language? Mojo

Sabine went from acedemia and a PhD in formal methods, to Python, Elm, Haskell, and now OCaml. We chat about this journey and some of the reasons why OCaml is an awesome modern language. Discuss this episode: https://discord.gg/nPa76qF

This week, Anna (https://twitter.com/annarrose) and Guillermo (https://twitter.com/GuilleAngeris) chat with David Wong (https://twitter.com/cryptodavidw), author of the Real-World Cryptography book (https://www.manning.com/books/real-world-cryptography?a_aid=Realworldcrypto&a_bid=ad500e09), and a cofounder [zksecurity.xyz]((https://www.zksecurity.xyz/) - an auditing firm focused on Zero Knowledge technology. They chat about what first got him interested in cryptography, his early work as a security consultant, his work on the Facebook crypto project and the Mina project, zksecurity.xyz, auditing techniques and their efficacy in a ZK context, what common bugs are found in ZK code, and much more. Here's some additional links for this episode: Crypto is not cryptocurrency (https://cryptoisnotcryptocurrency.com/) NCC Group (https://www.nccgroup.com/) OCaml website (https://ocaml.org/) Real-World Cryptography book (https://www.manning.com/books/real-world-cryptography) Mina Protocol (https://minaprotocol.com/) 3pages.fr (https://www.3pages.fr/home/login/) The Frozen Heart vulnerability in PlonK | Trail of Bits Blog (https://blog.trailofbits.com/2022/04/18/the-frozen-heart-vulnerability-in-plonk/) ZK Podcast Episode 284: Using Formal Verification on ZK Systems with Jon Stephens (https://zeroknowledge.fm/284-2/) zkSecurity Website (https://www.zksecurity.xyz/) ZK Podcast Episode 257: Proof of Solvency with Kostas Chalkias - ZK Podcast (https://zeroknowledge.fm/257-2/) ZK Podcast Episode 210: The Road to STARKs and Miden with Bobbin Threadbare - ZK Podcast (https://zeroknowledge.fm/210-2/) ZK Podcast Episode 76: Sean Bowe on SNARKs, Trusted Setups & Elliptic Curve Cryptography - ZK Podcast (https://zeroknowledge.fm/76-2/) Check out the ZK Jobs Board (https://jobsboard.zeroknowledge.fm/) for new job opportunities in the run up to the zkSummit 10 (https://www.zksummit.com/)! Aleo (https://www.aleo.org/) is a new Layer-1 blockchain that achieves the programmability of Ethereum, the privacy of Zcash, and the scalability of a rollup. For questions, join their Discord at aleo.org/discord (http://aleo.org/discord). If you like what we do: * Find all our links here! @ZeroKnowledge | Linktree (https://linktr.ee/zeroknowledge) * Subscribe to our podcast newsletter (https://zeroknowledge.substack.com) * Follow us on Twitter @zeroknowledgefm (https://twitter.com/zeroknowledgefm) * Join us on Telegram (https://zeroknowledge.fm/telegram) * Catch us on YouTube (https://zeroknowledge.fm/)

"Au final, la blockchain c'est juste une BDD distribuée" Le D.E.V. de la semaine est Xavier van de Woestyne. Xavier discute de OCaml, Haskell et de Blockchain. Il aborde des sujets tels que les "smart contracts" Tezos, les fonctionnalités offertes par la Blockchain, les DAO. Il explore également la manière dont les données sociales peuvent s'intégrer sur la Blockchain, la possibilité d'exécuter des programmes on-chain et le fantasme des blockchains sans crypto. Finalement, il fournit une définition et des exemples d'une application décentralisée (dApp). Liens évoqués pendant l'émission Derrière nos écrans de fuméeMadame BovarySite personnel de Xavier **Continuons la discussion**@ifthisthendev@bibear@vdwxvLinkedInLinkedIn de Xavier van de WoestyneDiscord** Plus de contenus de dev **Retrouvez tous nos épisodes sur notre site.Nous sommes aussi sur Instagram, TikTok, Youtube, Twitch ** Job Board If This Then Dev **Si vous avez envie de changer de job, visitez le job board If This Then Dev ! Si vous voulez recruter des personnes qui écoutent IFTTD, il va s'en dire que le job board d'IFTTD est l'endroit où il faut être ! Ce job board est fait avec My Little Team!** La Boutique IFTTD !!! **Affichez votre appréciation de ce podcast avec des goodies faits avec amour sur la boutique ou affichez clairement votre camp tabulation ou espace.** Participez au prochain enregistrement !**Retrouvez-nous tous les lundis à 19:00 (mais pas que) pour assister à l'enregistrement de l'épisode en live et pouvoir poser vos questions pendant l'épisode :)Nous sommes en live sur Youtube, Twitch, LinkedIn et Twitter

In this episode Niki Vazou and Mattias Pall chat with Richard Eisenberg. Richard is currently a language designer at Jane Street, he is the chair of the board at the Haskell Foundation and known for his work on the GHC compiler.  Today we talk about dependent types in Haskell, how to get involved with GHC and Haskell foundation and how Haskell and Ocaml are different, for example, functor means a totally different thing in the two languages. 

In this episode we have over Dan Plyukhin, a PhD Candidate from the University of Illinois Urbana-Champaign. We talk about Dan's research is in the field of parallelism, more specifically garbage collection in the presence of actors. Then we also talk about Pedro's research on translating GADTs from OCaml to Coq, and the burnout process that lead him to take 10 months off from his PhD to be with his family back in Brazil. Links Dan's Personal Website Twitter: @dplyukhn

In this episode we have over Dan Plyukhin, a PhD Candidate from the University of Illinois Urbana-Champaign. We talk about Dan's research is in the field of parallelism, more specifically garbage collection in the presence of actors. Then we also talk about Pedro's research on translating GADTs from OCaml to Coq, and the burnout process that lead him to take 10 months off from his PhD to be with his family back in Brazil. Links Dan's Personal Website Twitter: @dplyukhn

In this episode we have over Dan Plyukhin, a PhD Candidate from the University of Illinois Urbana-Champaign. We talk about Dan's research is in the field of parallelism, more specifically garbage collection in the presence of actors. Then we also talk about Pedro's research on translating GADTs from OCaml to Coq, and the burnout process that lead him to take 10 months off from his PhD to be with his family back in Brazil. Links Dan's Personal Website Twitter: @dplyukhn

Pierre-Étienne's interest in computing began with the functional programming language OCaml, created by Xavier Leroy. Before OCaml, Pierre-Étienne explains, “everyone thought functional programming was doomed to be extremely slow.”Pijul is a free, open-source distributed version control system. You can get started here. Want a GitHub-like interface? Find it here.Read the article that led to this conversation: Beyond Git: The other version control systems developers use. Pierre-Étienne is currently working on a new project with the creators of the open-source game engine Godot. We hosted Godot cofounder and lead developer Juan Linietsky on the podcast a few months back; listen here.Nix is a package management and system configuration tool. Learn how it works or explore the NixOS community. Connect with Pierre-Étienne on LinkedIn.Congrats to Lifeboat badge winner Rachit for answering Passing objects between fragments.

Lane and TJ DeVries chat about OCaml and why functional programming can result in more elegant and readable code. TJ is a core maintainer of NeoVim and explains how contributing to open source has had a huge positive impact on his coding career.Learn back-end development -  https://boot.devTJ on Twitter: https://twitter.com/teej_dvTJ on Twitch: https://www.twitch.tv/teej_dvTJ on YouTube: https://www.youtube.com/@teej_dv

In this episode Matthías Páll and Andres Löh  talk with Andrey Mokhov. Andrey is best known for his work on the Hadrian build system and today he talks about algebraic graphs, selective functors, and the  difference between OCaml and Haskell. 

About GeneGene Kim is a multiple award-winning CTO, researcher and author, and has been studying high-performing technology organizations since 1999. He was founder and CTO of Tripwire for 13 years. He has written six books, including The Unicorn Project (2019), The Phoenix Project (2013), The DevOps Handbook (2016), the Shingo Publication Award winning Accelerate (2018), and The Visible Ops Handbook (2004-2006) series. Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations.Links: The Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ The Unicorn Project: https://www.amazon.com/Unicorn-Project-Developers-Disruption-Thriving/dp/B0812C82T9 The DevOps Enterprise Summit: https://events.itrevolution.com/ @RealGeneKim TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: If you asked me to rank which cloud provider has the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud. Their developer experience is unparalleled and, in the early stages of building something great, that translates directly into velocity. Try it yourself with the Google for Startups Cloud Program over at cloud.google.com/startup. It'll give you up to $100k a year for each of the first two years in Google Cloud credits for companies that range from bootstrapped all the way on up to Series A. Go build something, and then tell me about it. My thanks to Google Cloud for sponsoring this ridiculous podcast.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out. Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by a man who needs no introduction but gets one anyway. Gene Kim, most famously known for writing The Phoenix Project, but now the Wall Street Journal best-selling author of The Unicorn Project, six years later. Gene, welcome to the show.Gene Kim: Corey so great to be on. I was just mentioning before how delightful it is to be on the other side of the podcast. And it's so much smaller in here than I had thought it would be.Corey Quinn: Excellent. It's always nice to wind up finally meeting people whose work was seminal and foundational. Once upon a time, when I was a young, angry Unix systems administrator—because it's not like there's a second type of Unix administrator—[laughing] The Phoenix Project was one of those texts that was transformational, as far as changing the way I tended to view a lot of what I was working on and gave a glimpse into what could have been a realistic outcome for the world, or the company I was at, but somehow was simultaneously uplifting and incredibly depressing all at the same time. Now, The Unicorn Project does that exact same thing only aimed at developers instead of traditional crusty ops folks.Gene Kim: [laughing] Yeah, yeah. Very much so. Yeah, The Phoenix Project was very much aimed at ops leadership. So, Bill Palmer, the protagonist of that book was the VP of Operations at Parts Unlimited, and the protagonist in The Unicorn Project is Maxine Chambers, Senior Architect, and Developer, and I love the fact that it's told in the same timeline as The Phoenix Project, and in the first scene, she is unfairly blamed for causing the payroll outage and is exiled to The Phoenix Project, where she recoils in existential horror and then finds that she can't do anything herself. She can't do a build, she can't run her own tests. She can't, God forbid, do her own deploys. And I just love the opening third of the book where it really does paint that tundra that many developers find themselves in where they're just caught in decades of built-up technical debt, unable to do even the simplest things independently, let alone be able to independently develop tests or create value for customers. So, it was fun, very much fun, to revisit the Parts Unlimited universe.Corey Quinn: What I found that was fun about—there are few things in there I want to unpack. The first is that it really was the, shall we say, retelling of the same story in, quote/unquote, “the same timeframe”, but these books were written six years apart.Gene Kim: Yeah, and by the way, I want to first acknowledge all the help that you gave me during the editing process. Some of your comments are just so spot on with exactly the feedback I needed at the time and led to the most significant lift to jam a whole bunch of changes in it right before it got turned over to production. Yeah, so The Phoenix Project is told, quote, “in the present day,” and in the same way, The Unicorn Project is also told—takes place in the present day. In fact, they even start, plus or minus, on the same day. And there is a little bit of suspension of disbelief needed, just because there are certain things that are in the common vernacular, very much in zeitgeist now, that weren't six years ago, like “digital disruption”, even things like Uber and Lyft that feature prominently in the book that were just never mentioned in The Phoenix Project, but yeah, I think it was the story very much told in the same vein as like Ender's Shadow, where it takes place in the same timeline, but from a different perspective.Corey Quinn: So, something else that—again, I understand it's an allegory, and trying to tell an allegorical story while also working it into the form of a fictional work is incredibly complicated. That's something that I don't think people can really appreciate until they've tried to do something like it. But I still found myself, at various times, reading through the book and wondering, asking myself questions that, I guess, say more about me than they do about anyone else. But it's, “Wow, she's at a company that is pretty much scapegoating her and blaming her for all of us. Why isn't she quitting? Why isn't she screaming at people? Why isn't she punching the boss right in their stupid, condescending face and storming out of the office?” And I'm wondering how much of that is my own challenges as far as how life goes, as well as how much of it is just there for, I guess, narrative devices. It needed to wind up being someone who would not storm out when push came to shove.Gene Kim: But yeah, I think she actually does the last of the third thing that you mentioned where she does slam the sheet of paper down and say, “Man, you said the outage is caused by a technical failure and a human error, and now you're telling me I'm the human error?” And just cannot believe that she's been put in that position. Yeah, so thanks to your feedback and the others, she actually does shop her resume around. And starts putting out feelers, because this is no longer feeling like the great place to work that attracted her, eight years prior. The reality is for most people, is that it's sometimes difficult to get a new job overnight, even if you want to. But I think that Maxine stays because she believes in the mission. She takes a great deal of pride of what she's created over the years, and I think like most great brands, they do create a sense of mission and there's a deep sense of the customers they serve. And, there's something very satisfying about the work to her. And yeah, I think she is very much, for a couple of weeks, very much always thinking about, she won't be here for long, one way or another, but by the time she stumbles into the rebellion, the crazy group of misfits, the ragtag bunch of misfits, who are trying to find better ways of working and willing to break whatever rules it takes to take over the very ancient powerful order, she falls in love with a group. She found a group of kindred spirits who very much, like her, believe that developer productivity is one of the most important things that we can do as an organization. So, by the time that she looks up with that group, I mean, I think she's all thoughts of leaving are gone.Corey Quinn: Right. And the idea of, if you stick around, you can theoretically change things for the better is extraordinarily compelling. The challenge I've seen is that as I navigate the world, I've met a number of very gifted employees who, frankly wind up demonstrating that same level of loyalty and same kind of loyalty to companies that are absolutely not worthy of them. So my question has always been, when do I stick around versus when do I leave? I'm very far on the bailout as early as humanly possible side of that spectrum. It's why I'm a great consultant but an absolutely terrible employee.Gene Kim: [laughing] Well, so we were honored to have you at the DevOps Enterprise Summit. And you've probably seen that The Unicorn Project book is really dedicated to the achievements of the DevOps Enterprise community. It's certainly inspired by and dedicated to their efforts. And I think what was so inspirational to me were all these courageous leaders who are—they know what the mission is. I mean, they viscerally understand what the mission is and understand that the ways of working aren't working so well and are doing whatever they can to create better ways of working that are safer, faster, and happier. And I think what is so magnificent about so many of their journeys is that their organization in response says, “Thank you. That's amazing. Can we put you in a position of even more authority that will allow you to even make a more material, more impactful contribution to the organization?” And so it's been my observation, having run the conference for, now, six years, going on seven years is that this is a population that is being out promoted—has been promoted at a rate far higher than the population at large. And so for me, that's just an incredible story of grit and determination. And so yeah, where does grit and determination becomes sort of blind loyalty? That's ultimately self-punishing? That's a deep question that I've never really studied. But I certainly do understand that there is a time when no amount of perseverance and grit will get from here to there, and that's a fact.Corey Quinn: I think that it's a really interesting narrative, just to see it, how it tends to evolve, but also, I guess, for lack of a better term, and please don't hold this against me, it seems in many ways to speak to a very academic perspective, and I don't mean that as an insult. Now, the real interesting question is why I would think, well—why would accusing someone of being academic ever be considered as an insult, but my academic career was fascinating. It feels like it aligns very well with The Five Ideals, which is something that you have been talking about significantly for a long time. And in an academic setting that seems to make sense, but I don't see it thought of or spoken of in the same way on the ground. So first, can you start off by giving us an intro to what The Five Ideals are, and I guess maybe disambiguate the theory from the practice?Gene Kim: Oh for sure, yeah. So The Five Ideals are— oh, let's go back one step. So The Phoenix Project had The Three Ways, which were the principles for which you can derive all the observed DevOps practices from and The Four Types of Work. And so in The Five Ideals I used the concept of The Five Ideals and they are—the first—Corey Quinn: And the next version of The Nine whatever you call them at that point, I'm sure. It's a geometric progression.Gene Kim: Right or actually, isn't it the pri—oh, no. four isn't, four isn't prime. Yeah, yeah, I don't know. So, The Five Ideals is a nice small number and it was just really meant to verbalize things that I thought were very important, things I just gravitate towards. One is Locality and Simplicity. And briefly, that's just, to what degree can teams do what they need to do independently without having to coordinate, communicate, prioritize, sequence, marshal, deconflict, with scores of other teams. The Second Ideal is what I think the outcomes are when you have that, which is Focus, Flow and Joy. And so, Dr. Mihaly Csikszentmihalyi, he describes flow as a state when we are so engrossed in the work we love that we lose track of time and even sense of self. And that's been very much my experience, coding ever since I learned Clojure, this functional programming language. Third Ideal is Improvement of Daily Work, which shows up in The Phoenix Project to say that improvement daily work is even more important than daily work itself. Fourth Ideal is Psychological Safety, which shows up in the State of DevOps Report, but showed up prominently in Google's Project Oxygen, and even in the Toyota production process where clearly it has to be—in order for someone to pull the andon cord that potentially stops the assembly line, you have to have an environment where it's psychologically safe to do so. And then Fifth Ideal is Customer Focus, really focus on core competencies that create enduring, durable business value that customers are willing to pay for, versus context, which is everything else. And yeah, to answer your question, Where did it come from? Why do I think it is important? Why do I focus on that? For me, it's really coming from the State of DevOps Report, that I did with Dr. Nicole Forsgren and Jez Humble. And so, beyond all the numbers and the metrics and the technical practices and the architectural practices and the cultural norms, for me, what that really tells the story of is of The Five Ideals, as to what one of them is very much a need for architecture that allows teams to work independently, having a higher predictor of even, continuous delivery. I love that. And that from the individual perspective, the ideal being, that allows us to focus on the work we want to do to help achieve the mission with a sense of flow and joy. And then really elevating the notion that greatness isn't free, we need to improve daily work, we have to make it psychologically safe to talk about problems. And then the last one really being, can we really unflinchingly look at the work we do on an everyday basis and ask, what the customers care about it? And if customers don't care about it, can we question whether that work really should be done or not. So that's where for me, it's really meant to speak to some more visceral emotions that were concretized and validated through the State of DevOps Report. But these notions I am just very attracted to.Corey Quinn: I like the idea of it. The question, of course, is always how to put these into daily practice. How do you take these from an idealized—well, let's not call it a textbook, but something very similar to that—and apply it to the I guess, uncontrolled chaos that is the day-to-day life of an awful lot of people in their daily jobs.Gene Kim: Yeah. Right. So, the protagonist is Maxine and her role in the story, in the beginning, is just to recognize what not great looks like. She's lived and created greatness for all of her career. And then she gets exiled to this terrible Phoenix project that chews up developers and spits them out and they leave these husks of people they used to be. And so, she's not doing a lot of problem-solving. Instead, it's this recoiling from the inability for people to do builds or do their own tests or be able to do work without having to open up 20 different tickets or not being able to do their own deploys. She just recoil from this spending five days watching people do code merges, and for me, I'm hoping that what this will do, and after people read the book, will see this all around them, hopefully, will have a similar kind of recoiling reaction where they say, “Oh my gosh, this is terrible. I should feel as bad about this as Maxine does, and then maybe even find my fellow rebels and see if we can create a pocket of greatness that can become like the sublimation event in Dr. Thomas Kuhn's book, The Structure of Scientific Revolutions.” Create that kernel of greatness, of which then greatness then finds itself surrounded by even more greatness.Corey Quinn: What I always found to be fascinating about your work is how you wind up tying so many different concepts together in ways you wouldn't necessarily expect. For example, when I was reviewing one of your manuscripts before this went to print, you did reject one of my suggestions, which was just, retitle the entire thing. Instead of calling it The Unicorn Project. Instead, call it Gene Kim's Love Letter to Functional Programming. So what is up with that?Gene Kim: Yeah, to put that into context, for 25 years or more, I've self-identified as an ops person. The Phoenix Project was really an ops book. And that was despite getting my graduate degree in compiler design and high-speed networking in 1995. And the reason why I gravitated towards ops, because that was my observation, that that's where the saves were made. It was ops who saved the customer from horrendous, terrible developers who just kept on putting things into production that would then blow up and take everyone with it. It was ops protecting us from the bad adversaries who were trying to steal data because security people were so ineffective. But four years ago, I learned a functional programming language called Clojure and, without a doubt, it reintroduced the joy of coding back into my life and now, in a good month, I spend half the time—in the ideal—writing, half the time hanging out with the best in the game, of which I would consider this to be a part of, and then 20% of time coding. And I find for the first time in my career, in over 30 years of coding, I can write something for years on end, without it collapsing in on itself, like a house of cards. And that is an amazing feeling, to say that maybe it wasn't my inability, or my lack of experience, or my lack of sensibilities, but maybe it was just that I was sort of using the wrong tool to think with. That comes from the French philosopher Claude Lévi-Strauss. He said of certain things, “Is it a good tool to think with?” And I just find functional programming is such a better tool to think with, that notions like composability, like immutability, what I find so exciting is that these things aren't just for programming languages. And some other programming languages that follow the same vein are, OCaml, Lisp, ML, Elixir, Haskell. These all languages that are sort of popularizing functional programming, but what I find so exciting is that we see it in infrastructure and operations, too. So Docker is fundamentally immutable. So if you want to change a container, we have to make a new one. Kubernetes composes these containers together at the level of system of systems. Kafka is amazing because it usually reveals the desire to have this immutable data model where you can't change the past. Version control is immutable. So, I think it's no surprise that as our systems get more and more complex and distributed, we're relying on things like immutability, just to make it so that we can reason about them. So, it is something I love addressing in the book, and it's something I decided to double down on after you mentioned it. I'm just saying, all kidding aside is this a book for—Corey Quinn: Oh good, I got to make it worse. Always excited when that happens.Gene Kim: Yeah, I mean, your suggestion really brought to the forefront a very critical decision, which was, is this a book for technology leaders, or even business leaders, or is this a book developers? And, after a lot of soul searching, I decided no, this is a book for developers, because I think the sensibilities that we need to instill and the awareness we need to create these things around are the developers and then you just hope and pray that the book will be good enough that if enough engineers like it, then engineering leaders will like it. And if enough engineering leaders like it, then maybe some business leaders will read it as well. So that's something I'm eagerly seeing what will happen as the weeks, months, and years go by. Corey Quinn: This episode is sponsored in part by DataStax. The NoSQL event of the year is DataStax Accelerate in San Diego this May from the 11th through the 13th. I've given a talk previously called the myth of multi-cloud, and it's time for me to revisit that with... A sequel! Which is funny given that it's a NoSQL conference, but there you have it. To learn more, visit datastax.com that's D-A-T-A-S-T-A-X.com and I hope to see you in San Diego. This May.Corey Quinn: One thing that I always admired about your writing is that you can start off trying to make a point about one particular aspect of things. And along the way you tie in so many different things, and the functional programming is just one aspect of this. At some point, by the end of it, I half expected you to just pick a fight over vi versus Emacs, just for the sheer joy you get in effectively drawing interesting and, I guess, shall we say, the right level of conflict into it, where it seems very clear that what you're talking about is something thing that has the potential to be transformative and by throwing things like that in you're, on some level, roping people in who otherwise wouldn't weigh in at all. But it's really neat to watch once you have people's attention, just almost in spite of what they want, you teach them something. I don't know if that's a fair accusation or not, but it's very much I'm left with the sense that what you're doing has definite impact and reverberations throughout larger industries.Gene Kim: Yeah, I hope so. In fact, just to reveal this kind of insecurity is, there's an author I've read a lot of and she actually read this blog post that she wrote about the worst novel to write, and she called it The Yeomans Tour of the Starship Enterprise. And she says, “The book begins like this: it's a Yeoman on the Starship Enterprise, and all he does is admire the dilithium crystals, and the phaser, and talk about the specifications of the engine room.” And I sometimes worry that that's what I've done in The Unicorn Project, but hopefully—I did want to have that technical detail there and share some things that I love about technology and the things I hate about technology, like YAML files, and integrate that into the narrative because I think it is important. And I would like to think that people reading it appreciate things like our mutual distaste of YAML files, that we've all struggled trying to escape spaces and file names inside of make files. I mean, these are the things that are puzzles we have to solve, but they're so far removed from the business problem we're trying to solve that really, the purpose of that was trying to show the mistake of solving puzzles in our daily work instead of solving real problems.Corey Quinn: One thing that I found was really a one-two punch, for me at least, was first I read and give feedback on the book and then relatively quickly thereafter, I found myself at my first DevOps Enterprise Summit, and I feel like on some level, I may have been misinterpreted when I was doing my live-tweeting/shitposting-with-style during a lot of the opening keynotes, and the rest, where I was focusing on how different of a conference it was. Unlike a typical DevOps Days or big cloud event, it wasn't a whole bunch of relatively recent software startups. There were serious institutions coming out to have conversations. We're talking USAA, we're talking to US Air Force, we're talking large banks, we're talking companies that have a 200-year history, where you don't get to just throw everything away and start over. These are companies that by and large, have, in many ways, felt excluded to some extent, from the modern discussions of, well, we're going to write some stuff late at night, and by the following morning, it's in production. You don't get to do that when you're a 200-year-old insurance company. And I feel like that was on some level interpreted as me making fun of startups for quote/unquote, “not being serious,” which was never my intention. It's just this was a different conversation series for a different audience who has vastly different constraints. And I found it incredibly compelling and I intend to go back.Gene Kim: Well, that's wonderful. And, in fact, we have plans for you, Mr. Quinn.Corey Quinn: Uh-oh.Gene Kim: Yeah. I think when I say I admire the DevOps Enterprise community. I mean that I'm just so many different dimensions. The fact that these, leaders and—it's not leaders just in terms of seniority on the organization chart—these are people who are leading technology efforts to survive and win in the marketplace. In organizations that have been around sometimes for centuries, Barclays Bank was founded in the year 1634. That predates the invention of paper cash. HMRC, the UK version of the IRS was founded in the year 1200. And, so there's probably no code that goes that far back, but there's certainly values and—Corey Quinn: Well, you'd like to hope not. Gene Kim: Yeah, right. You never know. But there are certainly values and traditions and maybe even processes that go back centuries. And so that's what's helped these organizations be successful. And here are a next generation of leaders, trying to make sure that these organizations see another century of greatness. So I think that's, in my mind, deeply admirable.Corey Quinn: Very much so. And my only concern was, I was just hoping that people didn't misinterpret my snark and sarcasm as aimed at, “Oh, look at these crappy—these companies are real companies and all those crappy SAS companies are just flashes in the pan.” No, I don't believe that members of the Fortune 500 are flash in the pan companies, with a couple notable exceptions who I will not name now, because I might want some of them on this podcast someday. The concern that I have is that everyone's work is valuable. Everyone's work is important. And what I'm seeing historically, and something that you've nailed, is a certain lack of stories that apply to some of those organizations that are, for lack of a better term, ossified into their current process model, where they there's no clear path for them to break into, quote/unquote, “doing the DevOps.”Gene Kim: Yeah. And the business frame and the imperative for it is incredible. Tesla is now offering auto insurance bundled into the car. Banks are now having to compete with Apple. I mean, it is just breathtaking to see how competitive the marketplaces and the need to understand the customer and deliver value to them quickly and to be able to experiment and innovate and out-innovate the competition. I don't think there's any business leader on the planet who doesn't understand that software is eating the world and they have to that any level of investment they do involves software at some level. And so the question is, for them, is how do they get educated enough to invest and manage and lead competently? So, to me it really is like the sleeping giant awakening. And it's my genuine belief is that the next 50 years, as much value as the tech giants have created: Facebook, Amazon, Netflix, Google, Microsoft, they've generated trillions of dollars of economic value. When we can get eighteen million developers, as productive as an engineer at a tech giant is, that will generate tens of trillions of dollars of economic value per year. And so, when you generate that much economic activity, all problems become solvable, you look at climate change, you take a look at the disparity between rich and poor. All things can be fixed when you significantly change the economic economy in this way. So, I'm extremely hopeful and I know that the need for things like DevOps are urgent and important.Corey Quinn: I guess that that's probably the best way of framing this. So you wrote one version that was aimed at operators back in 2013, this one was aimed at developers, and effectively retails and clarifies an awful lot of the same points. As a historical ops person, I didn't feel left behind by The Unicorn Project, despite not being its target market. So I guess the question on everyone's mind, are you planning on doing a third iteration, and if so, for what demographic?Gene Kim: Yeah, nothing at this point, but there is one thing that I'm interested in which is the role of business leaders. And Sarah is an interesting villain. One of my favorite pieces of feedback during the review process was, “I didn't think I could ever hate Sarah more. And yet, I did find her even to be more loathsome than before.” She's actually based on a real person, someone that I worked with.Corey Quinn: That's the best part, is these characters are relatable enough that everyone can map people they know onto various aspects of them, but can't ever disclose the entire list in public because that apparently has career consequences.Gene Kim: That's right. Yes, I will not say who the character is based on but there's, in the last scene of the book that went to print, Sarah has an interesting interaction with Maxine, where they meet for lunch. And, I think the line was, “And it wasn't what Maxine had thought, and she's actually looking forward to the next meeting.” I think that leaves room for it. So one of the things I want to do with some friends and colleagues is just understand, why does Sarah act the way she does? I think we've all worked with someone like her. And there are some that are genuinely bad actors, but I think a lot of them are doing something, based on genuine, real motives. And it would be fun, I thought, to do something with Elizabeth Henderson, who we decided to start having a conversation like, what does she read? What is her background? What is she good at? What does her resume look like? And what caused her to—who in technology treated her so badly that she treats technology so badly? And why does she behave the way she does? And so I think she reads a lot of strategy books. I think she is not a great people manager, I think she maybe has come from the mergers and acquisition route that viewed people as fungible. And yeah, I think she is definitely a creature of economics, was lured by an external investor, about how good it can be if you can extract value out of the company, squeeze every bit of—sweat every asset and sell the company for parts. So I would just love to have a better understanding of, when people say they work with someone like a Sarah, is there a commonality to that? And can we better understand Sarah so that we can both work with her and also, compete better against her, in our own organizations?Corey Quinn: I think that's probably a question best left for people to figure out on their own, in a circumstance where I can't possibly be blamed for it.Gene Kim: [laughing].That can be arranged, Mr. Quinn.Corey Quinn: All right. Well, if people want to learn more about your thoughts, ideas, feelings around these things, or of course to buy the book, where can they find you?Gene Kim: If you're interested in the ideas that are in The Unicorn Project, I would point you to all of the freely available videos on YouTube. Just Google DevOps Enterprise Summit and anything that's on the plenary stage are specifically chosen stories that very much informed The Unicorn Project. And the best way to reach me is probably on Twitter. I'm @RealGeneKim on Twitter, and feel free to just @ mention me, or DM me. Happy to be reached out in whatever way you can find me. Corey Quinn: You know where the hate mail goes then. Gene, thank you so much for taking the time to speak with me, I appreciate it.Gene Kim: And Corey, likewise, and again, thank you so much for your unflinching feedback on the book and I hope you see your fingerprints all over it and I'm just so delighted with the way it came out. So thanks to you, Corey. Corey Quinn: As soon as my signed copy shows up, you'll be the first to know.Gene Kim: Consider it done. Corey Quinn: Excellent, excellent. That's the trick, is to ask people for something in a scenario in which they cannot possibly say no. Gene Kim, multiple award-winning CTO, researcher, and author. Pick up his new book, The Wall Street Journal best-selling The Unicorn Project. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you hated this podcast, please leave a five-star review on Apple Podcasts and leave a compelling comment.Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

В 40 выпуске подкаста Javaswag поговорили с Никитой Прокоповым о разочаровании в Java, простоте Clojure и опенсорс проектах 00:01:20 О себе, Java, Erlang, Ocaml, Clojure 00:05:52 Что хорошего в Java 00:08:24 Dependency Injection & Spring 00:15:22 Impl и интерфейс, классы, помощь от IDE 00:20:52 Сложная архитектура и сеньоры 00:24:46 Maven, Gradle, Python как билд тул 00:38:08 Паблишинг библиотеки в Мавен Централ 00:46:04 Библиотека Skija и Fleet 00:53:16 Clojure 01:02:08 REPL, сериализация 01:07:52 ClojureScript 01:12:52 База данных - Datascript 01:21:28 Личный бренд 01:25:42 Дизайн интерфейсов, шрифты и программирование 01:29:46 TODO листы и Roam Research Гость https://twitter.com/nikitonsky Телеграм канал - https://t.me/nikitonsky_pub Блог https://tonsky.me/ Ссылки от гостя Кип сейф! 🖖

Array Cast - September 30, 2022 Show NotesMany thanks to Bob Therriault for gathering these links:[01] 00:03:08 ADSP podcast on K https://adspthepodcast.com/2022/09/23/Episode-96.html[02] 00:03:30 Paradigm Conference 2022 https://esolangconf.com/[03] 00:04:25 Troels Henriksen https://sigkill.dk/[04] 00:05:05 Futhark https://futhark-lang.org/[05] 00:06:12 Linux https://www.linux.org/[06] 00:08:00 Textualize https://www.textualize.io/[07] 00:08:27 Standard ML https://en.wikipedia.org/wiki/Standard_ML Common Lisp https://en.wikipedia.org/wiki/Common_Lisp Haskell https://www.haskell.org/[08] 00:09:50 Cosmin Oancea http://hjemmesider.diku.dk/~zgh600/[09] 00:10:53 Ocaml https://ocaml.org/[10] 00:12:20 Numpy https://numpy.org/ PyTorch https://github.com/pytorch/pytorch[11] 00:13:07 Single Assignment C https://www.sac-home.org/index[12] 00:13:20 Codfns https://github.com/Co-dfns/Co-dfns DEX https://github.com/google-research/dex-lang Accelerate for Haskell https://www.acceleratehs.org Copperhead https://github.com/bryancatanzaro/copperhead Tensorflow https://github.com/tensorflow/tensorflow JAX https://github.com/google/jax[13] 00:18:39 Phd Position https://employment.ku.dk/phd/?show=157471[14] 00:20:17 Experiential Learning https://en.wikipedia.org/wiki/Experiential_learning[15] 00:21:21 DIKU https://di.ku.dk/english/ Hiperfit http://hiperfit.dk/ Simcorp https://en.wikipedia.org/wiki/SimCorp Dyalog https://www.dyalog.com/[16] 00:23:00 TAIL http://hiperfit.dk/pdf/array14_final.pdf apltail https://github.com/melsman/apltail Martin Elsman https://elsman.com/[17] 00:29:17 Parametric Polymorphism https://en.wikipedia.org/wiki/Parametric_polymorphism[18] 00:32:06 Jay Foad https://aplwiki.com/wiki/Jay_Foadhttps://docs.dyalog.com/latest/Compiler%20User%20Guide.pdf[19] 00:33:00 Tacit Programming https://aplwiki.com/wiki/Tacit_programming[20] 00:36:30 Mandelbrot set https://en.wikipedia.org/wiki/Mandelbrot_set[21] 00:41:07 Typed Array Languages https://mlochbaum.github.io/BQN/implementation/compile/intro.html#typed-array-languages[22] 00:42:05 Leading Axis Array Theory https://aplwiki.com/wiki/Leading_axis_theory[23] 00:43:56 Ken Iverson https://en.wikipedia.org/wiki/Kenneth_E._Iverson[24] 00:49:25 Conor's Array Comparison https://github.com/codereport/array-language-comparisons[25] 00:49:50 APEX https://gitlab.com/bernecky/apex Bob Bernecky https://www.snakeisland.com/[26] 00:51:05 Second Order Array Combinators https://futhark-book.readthedocs.io/en/latest/language.html[27] 00:52:30 Associativity https://en.wikipedia.org/wiki/Associative_property Commutativity https://en.wikipedia.org/wiki/Commutativity[28] 00:56:12 Toxoplasma Gondii https://en.wikipedia.org/wiki/Toxoplasma_gondii[29] 00:59:20 Guy Blelloch https://en.wikipedia.org/wiki/Guy_Blelloch Nesl http://www.cs.cmu.edu/~scandal/nesl.html[30] 01:00:38 Remora https://www.ccs.neu.edu/home/jrslepak/typed-j.pdf Justin Slepak https://jrslepak.github.io/[31] 01:01:12 Conor's Venn diagram https://github.com/codereport/array-language-comparisons[32] 01:02:40 K https://aplwiki.com/wiki/K Kona https://aplwiki.com/wiki/Kona[33] 01:03:20 April https://aplwiki.com/wiki/April Andrew Sengul Episode on Array Cast https://www.arraycast.com/episodes/episode23-andrew-sengul[34] 01:04:40 Py'n'APL https://github.com/Dyalog/pynapl APL.jl https://aplwiki.com/wiki/APL.jl May https://github.com/justin2004/may Julia https://julialang.org/[35] 01:08:05 Bjarne Stroustrup C++ https://www.stroustrup.com/[36] 01:09:16 Artem Shinkarov https://ashinkarov.github.io/ Sven-Bodo Scholz https://www.macs.hw.ac.uk/~sbs/homepage/main/Welcome.html https://www.microsoft.com/en-us/research/video/sac-off-the-shelf-support-for-data-parallelism-on-multicores/[37] 01:10:19 Contact AT ArrayCast DOT com

Ella Ehrlich has been a developer at Jane Street for close to a decade. During much of that time, she's worked on Gord, one of Jane Street's oldest and most critical systems, which is responsible for normalizing and distributing the firm's trading data. Ella and Ron talk about how to grow and modernize a legacy system without compromising uptime, why game developers are the “musicians of software,” and some of the work Jane Street has done to try to hire a more diverse set of software engineers.You can find the transcript for this episode  on our website.Some links to topics that came up in the discussion:EG, The League of Legends team that Ella is a huge fan of.Apache Kafka, the message bus that Gord migrated to.Some of the various sources of symbology you have to deal with when normalizing trading data. (Really, there are too many sources to list here!)A list of Jane Street's recruiting Programs and Events, including INSIGHT, which focuses on women, and IN FOCUS, which focuses on historically underrepresented ethnic or racial minorities.

Episode 174 - 18 And Life Until last week, I was going to open the show saying it's been a long time since we last recorded, but we slipped in an interview with the guys from plz.review - so that's not exactly true anymore. It has, however, still been a while since we've had a normal, full session of discussion and argument. Delayed: The publishing/editing of this episode was unfortunately delayed due to me finally catching Covid. plz.review Updates Github "integration" is available, we even had GerritForge - Home page listed in the show notes, as part of GerritForge there's GerritHub for online hosted Gerrit+GitHub integration which uses Gerrit's replication plugin, and a Github integration for authentication/authorization. Patch sets and comments remain in Gerrit. JDK Related Since the last main episode, Java 18 was released (and earlier this week JDK 18.0.2 was released with various security and docker improvements.) Java 19 is currently in Rampdown Phase Two with a GA release slated for 2022/09/20 405: Record Patterns (Preview) 422: Linux/RISC-V Port 424: Foreign Function & Memory API (Preview) 425: Virtual Threads (Preview) 426: Vector API (Fourth Incubator) 427: Pattern Matching for switch (Third Preview) 428: Structured Concurrency (Incubator) Rust 1.63: Scoped Threads : rust. Similar to the forthcoming Structured Concurrency for Java. Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses - Interestingly no replies to that post at all. Value type companions, encapsulated Project Leyden: Beginnings (r/java discussion) Testing clean cleaner cleanup – Inside.java - Replacing finalizers with Cleaners. Tooling SD Times Open-Source Project of the Week: Adoptium - SD Times IntelliJ IDEA 2022.2 Goes Beta  | The IntelliJ IDEA Blog - Switches from running with Jetbrains' JDK11 to JDK17 IntelliJ IDEA 2022.2 Is Out! | The IntelliJ IDEA Blog JetBrains Fleet: The Next-Generation IDE by JetBrains Java / JVM Hibernate ORM 6.0 Delivers Improved Performance Languages Kotlin/Native vs. C++ vs. Freepascal vs. Python: A Comparison | by Alex Maryin | Apr, 2022 | Better Programming Kotlin 1.7.0 Released | The Kotlin Blog Scala 3.1.3 released! | The Scala Programming Language Build Bazel Announcing Bazel & JetBrains co-maintenance of IntelliJ IDEA Bazel Plugin - Bazel Bazel Community Update - 5/16/22 - YouTube Manage external dependencies with Bzlmod  |  Bazel Apache Maven Wrapper – Maven Wrapper Alternate Languages Celebrating 50 Years of Smalltalk | by Richard Kenneth Eng | Jul, 2022 | ITNEXT Help Microsoft shape the Azure SDK for Rust Shaving 40% Off Google's B-Tree Implementation with Go Generics - ScyllaDB Zaplib post-mortem - Zaplib docs - Post-mortem of porting JS to Rust/WASM Simplifying Go Concurrency with Futures Common Lisp - Repl Style. Dev visually with CLOG Builder : Common_Lisp OCaml 5 and new Website 1.5. Summary — OCaml Programming: Correct + Efficient + Beautiful - new OCaml site launched Ocaml 5 concurrency tutorial - concurrent OCaml is finally here (almost) GitHub - ocaml-multicore/eio: Effects-based direct-style IO for multicore OCaml Will OCaml 5+ multicore be fragile? - #17 by gasche - Learning - OCaml C++ C++ 23 to introduce module support | InfoWorld GitHub - carbon-language/carbon-lang: Carbon language specification and documentation. - An experimental successor to C++ Looks like it's getting a lot of flack on Twitter - Twitter: Carbon C++ Results Security Reflections on Log4J Security Issues Weeks after breach, the Heroku GitHub connections remains on ice Misc Major Version Numbers are Not Sacred Decentralized Identifiers (DIDs) v1.0 is a W3C Recommendation | W3C News Decentralized Identifiers (DIDs) v1.0 An open-source tool to seed your dev database with real data : golang How Apple, Google, and Microsoft will kill passwords and phishing in one stroke | Ars Technica Complexity is killing software developers | InfoWorld

How do we know that we can trust software? One answer is software reliability testing. Dr Mário Pereira and Dr António Ravara from the Nova School of Science and Technology in Lisbon, Portugal, and their collaborators have developed the Cameleer tool, a formal verification software tool for OCaml-written code. Read the original article: https://doi.org/10.1007/978-3-030-81688-9_31Read more in Research Outreach

While blockchains are huge right now, finding one to build on that doesn't use a ton of energy, has good privacy protections, and operates efficiently is harder than it looks. The original breakout blockchain, Bitcoin, was slow to adopt any innovations coming out of research. Other blockchains use the electricity of a small country to play elaborate gambling games. For someone looking to build the future of Web3, what are your options?On this sponsored episode of the podcast, we talk to Tezos co-founder Arthur Breitman. After finding out that the Bitcoin blockchain wouldn't incorporate all the good ideas generated around it—proof of stake, privacy improvements, and smart contracts to name a few—he decided to build his own. Arthur has a background in machine learning and statistics but spent his early 20s teaching self-driving cars how to turn left and working in quantitative finance for high-frequency trading. High-frequency trading was data-driven, but there was so much noise that machine learning didn't do very well. Self-driving cars, meanwhile, presented a more structured problem, so neural networks could yield good results. Around that time, Arthur got bit by the crypto bug. It lived at the intersection of a lot of his interests: Cryptography touched on computer science and math, but his time in finance got him wondering about banks and money work. The idea of individual sovereignty scratched a personal philosophical itch. Naturally, Arthur decided to try some mining software. It took all of his computer's resources, so he uninstalled it. But after seeing the price of Bitcoin break a dollar and other news items about it, he looked closer. He started to think about what a company could do if it didn't have to maintain banking relationships. He thought about possible applications, like decentralized poker. When Bitcoin refused to adopt the improvements developed by competing alt coins, Arthur started thinking about a new blockchain that would respond to new developments and focus on efficient processing, security, and a good smart contract system. Forking the code wasn't enough; he needed a new ledger. That's when Tezos was born. It was initially built by a small team of OCaml programmers using that language's functional subset. Arthur was inspired by the example of WhatsApp, which was built by a small team of senior Erlang engineers. While OCaml would limit the talent he could hire, it would be a very efficient way to build an error-free transaction system. He could have built the whole thing in Java, sure, but Arthur estimates that it would have cost a whole lot more. If you're interested in learning more about what an engineer's blockchain ecosystem looks like, check out the Tezos home page. Discover building on Tezos: https://tezos.com/build/

Today's guest on the Fortune Teller Podcast is Emre Tekisalp, CEO of O(1) Labs. O(1) Labs current projects are Mina, the world's lightest blockchain, that is powered by participants, and snarky, an Ocaml front-end for writing R1CS Snarks. Snarky is modular over the backend SNARK library, and comes with backends from libsnark. Mina is the world's lightest blockchain, at 22kb, letting users quickly and directly access the current state on their smartphone and other blockchains, powered by the users. Mina uses zero knowledge technology, to make for a secure and democratic future we all deserve. One can build on Mina with zkApps, smart contracts made possible by zero knowledge. The SDK is based on Typescript. Users today are compelled to provide their data to centralized entities in order to participate in the modern world. Even in the decentralized side of crypto, there are growing efforts to compel users to give up their data to be able to engage in the crypto space. Mina differs from these centralized crypto businesses with zkApps, smart contracts powered by zero knowledge, to help keep the users in control of their privacy by confirming and sharing proofs of their data, rather than the data itself. You provide proof of your data, as opposed to the data itself. This helps to reduce the chances for your personal information to be hacked or sold. This allows you to be the only owner of your data. With Mina's light size and off-chain nature of zkapp smart contract computations, Mina's proof system can be easy to use on other chains. Currently, a bridge is being established between Mina and Ethereum, with the progress that is made here to go towards building trustless bridges on other chains as well. This will help dapps on other chains to make use of the privacy-preserving data verification, as well as the prompt proofs of huge computations and covert login features of Mina's zkApps. Mina's zkApps can securely connect with any website and access verified actual data for use on-chain. This allows developers to leverage data on the internet and then bring it on-chain. All of this is done without ever risking the privacy of their users. Many blockchains have become so heavy, that intermediaries are needed to run nodes, which breaks from the primary decentralization promise of blockchain, thus leaving these networks to be more susceptible to a 51% attack. Since Mina's 22kb blockchain is so light, this means that anyone has the opportunity to easily connect peer-to-peer and formalize transactions like a full node, guaranteeing powerful censorship-resistance and security for the blockchain. For more: https://www.o1labs.org/ https://minaprotocol.com/ -- The Fortune Teller podcast is a discussion between industry leaders in blockchain and financial technologies. The podcast focuses on the development of blockchain-based financial services and outlines the current state of the industry and future predictions for the adoption of decentralized finance. Go to www.teller.finance/

"un langage de prédilection pour créer des langages mais pas que ..." Le D.E.V. de la semaine est Didier Plaindoux, fondateur de Fungus. Didier vient nous parler de Ocaml, le langage qui combine une approche Objet, fonctionnelle et modulaire. Et qui le fait tellement bien que OCaml est souvent utilisé pour créer d'autres langages (y compris lui-même) ! Nous parlons à plusieurs moments de l'apport de la synthèse de type chez Ocaml, signe de la puissance de son approche ! Didier nous parle aussi de l'approche très formelle et donc mathématique de OCaml. Liens évoqués pendant l'émission Site officielRessources à propos d'OCamlEpisode IFTTD sur la programmation fonctionnelle avec Frederic CabestreMirageOSRetrouvez tous nos épisodes sur notre site https://ifttd.io/listes-des-episodes/**Continuons la discussion**@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)Retrouvez tous nos épisodes sur notre site https://ifttd.io/** Le Livre Blanc de Danny Miles **Quels KPI suivre quand on est CTO d'un site e-commerce ?Danny Miles, CTO de Dollar Shave Club** Cherchez l'équipe de vos rêves **Si vous avez envie de changer de job, testez My Little Team qui vous permet de choisir une équipe qui vous ressemble plutôt qu'une entreprise sans trop savoir où vous arriverez !https://www.mylittleteam.com/ifttd** La Boutique IFTTD !!! **Affichez votre appréciation de ce podcast avec des goodies fait avec amour (https://ifttd.io/boutique/) ou affichez clairement votre camp tabulation ou espace.** Soutenez le podcast **Ou pour aller encore plus loin, rejoignez le Patréon IFTTD.** Participez au prochain enregistrement !**Retrouvez-nous tous les lundis à 19:00 pour assister à l'enregistrement de l'épisode en live et pouvoir poser vos questions pendant l'épisode :)Abonnez-vous à la chaîne Twitch ou retrouvez les épisodes en replay sur YouTube @ifthisthendev

On this episode of The Diff, Joel talks to Jordan, the creator of React, our most popular open source project, and the creator of Reason, a programming language cousin of JavaScript based on OCaml. Learn about why React was born, the need for another programming language, and how both of these projects have impacted development both inside and outside of Facebook. Also Joel finds out the real name of Reason's package manager.

Antonio Monteiro talks about building Lumo, improving the ClojureScript beginner experience, typed GraphQL in OCaml, and creating a custom AWS Lambda runtime.. Sponsor: Deps - Private, Hosted, Maven Repositories Lumo CLJS GWT Pilloxa V8 custom startup snapshots Glitch with Lumo clj-commons Om Relay Falcor Ladder The REPL episode with Martin Klepsch OCaml Reason ML Lambda support for Powershell Rust runtime for AWS Lambda and GitHub project Antonio’s OCaml Lambda runtime AWS Lambda Runtime API Howard Lewis Ship on The REPL talking about GraphQL Small FP - Antonio Monteiro Developing ReasonML frontend with GraphQL Zeit

Xavier LeroyCollège de FranceScience du logicielAnnée 2018-2019Leçon inaugurale : Le logiciel, entre l'esprit et la matière.Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche.Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCamlXavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker.Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui.Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Xavier LeroyCollège de FranceScience du logicielAnnée 2018-2019Leçon inaugurale : Le logiciel, entre l'esprit et la matière.Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche.Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCamlXavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker.Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui.Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Xavier Leroy Collège de France Science du logiciel Année 2018-2019 Leçon inaugurale : Le logiciel, entre l'esprit et la matière. Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche. Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCaml Xavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker. Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui. Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Xavier Leroy Collège de France Science du logiciel Année 2018-2019 Leçon inaugurale : Le logiciel, entre l'esprit et la matière. Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche. Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCaml Xavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker. Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui. Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Vamos falar sobre programação funcional: afinal, ela é usada no mercado? Faz sentido usar no dia-a-dia? Eu preciso aprender? Hora de descobrir! Participantes: Paulo Silveira, o host que não sabe nada sobre programação funcional Roberta Arcoverde, engenheira de software no Stack Overflow Andrei Formiga, professor na Universidade Federal da Paraíba Charlotte Lorelei Oliveira, engenheira de software na Xerpa Maurício "Balboa" Linhares, o co-host que é fã de Scala Produção e conteúdo: Alura Cursos online de Tecnologia Caelum Ensino e Inovação Links: Livro de Ocaml do Andrei Why functional programming matters Structure and interpretation of computer programs Livro de Haskell Elixir, a linguagem hipster - Hipsters #48 Curso de Clojure Programação funcional em .NET Programação funcional e concorrente em Rust Site do Elixir Site do Erlang Site do Clojure Site do Scala Site do Haskell Edição e sonorização: Radiofobia Podcast e Multimídia