Hacker Newsnew | past | comments | ask | show | jobs | submit | rspeele's commentslogin

Don't watch Big Fish unless you're ready to cry.


"Why would you need to see it? You're the genius who invented the product in question!"

> https://www.youtube.com/watch?v=9LtT0xZ11wM


Brilliant clip. :) I'm sure we've all had dreams that feel like that. If I had to put a point on it for this one, the "self-play" game happening here is your brain serving up instantaneous new plausible and unanticipated excuses for why you can't see the object that you're struggling to get a glimpse of!


This reminds me of playing Ecks vs. Sever on the GBA. A raycasted 2.5d doomlike game based on a crappy movie. It was pretty impressive for a GBA game, and it ran well, never stuttering. It had some pretty cool levels, I remember one where you fight through a hotel using IR night vision. It also had a sequel which added a guided missile launcher and some crazy Robocop ED-209 type enemies. As I recall both had multiplayer deathmatch but good luck finding a friend who also had the game and a link cable.

One thing I took full advantage of as a kid was that both games had some cheesy behavior with the sniper rifle scope implementation.

In the first game, while zoomed in with the scope you could use the D-pad to move your view a few clicks left/right/up/down to refine your aim. However, this was not really turning you, it acted more like you were a ghost side-stepping and poking his head up and down. So, you could crouch behind a box, scope in on the box, then D-pad up to look over it and shoot an enemy mob who still couldn't see your character and wouldn't engage you. Or stand just slightly behind a corner, scope in, and D-pad right to shoot around it.

The last level of the first game involves fighting a boss character who has a powerful weapon and a ton of HP, and is surrounded by his infinitely-respawning goons. There's no way kid me would've beaten it without abusing this trick, which reduces the challenge to avoiding his attacks while fighting enough lower-tier enemies to obtain their precious sniper rifle ammo.

In the second game, the D-pad moves a crosshair around a fixed viewport rather than shifting the whole viewport around. So the trick doesn't work exactly the same way. If you zoomed in staring at some obstacle right in front of you, you couldn't move the viewport to see around it like you could before.

However... when you zoomed in, it worked like you were a ghost moving forward in space, instead of narrowing your FOV from your original vantage point. So you'd instead stand about 10 feet back from a corner, zoom in past the edge, and voila: you were able to see more around the corner just as if you'd walked up next to it. Sure enough, you could slide the crosshair over and snipe the enemies now visible in your viewport despite your player character still being safely 10 feet back around the corner.

Good times. They were still great GBA games even with this exploit, it just made the (scarce) sniper rifle ammo even more valuable to the player.


SQL, C, Javascript: the three kings of "good enough".

Bad enough that their flaws are evident even to novice practitioners.

Good enough, entrenched enough, that they will be around for the next 50 years too.


All three are also superficially easy to learn to use, hence they're able to sucker people in initially with the learning curve, then keep them there with the sunk cost fallacy.


I think C will "be around" like COBOL in 50 years given its footguns despite its ubiquity today.

Not sure about SQL and Javascript though; successor options are way less clear.


Does AI do COBOL yet? Maybe that's where all the jobs will be in a decade. It's not like there are a ton of blog posts about how to do stuff in COBOL to train it on.


I empathize with you. I had a (very small) side business where I was making custom wood grip panels for handguns. On the one hand, these are firearm parts but on the other hand, they are also inert, harmless pieces of wood that aren't needed for the firearms to function. I used Stripe to accept payments. When I originally signed up for the Stripe account I specifically asked customer support whether this would be OK. The response I got (in 2019) was:

> Stripe does have some strict rules over the types of businesses we can and cannot support. Firearms accessories is an area that we split into two. Businesses selling firearms and parts required for the functioning of the firearm are restricted from using Stripe. Businesses selling firearms accessories and parts not required for the functioning of the firearm can be fully supported.

> As your business falls into the second category, I'm pleased to say that you would be able to use Stripe.

In 2022 my Stripe account was closed. I entered an "appeal" quoting that original response and asking whether their policy had changed, or their assessment of the products I was selling. The response I got did not answer that and simply said "we are unable to accept payments for weapons, ammunition, and related products, as mentioned on our restricted businesses list."

To be honest I was kind of done with it anyway, it had gotten to that "not fun" point where a hobby becomes a chore. And it wasn't an income stream big enough to make any difference in my quality of life. So I didn't bother appealing further or even seeking an alternate payment provider. But I was still annoyed that they didn't tell me what changed between when I got approval and when I got shut down.


Lazy loading was a mistake in EF. A lot of apps had awful performance due to lazy loading properties in a foreach loop creating N+1 queries to the database. It would be fine in dev with 50-100 rows and a localhost SQL and blow up in prod with 1000s of rows and a separate Azure SQL.

Also if you relied on lazy loading properties after the DbContext had been disposed (after the using() block) you were out of luck.

With old EF we would turn off lazy loading to make sure devs always got an exception if they hadn’t used .Include() to bring the related entities back in their initial query. Querying the database should always be explicit not lurking behind property getters.

Fortunately with EF core MS realized this and it’s off by default. EF with wise use of .Include and no lazy loading is a pretty good ORM!


I switched to Dapper a long time ago, with explicit SQL queries and really haven't looked back.


I am curious how you feel about the "Monty Fall"/"Monty Crawl" problems linked elsewhere in the thread.[0]

For my part I am somewhat sympathetic to jncfhnb's point. The exact phrasing that Vos Savant was asked did not specify the rules that the host was required to open a door, nor that it always must be a goat door. It simply says that the host has knowledge of what's behind the doors, and in this particular iteration of the game, he showed you a goat and asked you about switching.

That does not exclude a scenario where the host is a manipulative fellow, who chose to show you the goat only because he knows you are about to win, trying to convince you to lose. A contestant on the real show would surely worry about this possibility.

Of course, the people who wrote to disagree with Vos Savant almost never said "the problem is not fully stated", they said "it's 50/50 you fool", which isn't right. Additionally, since it wouldn't be a math problem at all if we let the host have agency, it is reasonable to assume the unspoken rule that he does not, leading to Marilyn's correct 2/3rds answer.

[0]https://web.archive.org/web/20230706235720/https://probabili...


It doesn't make a difference what causes Monty to reveal a goat.

A goat behind a door the contestant did not choose is eliminated. That is all that matters. It could have been done by a Heath-Robinson machine, or a passing lonely shrubber, or elves.

Monty isn't a floating variable in the puzzle who makes choices. His choice is fixed. Which I imagine is why vos Savant adds the actually extraneous information that Monty is fully aware what is going on behind the scenes -- to underscore the concept that Monty isn't a variable.

The fact that a goat behind an unchosen door was revealed is what is crucial to the setup of the entire puzzle.

And that -- despite jncfhnb's protestations -- is information that makes the puzzle determinate.


> It doesn't make a difference what causes Monty to reveal a goat.

Oh, but it does! See the "Monty Fall" version of the problem, in which Monty accidentally trips and opens a door, which just happens to reveal a goat. In this variant there is no advantage gained by switching, because no more information was revealed about the remaining unopened door.

The information gain only happens in the original game because we know that Monty was forced to avoid the winning door in the (66% likely) case where we didn't already pick it.


Nope.

But I am going to leave this to someone else to explain. I'm tired out now.


Suppose Car is C.

The only possible options are (equally likely)

You choose A and get shown B You choose B and get shown A You choose C and get shown A You choose C and get shown B

4 options. You lose 50% of the time.

The 2 options where you would normally get the 2/3 odds are explicitly ignored when you are told Monty chosen randomly and randomly got a goat.

You choose A and get shown C or you choose B and get shown C are forbidden.

50/50 probability on the dot.

If Monty chooses with intention then the options where you choose goat and are shown goat double in probability so you get back to 2/3


They are two different problems. Map out all the scenarios exhaustively and you'll find the difference.

In both cases we were originally 1/3 chance of being right. That is not in dispute.

In the original (fully defined) "Monty Hall", Monty was going to show us a goat no matter what. It's part of the rules, he has to show a goat. So the fact that we see a goat behind the revealed door is no surprise, and no new information. But which of the two unchosen doors was the goat, is valuable information because in 2/3s of the scenarios Monty's hand was tied and he HAD to show that door to avoid revealing the remaining car.

In the "Monty Fall" problem, the fact that we see a goat at all is interesting information. This becomes more likely when we picked the car in the first place, because if we had initially picked the car, and a random other door is opened, it's 100% going to be a goat, whereas if we had picked the goat in the first place, we are only 50% likely to see a goat when a random other door is opened. Let's call the goats Alice and Bob to illustrate this point. We know we DID see a goat, but we don't know which of these equally probable scenarios led to that:

1. We picked the car and saw Alice

2. We picked the car and saw Bob

3. We picked Alice and saw Bob

4. We picked Bob and saw Alice

Notice how "we picked the car" originally had 1/3 odds but represents half the scenarios that remain possible, because there are two ways to see a goat with that start, while only one way to see a goat with the others.

This kind of brings the problem back around to similar territory as Bertrand's Box[0] where the fact that you drew a gold coin is already hinting to you that you're more likely on the "both gold" box than on the "half gold" box.

[0]https://en.wikipedia.org/wiki/Bertrand%27s_box_paradox


Since this bugged me all day, and I suspect you are the kind of person where it bugged you all day, too, here is a better description of the "fall"/"hall" distinction.

I think we can agree that these are the six possible, equally likely, configurations of the problem starting from me having chosen door 1. G1 here is "goat 1" and G2 is "goat 2". For each possible prize behind my chosen door, there are two possible configurations of the remaining prizes.

    My Door | Door 2 | Door 3
    Car     | G1     | G2
    Car     | G2     | G1
    G1      | Car    | G2
    G1      | G2     | Car
    G2      | Car    | G1
    G2      | G1     | Car
With the "Monty Hall" problem, Monty uses his knowledge to always open a goat door. Thus we see the following revealed options and resulting 2/3s probability of switching succeeding. This is the classic version of the problem.

    My Door | Door 2 | Door 3 | Monty Reveals | Switch Result
    Car     | G1     | G2     | Either        | Lose
    Car     | G2     | G1     | Either        | Lose
    G1      | Car    | G2     | G2            | Win
    G1      | G2     | Car    | G2            | Win
    G2      | Car    | G1     | G1            | Win
    G2      | G1     | Car    | G1            | Win
With "Monty Fall", the first thing that happens is a randomly chosen door, that isn't our own, reveals a goat. This is interesting. In the classic problem we were always going to see a goat next, because those are the rules Monty plays by. But in this case, the fact that we randomly found one wasn't guaranteed.

Essentially, you are blindfolded and throw a dart at the 2x6 grid of cells under the headers "door 2" and "door 3", and I tell you that the cell you've hit is a goat. What do you know about the row you hit being a switch-or-stay row? Well, half the possible goats you might've hit are in the first 2 scenarios where you should stay, and half the possible goats are in the last 4 scenarios where you should switch. So you're at 50/50. You don't have any new information to switch on.

    My Door | Door 2 | Door 3
    Car     | G1(a)  | G2(b)
    Car     | G2(c)  | G1(d)
    G1      | Car    | G2(e)
    G1      | G2(f)  | Car
    G2      | Car    | G1(g)
    G2      | G1(h)  | Car
You are just as likely to be looking at (a), (b), (c), or (d) (so you should stay) as you are to be looking at (e), (f), (g), or (h) (so you should switch). It is 50/50 in this version of the problem.[footnote]

This may make it confusing going back to the original. I seem to have shown that both ways make sense but still, how is it different? Imagine it like Monty is doing a random dice roll for which door to open, and he simply juices the outcome by correcting it to the goat door when a car door is selected, since he can't reveal a car and spoil the game. Now we have these equally possible scenarios (a) through (l) for his fair dice roll...

    My Door | Door 2 | Door 3
    Car     | G1(a)  | G2(b)
    Car     | G2(c)  | G1(d)
    G1      | Car(e) | G2(f)
    G1      | G2(g)  | Car(h)
    G2      | Car(i) | G1(j)
    G2      | G1(k)  | Car(l)
Which he corrects, avoiding cars, to:

    My Door | Door 2 | Door 3
    Car     | G1(a)  | G2(b)
    Car     | G2(c)  | G1(d)
    G1      | Car    | G2(f,e)
    G1      | G2(g,h)| Car
    G2      | Car    | G1(i,j)
    G2      | G1(k,l)| Car
Now we are back to the original game scenario where we see a goat no matter what. And we can see that 8 of the possible ways we might have arrived at seeing this goat come from "switch" rows while 4 come from "stay" rows.


[footnote] If this part of the explanation is bugging you, consider these related problems:

Problem 1. There are two opaque, externally identical bags, each containing 2 marbles. One bag contains 2 black marbles. The other bag contains 1 black marble and 1 white marble.

You choose a bag and draw a marble from it, without looking inside. The marble is black. What should you conclude are the odds that the remaining marble in the chosen bag is black?

Answer: .elbram kcalb dnoces a dnif ot ylekil sdriht-owt era ew oS .gab etihw-dna-kcalb eht morf si eno ylno dna ,gab kcalb-lla eht morf era elbram kcalb a werd ew hcihw ni soiranecs elbissop eht fo owT

Problem 2. There are three opaque, externally identical bags. One bag contains 2 black marbles. The other two bags each contain 1 black marble and 1 white marble.

Again you choose a bag and draw a marble from it, without looking inside. The marble is black. What should you conclude are the odds that the remaining marble in your chosen bag is black?

Answer: .tnecrep ytfif era elbram kcalb dnoces a gniward fo sddo ruO .gab kcalb-lla eht nesohc gnivah fo sddo ytfif-ytfif ta won era ew oS .sgab etihw-dna-kcalb tnereffid owt eht morf era owt dna ,gab kcalb-lla eht morf era elbram kcalb a werd ew hcihw ni soiranecs elbissop eht fo owT

You can connect Problem 2 to our random door opening and a goat being revealed, in the Monty Fall (with an F) problem.


Noooo

It is not the fact that a goat is behind the door. It is the fact that a goat door would always have been opened! These two facts are not the same!


I'm sorry what now? Stop second guessing the puzzle which is clearly stated.

I'm so, so done with this now that I am actually going to render inoperable my only HN account so I cannot possibly come back to this, or any other thread.


It is NOT STATED in THIS VERSION OF THE PROMPT that monte will always open a door and that it will always be a goat door.

It is simply stated that on one play of the game, Monte CHOSE to open a door and it was a goat. If this is truly all you know, you have learned nothing.

It is only useful information if monte explicitly opens a goat door for you. If he opens a door at random and gets goat your information gain goes away even if it’s the same door!

I’ve literally mapped it out for you else where. There’s only 4 outcomes. You can check yourself.

2:2


One way to think about is, suppose you switch -- why not switch back?

In the random-open case, you really know nothing new about either of the closed doors. If you can talk yourself into switching, you could make an equally good argument for switching back.

In the Monty-knows-and-always-shows-goat case, you have gained information about one of the closed doors. You haven't gained any information about your initial pick door. But the other remaining door, you know there's a 2/3rds chance that Monty was forced to avoid it so as not to reveal the car. Only in the 1/3rd case where you were already on the car does Monty have freedom to open either door willy nilly.


that's all true, but i had concocted explanations that sounded equally convincing to me of why it was wrong


That's especially tempting since we're used to probability problems often being set up where considering previous state is the sucker's answer. E.g. a fair coin has landed on heads three times in a row, what are the odds of it being tails on the next throw?


The explanation that worked for me was:

Suppose after you make your initial choice, instead of opening a door, Monty simply asks if you'd like to switch to BOTH the other two doors, such that you win if the prize is behind EITHER of them.

That switch is intuitively a great deal, giving you 2/3 odds. The only way you can lose is in the 1/3rd case where you already picked a winner. The original scenario is equivalent to this, since by revealing a goat Monty is allowing you to pick "the best of" the two doors.

---

Often people who don't like this problem complain that actually Monty, with his knowledge of the winning door, may be trying to trick you into losing. Maybe he offers this trade conditionally based on whether you've already selected a winner. Of course, this wouldn't support the most common intuitive answer of "it's 50/50", either, making this a bad excuse. If we accept this behavior from Monty -- not stated in the problem -- it becomes a very uninteresting problem based on whether we are dealing with Evil Monty who only offers the trade when it's a bad one (stay wins 100% of the time), Friendly Monty who only offers the trade when it's a good one (switch wins 100% of the time), or somewhere in the middle. It has no analytical answer. So for this to be a solvable problem at all we must assume we are dealing with Fair Monty who offers the trade all the time, or at least, offers it at random times not based on the contestant's initial pick.


I think the important part of the problem is the unstated assumptions around it, and I suspect some people may see different assumptions than others.

If Monty always opens a door, and uses his knowledge of which door has the prize to ensure that the door he opens is always empty, then you should switch, because he's providing you with extra information about which door has the prize.

However, if Monty changes it up and sometimes doesn't open a door, or opens the door with the prize, the whole problem changes. If he only opens a door and offers you the chance to switch when you've picked the door with the prize, you should never switch of course. If he opens a random door and might reveal the prize (after which he obviously won't let you switch anymore), switching doesn't change your odds. I think a lot of people see it as one of those two situations.


I do think this modified scenario makes the solution much clearer. At the same time, I also think that it feels like a significantly-enough different scenario from the original that saying the two scenarios have the same probability then becomes the non-intuitive part. The act of revealing what's behind the second door seems like it should change the probability from 1/3 (one door) vs. 2/3 (one of two doors) to 1/2 (one door of the remaining unopened two) vs. 1/2 (one door of the remaining unopened two, since one was "eliminated").

It's amazing how even seeing the probabilities written out, or running simulations, doesn't really make it easier to truly understand the result.


a single sentence convinced me: "When Monty opens the door, he reveals information about the state behind the doors".


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: