[kakadu]

The embracing of Typescript and type hints pretty much solidifies the case against dynamic typing for complicated projects.

We have projects in java7 still which span thousands of LoC and juniors can just jump in using their IDE and make some sort of contribution.

With python this takes much longer.

[dartos]

Is typescript strong typing though?

I’ve been through several typescript projects where ‘as unknown as any’ makes me wish we didn’t even have typescript in the first place.

If you can’t trust the type system it’s worse than not having one :/

[master-lincoln]

apparently the words strong and weak typing have no agreed upon definition so they can not be meaningfully discussed without stating your definition.

e.g. https://perl.plover.com/yak/12views/samples/slide045.html

[rpdillon]

Wow, that's a fairly eye-opening post! I have always used definition 5 for strong typing. I would love to know where the other definitions come from.

[Tade0]

> Is typescript strong typing though?

The term "strong typing" doesn't have a clear definition to begin with.

Other terms which it often substitutes do, e.g. static typing, sound type system, decidable type system etc.

[jrajav]

I, too, find tools hard to use after I intentionally break them.

It's unfortunate that Typescript even provides this casting hack, though it's necessary for gradual, optional typing. The very first thing I would do on such a project is spend the time to fix those broken types, because it will pay back in full in productivity after a short time.

[agos]

if you abuse the type system enough, most languages will have weaker typing.

"the language" is not enough per se, you have to use the tools it gives you to gain some advantage: those projects were clearly actively avoiding strong typing, for whatever reason

[dartos]

In js land some packages don’t have strong types or, worse, wrong handmade types. ‘as unknown as any’ is kind of needed in those cases.

[ng12]

You can write bad code in any language.

[junon]

I'm tired of this adage. Yes, you can. Some languages make it way, way easier to write bad code, though.

[master-lincoln]

I think this comment doesn't add to the discussion. It's like saying you can kill yourself in any vehicle. Might be true (or maybe not), but doesn't add to the discussion of vehicle safety.

[poszlem]

This is a thought-terminating cliché and does not add anything to the discussion.

[darthrupert]

And only poor drivers need seatbelts.

[chpatrick]

Python is very much heading towards static typing although it isn't as mature as TypeScript yet.

[kerkeslager]

One might equally say that the embracing of reflection in Java and C# pretty much solidifies the case against static typing for complicated projects.

I'd tend to think the important feature here is strong typing, not static typing, and indeed TypeScript, which is hampered by the anemic type system of its parent JavaScript, it not the best example of strong typing.

Ultimately, strong typing is a hill I'm willing to die on, too. But a lot of people making arguments on this topic are conflating it with static typing, which just isn't the same thing. In general, that gives me the impression you haven't done enough work in enough different languages to really have an informed opinion. The type systems of different languages work within the context of the language as a whole, with tools like REPLs, test frameworks, constraint checkers, static analyzers, and IDEs carrying a lot of the work that might be attributed to a type system. There are a lot of confounding factors here, and if you're only talking about a few languages and you are making mistakes like conflating static=strong and dynamic=weak, you don't have the breadth of experience to understand what the benefits and downsides of strong types are.

Though uncommon, strong dynamic type systems do exist. Scheme is probably the most popular example, although its type system isn't the strongest. This is the approach I'm taking with Fur[1], which attempts to have as strong a type system as possible while still being dynamic. Python is... stronger than many other popular languages (i.e. JavaScript), but still does a lot of coercion (particularly around truth-y/false-y values--duck typing is a bit of a grey area in that it's sort of arguably weak typing, but also arguably indicates a capable type system rather than a weak type system).

But perhaps more critically, weak static type systems also exist, such as C, which is the source of many of the world's most serious bugs. It's highly unwise to assume that static typing is strong typing.

[1] https://github.com/kerkeslager/fur

[wait_a_minute]

> We have projects in java7 still which span thousands of LoC and juniors can just jump in using their IDE and make some sort of contribution.

This seems to be a main reason certain people like it. It gives a sense of productivity. However I think it is misguided. It’s a false sense of productivity. Can they commit? Maybe, yes. Will it be right? Maybe, and more likely with types to handhold. But does it mean they understand the data model and the domain of the codebase they’re working in? No. No typing forces you to know what your code is actually doing.

It takes longer to be productive, but you’ll be productive because you know what you’re doing. Not because the IDE held your hand.

Widget factories or scrum farms will no doubt like the “ease” of jumping into a codebase that has typing, but I’m not yet convinced it’s better or that much better for the experience developer. I need to think on it more. For certain though I’ve seen enough in my time to know that how quickly a junior can “just jump in and make some sort of contribution” is not a good measurement.

[master-lincoln]

Your argument sounds like a language should make it hard to understand parts of a codebase without understanding the underlying parts as well. I would argue this goes against the goal of abstracting problems to keep complexity manageable.

Of course abstractions can be misunderstood and misused, but is that an argument for not having them?

[berkes]

"Truly understanding what goes on" and "static typing" are in no way correlated, let alone causations.

You are making a false dichotomy.

It's perfectly possible to work in a dynamic codebase without understanding the domain, business, logic or big picture. And it's just as perfectly possible to build a statically typed codebase that forces you to understand the whole entirety before being able to make a change.

Now, whether it's actuallygood to enforce true understanding of the Whole, before being able to work on a subset, is another debate. One that, unsurprisingly, has long been proven to be false. It's why we consider modules, functions, boundaries, coupling, classes, microservices, layers, and so fort and so on.

[marcosdumay]

Nope. A new dev will need a lot longer to understand a large python codebase than a java one.

In fact, if all the developers change, it's a virtual certainty that none will ever understand the python code, while the odds are about even for java.

(But then, the types aren't the only factor for that.)

[BigJono]

Dude, duck for cover, lol.

You're 100% right though.