Comment by haileys | Hacker News Reader

Comment by haileys | Hacker News Reader

An interesting insight I came across a little while ago is that for mainstream, industrial languages, this way of thinking about types is relatively new. It's not that we're seeing the pendulum swing back to types, it's that we're discovering them for the first time!

In earlier typed languages, the types weren't there for reasons of soundness or productivity at all. The types were there for the compiler alone, as the compiler needed them to know which machine instructions to emit for various operations. Types were just a cost imposed on programmers.

Once computers became powerful enough that we could afford to spend cycles and memory making these decisions at runtime, dynamic languages became viable and we saw industry shift over to them, except in domains where dynamic languages still weren't viable, or where existing codebases or ecosystems made it not economically viable.

Fast forward to the present and decades worth of type theory knowledge is finally filtering through to industry in the form of languages like Rust, TypeScript, Swift, Kotlin, and others. For the very first time we're embracing types for their soundness and productivity benefits. This is an exciting new era.

You're not giving the older generations of programmers enough credit here.

While it is true that strong typing is a requirement for the best performance (and this remains so), the productivity benefits of strong typing have been known for a long time.

I mean, just look at languages like C# and Java. These are well established, extremely popular languages, used mostly in business software. A domain where performance is rarely critical. Yet, these languages are very popular. Not in the least because they make it easier for programmers to understand and work with other people's code, and because they provide good tooling, both of which are hugely valuable in a business/enterprise context. Strong typing plays a major role in enabling these features.

Even when C# was still a brand new language, roughly 20 years ago, Visual Studio already provided features like "go to definition", "find references" and autocomplete out of the box. These were a major reason for people to adopt the language.

It's no surprise that people like Anders Hejlsberg, who created C#, later went on to create TypeScript. They already understood the productivity advantages of strong typing and wanted to bring those to the web.

As a bit of a nit-pick, it's not _that_ new - see languages like ML, SML, OCaml, Miranda, Haskell, Coq, etc. that combined the notion of types from programming languages and types from mathematics. It's more that it's only recently that _industry_ has been learning about it.

That said, I definitely think you're right to point that this is a new thing for industry, and not just a swing back to the idea of types that were previously mainstream in industry. I'm excited too!

It seems pretty evident to me that most successful and popular dynamically and statically typed languages are converging from different directions on a similar set of solutions. Very much reflecting the phenomenon you describe. Some simple examples: C# has moved from very strong typing of the exact sort OP criticizes (`Person person = new Person();`) to increasingly permitting looser/more expressive typing with `var`, anonymous types, pattern matching, etc. From the dynamic side, optional, loosely enforced typing is starting to grow more common (e.g., type hinting in Python, TypeScript in JavaScript) and provides a static but still flexible form of typing. So there's some happy medium where the language balances the permissiveness of dynamic typing and the expressiveness of static typing.

>[…] increasingly permitting looser/more expressive typing with `var`, anonymous types, pattern matching, etc.

None of these features are related to loosening the type system.

It can still feel that way. Take C++ for instance:

  Foo  f = fooFromElsewhere;  // explicit typing (old)
  auto f = fooFromElsewhere;  // type inference  (new)

Now what happens if we change the type of `fooFromElsewhere` from `Foo` to `Bar`? With the old way, we need to change the code to:

  Bar f = fooFromElsewhere;

With type inference however, you won't need to change that line at all. And if the new type has enough in common with the old type, you may not change the code at all. It's just as strict as explicit typing, but it's arguably more flexible, and thus feels looser.

In cases where Foo and Bar are stricly incompatible, auto is fine here. In cases where Foo and Bar are similar and might cause trouble, auto shouldn't be used here.

Yeah, I was omitting a bias I have: I tend not to write class hierarchies, so my types are generally strictly incompatible. Things would be different if the code involved some big class hierarchy (as is sometimes the case, for instance in widget toolkits).

I feel like new features of popular typed languages have also helped them catch up to dynamic language it terms of ease of use. Go back before C++11, without "auto" writing generic code sucked! Callbacks without lambda closures also sucked. I'm sure someone will point to some 40 yr old language that had this but those languages weren't popular for whatever reason. var got added to C# in 2007 and it took more releases to let it be used in more places. Apparently added to Java much later.

I'm sure someone will give me a good example but for example std::sort in C++ before closures in C++, if you want to sort one array by another, for example you have an array of indices and an array of values and you want to sort the indices by the values, before closures I'd argue this was fairly painful unless you resorted to global variables or copying all of the data into some intermediate format. You'd end up having to write or generate a class with a sort function solely for the purpose of being able to pass in a member function to sort that could access the values. Today it's trivial because you can write a lambda that closes over the values and pass the indices into sort.

Reply on news.ycombinator.com