jayvanguard

My thoughts as well. This looks like a hodge-podge of app ideas that got created in some brainstorming session.

Then instead of focussing on a real product line they build 20 of them and are trying to see what will stick when they throw them against the wall.

Which really means what can they use as bait to get big consulting contracts since no-one will ever use these off the shelf.

It would have been great but they didn't follow through on their cross platform commitment.

They never have in the history of their company so I'm not sure why people believe this time they will. Open sourcing the core guarantees nothing if they move the Microsoft support at a faster pace and don't commit to keeping the other platforms at par.

I think this will be about as revolutionary as Silverlight was.

I like the term micro-optimization. I wouldn't use them regularly in my code, maybe just in tight loop or something, but they aren't too invasive and can actually flag the code for future maintainers.

In fact, I'd consider adding a little "// micro-optmized" comment at the end of one of these to communicate to future developers that this mildly odd line is a useful but non-essential little optimization. So feel free to change it but you'll probably want to read up a little or do a quick benchmark before you do that.

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

Bam. That is it right there. Java really messed this up.

Strong static typing and OO is an abomination.

I thought even the most die hard WMD/Iraq war defenders had given up by now. Apparently not.

I suppose it depends on your political views. She was a core part of the administration that invaded an entire country on false premises and resulted in thousands of deaths.

Good point about the rest of her story though – she is a successful women and came from statistically unlikely circumstances.

Tough to balance those things out. In my view the participation in war crimes outweighs all other possible successes.

Edit: forgot to mention her role in authorizing torture.

That isn't mean. Reprehensible, sure, but not mean.

At first he was rude but now he's mean.

The difference being if you cause offence but don't know it will hurt someone you're just rude. If you know it will hurt them and you do it anyways you're mean.

At this point Linus knows how his behavior affects people so to do it intentionally is either ignorant/stupid or mean.

I agree with you. I think the complete opposite is true. Very few successful CEOs aren't assholes are at least on the higher end of aggressive and ruthless.

It could be what he intends by the word "mean" is more along the lines of petty and emotionally immature with aspects of small-minded vindictiveness. If so, I think what he is saying is true.

That style of "meanness" (think nasty little kid) is very difficult to hide and doesn't garner respect. Aggressive ruthlessness does unfortunately, at least among the types of people that are followers.

Damn kids and their "hyper" media. Why couldn't they all just be satisfied with good old fashioned calm media.

Great article. I love this style of free flowing retrospective with pictures of old technology. The Radio Shack 160-in-one electronics kit was awesome.

The 1 million sounds about right but the 100k doesn't. How on earth do you staff up quickly enough in two months to get tho that burn rate?

Or if that is contracting fees then it isn't really part of your consistent burn rate.

Nice write-up.

Re: first pick, right it doesn't affect things, but here is the code anyways using Ruby Array.sample().

  open_door = host_opts.sample
  choice2 = [0, 1, 2] - [choice1, open_door]  # switch
  if open_door == car then

As for the denominator, good point.

I found this on the internet and modified it so you can just change the commented out options to run it under the different scenarios.

  car = wins = 0
  many = 100000
  actual = 0

  many.times do
    choice1 = rand(3)
    car = rand(3)
    #host_opts = [0, 1, 2] - [choice1, car]  # host knows what is behind
    host_opts = [0, 1, 2] - [choice1]  # host doesn't know what is behind
    #choice2 = [choice1]  # don't switch
    choice2 = [0, 1, 2] - [choice1, host_opts.first]  # switch
    if host_opts.first == car then
        # Discard? Automatic win? It doesn't actually matter!
        # It only changes the denominator.
    else 
        # According to the puzzle, it is decision time!
        wins += 1 if choice2.first == car 
        actual += 1
    end
  end

puts "#{(wins * 100) / actual}%"

No doubt. See seriuslyguys post above. He did it and now agrees.

Yes, _this time_. But how on earth are you evaluating probabilities without considering all the priors and/or doing multiple trials? Is this some new kind of mathematics you've invented?

The hidden assumption is that the odds that he opens a door containing a car is zero. That is what changes the odds in the second step. Without that they don't change.

Seriously. Write the simulation.

But 1 in 3 times the host opens a door with a car. That changes the probabilities. Or are you assuming this never happens? Why?

He does in this single instance, but in order to calculate the probably you need to consider all the possible cases. Does the case where opens the door with the car calculate in? Why or why not? Seriously, write the simulation to calculate the probabilities. It makes the assumptions very obvious.

This is true but it isn't really a mathematical question then with a single correct answer.

If I was in a culture where gameshow hosts behaved differently the question would have different priors and a different answer.

What if all gameshow hosts shot contestants immediately after they won? Would you be better of switching? No, you'd be dead, so you didn't "win" the car. Completely silly example but it shows why this can't be taken seriously as a mathematical question with probabilities without injecting additional assumptions (unless of course it is stated clearly but then I bet few mathematicians would get tripped up).

There is a difference. Write a simulation in your favorite language. You'll be forced to decide whether the door with the car ever gets revealed to the contestant. In those cases does the contestant get to switch and win the car? Or did you just throw those cases out in your code? If so, you made an assumption that isn't aways stated clearly in the problem.

This is exactly right. It drives me nuts that most explanations gloss over this.

If you're a mathematician you don't tend to introduce any additional assumptions unless they are stated. Assuming the host has knowledge of what is behind all of the doors (or at least where the car is) changes everything. Some wordings of the question include it, others don't.

Of course a non-mathematician might assume things about the game show host based on their knowledge of game show hosts but a mathematician is entirely correct to simply take the question at face value and not inject additional unstated assumptions. Otherwise what is preventing them from putting in other completely wacky assumptions like "the host wants you to win the car and knows you know about the monty hall problem and is using reverse psychology"?

Good article, but why is Rothko mentioned in the same breath as Fra Angelico?

Wow, you actually sound bitter towards the fact that people on average get happier later in life.

His dissertation is quite out of date with respect to current practical experience. Some of the ideas turned out to be great, others largely irrelevant. It was very useful at the time but don't forget it was realistically based on less than a handful of years of real industry experience. And most of that was in reaction to SOAP/SOA wars.

Before and during the time it was written there were existing HTTP based web services that were successful and they didn't follow all the principles outlined in the dissertation. Fast-forward 15 years and the vast majority of successful HTTP based web services still don't follow all the principles. Some turned out to be more useful than others.

APIs are what we are talking about.

If you are building a web service for the general public that you want to last forever (e.g. an interface to Wikipedia or something), follow theoretical REST principles and you'll be well served.

If you have actual paying customers that you'll need to support over many years then version your API. Paying customers won't tolerate API breakage and you can't always force them to update on your schedule. Assuming you still want to evolve the API and also sign up new customers, you'll quickly find out you'll need versioning.

This debate was settled almost a decade ago. URL forms don't matter in theoretical dissertation REST, but 15 years of practice has firmly decided they are indeed a core part of real-world REST.

HTTP based web services existed before Roy's dissertation and while the formalizing of them helped them mature rapidly, the idealistic principles aren't the final word on the subject anymore. Real world practice now is.

Fluff piece.