> In a statically typed language, types are attached to variables.
More precisely, expressions may be typed. Of course, free variables are one particular of expression.
> In a dynamically typed language, types are attached to values.
More precisely, tags are attached to objects. An object is a “physical” entity that exists in space (computer memory) and time (from its construction to its destruction or garbage collection). A value is an abstract and atemporal entity that only exists in the language's semantics.
> Such a language would not allow you to, say, add an integer and a floating point number without explicitly converting one to the other.
But it does allow you to add integers and floating points! The result just happens to be an exception, which is a very well defined operation in the semantics of most high-level languages.
If, in an application, all your references are of a single data type and those data types never change the types in that application are static. This remains true even though the language is not statically typed. The language may be dynamically typed but all data types are static at execution, which is what static typing is.
Also don't confuse static/dynamic type classifications for strong/weak type classifications.
> Performance problems are the least issue with uncaught type errors. Crashes and incorrect results are the more common results.
Quite sure, in a dynamically typed language there is only a single static type inhabited by all values. If the compiler is reasoning about classes of values at runtime then it does indeed have nothing to do with static typing.
It's a big topic. Not only static/dynamic, but also things like structural vs nominal typing.
In this case, it comes down to whether the compiler tracks the "type" of every value when compiling (static typing) or whether types are stored somewhere in memory that is read from when your program is actually running.
> should the language catch us making a type error here?
With a statically typed language, the choice is up to you. Every statically typed language is just a "dynamically typed" language with the ability to statically assign types. For example, you can type the variable as an "Int" or for more runtime flexibility, a "Variant" (if using C++).
This is not a complete answer, but covers some languages. If you program too exclusively in dynamically-typed languages, you can be too used to not thinking about how physically large your types are, because you work in a world where everything is boxed, and allocations so plentiful you don't even hardly have a way of thinking about them because your language does them at the drop of a hat, and so on.
But there are many strongly-typed languages that look at types at compile time and decide how large they are, by which I mean, how many bytes of physical RAM they take. These languages have gotten better and better over time at the APIs they offer that give the benefits of this without incurring the programmer costs, but under the hood, no matter how slick they've gotten, there is still a mapping of type -> size & layout. In these languages, this sort of narrowing is a great deal more complicated, because it implies a new type, which will probably require more allocation. For instance, in the example given between a "string" and a "number", that definitely looks like two differently-sized types to me. This would become very complicated very quickly as you start having to allocate these things in ways that can't be transparent to the user, you have to pass these types around, etc. etc.
One would expect that the affordances of statically-typed languages would end up being very different. And in fact, they are. Many modern statically-typed languages can solve the same problems outlined in the post, they just solve it in a different way. In this case, an Either, or more generally, a sum type. Then "getViewsOf" returns a value of that sum type and you can switch on it based on the value. It isn't exactly the same, in fact I'm not sure there's one aspect of it that's the same let alone the whole, but it solves the same problems.
So my suggestion would be that there are in fact a lot of languages that essentially have the same feature. They just don't call it "flow typing" and it's not spelled the same way.
Depending on code review instead of a static type system does not scale. Look at all of the memory safety security vulnerabilities that are solved by "simply making sure to manage memory correctly."
I see, thanks. Looks like static compilation will only work if the entire program is “type stable”, which AFAICT means that the type of every variable can be deduced statically.
>Strictly statically typed languages preclude the option of going dynamic.
No they don't; even in C it's possible to just type everything as void*, and everything as Object in Java. Just nobody does this 'cos it introduces a bunch of unnecessary runtime errors.
Judging by the first paragraph, the author has a very biased, even aggressive preference for static languages and a contempt for anyone that disagrees with him. I don't like that, and I find that the best and most convincing arguments are those that show understanding of the opposite side. People using aggression or logical fallacies in their arguments are usually the people who can't use logic to convince others.
" ... types (static types, of course, there being no other kind) ... "
This is the statement I'm referring to above. It strikes me as completely misguided and wrong. Most languages that I know of, even most statically typed languages, know dynamic types. Java has instanceof. C++ has virtual dispatch (which is based on an objects dynamic type). Even C (untagged) unions usually have some (bit)field that allows the running program distinguish the type of data in the union.
I believe that in general, types are properties of data, which rarely exists at compile time. Thus, almost all types are dynamic. Statically typed languages simply restrict the data that can be stored in variables to a particular type and subtypes thereof.
Please read my comment again. I didn't say no statically typed languages support them.
But your Java example isn't a true heterogeneous lists, very close but not really. You cannot put instances of value types into it.
Even if it were a true heterogeneous list. You have given up on static typing with such a list and defer it to runtime. Which is exactly the dynamic typing approach.
> If you add a new type to a sum type in a statically typed language, that's a breaking change for all downstream consumers.
Yes, but that's true regardless of whether the compiler tells you or not. The question is whether adding the value to the set of types that can be returned breaks at compile time or at run time.
The situation is not written entirely with static types if the run-time processing requires the expression of dynamic typing. That's based on some actual dynamic typing from the language, or else some ad hoc dynamic types cobbed together in the program itself.
> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assigned to that variable, thereby increasing programmer productivity
Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc). Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed.
> ...since the variable types are not declared in the source code, the source code becomes difficult to understand and extend
> For programmers working on the large code base written in dynamic languages, it is hard to understand the control flow of the program if the types are not available at the compile time.
Dynamic languages as a result of their "dynamicness" tend to allow much better expression of control flow when compared to static languages. Only recently available statically typed languages have targeted expressiveness as a first class goal in designing the language. In fact, statically typed languages are notorious for obtuse control flows as a result of their type enforcement (see C, C++, Golang)
That is false; a static language could have bignum integers. E.g. you can easily have a bignum class in C++, which is static.
You can't have a variable-length bignum as an unboxed value type.
"Language with unboxed value types" and "statically typed language" are separate, somewhat related concepts.
reply