HolyHaddock

It seems you keep your corpse related conversation mostly to email: https://hn.algolia.com/?query=mikekchar%20corpse&sort=byPopu...

As someone who's quirked the odd sceptical eyebrow at base metabolic rate charts, that's a helpful way of looking at it. Thanks!

Is it just pedantry? Even in the strongliest of practical strongly typed languages, two functions with the same signatures might fail to return on some inputs in the new version that it didn't in the old.

That's a practical distinction I care about that can't be computed.

You may also want to look into the Saga pattern - I found https://www.youtube.com/watch?v=xDuwrtwYHu8 to be a handy high level overview for applying it to microservices.

Although personally, I've never felt the need to try and apply it specifically, but the idea is interesting.

Earnestly: Yes. But there may well be programming tasks or jobs that they are suited to, for which no understanding of boolean logic will make no difference on a day to day basis.

What's the scrum manifesto?

Thank you for the clarification.

> a practically-attainable real-world solution.

I can't be understanding this correctly. Please expand, I fear otherwise this is going to be at the back of my mind all day.

That's delightful, thank you for posting it!

Thank you both for the link and the google-fu tip.

Do you have a citation for that first claim? It fits my prejudices so neatly that I'd like to see the proof. I've tried to google a little for it with no success, so my apologies for any imposition.

> And frankly, if you can't point to bugs or performance issues, it's likely you don't need to be refactoring in the first place!

I feel this is a lack of clarity around the word refactoring. Improving the code in a way that fixes bugs is "bug fixing", in a way that makes it do its job faster is "optimisation" and in a way that improves the design is "refactoring".

Of course one can do several of them at the same time. And add features, at least in the small.

Refactoring can be a valuable activity for bits of a code base where the cost of change could be usefully reduced. It's useful to have a word that can be used to describe that activity that isn't commonly conflated with bug-fixing or optimisation.

At least one blogger preferred Googles assistant because she was ordering around an impersonal un-gendered corporation rather than what felt like an individual.

That said, this does seem like a great opportunity for Ask to bring Jeeves back.

> language is designed for communication between humans.

Unlike machines, humans do not always just want to exchange factual information about the world, and often use communication for additional purposes - jockeying for status, claiming membership in groups, and yes, playing games. This can even be quite enjoyable for the humans in question, for example, mutual flirtation.

In this example, one of the bits of information that can conveyed by being a bit more thoughtful about the use of pronouns is where the human in question might fall on a scale between "I am aware that there is pervasive and systematic discrimination against one class of human, and do not wish to take even small part in it." and "I believe all relevant systematic discrimination is in the past."

I'm afraid I'm missing the point too. Would you mind finding another way to make it?

If the core point of the essay is to cut the YAGNI and just get something shipped, aren't gamejames like Ludum Dare a great way to do that?

So what is the distinction? I mean that as a genuine question - Vidarh's position seems to be that the death penalty is intentionally taking a life, and shouldn't have a different moral standing to murder.

The response seems to be that that's a bad argument, they don't really believe that there's no distinction, and it would be stupid to believe that.

If I don't see a distinction of moral significance between the death penalty and, say, the CEO of a company deciding to painlessly execute one of their reports that they discover has gotten away with serious embezzling for multiple years, scorn doesn't help me understand the distinction someone else does see.

Interesting! My team in HCOM is all Scala, but more generally here and in our upstreams it is still quite niche.

Are you based in the UK? It would be interesting to compare notes. :)

Does anyone know what they mean by `Instead, use applicative transactions.`?

I've wondered about building an AI tournament for Avalon before, as my feel from playing and discussing it is that success in the game is strictly dominated by social strategy.

It would be interesting to test out different bot strategies - I'll take a look later. :)

Have you had any feedback from colleagues that have found that useful?

> Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made.

This is interesting - even places I've worked that have cared about commit messages have been pretty happy with the entirely content-free "Fixes from code review."

Do you summarise code review discussions in the commit messages?

That's fine in theory, but it's not a universal heuristic, and even then, different smart well-intentioned people independently applying it won't necessarily come to the same result.

Having conversations about what the system being architected/designed/planned is going to do can be very useful.

There are definitely better techniques than waiting until someone quibbles a field in a lines-and-boxes design session to pull that kind of insight out though. Just sitting around and telling stories about what the user will be able to do, and how they will be able to do it can work wonders.

The "See what it does" slideshow's totally broken for me - what does it actually do?

It's no longer correct that it uses MySQL - it's still not using BigTable, and in fact an RDBMS seems to have been implemented instead. That would appear to still support his rant?

This is a reasonable, common quibble when starting property based testing.

A failing test should be straightforward to turn into a simple checked example - most good libraries have extensive simplification steps that try and boil failing examples down to the minimal example that still causes the test to fail.

But this is only necessary if repeated runs of the property based tests don't reproduce a failure*. For me, they have.

A reasonable question. Perhaps it's not and there's no reason for anyone to take any time to say anything when someone's wrong.

But if they do take that time and say something, then it's not unreasonable to consider the goal. Is it to demonstrate superiority and massage ego? Unkindness works well. If it's to help someone correct a mistake, do better next time or bring their conversational partners thinking closer to theirs on a subject, then kindness is likely to work better.

Personally, I prefer to work with someone who's right and delivers the message in a way they think I and my other colleagues will respond well to, than someone who's right and delivers the message thoughtlessly, or in a way designed to maximise their own pleasure.

Not for pennies. People whoe aren't willing to exercise regularly to make use of hundred pound gym subscriptions are unlikely to finish a MOOC because of a few pennies.

Jeff Vogel is great, and I've been playing his games for over half my life. But he's written similarly themed blog posts himself: http://jeff-vogel.blogspot.co.uk/2014/05/the-indie-bubble-is...

Part of the reason he can still do it is that he's been doing it for so long, and has a loyal long term audience quite happy to buy a new Spiderweb game because it's a new spiderweb game.

This is worth understanding, and works out a lot better in practice than having to pass in ad-hoc collection builders as equally ignorable "out-params" or exceptions.

The writers for Avatar were extremely lazy.

However Unobtanium has been an engineering in-joke since the '50s: http://en.wikipedia.org/wiki/Unobtainium