The plague of dynamic type checking

I am legitimately unsure why would anyone intentionally use dynamic over static type checking. It's almost as if they don't value safety nor speed.

dynamic type checking allowed to escape verbosity of statically typed languages without inference, and it's a decent tradeoff when you want to have customizable behavior without bloating your're are binary size (runtime speed is the tradeoff). static languages are getting better now and type inference is going mainstream so I'm pretty sure that it's going to become a bigger trend but let's not kid ourselves: the C/Java/Pascal way tended to be tedious while the Haskal way was too focused on academic category theory to appeal to the common programmer. things might have been different if OCaml started off with a better license and learning materials in non-surrendery languages but it was how it was and you have to live with that.

I just wish there was a lithp with optional static typing that is less tedious to use thran tRacket.

>>2

without inference

The HM type inference algorithm for simply typed lambda calculi was first published in 1969 and was independently discovered multiple times due to its simplicity. Any language without type inference is a bad hack published by clueless assholes.

without bloating your're are binary size

Static type checking does not influence the binary size in any negative way.

static languages are getting better now

Languages designed with static type checking in mind were good since a long time ago. SML was published in 1990!.

C/Java/Pascal way tended to be tedious

The funny thing is that the type system of these languages was so simple that type inference would be extremely easy in them.

while the Haskal way was too focused on academic category theory

Was it?

with optional static typing

Why optional?

less tedious to use thran tRacket

Typed Racket seems simple enough though. Is there something specific that you do not like?

>>3

The HM type inference algorithm for simply typed lambda calculi was first published in 1969 and was independently discovered multiple times due to its simplicity. Any language without type inference is a bad hack published by clueless assholes.

which language from the 70s had inference?

Static type checking does not influence the binary size in any negative way.

not by itself, but if you want customizable behavior your're are probably going to need generics/dependent types/polymorphism, therefore you'll generate more machine code.

Languages designed with static type checking in mind were good since a long time ago. SML was published in 1990!.

they were also fairly obscure outside of European academia. I don't think anything earlier than OCaml was promoted for practical uses, and OCaml had problems related to license and frenchness

The funny thing is that the type system of these languages was so simple that type inference would be extremely easy in them.

Java 10 will finally have inference

Was it?

it's usable in practice but forced purity makes you anally deform your're are brain for databases, I/O and networking. also, most of the learning materials are about abstract bullshite

Why optional?

because more options = the lithp way

Typed Racket seems simple enough though. Is there something specific that you do not like?

variadic macros, especially if imported from untyped modules

>>3
continuing on tRacket in >>4, it's not just macros but all variadic functions with non-uniform types: just look at how the type definition in fold-left looks https://docs.racket-lang.org/ts-guide/types.html#%28part._.Non-.Uniform_.Variable-.Arity_.Functions%29

|\

check my dynamic dubs

>>4

dependent types

Dependent types live only during compile time in every language that I am aware of supporting them.

generics/polymorphism

How is this in any way worse than dynamic type checking in terms of binary size?

because more options = the lithp way

Sure, but what is the point? After all static type checking is superior in every way.

>>5
I think that the issue here is that Typed Racket does not support higher kinds so they end up resulting to dirty hacks like this.

>>7

How is this in any way worse than dynamic type checking in terms of binary size?

for dynamic checking you need to implement a checker and some runtime type data. for generics you might (depending on implementation) need to generate code each time you use a generic type with a different type parameer.

Sure, but what is the point? After all static type checking is superior in every way.

if your're are type system isn't perfect, your're are going to have edge cases that need ugly/unintuitive hacks like >>5. making typing optional lets you avoid those hacks by just switching to dynamic for a while. as no type system is perfect, you might need this more than you think.

Perl 6 has gradual typing :^)

I have voice recognition so I don't have to type at all.

dynamic dubs checking

>>11
If it looks like a dubs, and walks like a dubs, then it probably is a dubs.