This week Jerod is joined by Paul Biggar the creator of Dark, a new way to build serverless backends. Paul shares all the details about this all-in-one language, editor, and infrastructure, why he decided to make Dark in the first place, his view on programming language design, the advantages Dark has as an integrated solution, and also why it’s source available, but NOT open source.
In this game, your goal is to create a sequence of functions which transforms the colored cubes into the desired pattern.
It starts off pretty easy, but there’s plenty of challenge once you get past the first few levels. A wonderful companion to our recent FP episode of JS Party with Eric Normand (a must-listen if you’re FP curious, IMHO).
Oh, and join us in the #jsparty channel of our community slack where we’re giving away three FREE e-book copies of Eric’s new book! 🎁
Yes, it’s that time once again… Time for yet another front-end JS library!
Often times “simple” is a proxy for “only solves my immediate use-case, but I will continue to link up JS solutions that bring good ideas to the table, and pure functions are a good idea for many reasons.
Like so many of Dan Abramov’s posts, this blew my mind. He is incredible at breaking down complicated concepts and making them understandable, as well as showing the reasons behind the concepts. Should you read this post? I’d say yes, but Dan would say:
If you’re the kind of person who likes to learn about programming ideas several years before they hit the mainstream, it might be a good time to get curious about algebraic effects. Don’t feel like you have to though. It is a bit like thinking about async / await in 1999.
“Higher-order function” is one of those phrases people throw around a lot. But it’s rare for anyone to stop to explain what that means. Perhaps you already know what a higher-order function is. But how do we use them in the real world? What are some practical examples of when and how they’re useful? Can we use them for manipulating the DOM? Or, are people who use higher-order functions showing off? Are they over-complicating code for no good reason?
Author James Sinclair on why bother learning this challenging concept:
A solution that would give us the elegance of using small, simple functions. But also the efficiency of doing our processing in a single pass through the array. What is this magical solution? It’s a concept called a transducer.
Quick and easy explanations of immutable data structures, pure functions, and first-class functions. Pairs nicely with Go Time #87.
I’m blown away by the clarity of explanation in this post, and came away with it excited to start using Reduce way more. Definitely worth a read to level up your game.
Reduce is the Swiss-army knife of array iterators. It’s really powerful. So powerful, you can build most of the other array iterator methods with it, like .map(), .filter() and .flatMap(). And in this article we’ll look at some more amazing things you can do with it. But, if you’re new to array iterator methods, .reduce() can be confusing at first.
Panelists Mat Ryer and Johnny Boursiquot are joined by guest panelist Aaron Schlesinger to ask/answer questions like; What is functional programming? Can you do functional programming in Go? Can we apply any learnings from functional programming languages as we write Go code today?
But functional programming does not need to be all-or-nothing, and in my view it’s better to be a little more pragmatic. That is to say, if you don’t do anything else, try writing code that’s functional-ish.
This definitely matches my personal approach. Fully functional still kinda blows my brain, but layering in functional approaches has dramatically improved my code. What about you? Would love to hear some functional or functional-ish “war stories”.
This is an absolute mindbender if you’re not already deeply in the functional world, but this post by James Sinclair is also a readable & fascinating look at how to incrementally move from a try/catch error management approach to a fully functional approach.
In this article, we’ll assume you already know about function composition and currying. If you need a minute to brush up on those, that’s totally OK. And a word of warning. If you haven’t come across things like monads before, they might seem really… different. Working with tools like these takes a mind shift. And that can be hard work to start with.
Go already supports many features that functional programmers might want: closures, first-class functions, errors as values, etc. The main feature (and in fact only feature for now) that Fo adds is type polymorphism via generics. Generics encourage functional programming techniques by making it possible to write flexible higher-order functions and type-agnostic data structures.
People have been asking for Generics in Go since the beginning of time. (2009)
At this time, Fo should be thought of primarily as an experiment or proof of concept. It shows what Go looks like and feels like with some new language features and allows us to explore how those features interact and what you can build with them.
Perhaps Fo’s author is hoping that enough traction/excitement around this project will convince the Go team to add Generics to the language.
Our world is full of uncertainty. This uncertainty bleeds into our programs. A common way of dealing with this is null/nil. Unfortunately, this leads to even more uncertainty because this design means any value in our system could be null unless we’ve explicitly checked it’s presence.
Imagine how many developer-hours are wasted globally each year dealing with null/nil. The number would probably astound us.
The major advantage of guard clauses is to suss out invalid inputs (often nils) at the perimeter of your program/module/function, so the rest of your code doesn’t have to concern itself with these uncertainties. But
Maybe there’s another way…
In Elm, all values are guaranteed to be present except for those wrapped in a Maybe. This is a critical distinction. You can now be confident in most of your code and the compiler will force you to make presence-checks in places where values are optional.
Click through to learn the mechanics of it all.
Eric Normand joined the show to talk about Functional Programming. We talked about FP vs OOP vs Imperative, why FP is popular again, the advantages and disadvantages of Functional Programming, and teaching Functional Programming concepts.
Evan Czaplicki, creator of Elm, and Richard Feldman of NoRedInk joined the show to talk deeper about Elm, the pains of CSS it solves, scaling the Elm architecture, reusable components, and more.
José Valim joined the show to talk about Elixir. We learned about the early days of José’s start as a programmer. José took us back to the beginning of Elixir and shared why Erlang got him so excited, we broke down features of the language, we talked about functional programming, concurrency, developing for multi-core systems, we talked about the Elixir community, the future of Phoenix, Ecto, and more.