m_arnold's comments

If you want to know:

A monoid is just a collection of things that can be associatively "added". Think addition with integers, or append with lists.

Members of the dreaded monad can be sequenced, or composed, while taking into account their context. For instance: if I want to get a value from stdin, then use that value safely; or make a network request and then use the result safely; or run a function that can fail, and use it or short-circuit as needed.

>A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time".

A sufficiently complicated FP codebase almost certainly has some form of effects management in place (monad transformers or algebraic effects, for instance), so adding a timeout is as simple as adding the effect to the type signature at the top level and then letting the compiler tell you all the places you need to wire it up. I've done this in many codebases. It's actually a dream, as the type system won't allow you to make a mistake.

>I would love to know that there is a panacea that automatically improves productivity. Unfortunately, I haven't seen one in my career, as yet.

I suspect you've seen many of them. They're just the ones that are so normal you don't notice anymore. For instance, no one does pure waterfall-style project management anymore. "goto" programming has completely dissappeared. Etc.

>Haskell is cool, but trying to explain to someone the difference between `.`, `$`, `<|>`, `|>`, `<$>`, `>>=` and more is quite painful.

For those who aren't familiar, I'll explain:

First of all, these are all infix operators, meaning they take two parameters: one before the symbol, and one after. You already know many infix operators: +, -, %, etc. I'll be surrounding them in parentheses, as that's idiomatic when they're not being used in the infix position.

(.) is compose: run one function, then feed its result into the other.

($) is just a tool for avoiding parentheses. It means "wrap everything after this in a set of parens".

(<|>) is alternative. Try one computation that can fail. If it doesn't work, try the other.

(|>) is either snoc (the opposite of cons) or pipe--as in bash--depending on what you have imported.

(<$>) is the general form of map, called fmap in Haskell (since map is just for lists). Given a function and a value inside a container, return the function applied to the value, inside the container.

(>>=) ah, bind. One half of the interface to the famously difficult monad. It's really not that hard, conceptually: run a computation, then use the result of that to run another computation. You might say "that sounds like compose!" and you'd be right. The difference is that a "computation" (or "action", or whatever your local monad tutorial calls it) is a function in a context. That context can be "it might not exist", which is called Maybe, or "there are a lot of values in order", which is called List, or "it can do side effectful IO", which is called, well, IO. If you want to compose those kinds of computations, you need to also "compose" their contexts as well. The implentation of that composition varies from context to context, but the interace is the same: (>>=), or bind.

Of course, conceptually is the easy part. This is the one operator in your list that can be a little difficult to gain an intuition for.

>using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

Boss makes a dollar, I make a dime, that's why I learn zygohistomorphic prepromorphisms on company time.

10 days, IIRC

Addiction is often a response to life circumstance.

Everyone points to the famous experiment in which rats were given access to a button they could push to release happy drugs in their brains. The rats hit the button until they withered away and died.

There was, however, another experiment done, in which the rats were given access to the drug button, but also an expansive "rat park" in which they could play and interact with other rats. In this case, most rats tried the button, but did not abuse it.

This makes perfect sense: if you were trapped in a cage with no future, no friends, and nothing to do but hit the pleasure button, wouldn't you? The parallels to human behavior are left as an exercise to the reader.

I'd love to see that hold up in court.

LOCATION: San Francisco, CA

REMOTE: No

WILLING TO RELOCATE: Yes (US and Canada only, with preference for the west coast)

TECHNOLOGIES: Strong in JavaScript, Git, AngularJS, Node.js/Express, HTML, jQuery, Grunt, MySQL, Bookshelf.js, D3.js, Bluebird.js; Experienced in Heroku, Ionic, Backbone.js, MongoDB, SML, LISP, Ruby, Waffle.io, ZenHub, CSS, REST, SASS, Gulp, Python

WHAT I LOVE: Web development, full-stack or backend

BLOG: http://coderpillar.co/

GITHUB: https://github.com/m-arnold

RESUME: http://tinyurl.com/nswgzqq

EMAIL: [email protected]