[kdmccormick]

I think this is OK as long as you keep your mind open to situations that you have not considered.

Imagine someone is working in a relatively niche new programming language ecosystem which is dynamically typed, allowing the language to have some richness that modern type systems don't support. I don't have an example because I don't know of any such language in 2023... BUT back in the 70s and 80s this would have been Lisp. Lisp couldn't have been strictly typed back then because, AFAICT, type systems hadn't advanced enough to express the sort of metaprogramming that made Lisp unique and awesome. This was at a time when most popular languages were strictly typed.

I would hope that you would keep your mind open to whatever that maps to in the 2020s.

Now, if someone says "I like JS over TS because types are annoying and slow me down", then yeah, I don't have much patience for that either.

[digging]

You make points that seem great to me although I know almost nothing about Lisp or 20th century programming.

The thing is, I've yet to encounter a single instance of such an argument today. Every single time it ends up being "I like JS over TS because types are annoying and slow me down". It hadn't even occurred to me that laziness and sloppiness weren't the the only reasons to write in dynamically typed language.

I suppose what I'm saying is I'm quite interested in seeing what kind of evolution some dynamically typed language could offer in the future. Although with no signs of its coming, I'm going to stick to TS because it's objectively better for anything but very small projects.

[hansvm]

TS is an interesting example to pick when trying to argue that types are better. You have all the same downsides people pick on when arguing against strong, static typing, but since the type system isn't sound you still can't rely on the input to a function being the type you expect (and the problem is worse anywhere you inevitably interact at least a little with the JS world outside your TS bubble).

At best it's a form of documentation that enables some simple linting rules and a bit of jump-to-definition magic. Like, that's a benefit (mostly -- I tend to think that type signatures implying more guarantees than they provide is a recipe for inadvertently relying on falsehoods), but it's not as clear-cut of a win as you see in other statics/dynamic tradeoffs.

[lelanthran]

> The thing is, I've yet to encounter a single instance of such an argument today.

I don't mean to be unnecessarily contentious, but isn't that the point of undiscovered territory?

We haven't encountered it yet, when we do then as awareness grows that pattern, idiom, theorem or concept will be picked up by mainstream statically typed languages.

It's enough to believe that the properties of (for example) JavaScript might lead to an as yet undiscovered pattern that is not possible in current statically typed languages.

Unlikely, but still possible.

[digging]

Yes sure, it's always possible. My narrow experience leads me to believe, however, that some necessary threshold hasn't been crossed yet. And there's vanishingly little chance that I personally will be participating in such a revolution. Therefore from my perspective, it isn't happening yet and I can only wait to see if it does - meanwhile, I'm on the opposite side.

[mikelevins]

Imagine working on a networked system that uses types to make it impossible to express operations that violate data security and integrity constraints, and where such constraints control whether data is allowed to be read or written from or to a given endpoint. Imagine further that the types governing permission to read or write depend on environmental state that can change at any time--for example, as soon as a specific person changes roles, the set of ports they are allowed to read and write changes.

The type system enforces those permissions: writing to an impermissible destination is a type error. The types applicable to an entity are not necessarily knowable at compile time; some of them might change at any time.

I had a job working on such a system. It supported a type system implemented in Haskell with both static and dynamic type disciplines, where values were tagged with base types designed to be checked dynamically in hardware.

Was the programming language dynamically typed? Yes. Was the programming language statically typed? Yes.

[monocasa]

Python fits that niche now. Half the way tensorflow, et al work is by doing brain surgery on the AST in a way that resembles hey day Lisp's 'even the code is just s-expressions, process it as much as you want to the point of 80/20ing your way to your own compiler'.

[uoaei]

It sounds like you have an implicit prejudice against those who do not "keep [their] mind open to situations that [they] have not considered", since the way you phrased your concern is moral in nature. You see it as morally bad not to have an open mind in that way.

[mvdtnz]

As Carl Sagan said: it's good to have an open mind, but not so open your brains fall out.

[kdmccormick]

Yeah, sure, I do in fact think it is virtuous to be aware that we don't always have complete information and that we should be willing to revise our opinions when new information is encountered. Is that controversial?

[uoaei]

No, no, not controversial. I intended to make it easier to understand the point by demonstrating for the more literal-minded that using moral language sets up two halves of a dichotomy, one preferred to the other, so that such prejudices needn't be personal but rather merely moral. The difference is of course that which side of a moral dichotomy is a choice that can be reversed (e.g. making an effort to open the mind) while personal matters are immutable in those people.