| (import '[java.util Timer TimerTask]) | |
| (defn debounce | |
| ([f] (debounce f 1000)) | |
| ([f timeout] | |
| (let [timer (Timer.) | |
| task (atom nil)] | |
| (with-meta | |
| (fn [& args] | |
| (when-let [t ^TimerTask @task] |
There are three easy to make mistakes in go. I present them here in the way they are often found in the wild, not in the way that is easiest to understand.
All three of these mistakes have been made in Kubernetes code, getting past code review at least once each that I know of.
What do these lines do? Make predictions and then scroll down.
func print(pi *int) { fmt.Println(*pi) }Kris Nuttycombe asks:
I genuinely wish I understood the appeal of unityped languages better. Can someone who really knows both well-typed and unityped explain?
I think the terms well-typed and unityped are a bit of question-begging here (you might as well say good-typed versus bad-typed), so instead I will say statically-typed and dynamically-typed.
I'm going to approach this article using Scala to stand-in for static typing and Python for dynamic typing. I feel like I am credibly proficient both languages: I don't currently write a lot of Python, but I still have affection for the language, and have probably written hundreds of thousands of lines of Python code over the years.
| /* eslint-disable new-cap */ | |
| /** | |
| * Lens types. | |
| * =========== | |
| * | |
| * a * b = {fst: a, snd: b} | |
| * a + b = {index: Boolean, value: a | b} | |
| * | |
| * Iso s t a b = forall (~>) . Profunctor (~>) => (a ~> b) -> (s ~> t) |
This blog post series has moved here.
You might also be interested in the 2016 version.
Original text from http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html
From: Mark Jason Dominus <mjd@plover.com>
Date: Jul 28, 2005 11:16 PM
Subject: Re: HOP -vs- SICP
(A book that I might eventually write!)
Gary Bernhardt
I imagine each of these chapters being about 2,000 words, making the whole book about the size of a small novel. For comparison, articles in large papers like the New York Times average about 1,200 words. Each topic gets whatever level of detail I can fit into that space. For simple topics, that's a lot of space: I can probably walk through a very basic, but working, implementation of the IP protocol.
This is my attempt to give Scala newcomers a quick-and-easy rundown to the prerequisite steps they need to a) try Scala, and b) get a standard project up and running on their machine. I'm not going to talk about the language at all; there are plenty of better resources a google search away. This is just focused on the prerequisite tooling and machine setup. I will not be assuming you have any background in JVM languages. So if you're coming from Python, Ruby, JavaScript, Haskell, or anywhere… I hope to present the information you need without assuming anything.
Disclaimer It has been over a decade since I was new to Scala, and when I was new to Scala, I was coming from a Java and Ruby background. This has probably caused me to unknowingly make some assumptions. Please feel free to call me out in comments/tweets!
One assumption I'm knowingly making is that you're on a Unix-like platform. Sorry, Windows users.
At DICOM Grid, we recently made the decision to use Haskell for some of our newer projects, mostly small, independent web services. This isn't the first time I've had the opportunity to use Haskell at work - I had previously used Haskell to write tools to automate some processes like generation of documentation for TypeScript code - but this is the first time we will be deploying Haskell code into production.
Over the past few months, I have been working on two Haskell services:
I will write here mostly about the first project, since it is a self-contained project which provides a good example of the power of Haskell. Moreover, the proces
This document is intended to be a simplified version of the OAuth 2.0 specification. In particular it has been written with implementors in mind, and as such attempts to trim the spec down to just what you need to implement an OAuth provider or client. It is necessarily not complete, but attempts to introduce spec requirements in the same order in which the protocol proceeds in practise, with everything you need to know about each protocol endpoint brought together in one place rather than scattered across a large document.