Hacker News Reader

Comment by straight-shoota | Hacker News Reader

Remember static typing is also really useful for code quality and avoiding hidden bugs. Some code in Ruby requires a ton of specs to discover bugs caused by type issues, while the Crystal compiler tells you immediately that something doesn't work out. I love Crystal's type system really for productivity reasons.

View on HN

I haven’t ever understood the argument against static typing. I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.”

The only exception to this is untrusted input, but for that an string is usually always fine.

> I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.”

Never written generic/template code? Making that much easier is one of the main benefits of dynamic typing.

Change it to "this variable is always going to be a T, never not a T" and it still stands.

It's possible—nay likely—that I don't understand the true value of generics. It's something that I've looked into on occasion and it never seemed all that useful to me. Most examples I've come across in the past were C++ and seemed like formalised workarounds for deficiencies in the C++ type system rather than being actually useful. I'm sure I've failed to grok them—or based on the code I write I'm not the target audience for them.

I have no problem when a language allows the programmer to explicitly opt for a variable to be an undefined/dynamic type, whether as part of generics or as part of a defensive ingest of untrusted data. I admit this is previously unspecified nuance but in my mind this doesn't break my rule: "this variable is always going to be a dynamic type, never not a dynamic type." This means you know when to interact with it defensively.

The thing I'd like in a hybrid static-dynamic language is type assertion blocks which restore some benefits of static typing while dealing with dynamic typed variables. E.g.:

  declare x as dynamic;
  x = untrusted_source();
  if (x IS_A string) {
    // Inside here, x behaves as a statically typed string.
    // The compiler knows it and checks types appropriately.
    // Passing x elsewhere will send a static typed string.
    function_that_demands_a_string(x);
  }
  else if (x CAN_SAFELY_BECOME_A uint) {
    // True for any non-negative integer regardless of data type.
    // Inside here, x is always a statically typed uint.
    // If it was some other type, it was converted for me.
  }

(This probably already exists in some language somewhere but my familiarity with languages is narrow.)

Crystal does some of what you want:

https://tio.run/##ZVDBbsIwDL33KywmrRcaUXbbhHbeaYdpJ4RQaA1kCk...

Note how the language is pretty smart about flow-typing variables as you narrow down their types. `x` here is typed as a tagged union (String | Int32 | Array(Char) | Float64 | UInt32), but by the time the program gets to the final `else` the compiler has figured out that the String and Array cases have already been dealt with (even though we never mentioned Array by name, just asked if the object implements a method that only Array implements), so it lets us call `x.abs`, which only works for numeric types. Of course, `abs` has different implementations for Int32 and Float64, but the signatures are compatible so the compiler lets it fly, resorting to dynamic dispatch at runtime.

The missing part is that there's nothing like a CAN_SAFELY_BECOME_A operator so I had to implement that test myself (as `try_to_u32`) and call it early to get the flow typing to work.

The Wikipedia article for the concept is https://en.wikipedia.org/wiki/Flow-sensitive_typing

That's very cool. And especially thanks for surfacing the Wikipedia article.

Python typecheckers (both pyright and mypy, I believe) do this (isinstance checks and some other checks in conditionals narrow the type on the defended path.)

The main benefit of generics is to easily maintain strong type information for implementers.

With a

  <T>createMapWithStringKey(T arg) -> Map<string, T>

You can keep strong type info with

  AType a
  var b = createMapWithStringKey<AType>(a)
  // b is for certain a Map<string, AType>

The classic use case for generics is when creating Abstract Data Types. Implementing stacks, queues, dynamic arrays etc of differing Types is made relatively simple using generics.

If all you get from static typing is runtime performance and correctness, your type system is not pulling its weight.

In any serious statically-typed language, the type system does real heavy lifting. In practice that means that libraries execute code at compile time that, in effect, generate the code you would otherwise need to write (again) yourself.

C, Pascal, and Go are examples of statically typed languages whose type system does only trivial work.

Reply on news.ycombinator.com