A lot of the answers thus far are overly concerned with the Twitter user. It's helpful to keep focused on the messages and not the messenger. There is a fairly consistent message with the even just the excerpts mentioned thus far:
It's funny when Java users complain about type erasure, which is the only thing Java got right, while ignoring all the things it got wrong.
I get huge benefits (e.g. parametricity) and nil cost (alleged cost is a limit of imagination).
| -- The package version. See the Haskell package versioning policy (PVP) | |
| -- for standards guiding when and how versions should be incremented. | |
| -- http://www.haskell.org/haskellwiki/Package_versioning_policy | |
| -- PVP summary: +-+------- breaking API changes | |
| -- | | +----- non-breaking API additions | |
| -- | | | +--- code changes with no API change | |
| version: 0.1.0.0 |
| def setFromArgs(args: Args): Settings => Settings = { | |
| val input = | |
| args optional "input" map { i => | |
| { s: Settings => s copy (inputBasePath=InputBasePath(i)) } endo | |
| } orZero | |
| val dataCenters = | |
| (args list "data-centers" some) filterNot { _.isEmpty } map { dcs => | |
| { s: Settings => s copy (dataCenters = dcs map DataCenter.apply) } endo |
We often accept for granted that functional programming (FP) helps us reason about our programs more. This is often attributed to "referential transparency" or "equational reasoning" with only a cursory explanation.
With this post, I'd like to give a slightly more involved illustration for how the referential transparency of functional programming helps us reason
| ; I know this is super naive, but I haven't been in a Lisp for some time, and I | |
| ; haven't had to think about how best to deal with a Lisp-1. | |
| ; | |
| ; Really, all I'm trying to do here is define a local function so it's easier | |
| ; to read in the mapcar call. | |
| ; | |
| (defun tnks--gnus-ident (idents) | |
| (let | |
| ((f (lambda (ident) (list (car ident) nil (cdr ident) nil nil nil)))) |
| import scalaz._ | |
| import Scalaz._ | |
| import Free._ | |
| /** "Pure" interactions with a console. */ | |
| sealed trait Console[+A] | |
| case class GetLine[A](k: String => A) extends Console[A] | |
| case class PutLine[A](s: String, a: A) extends Console[A] | |
| object Console { |
| import Control.Exception | |
| import Control.Monad | |
| import Data.Maybe | |
| import Data.Version | |
| import Distribution.PackageDescription (PackageDescription(..), HookedBuildInfo, GenericPackageDescription(..)) | |
| import Distribution.Package (PackageIdentifier(..)) | |
| import Distribution.Simple (defaultMainWithHooks, simpleUserHooks, UserHooks(..)) | |
| import Distribution.Simple.LocalBuildInfo (LocalBuildInfo(..)) | |
| import Distribution.Simple.Setup (BuildFlags(..), ConfigFlags(..)) | |
| import Distribution.Simple.Utils (die) |
| #!/bin/bash | |
| exec ~/src/scala/bin/scala -savecompiled "$0" "$@" | |
| !# | |
| // Example of object algebras, based on the scala example at http://ropas.snu.ac.kr/~bruno/oa/ | |
| // type Term = ∀A,O. O[A] -> A | |
| trait Term[O[_]] { | |
| def apply[A](o: O[A]): A | |
| } |
| // Implementing functor manually | |
| import scalaz._, Scalaz._, Free.liftF | |
| sealed trait TestF[+A] | |
| case class Foo[A](o: A) extends TestF[A] | |
| case class Bar[A](h: (Int => A)) extends TestF[A] | |
| case class Baz[A](h: (Int => A)) extends TestF[A] | |
| implicit def testFFunctor[B]: Functor[TestF] = new Functor[TestF] { |
This is a draft proposal for BuiltWith's Firehose web service API. It leans a bit on HTTP and uses some status codes from spec extensions and custom media types. If a user agent only accepts application/json, the API should still work as each representation is still JSON. The only thing a user agent would lose is a clear indication of the contract of the payload, which specifies how to parse it beyond just JSON.
This covers enough to give a feel for the API, but probably isn't yet comprehensive for all the edge cases.