With types, you can make illegal states unrepresentable. Instead of storing a bunch of strings, you can store a Name and and Address, and can encode into the type system that ContactInfo must contain a phone number, an email address, or both but not nothing. By encoding that requirement into the type system, it becomes impossible to represent an incomplete record in your program. It also aids refactoring - if your business logic changes, your compiler will guide you through the refactor for ensuring your whole codebase reflects the change.

One of the best advantages of types is that it lets you catch errors before the code is executed. With the right precompiler/language server, you can see that your code is faulty even in your IDE. I can only speak for Javascript to give you an example.

function sum (num1, num2) {
  return num1 + num2
}

const total = sum.apply(null, [1,2])
// Returns 3.

It is a sum function that takes in two numbers as the arguments. However, a common mistake is to think that the sum function can take in multiple arguments then get a sum of them. Maybe the function is imported into a different file and you might have already forgotten about the interface.

const anotherTotal = sum.apply(null, [1,2,3])
// You're expecting it to return 6, but... it's actually still 3.

Unfortunately, you wouldn't know that you're making a mistake until you run the code in the browser and test the feature that is using the code, or you have your unit tests running. The scariest part is, in the browser, it won't even throw an error.

With Typescript, you can spot this in your IDE even before it is run anywhere else. This is how it looks like, more or less:

const anotherTotal = sum.apply(null, [1, 2, 3])
//                                ❌ ^^^^^^^^^
//  Argument of type '[number, number, number]' is not assignable to parameter of type '[number, number]'.
//    Types of property 'length' are incompatible.
//      Type '3' is not assignable to type '2'. ts(2345)

This is just a really simple example. Of course, the mistake is obvious on this one, but, as the software gets more complicated, the argument for the necessity of typing (IMO) is going to get more and more valid. For more info on this topic (Typescript), I've written an article about this (shameless plug 😋):

How strict is Typescript's strict mode?

briwa ・ Jun 1 '19 ・ 7 min read

#beginners #typescript #javascript #bestpractices

Another advantage that I find it useful is the documentation. With a good IDE integration, Typescript (or any strongly-typed language) code is sort of self-documented, but if you want to take it up a notch, you can easily generate a user-facing documentation from it without a hassle, using libraries like Typedoc. It would help a lot for, say, you're creating a library in Typescript and you want to put up a page for the API documentation.

But I also understand the other side of the story. I've read this article, and I can see that the overhead of using Typescript (or any strong-typed language, for that matter) can be too expensive to some. I would say, if you still want to skip typings, at least have a good documentation and a good testing coverage. Without these two (and also typings), I'm not sure if maintaining the code would still be productive when the code is growing in complexity and also the number of devs maintaining it ;) Just my two cents.

Slow down there! You already got a response from me today about switch. :D

I can talk for days, literally days, about how awesome types are and the problems with untyped languages...

...though I figure I might not have to, in about a year, as the dev codebase grows, and the contributors increase, you'll look back at this post and cringe. ;P

Imagine you have this function

def combine(a, b) = ???

how would you test this does what you think it should do? The way this is written combine can accept any a or b and can return anything

Now lets add some types

def combine(a: Int, b: Int): Int = ???

For your program to compile a and b must both be of type Int and combine must return an Int. This means rather than testing every possible input and output, you now only consider a tiny subset of the inputs/outputs you originally started with

Here's another example. This function is parametricly polymorphic in T (that's what the square brackets are saying), we must take a T and must return a T

def thing[T](a: T): T = ???

Can you think of an implementation other than this? Remember T can be anything, so the implementation must work for any possible T

def thing[T](a: T): T = a

I can't. And in fact the types have limited the space of implementations for this function down to just this and things like just throwing an exception or doing a side-effect.

Depending on your language you can go really far with this. In lots of FP languages OOP is never used and instead ad-hoc polymorphism (aka typeclasses) is preferred. The idea is really just an extension of the idea "my program won't even compile if the types don't work". If your language has higher kinds, you can meaningfully talk about things like IO and sequential/parallel computations. If you have a language like Idris with dependent types, you can do type-driven-development, where each time you compile your program you do a "proof of correctness" (note the quotes before you start yelling at me :) )

When you use a library with seriously shitty documentation, it's an absolute hell to have no tool to actually display you what x or y method expects or does.

I enjoy writing in TypeScript for this very reason. The documentation can be garbage, but at the very least I can look at the distributed definition files for guidance.

I used to cringe at JavaScript for the lack of types because I feel unsafe, but then after years of using JavaScript, I've grown pretty comfortable with it and just know where I needed to do type checks and coercion. Now, I cringe at how slow I work with Typed languages because of the additional mental effort to think about the type of every variable and the compilation time. But really, I've just gotten really spoilt, because the extra mental effort and time waiting for compilation is not significant really.

The thing I came to realise about why I would pick Typed languages is to make it easier to work with junior developers. I used to feel unsafe with JavaScript and now I feel comfortable with it, and the reason is simply because of experience from making all sorts of mistakes before. I find myself frequently pointing out to junior devs now where they have missed a potential type error and need to add type checks and/or type coercions when working with JavaScript. At the end of the day, I think Typed Languages have better developer experience. Plus, I really rather a machine tell me that I have made a silly mistake than having wasted the time of a colleague pointing it out to me later on.

Let's clarify a bit. You may think untyped language is a language which has no types (the name suggests it), but in reality, it is a language with the single type (it doesn't make sense to talk about types if there is only one). Examples of untyped languages: untyped lambda calculus (lambdas), assembly (bit strings). Most of the languages have types. Let's take, for example, ruby (which @ben likes):

1 + ""
String can't be coerced into Integer
(repl):1:in `+'
(repl):1:in `<main>'

This is nothing else than type error ¯\_(ツ)_/¯. So ruby is typed language, but there is no static type checker (at least not built in one, there is sorbet project which will be part of ruby 3).

What Ben meant to ask, I guess, is how dynamically type checked languages differ from statically type checked languages.

More about terminology dev.to/stereobooster/pragmatic-typ...

First up

Suppose I've mostly used untyped programming languages

This is unlikely, unless you program only using bits - but that's not efficient or terribly fun. You probably mean that you've been using dynamically typed languages - which definitely have types, but do not have typed variables or a type checker to make sure that you're not, say, assigning an integer to a variable which holds strings.

It's possible that I may have written an article to address this already...

Why learn... a statically typed language?

David Wickes ・ Mar 21 ・ 10 min read

#languages #beginners #types

This is gonna be a really crappy persuasive argument, but I wanted to give pros and cons of types, and you can decide for yourself 😄

Pros:

• More self-documenting
  • what does this function expect?
  • how is it gonna use it?
  • what is it gonna return?
• IDEs can provide richer & faster intellisense / code completion / go to definition / inline docs \
  • Check out XCode for Swift and Visual Studio for C#. Both are 🔥 at this stuff for their languages
• Usually less boilerplate-ey tests to write
• Some groups of runtime errors are impossible. Some examples:
  • In some languages, there's a type of array that cannot be empty, so myarray[0] will never throw
  • Others have literally no exceptions. Functions that might fail will always return a type that can either be a successful value, or an error. You have to deal with both or your code won't compile

Cons:

• Some typed languages have horrific compiler error messages if you mess up. Good luck figuring out what you did wrong, let alone fixing it
• Typed languages often have a steeper learning curve
  • There are exceptions on either side, of course!
  • Go is easy to pick up for lots of folks
  • ... and Ruby has magic in it that can trip folks up pretty early on in their learning
• There's math behind type systems (no joke! "Category Theory" on wikipedia). Some languages will force you to learn some of that, even if they don't mean to
• Some typed languages have "generics" - being able to write functions that can handle any type. It's handy and powerful, but these functions can be super confusing for the person calling the function

That's all I can think of for now. I think typed languages pay off after you get to a medium sized codebase. I usually reach for them on day 1, because I've been burned a lot by errors in dynamic languages, that typed languages don't have.

Hope this helps!

Do not ask this question to an Ada programmer: we are the hard-core of strong typing :-) :-)

Seriously, as many said, correctness is a big plus of strong typing. I say strong typing and not just typing since C, for example, is typed but not strongly (it converts silently between integer/pointers/chars/float/...). In a strongly typed instead no conversions are done by default and mixing different types by mistake is impossible.

Few years ago I wrote a program that made a .dot graph starting from Ada code, showing the dependence among packages. The code uses both package names and the names of the files that contain the package. Initially I used String for both of them, but I discovered that I was keeping mixing them (passing a filename when a package name was expected).

The solution was very simple: I just defined

type Filename is new String;
type Package_Name is new String;

and the compiler prevented me from mixing them. A good portion of potential bugs never made beyond the compilation stage.

Of course, strong typing reduces a bit the flexibility in your code. In languages like Matlab or Rudy variable can change value type dynamically and you can call procedures with any type of parameter you want. Indeed, because of this, I find this kind of languages a good choice for short or "short lived" fast-and-dirty software: you write it in little time and it does the work you wanted. If it is short lived, you do not care about maintainability, if it is short, it is quite easy to master it anyway.

1. Intellisense is easier and better supported with typed languages because Intellisense knows what it's looking for. I found that I have more problems with Intellisense in JavaScript than I do in Typescript

2. Types catch bugs at the editor level, so even before compile time, with a good editor/IDE.

3. Types allow you to create functions that know what to expect. Suppose I have the following:

async function httpConnection(httpManager:HttpManager, request:Request): Response {
  const response = await httpManager.sendRequest(request);
  return response;
}

In the above snippit I know, and the compiler knows, that the httpManager, which is of type HttpManager, has a sendRequest method.

But if I do the same in JavaScript:

async function httpConnection(httpManager, request) {
  const response = await httpManager.sendRequest(request);
  return response;
}

Then neither the programmer nor the compiler knows that the httpManager has a sendRequest object and I could pass the function an object that doesn't have that method. Program will attempt execution and crash when it calls the function. In a typed language, this doesn't happen, because you'll catch the error at the editor level.

Do you mean dynamic vs static typing? If so, I was kind of surprised recently to find that the overhead of a dynamically-typed language like Python can be quite high.

Resolving types at runtime can produce orders of magnitude more machine instructions compared to the same logic written in C, C++, or more generally, in a statically-typed language. That can easily lead to a slowdown in the 10-100x range, assuming the code is not I/O bound. I knew it was slower but I don’t think I appreciated just how much. Here's a benchmark for illustration.

My minimax code for tic-tac-toe in Python takes over a minute to run without caching (on my PC). @mortoray suggests it would be much faster in C++, even a naive implementation; possibly same as the cached version in Python, which is < 1s

This may not be relevant for every use-case but I thought it was worth mentioning.

I didn't realize this was a debate. What is 1100101110001? You have to know the type to figure it out. Is it an integer? A letter? A string? A pointer? Types are essential for doing stuff with computers.

Should you use a typed language? It depends. Are you writing short scripts? Then the overhead can be annoying. Are you writing a large application? Then the types can help ensure system integrity.

Mic drop.

To the person:

You already use types (: You don't use your chair to start your car. You don't pour water on your computer so you have something to drink. But you do use a cup for water, or perhaps a mug, or even a milk carton if you wanted. We group real-life objects like this to keep ourselves at least a little more organized in such a chaotic world.

Types are kinda like this in the programming world ^{^}

(admittedly it's not a perfect analogy, especially because I'm a huge advocate for functional freedom, but it's a start for at least gaining an intuition)

According to Eric Elliott, a veteran programmer and Now a JS advocate,types helps for better productivity and lower bugs in his blog

The TypeScript Tax A Cost vs Benefit Analysis

Eric's thoughts on Dynamic types

JavaScript’s dynamic types were hard to adjust to at first, but once I got used to them, it was like coming out of a long, dark tunnel and into the light.

I just thought you'll be convinced when some one with more experience offer their wisdom

His thoughts on types

Static types can be very useful to help document functions, clarify usage, and reduce cognitive overhead. For example, I usually find Haskell’s types to be helpful, low-cost, pain-free, and unobtrusive