I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
/// Playground - noun: a place where people can play | |
/// I am the very model of a modern Judgement General | |
//: # Algorithm W | |
//: In this playground we develop a complete implementation of the classic | |
//: algorithm W for Hindley-Milner polymorphic type inference in Swift. | |
//: ## Introduction |
Most active GitHub users (git.io/top)
The count of contributions (summary of Pull Requests, opened issues and commits) to public repos at GitHub.com from Wed, 21 Sep 2022 till Thu, 21 Sep 2023.
Only first 1000 GitHub users according to the count of followers are taken. This is because of limitations of GitHub search. Sorting algo in pseudocode:
githubUsers
.filter(user => user.followers > 1000)
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
- Proposal: SE-XXXX
- Authors: Chris Lattner, Joe Groff
Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.
This paper introduces a first class Coroutine model to Swift. Functions can opt into to being async, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.
- Counterparts Lite (Mac App)
- POEditor (Web App)
- brightec Online XLIFF Editor (Web App)
// Swift's untyped errors are a goddam PiTA. Here's the pattern I use to try to work around this. | |
// The goal is basically to try to guarantee that every throwing function in the app throws an | |
// ApplicationError instead of some unknown error type. We can't actually enforce this statically | |
// But by following this convention we can simplify error handling | |
enum ApplicationError: Error, CustomStringConvertible { | |
// These are application-specific errors that may need special treatment | |
case specificError1 | |
case specificError2(SomeType) |