Sandman

EDIT: Ah, here it is: https://news.ycombinator.com/item?id=117171

Roy Lichtenstein asked himself "What is art?". And when he took pictures out of instruction manuals and newspaper advertisements (and, later, comic books) and reproduced them on canvas he said "Ok, I took something mundane, something mass-produced, something you see every day all around you, and I reproduced it here on canvas, using tools and techniques that artists use, I painted each of the Ben-day dots by hand, and is this now somehow not mundane? Is it now art?". And when I see one of his pictures a voice in my head says "Yes, this is art."

When I see a canvas painted black (or a shark in a tank, for that matter), that voice says "no".

The US doesn't have a VAT, but it does have a sales tax, which is pretty low compared to VAT in most European countries[2]

[1] http://en.wikipedia.org/wiki/Value-added_tax#EU_countries

[2] http://en.wikipedia.org/wiki/Sales_taxes_in_the_United_State...

Yeah. Unfortunately this only works if you have enough money after you pay the bills etc. to put aside.

Scala has some great ideas, but it's so easy to abuse it. I know, I know, you can shoot yourself in the foot with any language. But there are languages that have several safety mechanisms you need to circumvent in order to be able to shoot yourself in the foot, and then there are those that give you a gun and a book called "How to shoot yourself in the foot".

Oh yes, this is one of the things that bother me the most about Scala, actually. I don't mind if there are conceptually different ways of achieving the same goal, as you put it, because those different ways usually have different trade-offs; if you're doing things one way instead of the other, you know why you're doing it, there's a certain benefit in doing it this way.

But syntactic diabetes is bad because it ultimately provides no real benefit. Different people will write different code based simply on their tastes and preferences and pretty soon you'll have a mess in your project codebase, unless you enforce strict rules and conventions about writing code. Furthermore, people who work in a team that enforces one set of conventions may have trouble when joining another team that uses a different set of conventions. In Java, for example, this is not the case. Yes, there are things that the language itself doesn't enforce, and conventions are used, but these conventions are well known, and there's probably no Java developer on Earth who wouldn't adhere to them. When a totally new Java developer joins the team, she can usually read code right away, because there are no surprises with regards to the syntax. Sure, she'll need to spend some time perhaps to really get what's going on, because the code might be complex, but the syntax itself won't stand in her way.

And, of course, there's always Yngwie Malmsteen.

Couldn't the same be said about civil marriage in general? Yet I don't see many religious groups opposing civil marriage between a man and a woman.

a) Now your singleton is also responsible for providing a mock implementation of itself (which shouldn't really be one of its concerns).

b) You didn't really do anything here: the class under test is still going to use the concrete implementation of C. You need a way of providing a mock implementation to your class while testing. The obvious answer to how to do it is dependency injection. But if you're going down that route, you can just ditch the whole singleton thing, instantiate a class using "new" somewhere else and pass it to your class. And in your unit test, you simply pass the mock implementation. This is what DI containers like Spring do. We'd be doing the exact same thing here, only manually.

Well it isn't really a unit test if you don't, is it? If you don't mock it then you're not only testing classes under unit tests, but also C's methods. And you're doing that not just in one place but in several different places in your testbase. The same methods. Over and over again.

It's easy to dismiss all this as "bloated" and "enterprisey" and people that use this as "architecture astronauts" but in reality, this pattern really does help. Well, at least if you want to be able to unit test your code properly. Otherwise, you might as well just use a singleton object.

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

What you're looking for is at http://www.lighttable.com/

As I see it, there are three options - either it's a boy-boy pair, a girl-girl pair or a boy-girl pair. Now, since OP introduced the age variable, let's give the kids names to make things easier to understand. Let's say that the boys are named John and Jack, the girls Jill and Judy and if it's a boy-girl pair then they're named Jack and Jill.

Now if it's a boy-girl pair, we have exactly two options: either Jack is older than Jill or Jill is older than Jack. This is shown in the first picture.

However, we also have two options for boy-boy and girl-girl pairs: Either Jack is older than John or John is older than Jack. Either Jill is older than Judy or Judy is older than Jill. This is not shown.

Since we know that one of them is a boy, we can dismiss both girl-girl pairs. Now we're left with four options. In 50% of these options the other child is a boy.

What am I missing?

This might interest you as well: http://en.wikipedia.org/wiki/Hippie_%28etymology%29