As Brian Kernighan said “UNIX since the start has become a vehicle for creating and using programming languages.” Brian initiated work on what would become the UNIX system. He helped develop it to run on a minicomputer and would eventually be ported to other computers. In this episode, Brain will go in-depth on how the UNIX was built. Episode Page Episode Transcript “If you wanted, you could go sit in your office and think deep thoughts or program, or write on your own blackboard or whatever, but then come back to the common space when you wanted to.“ - Brian Kernighan “I found it easier to program when I was trying to figure out the logic for myself rather than trying to figure out where in the infinite stack of documentation was the function I needed. So for me, programming is more like creating something rather than looking it up, and too much of today's programming is more like looking it up.” - Brian Kernighan “If what I find challenging or hard or whatever is also something that other people find hard or challenging or whatever, then if I do something that will improve my lot, I'm perhaps improving their lot at the same time.” - Brian Kernighan Links: Brian's Homepage Book: Unix: A History and a Memoir Book: Millions, Billions, Zillions: Defending Yourself in a World of Too Many Numbers Book: Understanding the Digital World: What You Need to Know about Computers, the Internet, Privacy, and Security

CoRecursive - Software Engineering Interviews

The Birth of Unix with Brian Kernighan

How do CPUs work? How do compilers work? How does high-level code get translated into machine code? Today's guest is Matt Godbolt and he knows the answers to these questions. How he became an expert in bare metal programming is an interesting story. Matt shares his origin story and the creation of compiler explorer in today's interview. Episode Page Episode Transcript Links: Compiler Explorer Matt's Github Matt's Blog Matt's YouTube

To The Assembly

Preparing our minds for the inevitable - death is pressing. After facing terminal cancer, Kate Gregory reminded herself that this event can still become inspiring by focusing on the positive. In this episode, Kate is going to share her success and explain how you would apply her 5 pieces of advice to your career as a software developer to help you to build a remarkable career for yourself. Episode Page Episode Transcript Links: Gregory Consulting Limited Kate's Classes in Pluralsight Include CPP Kate's Blog  

Memento Mori

Today Richard Feldman shares his story of going from javascript developer to elm developer to functional programming teacher.  Along the way, Richard finds that people are teaching functional programming wrong.  We are teaching it in a way that misses how most industrial software developers learn best. In this episode, Richard Feldman delves into Elm, his approach, and how to make teaching delightful. Episode Page Episode Transcript Links: Book: Elm in Action A Taze of ATS Elm Language

We are teaching Functional Programming Wrong

Building Subversion Software is just the tool and it should get out of your way. In this episode, we will discuss Jim Blandy’s insights on how to build and recognize improvements for a great developer tool and find out how he approached the question: “What's the worst software that you use every day?” “Everybody likes imaginary code because imaginary code is always perfect.” -Jim Blandy “You don't want to maximize engagement with your version control system. You just want it to do its job and get out of the way. And so basically if somebody says, you know, this doesn't suck. That's actually pretty much exactly the right thing.” - Jim Blandy “If you're making a series of small incremental changes to a large data structure, then the way that the persistent data structures are trying really hard to share as much data as possible really works in your favor.” -Jim Blandy Episode Page Episode Transcript Links: Subversion Jim's Email Mercurial  GNU Emacs 

Software That Doesn't Suck With Jim Blandy

Choosing The Right Tool For the Job Choosing the right programming language or framework for a project can be key to the success of the project. In today’s episode, Sean Allen Sean shares a story of picking the right tool for a job. The tool he ends up picking will surprise you. His problem: make a distributed stream processing framework, something that can take a fire hose of events and perform customer’s specific calculations on them but the latency needs to be less than a millisecond and the calculations might be CPU intensive. Who would need something like this? The initial use case was risk systems for Wall Street banks.  “Basically programming languages are tools. It's not about ergonomics, it's not about developer experience, it's not about all the things that we normally talk about, it's about getting the job right. For whatever that means it's a means to an end.” - Sean Allen Episode Page Episode Transcript Links: Martin Thompson - Low Latency JVM Basho - Riak Haskell Quicksort Pony Talk Pony Lang 

Unproven Tech Case Study with Sean Allen

Chasing Your Curiosity and Continuous Learning Things are easier to learn when you are passionate about something. A lot of great careers are built on curiosity and obsession including Krystal Maughan our guest for today's episode. Krystal will share her journey as she chased her curiosity in programming wherever it led her. "Everybody has that moment when everything's shiny, you know when it's new and you walk on to campus like Google or whatever. Like the first time, I went to Google IO and I just thought it was like, this is insane." "If you like to learn things, I think that's a gift. I think that's not something that everybody has."  "I think that seeing programming in different ways and seeing that it could be this kind of fun thing that you could break apart and find different ways of executing."  Episode Page Episode Transcript Links: Krystal's Blog Her GSOC Project Interview with Krystal Full Timeline of Krystal's Journey 

Krystal's Story

There’s joy that can be found in language learning and pain as well. Whether you’re a beginner or an expert, there are still some things you can only discover by picking up a new language.  Bruce Tate will tell us how learning new languages rekindled the spark of joy for him. “I find that learning a new language mixes a lot of joy in that pain, and that's when I grow most rapidly as a developer.” “You can't break somebody else through their own pain. They have to learn their own lessons, and they have to, at some point in the model, they have to feel more and more pain to break through to the expert.” “When you visit other places, when you learn other languages, the world gets smaller.” Episode Page Episode Transcript Links: 7 Languages in 7 Weeks Book 7 More Languages Joy Talk  

Learning a new language with Bruce Tate

Buckle up, on today’s episode Adam interviews Sam about how the abstract algebra and probabilistic data structures helped solve fast versus big data issues that many are struggling with. Sam Ritchie is a machine learning researcher and a mechanical engineer by training. Stop in to hear Adam and Sam’s conversation about portal abstractions that let you leverage work from other fields. You cannot miss this episode! "And that's really all we want to do. Like, we want things where you can pause and wait a while and then load it back out and keep going." - Sam Ritchie "I'm aiming to implement these interfaces and pass these tests and then being able to immediately turn around and have like an approximate sliding window counter that would just work with stripes, like entire machine learning feature generation interface." - Sam Ritchie "I'm really passionate about and the reason this stuff's important is. You want to go mine the literature of what other people have done. You know you want to go be able to plug these things into your work and really just benefit from this incredible community that's been cranking for, you know, again, maybe hundreds of years." - Sam Ritchie Episode Page Episode Transcript Links: Sam's Blog Summing Bird Algebird Reinforcement Learning

Portal Abstractions with Sam Ritchie

Legacy code is everywhere. I don't think I've met anyone who doesn't have to deal with legacy code in the substantial portion of his work. Our guest, Jonathan Boccara is a French C++ developer and the author of The Legacy Code Programmer's Toolbox. In this episode, Jonathan will help us understand and build the correct mindset to effectively work with legacy code by using his approach and processes. "An important message I'm trying to get across is that you should not complain if you don't, in turn, intend to improve the code." - Jonathan Boccara "That would be any critique that's technical. One thing that comes up very often is levels of obstruction. If I had to sum up best practices in, in three words, that would be those levels of obstruction." - Jonathan Boccara "The point of code is to make a piece of software run and to make it run in a way that will make customers happy. " - Jonathan Boccara Episode Page Episode Transcript Links: Fluent C++ SE Radio: Understanding Legacy Code Counting words in your code  

Loving Legacy Code with Jonathan Boccara

Adam talked to Jared Forsyth about his journey from untyped javascript to using flow and eventually reasonml. Click here to see if you are eligible for a the Springboard scholarship from our sponsor "I mean, I was, I'll admit it I was definitely in the: 'I was scarred by Java and C plus plus in an intro to programming class and I never want to look at types again' Camp" "My first language was Python and followed closely by Javascript. And so I was, I was loving the loosey goosey scripting language. My first experience of using types in JavaScript, I was like is this going to be terrible? Because there's so much overhead in Java and C plus, plus you have to write types for literally everything." Links: Springboard Scholarship Reason Town Podcast ReasonML Jared's Talk on ReasonML React with Reason Talk Types in Javascript 

The Reason For Types with Jared Forsyth on ReasonML and Javascript

Adam talks to Karl Hughes about his path to becoming a conference speaker and the work he has done to make it easier for others to follow in his footsteps. "I didn't start trying to speak at conferences until I was at least seven or eight years into my software development career. So. Just a couple of years ago and before that, I think what helped build confidence was speaking occasionally at meetups. I started talking occasionally at local code bootcamps, just kind of getting to be in front of a crowd and start to build up some like level of self-assuredness and eventually I think the next step was just obvious. I wanted to push myself to do something a little scarier and bigger, and that was like, get in front of people at a real conference. " "And so it is scary. Partly also it's that, you know, because it was my first time, I didn't really know what to expect. I had only been to a couple of tech conferences before. I didn't know what the audiences were going to be like. If there was kind of be this like big tomato throwing thing at the end, they're all just bashed me or if it was going to be like a more of a friendly conversation." Show notes: CFP Land Karl's Personal Site Washing Machine Guy Talk episode webpage 

Karl L Hughes on Conference Talks

Today we try a different format. Adam invites his neighbour, Don McKay, over to ask him questions. An interesting discussion on recursion, corecursion and the naming of the podcast unfolds. "John was saying, we conclude that since modularity is the key to successful programming, dah, dah, dah, dah, dah. I think what he means by modularity is okay, we write our fold and it's like three lines long.  Once that exists somewhere, we don't have to have that base case all over our code. We ended up programming a higher declarative level. The other reason is just I really like clean abstractions. There's more to learn but once you do, you're able to kind of have this language where you can talk about these things at a higher level" Why Functional Programming Matters - John Hughes Beautiful Folds - Gabriel Gonzalez 

Don and Adam discuss folds

David Heinemeier Hansson talks to Adam about being avoiding a software monoculture. He explains why we should find a programming language that speaks to us, why ergonomics matter and why single page apps and microservices are not for him. "That is the pleasure and privilege of working with the web. No one knows what you built it. It, you could build an in basic, you can build it a no camel, you can build in the Haskell, you can build it in whatever Ruby. No one is going to be none the wiser you get to choose, You want to write for the web. I mean, literally every programming language that's ever been invented and known to humankind is serving a webpage somewhere." "There's just something heartwarming in that, that this idea of the monoculture that like this is all just a battle to the death and there's going to be one framework and there's going to be one programming language that lifts is left standing. Programmers are really drawn into that right into that horse race. So much of their technology choices seem to be predicated on like, is this popular? Is this going to be popular next year? Do you know what I mean?" "The crimes against programming humanities that have been done in the service of single page applications are far worse than the ones that have been done in the service of microservices. But then of course, as it is, lots of people combine the two. So it's a fleet of microservices serving a single page application, and that's just where it bam, my head explodes with like, yeah, I would rather retire and fucking, I don't know, make weaved baskets than deal with that shit." "I'm not saying that email is sort of in its base form is wonderful, but you know what is wonderful asynchronous. Write-ups of cohesive, full thoughts, people using actual goddamn paragraphs to describe ideas and proposals, and they put those paragraphs together into form entire, cohesive thoughts. And then letting someone take that in, read those several paragraphs, sit back for more than five minutes. Ponder that. And then respond." Links: The Majestic Monolith On React TDD is Dead RailsConf 2014 Podcast Page

David Heinemeier Hansson, Software Contrarian

Today Adam talks to Shadaj Laddad. What is React? Why do we need front end frameworks at all. Shadaj explains modern front end web development. He also explains why he likes to use react from scala.js and built a framework to make that easy for all. "React is a lot of things. I guess the core principle is it lets you model your entire application as a function from properties of what you want your page to look like to an HTML tree. Everything is defined as this function. "" "In the traditional web, everything was built upon mutations, right? You'd collect some data and then you'd do some DOM manipulations to say, Hey, modified the contents of this html node." "React kind of abstracts away from that and says, Hey, this is the result I want. Just tell me what you would like the webpage should look like. And I'll do the internal work to actually make that happen. "" Person site of Shadaj Slinky JS Talks by Shadaj Youtube channel https://corecursive.com/044-shadaj-laddad-react-and-scala-js/

React and Scala JS with Shadaj Laddad

CoRecursive features In-Depth technical interviews with software developers. Learn about programming languages such as Scala, Haskell, Idris, Kotlin, Erlang and Functional Programming and Type Theory from experts in one on one interviews. Similar to podcasts software engineering daily, functional geekery and hanselminutes technology podcast.

hubhopper

CoRecursive - Software Engineering Interviews

hubhopper