tmhedberg

Clinton did not resign, nor was he removed from office. Are you thinking of Nixon?

Haskell's aeson library, which is probably the most popular way to use JSON in that language, doesn't require any of this complexity or typecasting ugliness. It can derive a typechecking parser for a particular JSON format from an ordinary Haskell data type. Your type becomes a JSON schema, and as long as the JSON you're parsing conforms to that schema, the parsing just works with a single function call.

The problem you're pointing out is not a problem with statically typed languages. It's a problem with bad languages.

`zip toss toss` only produces 2 of the possible outcomes. Try `liftA2 (,) toss toss` instead.

The canonical Go style eschews underscores in package names.

Well, you can always assign a different reviewer if your initial choice is taking too long. I usually try to check with my teammates to see who has time for a review before sending them my code, at least if it's something that I want to get submitted quickly. That ensures that I pick someone who will look at it sooner rather than later. Sometimes the specifics of the process require someone who is not on your immediate team to give their approval, in which case delays are more likely.

I'm an SRE, which means most of the code I write isn't directly user-facing, and thus isn't normally subject to hard external launch deadlines. That means I'm rarely rushing to push my changes through on a tight schedule. If there's a production emergency and I need to make an urgent change to avoid or mitigate an outage, there are escape hatches at our disposal to temporarily circumvent the code review system when no one is immediately available to do a review, but the need for that is pretty infrequent.

I rarely find it frustrating. On the contrary, I really appreciate Google's emphasis on code quality, even though it does come at the cost of some agility. I used to work at a company where the implementation of code reviews was generally resisted, and though we did get new code out the door faster, we ended up with some real maintenance nightmares as a result.

It's common at Google to have a few projects cooking that you move between. One reason for this (though I doubt it's the sole reason) probably has to do with the mandatory peer review process for all code, which can cause delays in getting your code submitted if your reviewer's schedule doesn't line up well with your own. Instead of introducing a bubble into your pipeline when that happens, it's nice to have a side project you can hack on for a little while until you get your code review feedback.

He's a Tech Lead Manager, or TLM, which means he's an engineer who also manages the team he's a part of. In some cases, dev teams have SRE counterparts who take the pager responsibilities, among other things. But not all services at Google have SRE support, and for those that don't, the developers themselves are usually on call. That includes the dev team's TL, or TLM, as the case may be.

There's some info here: http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloade....

tl;dr: The patch worked but was messy/overly complex, so it needs refactoring before it's merged.

Sadly, OverloadedRecordFields won't be making it into 7.10.

Agreed that the back button issue was annoying for a long time. Fortunately, the fix went live last week!

It doesn't integrate multiple accounts into a single inbox, if that's what you mean. It works the same as Gmail in that respect.

It's too different from Gmail to be integrated into it. It coexists with Gmail so that you can choose to use Inbox and its "opinionated" workflow, or not. Users who like their personal Gmail workflow probably wouldn't appreciate having that flexibility taken away if it's not aligned with how Inbox wants you to work.

> In java or php, you, as a developer, can never know wether the functions you are calling will throw an exception.

That's what checked exceptions are for in Java.

That would be difficult, since coastlines are essentially fractal.

Parametric polymorphism ("generics") and sum types.

Every existing class A or B share will be matched by a class C share. Most Googlers had class A shares before, so now we'll have half class A and half class C, i.e. twice as many total shares, with the same number of votes as before.

If you don't think it's worth your time to interview twice at the same company, then simply don't. That's a completely reasonable point of view, and I didn't mean to imply otherwise.

For what it's worth, Google has a public reputation as a great place to work and as a company that hires "high quality" engineers. Both of these things mean that some people are willing to put more effort into getting a position there. My post wasn't meant to say that he must keep trying at all costs, but just to let him know not to be discouraged if he happened to really want that job. In many places, you're dead in the water if you don't make it the first time, but Google is not like that.

Personally, I didn't see my interview process as "something I had to go through", i.e. a laborious means to an end. I enjoyed the challenge and the opportunity to get a glimpse of a company like Google from the inside. Even when I was turned down the first time, I came away feeling glad that I had done it. It's not like I had anything to lose from trying.

> You wanna be the person that has to obey Larry Page's whims and integrate Google+ into more places users don't want it?

Not in the least, nor do I feel that I am doing that. I don't work on Google+ or anything related to it. However it may look from the outside, Google is not Google+. It's a big, multifaceted organization with opportunities to work on all sorts of interesting things. Much of our work is driven directly by the engineers themselves and not by management whims. And there's plenty of mobility to change roles if you decide you don't like what you're doing.

SRE specifically has proved to be a truly interesting and unique position. There are engineering challenges that we face which quite simply don't exist anywhere else. Beyond the much-touted perks, that's what makes Google special, in my opinion, and well worth the comparatively small effort I put into getting there.

The Google lunches are emphatically not a test. It's very rare for the lunch "interviewer" to provide any feedback at all. That usually only happens if the candidate starts spouting racist comments or punches someone in the lunch line, etc. The real purpose is to answer any questions the candidate has about culture, perks, etc. and to give them a chance to relax, catch their breath, and feel at ease in the middle of a stressful day of interviews. If the candidate was referred by a Googler, then often that person will be the one to take them to lunch, which would obviously create a conflict of interest if real feedback was expected.

I'm a Google SRE that had a very similar experience. My best advice would be not to sweat the rejection.

I was also contacted by a recruiter based on an open source project I had contributed to. I went through the same series of phone interviews, culminating in an on-site in NYC. I left there feeling largely positive about my chances, but a few days later, I was politely rejected. I was not that broken up about it, as I already had a job that I liked, so I just counted it as good interview practice and moved on.

A year later, almost to the day, the same recruiter called me up out of the blue and asked if I'd be willing to try again. I agreed, and after an abbreviated version of the phone interview process, went to Mountain View for another on-site. Soon after, I was hired!

It's actually very common for Google to reject candidates the first time around, as the interview process is deliberately tuned to produce a lot more false negatives than false positives. We have that luxury thanks to the volume of applicants we receive (there are still a surprising number of Nooglers starting each week despite the selectivity). The hiring committees recognize this tendency to reject qualified candidates and won't count you out after one try. If you got to the on-site stage, then rest assured that your interviewers took you seriously as a candidate. If you've decided that you would really like to work at Google, you will still have a good shot if you try again in a year or so. And if not, then hopefully it was at least a fun challenge and a free trip to London.

For one thing, it allows your pipeline to both read from and write to the same file, as it defers the output until there is no more data to read from "upstream". For instance, this won't work (it truncates the file for writing before it is ever read):

    grep foo <some_file >some_file

But this will have the intended effect:

    grep foo <some_file | sponge some_file

> - if there's a 6 and 8 next to each other, the third field is always a 2 or 12

At least in the version of the game that I own, if you follow the prescribed setup rules, there can never be an adjacent 6 and 8. The terrain tiles are randomized, but the placement of the numbers on the tiles is deterministic, and results in a spatially uniform distribution of the high-yield numbers.

It seems like kernel-space code would be one of the worst possible environments in which to use a dynamic language. A runtime error in that context can easily bring down the entire system; you're really better off sticking to languages with at least a semblance of static safety. Haskell may be a high-level language, but it's also a significant improvement over C when it comes to compile-time safety, unlike Ruby and JavaScript, which have none at all.

The win for Haskell is that it wears its statefulness on its sleeve. Of course you can, with sufficient discipline, write pure code in any language, though it can be frustratingly difficult in languages where libraries make idiomatic use of mutation. And yes, you can also write impure code in Haskell, at least for some definitions of "impure".

What you can't do in Haskell is write impure code that claims to be pure (up to the customarily and idiomatically avoided `unsafePerformIO`), or write code whose degree of statefulness is ambiguous. Reliable, explicit, and statically enforced purity holds more than just theoretical benefits. I don't have to read through library code to see if it is thread-safe. I don't have to worry about whether passing a data structure to a library function will result in that structure being mutated behind my back. I don't have to trust code comments that may not be in sync with the current state of the code. Simply by virtue of the fact that a function does not mention `IO` in its type, I can have total confidence that it won't violate my assumptions about its behavior. And I don't even have to take it on faith that the author wrote the correct type for his code; if he hadn't, the compiler would have rejected it. This is the difference between "pure by convention" and "provably pure".

Every language must necessarily have an "IO monad" and interact with the inherently stateful world, or else it is useless. Haskell is different not because you can choose to avoid I/O, but because when you do so, the type system will back you up with perfect accuracy.

I'm aware of dependent types and, more generally, the strong undercurrent of emphasis on provable correctness in the Haskell community at large. I don't disagree at all with what you wrote, but it's not what I was referring to with my comment.

My disagreement was specifically with the implied claim that it can be mathematically proven that Haskell code is easier to maintain than code written in other languages. That has indeed been my experience with Haskell, but I do not think it is directly provable. What seems easy for me may be stupefyingly difficult or confusing for someone else.

"How easy something is" is not really a quantifiable measurement; it is a subjective experience. As chongli points out, however, there are related measurements that can be taken, such as cyclomatic complexity, and those at least seem to be correlated with ease of maintenance. So perhaps I'm just being overly pedantic!

While I fully agree that pure code is far easier to maintain than impure code, and the advantages of Haskell are numerous, I think it is a bit strong to state that such claims are backed up by mathematical proofs. Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others).

The latest version of Cabal (1.18) includes built-in sandboxing support, which alleviates this problem to a significant extent. Prior to that, there were/are tools [^1][^2] for doing the same thing external to Cabal itself. Dependency hell has without a doubt been problematic with Cabal, but it is fast becoming a solved issue.

[^1]: http://hackage.haskell.org/package/cabal-dev [^2]: http://hackage.haskell.org/package/hsenv (Disclosure: I am the current maintainer of this project, though I am happy to see it becoming obsolete)

A patch series implementing asynchronous timers has in fact recently been posted to the Vim development list [^1]. Its status is uncertain, and is still being actively discussed, but to state that such a thing "will never be possible" is just blatantly false.

[^1]: https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

Not sure about web applications, but Pandoc [1], git-annex [2], and xmonad [3] are a few examples of successful, reasonably-sized applications written in Haskell. It's definitely worth browsing through their code if you want some examples of idiomatic Haskell in a practical context.

[1] http://johnmacfarlane.net/pandoc/

[2] http://git-annex.branchable.com/

[3] http://xmonad.org/

This simplifies the type signature, but doesn't avoid the need for `return $ f "unneeded"`, which seems to be the ugly part he was really hoping to eliminate.

Also, now you have to write your own lookup function instead of just using Prelude.lookup.