tomstuart

Yes, because it lives with the code.

I wrote a book to help answer these questions: https://computationbook.com/. It won’t necessarily be right for you (e.g. the code examples are in Ruby) but the sample chapter may help you to decide that for yourself.

“It seems be too good to be true” is a useful intuition, but it’s importantly different from “it is proven to be false”. (See also P ≠ NP.)

Here’s the information you’re missing: https://en.wikipedia.org/wiki/Kleene's_recursion_theorem

> Instead, because hooks are they only non-terrible way of using libraries (again say apollo), users/codebases are basically forced to convert their OO components over to FP.

I know what you mean, but in practice it’s easy to retrofit a hook into a legacy class component by wrapping the hook in a tiny functional component. Sure, you have to find some other mechanism (e.g. make it a HOC, or use render props, etc) to make that wrapper component compose nicely with your class component, but that’s the price of not porting the whole thing over to hooks.

In this context, it’s more likely the 3 basic primitive recursive functions: constant, successor, projection. https://en.wikipedia.org/wiki/Primitive_recursive_function#D...

In my experience it’s easiest for people to understand monads when they’re presented as an abstract data type (e.g. what I wrote at https://codon.com/refactoring-ruby-with-monads#abstract-data...) rather than a programming pattern, because despite having “abstract” in the name, abstract data types are a relatively concrete thing that programmers already know how to use.

You’re exactly right about this. Of course compilers which compile themselves come with their own risks! https://dl.acm.org/citation.cfm?id=358210

How would you write the type of a function that takes a parameter called `returns`?

For what it’s worth, mathematically a “sphere” is the set of all points which are equidistant from its centre — it’s hollow all the way through. The solid version is called a “ball”.

Yes, because request methods provide a uniform way of communicating meaningful information to HTTP infrastructure like caches. If a request uses the DELETE method then a cache in the middle can know something about the meaning of that request (e.g. it's idempotent) and change its behaviour accordingly. If that information lives only in the URI then there's no way for a cache to understand its significance.

Makes sense, thanks. So you end up redoing most of this (parsing) work later when you want the AST, but a) you might not have to redo it at all if the method's never actually called, and b) it's not the expensive bit anyway?

How difficult is lazy parsing for Ruby? How much parsing do you need to do just to find where the method body ends?

Your observation is a consequence of Kleene's recursion theorem, which I summarised briefly in http://vimeo.com/66863570#at=13m40s (extracted from chapter 8 of http://computationbook.com/).

Not the OP, but I'll state the obvious on their behalf.

The number one thing that you (and Facebook) could do to help people learn React, and combat the perception that it requires overly complex tooling, is write a tutorial that shows how to use React entirely in-browser without any build toolchain. A static HTML file, some <script> tags pointing at a CDN — done. No distractions, nothing to download, nothing to install, nothing to run, just a JavaScript library that makes it easier to write view templates.

It would make it even easier to get into if that tutorial were written entirely in ES5, but you could use babel-standalone if you felt that JSX and ES6 were important enough.

DPReview is owned by Amazon.

This is great, but as chrisseaton asked on Twitter [1], how does it interact with CI?

The trees in the rebased commits are new and may never have been tested. Is GitHub going to expose a `refs/pulls/123/rebase` ref (cf. the existing `refs/pulls/123/merge`) for running through CI before the button can be pressed?

EDIT: The docs [2] say:

  You aren't able to automatically rebase and merge on GitHub when:
  
  * Your pull request has merge conflicts.
  * Rebasing the commits from the base branch into the head branch
    runs into conflicts.
  * Rebasing your commits is considered "unsafe", such as when a
    rebase is possible without merge conflicts but would produce a
    different result than a merge would.

So I guess the point is moot. You can’t rebase a branch unless the resulting tree is identical to the one you’d get from a merge, and that’s the tree that runs through CI.

[1] https://twitter.com/ChrisGSeaton/status/780441251992731648

[2] https://help.github.com/articles/about-pull-request-merges/#...

I find Chris Patuzzo’s solo Sentient language (http://sentient-lang.org/) inspiring, so much so that I got him to tell the story on a podcast: http://whyarecomputers.com/4

This is misleading advice, principally because “squash merging” is the very definition of losing history — it literally discards the commit history of your branch, which will then be lost to GC.

That’s right. `git merge --squash` doesn’t even make a commit, it just updates the working tree and index to look like the post-merge contents — it’s then up to you to actually commit. So yeah, you don’t even end up with a merge commit.

I assume (but don't know) that this is an attempt to avoid returning `nil` for empty collections: `[].inject(:+)` is `nil`, but `[].sum` is `0`.

Forcing the use of the additive identity every time, rather than starting with the first element of the collection, is a good way of setting people up to get the correct behaviour on empty collections, even if they don't test for that case.

What alternative decision are you imagining? A service like this can’t depend on Git alone. It needs to know when the repo is updated (e.g. GitHub’s webhooks) and has to publish its results somewhere (e.g. GitHub’s commit statuses). So it only really works with hosted repos.

Since each hosting service has a different API, each integration needs to be built individually. And it makes sense to integrate with GitHub first because it’s the most popular repo host.

Your answer doesn’t explain why you made `capistrano-harrow` a dependency of `capistrano`.

For example, RSpec 3.4 will use `coderay` for syntax highlighting [1] if it’s available, but doesn’t make `coderay` a dependency of the `rspec` gem. That’s great! People who want syntax highlighting can install the extra gem and get the benefit; people who don’t care about syntax highlighting, or who don’t think it’s worth adding a dependency, can carry on as before.

Why didn’t you do the same with `capistrano-harrow`? (I have no investment in the answer, just trying to clarify what others are asking about here.)

[1] http://rspec.info/blog/2015/11/rspec-3-4-has-been-released/#...

I’m surprised that the article doesn’t mention Ze Frank, since he was the originator of this style of speech in online videos, or at least very influential in popularising it.

Markus Kuhn’s work on “optical eavesdropping” — reconstructing a CRT image from reflected visible light — is really interesting: https://www.cl.cam.ac.uk/~mgk25/ieee02-optical.pdf

Perhaps not what you're thinking of, but it reminds me of this quote from Kevlin Henney:

"There is an art, craft and science to programming that extends well beyond the program. The act of programming marries the discrete world of computers with the fluid world of human affairs. Programmers mediate between the negotiated and uncertain truths of business and the crisp, uncompromising domain of bits and bytes and higher constructed types."

http://www.slideshare.net/Kevlin/cool-code/4

Thanks! There’s a transcript at http://codon.com/refactoring-ruby-with-monads.

Thank you very much! It's so gratifying to hear that you got something out of it.

FWIW I got a $6000 advance for the book. I earn a 10% royalty on sales which varies a lot but is around a couple hundred bucks a month on average. So not bad, but since it took me a year to write I don't think it's ever going to recoup minimum wage for that period.

No complaints though! O'Reilly is a brilliant publisher and I never had any expectation of making money from it. It was just a thrill to be able to get the bloody thing off my chest at last.

Just to answer your question: it's in its genetic material. It really is fascinating; it can even make evolutionary sense to think of the dam as an extension of the beaver's physical body, in as much a beaver's dams are "built by" its genes just like the cells of its body are. Google "extended phenotype" if you'd like more detail.