7 ms·

The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos

• chc 8y ago
  Languages with type inference still require you to give enough information for a type to actually be inferred. Type inference isn't an escape valve for the things named in the GP comment, it's just a shorthand.
• noir_lord 8y ago
  Which isn't bad if the type inference is good. Nearly all the type errors I see are things like var foo = "Hello World"; bar = foo + 10; That should scream it's head off.
  • hombre_fatal 8y ago
    To be fair, that's valid in Typescript because it simply uses Javascript's coercion rules. You could imagine it having built-in rules for JS' coercions: string + number -> string number + string -> string Maybe your snippet is provocative to some people, but in real code it would quickly fail once you actually use `bar` and were wrong about your assumptions. At which point it's similar to languages with `Int + Float -> Float` and `Short + Long -> Long` in that perhaps you wish those operators weren't defined but it's at least consistent. And you'd find the error once you've passed those results to a function that expected Int or Short.
    • chc 8y ago
      This is more of a knock against the compromises TypeScript's wacky type system has to make for JavaScript compatibility than anything else. It's not possible in a language that was really designed for strong static typing like Haskell or Rust.
    • pas 8y ago
      It's not the fall, but the stop that kills you. So in case of TS we don't know what was the intent. Maybe it was this. function suffixWith10(s: string) { return s + 10; } But if the intent can be discovered by analysis of usages of the variable later in the code, then TS will scream loudly.
  • msla 8y ago
    The kind of errors I'm interested in preventing are more like this: var foo = 5; var bar = 100; baz = foo + bar; Why is that bad? Well... what do 5 and 100 mean in that program? Did you just add age in years to pixels from edge? How do you know? Appending an integer to a string is comparatively sensible next to adding age in years to pixels from edge.
    • jakevn 8y ago
      Then you should not use a general numeric when you really should be using Pixel and Age types.
      • coldtea 8y ago
        Some languages don't care either way, and will let you add those types.
      • msla 8y ago
        My broader point is that low-level representation doesn't matter nearly as much as semantics, and yet by default type systems are obsessed with low-level representations. Appending a number to a string is a perfectly sensible thing to do when you're displaying information to a user, yet adding two numbers or concatenating two strings could be completely senseless and proof that the development process has gone off the rails. My dream type system is strict about semantics and only handles representation in specific circumstances. The simplest way to talk about this is in terms of units of measure: Height is a type. Whether it's in inches or centimeters is a representation. Whether that representation is a number or a string is another representation. Keeping track of whether you're showing height-in-inches or height-in-centimeters to a user is useful, but burdening your mind with whether this height-in-inches is a string or a number right now when the runtime can just as easily convert between the two is senseless, and fretting over height-in-inches versus height-in-centimeters adding person-height to shoe-sole-height to get height-in-shoes is similarly senseless.
        • jakevn 8y ago
          Your dream type system is out there, yet not manifest in any popular or somewhat-popular language. I've yet to see a strictly/strongly typed language that makes this easy to do. Through some combination of plugins, esoteric languages, macros, or boilerplate, sure. We're decades behind what is possible due to the practical.
• wvenable 8y ago
  Type inference is perfectly ok; it's still statically type checked and all the parameters and return-types are properly typed. Type inference takes away the main argument against static typing: That static typing requires you type in a bunch of useless obvious types.
• jschwartzi 8y ago
  I don't really use auto unless I'm interfacing with some templatized nightmare body of code where the typename is very difficult for my tiny human brain to interpret. Using "auto" is usually a code smell, because it means your type system is too complex for you to reason about.
  • scarface74 8y ago
    This is a valid, strongly typed C# object: var foo = {bar = 1, baz = “Hello”, boo = “World”}; You get auto complete help and compile time type checking. foo.bar = “Goodbye”; Won’t compile. What would it buy you to not use ‘var’ and create a one time use class/struct?
    • maxxxxx 8y ago
      I use auto almost always. Makes the language "feel" more dynamic but you still have type safety.
    • gmueckl 8y ago
      It would make me ask why you need a one time use struct at all and probably remove it.
      • scarface74 8y ago
        More complicated example: var seniorMales = from c in customer where c.age > 65 && c.Sex == “male” select new {c.FirstName, c.Lastname, c.Age} foreach(var customer in seniorMales) { Console.WriteLine(customer.Firstname + “ “ + customer.Lastname); } Why would I create a class/struct for that use case? Side note: this is why I find ORMs in most languages besides C# useless. Here, “customers” can represent an in memory List, a Sql table or a MongoDB collection and the LINQ expression will be translated appropriately to the underlying query syntax. The “ORM” is integrated into the language and yes anyone can write a LINQ provider.
        • gmueckl 8y ago
          This us one of the cases where I would want you to write an explicit type for seniorMales. Reasoning about the LINQ expression is just complex enough that by not constraining its type to your expectations you can easily obscure a mistake in your thinking that would otherwise show up in the data types.
• scarface74 8y ago
  Type inference for static languages are just syntactic sugar. The IDE and the compiler will both scream if you try something like var x = “John Smith”; x = 5;
• chongli 8y ago
  Haskell has very powerful type inference but it also lets you ask the compiler "what type is this expression?" There even exists tooling that lets you automatically insert inferred type annotations. Sometimes the type it infers is more general than what you wanted, so you get the opportunity to fix it in a way that makes sense to you.
  • staticassertion 8y ago
    Similarly, the intellij plugin for Rust will reveal implicit type annotations.
• Verdex 8y ago
  The problem with eating pizza is nearly every restaurant with pizza also has some kind of ice cream. You'll just wind up with a bunch of people eating ice cream and pizza all over the place. Like, type inference is pretty widely regarded as a definite good. Additionally, technologies like row polymorphism make it possible to have statically typed and inferred duck typing. To me it's hard to hear this as anything other than mission accomplished. We made a static language that looks and feels like a dynamic one. If you don't like type inference, you'll need to offer additional explanation as to why it is bad. Because otherwise you're statement only sounds like the one I made above. It sounds weird because one doesn't necessitate the other AND because they're both widely considered good.
• PurpleBoxDragon 8y ago
  In C# var is always a place holder for the actual type which the compiler only accepts if it can figure out the type. If you do anything to the var that you can't do to the actual type it will still give you a compile time error.
• coldtea 8y ago
  That's still good. In that case the language even writes the documentation for you!