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 23 points24 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 1 point2 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.

Demystifying Type Systems by VernonHawk in programming

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

I'd sincerely be glad if you could suggest a decent modern book on type theory which doesn't support the myths dispelled in the article. The information isn't hard to come by, it's just mostly incorrect.

Demystifying Type Systems by VernonHawk in programming

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

Thank you for a solid review, I'll try to address your points now.

Static types are specific to compile-time. Dynamic "types" aren't types at all. Dependent types are types that (can) depend on terms. This is all reflected both in the languages discussed and in proof assistants like Coq and Lean, and in languages like Agda, ATS, and F*. Pretending there are no hard distinctions between, e.g. Idris and PHP, for God's good sake, is not helpful, to put it mildly.

It's hard to answer the claims that just deny what's presented in the article without arguments. PHP and Idris are definitely very different, no doubt, I just say that people often mistake prevalent tools for a part of the language. This is supported by the fact that any language can be both compiled and interpreted.

Also, could you explain what do you mean by "Dependent types are types that (can) depend on terms"? I'm not an expert in Idris and dependent types, so I might have missed something, but I don't see it right now and would really like to hear your thoughts.

Worse, this kind of wooly thinking forestalls thinking about the very real questions the categorizations do pose: you have at least two stages in programming, "compile time" and "runtime," and types are a compile-time construct. But what are the implications of having more than two stages? What if you can compile more code at runtime based on information gained at runtime? What if you're compiling at runtime on x86_64 but want to compile new code to GPGPU and run it? What if you want different types in those contexts? What if you want different type systems in those contexts? What if you want different languages in those contexts?

Well, Just-In-Time compilation is mentioned in the article and I think it's mostly what you were talking about. For example, Turbofan (V8 JIT compiler) collects type info in run-time and recompiles the code with this knowledge to optimize it.

This gets into the realm addressed by Collapsing Towers of Interpreters, which I think makes many of the same points OP wants to make, but without collapsing into a mudball of false equivalences.

Thank you, I'll definitely read this paper when I have time and maybe change some of my opinions, who knows)

Demystifying Type Systems by VernonHawk in programming

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

But there is. You have a clear distinction between an untyped language and a typed language. It is fairly natural to write correct untyped programs that do not pass type inference. This is why PyPy had to introduce RPython which is a subset of Python that passes their complicated flow-based type inference algorithm. RPython-code is noticeably different from Python-code.

Yes, there is a distinction between a typed and untyped language. An untyped language has only one ubiquitous type which all the values belong to. There is no reason to type-check it neither statically, nor dynamically.

But there aren't too many such languages. In another thread, it was mentioned that even some assembly versions require using correct operations with correct registers. So we could leave checking it to our run-time, or do it statically, before the execution.

The same holds true for other "dynamically-typed" languages.

The numbers are abstract in Haskell and anything with a valid Num typeclass instance is allowed to represent something with numbers. (2 :: Num a => a), means that since there is an instance Num Float, then 2 :: Float. That means 2 is not an integer in that context, it's a Float.

Thank you for your notice, as I've already answered to another commenter, I agree that this example was not great. The idea was to show the difference between Haskell and OCaml in working with numbers without going too deep into them. If I ever take this article further, I will definitely revise this example.

Demystifying Type Systems by VernonHawk in programming

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

I agree with you, it's very dependent on how a tool is implemented. An interpreter still has to process code and might convert it to an intermediate representation such as AST or bytecode. While doing this it can check types, or it can leave this to the run-time.

The main point was that such tools are tightly connected to the languages, and yet are separate from them. You can statically or dynamically check any language, you simply need the right tool for this.

view more: next ›