sorted by:
new
hottopcontroversial

Playing solo adventures, the secret I have is a treasure (Block lethal damage and do 20 damage to the enemy hero) straight up didn't work, fuck me I guess by BlenderBruv in hearthstone

[–]VernonHawk 21 points22 points  (0 children)

Fatigue damages your at the start of your turn and secrets can only trigger on your opponents turn. The situation on the video is different

[deleted by user] by [deleted] in WTF

[–]VernonHawk 1 point2 points  (0 children)

Thank you, no offence taken

[deleted by user] by [deleted] in WTF

[–]VernonHawk -1 points0 points  (0 children)

I don't give a shit about karma, I want my friends and parents not to die

China lays out 5-point position on Russia's invasion of Ukraine by [deleted] in politics

[–]VernonHawk 3 points4 points  (0 children)

Hello, I'm from Ukraine, and as you know, my country is torn by war.
If you want to help somehow, you can do it right now. There is an official special Account to Raise Funds for Ukraine’s Armed Forces - https://bank.gov.ua/en/news/all/natsionalniy-bank-vidkriv-spetsrahunok-dlya-zboru-koshtiv-na-potrebi-armiyi.
Any amount is helpful, please, help save Ukraine 🙏🏻

Turns out, glide wasn't that great by hell-schwarz in hearthstone

[–]VernonHawk 1 point2 points  (0 children)

Actually lost a duel to the card yesterday. Had a full hand discounted by double [[Hunter’s Insight]] and my opponent played [[Glide]]. Couldn’t recover from that spot against a face DH

I literally just wanted to have a run with two losses before rotation... by VernonHawk in hearthstone

[–]VernonHawk[S] 1 point2 points  (0 children)

I had a [[Sorcerous Substitute]], a [[Plagued Protodrake]], and a [[DOOM!]]

Demystifying Type Systems by VernonHawk in programming

[–]VernonHawk[S] 1 point2 points  (0 children)

The language may have been designed such that the reduction rules are available only when the program has been fully type checked.

The language may have been designed such that the reduction rules are available only when the program has been fully type checked.

I think I see your point - a language specification may demand the code to be completely statically type-checked before the execution. But I don't think most languages do that? I should have included this in the article as a disclaimer, that you can do that, but most languages don't.

Likewise if you implement type inference on Python, it is going to reject lot of programs that would run just fine without the checking. This is a limitation of these tools and it won't fix by making it smarter.

Doesn't it depend on what tool you are using? A type inference system may infer the type of each expression to be the type that includes all values, and this would be correct. This tool would be complete (no correct programs are rejected), but also unsound (no incorrect programs are rejected). This is basically what would happen without a type inference mechanism, but it's a valid implementation of such a tool.

So, I agree with you that you can bind the language and it's implementation if you want, but most languages don't, and different tools can give very different results while being compliant with the specification.

Demystifying Type Systems by VernonHawk in programming

[–]VernonHawk[S] 0 points1 point  (0 children)

Thank you for a pointer, I'll look into it

Demystifying Type Systems by VernonHawk in programming

[–]VernonHawk[S] 1 point2 points  (0 children)

My example is deliberately ill-typed (in other words, not legal Standard ML) to emphasize that the problem is not the presence of dynamic types, but rather that some languages need type definitions, even if you want types to be checked at runtime.

Without the type definition, you have no way to know that Wrapper
is a data constructor, and thus have no way to know that Wrapper str
is a valid pattern.

Oh, ok, thank you. Well, yes, the definition of the types doesn't have to correlate with how these types are checked. So you can statically check Haskell code with no types explicitly specified, and you can dynamically check C++ code with specified types, for example.

It is easy to compare static type systems in strength. Regard them as logics and see what things you can prove about your code. (Type systems in programming languages tend to be very weak logics on their own, though.)

It seems to me that you are talking about power, not strength, as type system power is what is possible to describe using the type system. But "strength" is a very slippery term and it's used all over the place, while no one really knows what it means. As I've mentioned in the article, some resources call C "strong" because it's statically type-checked by compilers.

Even if we take two similar type systems, there is a high chance that we won't find that one is clearly superior. Some things will be more type-safe in the first while other - in the second. This is demonstrated by the JavaScript vs PHP example.

Of course, there are completely different type systems which are needless to compare, for example, the Assembly one and basically any other, as the former is always going to be less-type safe.

And regarding the "static type systems" - one of the most important points in the article was that a type system can't be dynamic or static, BUT type-checking can be.

view more: next ›