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

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.

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.

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.

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.

You also have to type, refactor, and test them. I work in multiple languages and the typed are definitely slower at the beginning, but pay off later. The strategy I outlined is the way to get the best out of both.

> types as a first class construct

A wild Idris programmer appears

TypeScript works reasonably well for this approach; it's how I tend to do things. It has some gaps when you want to do really advanced stuff, but it gives you tools like typecasting for crossing those gaps. One of the great benefits of JavaScript type systems is that since they're overlaid on a dynamic language, you can just "turn them off" as needed (when the type system fails to understand that what you're doing is safe). You can comment out type checking for a particular line, or even let your whole project successfully build while type errors remain. The type system then becomes purely a tool, and never a roadblock.

I recently had to write a tool to output a Swagger file from a proprietary api testing format, and writing all the interfaces for Swagger based on the Swagger specification was hugely helpful. I’m not sure I would have been capable of completing the project without TypeScript.

Also coming from JavaScript development first, TypeScript made learning C# and templates a breeze.

> design your system first just by writing the types,

Fine.

> look how it works,

Beutiful except it doesn't work yet because it's just types that make some shape. You could literally draw the thing with pen and paper.

> go bother with implementation.

And only then discover that something you have thought of as implementation detail is one of the main problems with your solution.

No problem. I'll just refactor some type. It's easy. Less beautiful but at least it'll work. Except it doesn't. Butchering your elegant design for hours you come to hard earned realisation that the shape you imagined that you wrote and carefully named all your types to represent actually has nothing to do with the one you need.

If you are a bad person you ship your mangled typed monstrosity that you just barely made to work with traces of your struggle fossilised for any future maintainers.

If you are a good person you toss everything to into trash (save for few hard earned implementations) and start fresh with knowledge and humility wishing you worked with TypeScript where you can start with implementation and only after you figured out the hard parts, add types that reflect your solution (finding few additional bugs in the process and getting more confident about the thing you wrote).

What you described is the waterfall approach, which brings so many problems in most real world software development scenarios.

It does, I’m talking more about module/system architecture than properties. I might go through three designs on a brand new project and futzing with types and tests while factoring it is an inefficient use of time. Waiting until satisfied with design is my advantage.

Experience. Again, not talking about a mature project, but a new one in the design phase. Types (like unit tests) are extra work at this point until a good design is discovered. Which takes time to think about.