It's a delicate balance. Swing too far one way, and you can make it easy to make very difficult to detect mistakes. Swing the other way, and you now have a system that makes it very hard to just get lost in the process of writing, instead forcing yourself constantly to remember basic low-level details when you should be focusing on the problem.<p>I generally like C++'s approach. Most things that should work together (like doubles, floats, ints, etc) can work together. If you want to have stronger types, you can make your own classes or use enum classes. If you want, the compiler can warn you about different types, or just let it slide.
In the case of arithmetic, strong typing is kind of nice, because math is different dependent on what types you are using. 3/2 = 1 for integers, 1.5 for floats, etc... You really don't want to mix those up in mission critical sections of code.
This comment section is the most absolute proof I've ever seen that absolutely nobody reads the article before commenting.<p>Hint: it's not about integer types <i>at all</i>
I'm sure this is good, like, really really good, but I'm struck by the feeling that it wants to baby talk me the same way Godel, Escher, Bach did.<p>I mean, it reads like a Homestuck pesterlog.
Wouldn't any person with even a passing familiarity with the Pascal-family of languages, immediately recognize the issue?<p>I think this post is longer than the entirety of the Oberon-2 language specification, which is about 24 pages long (not including details of certain modules etc.) : <a href="https://link.springer.com/content/pdf/bbm%3A978-3-642-97479-3%2F1.pdf" rel="nofollow">https://link.springer.com/content/pdf/bbm%3A978-3-642-97479-...</a>
This seems like an article for a beginner programming forum not Hacker News? These concepts should all be understood before I'd consider hiring you as an SE 1.
Floating-point numbers, existing on finite computers, are just erroneous approximations of real numbers, so the same operation on floating-point and on ints means different things, yielding different results. Thus, allowing the programmer to magically unconsciously convert between floating-point and ints is a recipe for disaster arising from hidden/misunderstood floating-point error.<p>The safe way is to require the programmer intend about the type to use to be clear in the code and to force the programmer to be mindful about whether or not he is using floating-point. This is just what some languages do, including Rust.<p>In the first example, the author is essentially complaining that he has to type '2.0' instead of '2'. I don't think that's a lot of extra typing.<p>Perhaps it is good and convenient to have automatic int-to-float conversion, but such conversion involves error if the int values are large. Conversion in the opposite direction is similarly lossy/erroneous, even if the floating-point type can represent every real number perfectly, since not every floating-point value is an int value. Even with a perfect floating-point type, supporting automatic conversion only in one direction is weird/confusing from a user-interface POV, so the normal thing to do is to just not do automatic conversion.<p>To drive the point about floating-point error, perhaps some people complaining about lack of automatic conversion may be surprised by how the following round-trip conversion between int64 and float64 accumulates error, as demonstrated in a Python interpreter:<p>>>> int(float(0xffffffffffffff)) - 0xffffffffffffff<p>1<p>If you drop one digit, there is no error. A language forcing you to do the conversion explicitly forces you to be mindful of the potential for floating-point error. A language that does automatic conversion promotes blissful thinking and eventually big surprise.
Strong typing is not a mistake or a curse. Use a more advanced language that supports stuff like generics, or model your problem with the appropriate type. If you need real numbers you need real numbers, not some weird mix. I don't think it is good to just let it arbitrarily switch between int and float, that can hide bugs or mistakes.<p>Computers are much stricter about what is what. In mathematics people are on the surface less strict, a lot of maths is done up to some sort of isomorphisms/forgetful functor, but we are smart enough to fix up potential type errors. Doing maths, as a mathematician is using a much more expressive language that takes care of some details for you.<p>For 2 \pi, \pi ( ) is a program, an infinite list, a monad, and we implement it as a lazy calculation sometimes we can extract numbers up to a certain accuracy. 2 \pi is 2 \pi or if you know more, you can write it as another sequence, or pull the 2.<p>As for integer * float, well what is this supposed to actually mean to a computer?<p>Integers are not subsets of the reals. Integers are not sets, the reals are not sets. There is a representation of the integers in the reals represented as a set however. There is however a way to act Z on R. It even seems like a very natural operation. However we are doing maths, using our powerful reasoning abilities. Now it is your job to explain all these differences to a computer. Pretty tricky, so how about we just make things more restrictive. If you need real(integer) * real how about you just use that.
It's our job to explain to the computer what it needs to do. Being explicit is always helpful since our minds aren't computers. I want to be 100% explicit and when I'm not I want the compiler to ask. Not assume. Writing a cast or a clarification of some sort is a small price to pay for a potentially undetectable bug.
I've run into another one of these articles on HN before and both times I was very confused. After about 10-15 minutes of reading I'm still wondering whether I'm reading a tutorial or a discussion about strong typing (or whatever programming concept is being discussed)? Is this article meant to be a tutorial or is it some sort of commentary I'm missing? I'm fine with either one, it just helps me get in the right mindset if that makes sense :)
This takes an agonizing amount of vertical space to discuss the fundamental concept of different numeric types and how literals are mapped to them (assuming they do get to the part about literals - I didn't get that far). It's not because the author is long-winded, but because they are pushing the "cute bantering dialogue" style of writing to its logical extreme.
So when do we find out why Rust can't multiply pi by 2?<p>I mean, what is the point of making float x int an unsupported operation?<p>I understand they're different types, but that doesn't seem like a good enough reason. Isn't it obvious that the output type should be float? So why not just cast the int to a float and multiply them and output a float, like other languages do?
> I'm not sure where they got that idea from. Maybe they've been reading propaganda. Maybe they fell prey to some confident asshole, and convinced themselves that Rust was the answer to their problems.<p>That's a very strong statement and I don't see any back up on this claim.<p>> At any rate, I now find myself in a beautiful house, with a beautiful wife, and a lot of compile errors.<p>Sounds like a layer 8 problem to me.<p>I already questioning everything in this blog post that comes after.