Dynamic languages are (generally) not compiled ahead of time. It is possible to have static typing in a dynamic language in the sense that the code is interpreted at runtime (but the types are set statically in the code), and there is no "binary" that one runs.
It used to be called interpreted language or "scripting" language - but I think the vocabulary shifted so the word "dynamic" more encompasses what the languages are about.
As to whether it is dynamically or statically typed - it's easy to tell - do you need to indicate a variable is an int or a char or a string before you start using it? and do you have to cast the variable to different types when using functions that expect a certain type? If so - it's statically typed. Dynamically typed languages allows you to give an character "5" to a function that expects an integer (ie the number 5) and then automatically converts it so for example the final result to 5+"5" is int(10). Or when you try to print it, it gives you a string literal "1" and "0" without you having to recast it yourself.
Obviously having dynamic typing makes things easier for humans, but the computer has to keep predicting what the programmer is going to do with that variable, so it has some runtime and compile time weaknesses in performance, memory usage, as well as less strictness in compile-time checking - which might allow certain types of errors to sneak by, whereas static typing is very direct - you have to instruct the computer to do every casting from one type to another, etc., and the statically-typed compiler is a sadist - it will fail all your code over and over again until you get all the types right. The difference is extremely noticeable even for a novice programmer.
says that Swift is "type-safe" (compiler is a sadist and will halt on all type errors) but has type inference so you don't have to explicitly indicate the typing of a variable. I would consider it to be heavily on the statically-typed side though - since it seems the language won't let an integer variable all of a sudden also be a string - you have to cast it properly first.
Not sure where the confusion comes from, probably from people putting buzz words to everything that is new regardless of applicability.
Either way, you are correct, swift is not "dynamically-typed" and neither is it a "dynamic/interpreted" language.
> As to whether it is dynamically or statically typed - it's easy to tell - do you need to indicate a variable is an int or a char or a string before you start using it?
Modern statically typed languages often don't require this, because type inference, so its a bad test.
> and do you have to cast the variable to different types when using functions that expect a certain type?
Modern statically-typed languages may not require you to do this (e.g., Scala if the types involved have appropriate implicit conversions defined.)
> Dynamically typed languages allows you to give an character "5" to a function that expects an integer (ie the number 5) and then automatically converts it so for example the final result to 5+"5" is int(10).
That's the canonical example of weak typing; many (maybe most) dynamically-typed languages do not do this type of conversion.
A better test for a dynamically-typed language is what kind of error is produced by sending a value of an unexpected tpe (including, as expected, anything that can be handled by the applicable implicit conversion rules) to a function: if it is a compile-time error, the language is statically typed. If it is a runtime error, it is a dynamic language.
> Dynamically typed languages allows you to give an character "5" to a function that expects an integer (ie the number 5) and then automatically converts it so for example the final result to 5+"5" is int(10)
This really has nothing to do with the dynamic/static axis. Many definitely dynamically typed languages (python, lisp variants, etc) do not allow this kind of conversions. This is just poor language design.
Often languages which allow this kind of implicit conversions are called weakly typed, but that's another very ill defined term. I like "stringly" typed.