Static Typing vs Dynamic Typing

Pros and Cons?

Other urls found in this thread:

rayb.info/uploads/cacm2017-lang.pdf
i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html
twitter.com/NSFWRedditGif

Dynamic typing for small, personal projects and MVPs.

Static for everything else.

Static typing is more time-consuming at the start but avoids issues later. Dynamic lets you just get started.

As a rule, if what you're doing involves mixed types, neck yourself

Strong typing is more important than static typing

With static typing you can do source code analysis for things like function invocations to check if argument types are correct which is pretty nice. That and something about being faster for some reason. Cuck js dev here. Typescript is static typing for JS and it's getting traction since js is being used to build complicated apps and it just adds another layer of confidence that your code is thick solid and tight

This.

...

moron

Idiot

i'm not the one who fails to understand the difference between value types and reference types

performance overhead for lazyness that introduces new class of errors vs. complicating linker with statically dispatched templates and generics? Dynamically dispatched interfaces with strong typing is easiest to implement, still quite fast and statically analyzable.

Most of the arguments in this area ignore the other general rules of the languages being discussed.

Typescript is the only way I find Javascript tolerable. A lot of people argue that having it enforce static typing is the answer.

But Ruby and Python are dynamic, and I've never found it to be a problem.

What IS a problem is Javascript's "undefined is undefined" classics, which end up addressed by static typing. It doesn't mean Ruby should be statically typed.

Sounds like your problem is with weak typing rather than dynamic typing.

I don't get how dynamically typed oop is supposed to work. If i open up some strange python file and see x = foo.bar() how am I supposed to know what x's type is without finding bar's method definition to see what is returned.

pro dynamic
- language is smaller
- language is typically easier to implement, in particular for interpreters, since you outsource both script type checking and host API type checking to other programmers; the checking itself isn't necessarily the hardest part
pro static
- for actual software you can leverage static typing for improved
-- performance
-- code correctness
-- expressivenes
-- self-documentation of trivial code
in software that is about greater than 100 lines

That's pretty vague, but so is dynamic vs static typing, since it is not a boolean thing, but an entire field of options and aspects combined with other static or dynamic checks and other properties of the language.
Equally, so is strong typing, so is not necessarily true.

There's this common sentiment that dynamic typing helps you avoid a certain class of bugs, but from my experience, those bugs don't really exist in dynamically typed languages.

Does anyone here know of a study that's looked at bug classifications and found a meaningful difference between dynamic and statically typed languages, or has anecdotes indicating that?

Modern programming languages can do type inference so type declaration just makes compile times faster and it helps with documentation.

this

>There's this common sentiment that dynamic typing helps you avoid a certain class of bugs
Did you mean static typing?

Yeah, but type inference is a form of static typing.

It also helps with expressiveness.
Imagine a type like
SomeType = SomeStuffThatCanOnlyExistAtStateA | SomeStuffThatCanOnlyExistAtStateB

Ruby is dynamically typed, but also strongly typed.

What do sum types have to do with static typing?

They have to do with Explicit vs Implicit static typing.

At the same time it's not, btw. because of duck typing.

There are studies like
rayb.info/uploads/cacm2017-lang.pdf
i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html
but they reveal mostly two problems:
a) Cniles (we don't need a study for that)
b) those studies are probably not refined enough

Measuring bugs in dynamic anything is problematic, since, as "dynamic" indicates, the bugs are discovered later, if at all.
For example, I often see JSON files where numbers are strings and strings are numbers when they should not be. It doesn't fail, because the endpoints use dynamic languages or super tolerant parsers but technically it's a bug.

Also not covered are for example
- the environments in which what is used
For example webshit - the greatest field using dynamically typed stuff - is a relatively relaxed and trivial environment, often with time to write masses of tests. I seldom hear complaints about dynamic typing from that direction.
Whereas when going to AAA gamedev - a rather stressed out, pressured and high profile field - I happen to hear quite some complaints about e.g. Lua sucks because it doesn't do static type checks and devs would rather use C++ for this reason. Also, many of the in-house scripting languages are statically type checked.
- the actual amount of code that exist in those languages
Most software in dynamic programming languages is trivial in size and probably rely on multiple size the amount of compiled code written in static languages.

Buzzwords aside, languages like C and C++ is doing it right, languages like python and javascript is doing it wrong.

For the original author of the application, it doesn't matter one way or the other.
What matters is when other people are reading the code.
In C, you can look at any variable at any random spot in your code and read upwards until you find the declaration where the type is clear.
Any IDE can show it by hovering over the variable (or whatever they do) so developers can easily find out how the data is structured.
In C++, it can be rather difficult to quickly estimate how data is structured if there is several layers of inheritance but that is usually just a poor design strategy and does not have anything to do with being explicit or not.

Everyone agrees data structures in C are dumb and basic.
You are supposed to build ones on top of those simple building blocks yourself.
A c++ vector is a much better data structure than a c style array for most use cases and I don't see why it wouldn't be implemented by most c users (or a shorter variation of it).
I personally like the kvec preprocessor version.
The template version in c++ is a bit more involved but essentially the same.