[Retozi]

I have never understood why typed languages make you slower at any point in time (early, late etc.).

Because you have to hit more keystrokes to write your program?

That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystrokes nobody questions. But when you have to type " ... : number" it's slow velocity?

In my opinion people vastly over-estimate productivity boosts of saving keystrokes. It's the tedious, boring part of the work that you would like to skip entirely, hence excess keystrokes feel way more "slowing you down" than they acutally are.

Although it doesn't matter, you actualy save keystrokes: autocomplete, auto-refactors and less low level unit-tests compensate the couple of type annotations easily.

[williamdclt]

I completely agree with you, but the criticism isn't usually with typing number, it's typing complex higher-order functions or this kind of things. Where the time lost isn't in typing out the code, but in understanding what the type should be or (worse) what does this cryptic typing error means

[weberc2]

I don’t tend to write or encounter many complex higher order functions in other languages. Are they common in JS?

[nurettin]

It is not the typing per se. Anecdotally, I started adding types to my python code and it is somewhat useful.

That usefulness is diminished when you are fighting the type system instead of getting things done.

Like when you have to make exceptions in typescript by using Any. Like when an interface for a js library is missing and you don't want to do all that work.

Or when an API returns a field with a different type in between two calls and you have to make exceptions in the code when parsing with jackson in java.

[weberc2]

Python’s type system is a particularly bad example. It’s not ergonomic and the type checking is immature.

[nurettin]

Not sure what immature or ergonomic means in this context, but I'm pretty sure handling of "private" variables (self._foo) is abysmal.

[seanmcdirmid]

Though you have a point, writing down type annotations can seriously slow you down when you are doing exploratory (prototyping) programming. It can also make your code less readable as the annotations can get in the way of the logic you really care about (easily fixed in an IDE, but people want to still use notepad to edit/read code). Then there is figuring out what the annotation should be in the first place, again easily enough automated in an IDE but the notepad problem remains.

[james_s_tayler]

What usually slows me down about dynamically typed code is you have some variable returned by a function only denoted by var myVariable = myFunction(); and I'm sitting there staring at thinking... "what are the contents of that variable? what properties do I have access to on that object? what can I do with it?"

And figuring that out becomes a massive time suck when that's a constant across an entire code base. Statically typed stuff means I can very quickly find that out even if it's the first time i'm exploring that particular area of the code.

[seanmcdirmid]

I agree, in a type inferred language or a language where annotations can be supressed, this is just another matter of IDE affordable.

Some dynamically typed languages support type annotations that are only enforced dynamically; Julia is the primary example of such a language ATM.

[vnorilo]

A well designed dynamic language like clojure can have explosive velocity. Stuff just fits together smoothly: a predicate can be a function or a set or a map or a regex, but most importantly, libraries are built of these mutually compatible blocks. Reminds me of (Sussman's?) description of lisp codebases as organic.. of course, "explosive" can be very literal when type mistakes propagate and the data model goes to bizarroworld. In clojure, you can defend yourself with spec, which catches these things at the site of the mistake. It's a tradeoff I often like (velocity vs. compile time checks). It all depends on the domain.

[mixmastamyk]

Yes. Extra typing is not a huge drain, I agree, but it is a minor one. Shorter is better until it impacts readability. Visual noise is a thing.

Code is read much more often of course. You may argue you can read a fifteen-page book as fast as a ten-pager, but it's pretty clear that's not the case.

Of course tools and inference change the balance, but even so I avoid putting code into the the kiln until the design is fully understood and at least satisfactory. And that can take a few revisions.