4 ms·
Many of these are good. I agree with joncampbelldev. The dynamically typed quote is quite snarky. To that I'd reply: Statically typed languages are when you ha
by ianamartin 9y ago
Many of these are good. I agree with joncampbelldev. The dynamically typed quote is quite snarky.
To that I'd reply: Statically typed languages are when you have to tell a computer that 2 is an integer and 'two' is a string.
I know this argument goes back and forth and never ends. And I'm not trying to start a flame war.
But I will say this: type systems occupy a space on a spectrum in my opinion, and the spectrum is imperative vs. declarative languages.
It's a conceptual spectrum, of course. And the difference is between telling the language exactly what you want and how you want it vs. telling the language what you want to get.
On one end you have C# as the avatar of strongly and statically and imperative languages. In the middle, you have something like Python that is strongly typed but dynamic, and at the far end, you have SQL, which is as strong or weak as you define your tables as well as entirely declarative. You can choose your own adventure with databases.
You have some bad citizens like JavaScript and PhP, but the conversation is really about the use-case.
IMO, strong typing is far more important than static typing. Because I personally can't stand silent errors. Weak type systems are the root of all evils. Anything that can fail silently is dead to me. Fuck you, <language>. Tell me if something broke. Don't just quietly do something I don't expect.
Which approach to use to me depends on the team and the size of the project. You can run with Python for small teams. You really can't for large teams. You really shouldn't use C# for rapid prototyping or small teams.
But you absolutely should a statically typed language for large teams.
Edit to put the sharp in my example of statically and strongly typed language.
- goatlover 9y agoBut C isn't the best example of strongly typed.
- ianamartin 9y agoSorry about that. Edited to say C#.
- quickthrower 9y agoHow do you know 2 isn't a string and two isn't an integer representing, well 0 of course :-)
- tome 9y agoYou are making a fair comparison of dynamically typed languages (Python, Lisp, Clojure, ...) to badly statically typed languanges (C, C++, C#, Java, ...). What's missing from your analysis is a comparison to well statically typed languages (Haskell, OCaml, F#, ...).
- ianamartin 9y agoI thought I was talking about the principal of static typing, rather than any language's implementation of it. Back to my original point, if you have tell your language that 2 is an integer, well, that is a certain kind of issue with that. And if you don't have to tell it that, then there's another issue that happens. I don't know Haskell or OCaml beyond toy programs, and I'm willing to hear things beyond my knowledge. But as far as I do know, the point doesn't change. I'm happy to eat my words and learn.
- Sharlin 9y agoThe GP's point was that "good" statically typed languages have type inference and indeed do not need to be told that 2 is an integer and "two" is a string. It is pretty orthogonal to the question of dynamic vs. static typing. In C++: auto i = 2; auto s = "two"; Scala: val i = 2; val s = "two"; C#: var i = 2; var s = "two"; Rust: let i = 2; let s = two; and so on. Note that these are not dynamically typed bindings - you cannot later assign a string to i, or an integer to s. However, these are examples of local type inference where the compiler simply deduces the type of a variable binding based on the type of the bound expression (although Scala and Rust type inference is actually somewhat more general than that). Haskell, on the other hand, has global type inference where the compiler considers the whole program when assigning types to bindings that are not explicitly annotated. However, some arguably useful capabilities of a type system such as subtyping and implicit conversions make global type inference a much more difficult problem to solve.
- falcolas 9y ago> if you have tell your language that 2 is an integer, well, that is a certain kind of issue with that. The question is what size integer - that matters, no matter how much our programs attempt to abstract it away. And the value 2.0 is an integer as well, but no program will consider it to be an integer, instead considering it to be some approximation of the integer value of 2.