[gruffle]

The issue is you think you know what you're talking about, but it's painfully obvious you don't.

> Errors that would be caught by static type checking are exceptionally rare when you do commerical development in dynamically typed languages.

Those kinds of errors are not rare at all.

[ReflectedImage]

I've got lots of experience in developing with both static and dynamically typed languages, I know the differences and it has very little to do with anything you are talking about.

Dynamically typed languages tend to be simpler and easier to use. This means on the whole they have less bugs than their static typed counter parts.

The real issue with dynamically typed languages is that their performance sucks. (That and according to this thread people not having a clue on how they are properly used. You can't just use the same development techniques as you use in a statically typed language. It's different.)

[gruffle]

> I've got lots of experience in developing with both static and dynamically typed languages

And yet your comments demonstrate the opposite.

> Dynamically typed languages tend to be simpler and easier to use.

Very debatable.

> This means on the whole they have less bugs than their static typed counter parts.

Not at all.

> The real issue with dynamically typed languages is that their performance sucks

Every time you say something like this it just makes it obvious you have no idea what you're talking about. You can write almost completely typeless, highly performant, c and assembly code, while high level languages with advanced type systems are generally not the most performant.

You seen to be confused about interpreted/jit/compiled languages and static/dynamic typing - which are not the same thing.

[ReflectedImage]

Here's a study: https://games.greggman.com/game/dynamic-typing-static-typing...

The key points are as follows:

* Development in Dynamically Typed Languages is faster

* Dynamically typed languages use less lines of code than statically typed languages by a significant margin

* The level of bugs is the same between Dynamically typed and Statically typed code.

"You can write almost completely typeless, highly performant, c and assembly code,"

Yes, I'm sure the LOAD instructions take pictures of cats as operands via their typeless instruction sets... What in earth are you on???

"completely typeless, highly performant, c"

well once someone does that let me know. The only thing near is Javascript and that is only faster for microbenchmarks not real programs.

[gruffle]

The comments in the article you linked dismantle most of the arguments made.

From one of the comments:

https://dev.to/aussieguy/the-non-broken-promise-of-static-ty...

> The article covers a study of the same name. In it, researchers looked at 400 fixed bugs in JavaScript projects hosted on GitHub. For each bug, the researchers tried to see if adding type annotations (using TypeScript and Flow) would detect the bug. The results? A substantial 15% of bugs could be detected using type annotations. With this reduction in bugs, it's hard to deny the value of static typing.

> Yes, I'm sure the LOAD instructions take pictures of cats as operands via their typeless instruction sets... What in earth are you on??

Have you written any assembly? Assembly generally has no or very rudimentary type checking, you're generally dealing with words/bytes and addresses, you can arithmetically add parts of strings, divide pointers, etc. Errors due to these operation will surface at runtime, not be typechecked.

> well once someone does that let me know.

You can use void pointers as return types and arguments for all functions in c code. The effect is significantly less type checking while having equivalent performance.

[ReflectedImage]

"A substantial 15% of bugs could be detected using type annotations. With this reduction in bugs, it's hard to deny the value of static typing."

Actually, that makes it really easy to deny the value of static typing. If the total number of bugs in dynamic and static code is the same. But some bugs in dynamic code would be caught by static typing checking.

We most conclude that adding static typing results in a large number of non-typing related bugs being added to the code base. It's simple maths.

"Have you written any assembly?" Yes, I'm an emulator author, thank you very much.

The registers and opcodes are typed with things such as u8, u16, u32, u64, i32, i64 and only work with data of the right type.

"arithmetically add parts of strings, divide pointers" You mean standard C stuff, you know the statically typed language.

"You can use void pointers as return types and arguments for all functions in c code" Dynamic types is not the same thing as type eraser. That void pointer doesn't carry the information that it points to a picture of a cat for example.

The fact you don't understand the difference between a void pointer and dynamic typing doesn't exactly surprize me. It's more like a giant vtable.

[gruffle]

> If the total number of bugs in dynamic and static code is the same.

Completely baseless assumption.

> Yes, I'm an emulator author, thank you very much.

Ahahaha let's have a link then.

> The registers and opcodes are typed with things such as u8, u16, u32, u64, i32, i64 and only work with data of the right type.

Those are sizes, not types, and the same opcode generally applies to signed and unsigned integers. You consider that to be a static type system and you think the purpose is performance and not correctness? Lol

> You mean standard C stuff, you know the statically typed language.

You're trying to debate against the need for static typing by pointing out unsafe parts of c? Ahaha

> That void pointer doesn't carry the information that it points to a picture of a cat for example.

First of all you can totally carry around runtime type info and value with a single void pointer. Not to mention many dynamically typed languages have type erasure and many statically typed languages have runtime type info. Also, you've claimed multiple times that there's no need for type checking whatsoever. You need runtime type information at runtime now?