> However, it is not a matter of opinion whether software safety (and therefore
availability) benefits from checks performed before run-time.
The article I linked to (it's still there for me?[1]) linked to another article[2]
which in turn mentioned a paper[3], which conclusion is:
> The data indicates functional languages are better than procedural languages;
> it suggests that strong typing is better than weak typing; that static typing
> is better than dynamic; and that managed memory usage is better than
> unmanaged. [...]
> On the other hand, even large datasets become small and insufficient when they
> are sliced and diced many ways simultaneously, [...] Hence, we are unable to
> quantify the specific effects of language type on usage.
So I still think there's no way to tell, for example, if a statically typed
imperative language with manual memory management is better than a dynamically
typed functional language with a GC. I think it's a case of "all else being
equal" in the context where "all else" varies drastically.
The argument is not about if static typing improves safety (because many things
do) but instead by how much and if that increase in safety is worth the
drawbacks it comes with... Which again is subjective and situation-dependent.
In other words, even if we agree that static typing has a positive effect on
some metric (like number of bugs) it's not going to move the discussion forward.
> Conversely, it is not a matter of opinion that dynamic languages allow
patterns that static typing does not (eg. duck typing[sic]).
Not a very good example, actually there are static type systems which use
structural typing to allow for type-safe duck typing. Examples are Opa with its
Power Rows, OCaml with its polymorphic variants and others.
And while there certainly are techniques very hard (in terms of lines of code)
to use in a statically typed language it's not like they're impossible at all
(in the worst case you can write an intepreter). So the argument becomes: is a
particular technique (or a set of techniques) beneficial enough to offset the
lost benefits of static typing?
Given that, per the paper above, we have no hard data on how exactly static
typing (much less on a dynamic typing techniques...) affects the metric we're
interested in, the answer to the question is - again - a matter of personal
opinion.
> These are objective arguments we can discuss, and weigh against each other.
There are even studies that we can throw in here.
I'm sorry, but I'd like to trouble you to provide such papers; as you can see
above my quick search returned somewhat different results.
> Basically, you've had a nice pair of cards, but they make your hand. What I'm
trying to reiterate is that there seems to be a definite trend towards types.
Yeah, I also feel that argument was weak :) I only wanted to show that not "all"
new languages are statically typed, I didn't want to deny that the trend exists.
The trend of "mainstream" moving to static typing is visible, but it's important
to note that the same trend was observed more than once in programming history
already. In all the previous cases it reversed (to dynamic typing) after ten to
fifteen years. For the time being, I think, it's safer to assume we're going to
repeat the cycle than that we arrived at the last iteration. This is however
just an assumption and it may well be wrong!
> I really wish someone would think that through and try and convince me.
Your original thesis was that static typing is an overall win over dynamic
typing. I already managed to convince you that this is not the case: you admit
that there are techniques hard to pull off in a statically typed language. To
me, that's enough.
My belief is that static and dynamic typing are more or less equivalent and that
their impact on most metrics is rather minor. I think that the typing discipline
matters little and that the safety (or any other metric) of a language cannot be
determined without taking all the other features into account. Of course, this
is only my belief, as there is not enough evidence to say for sure (unless there
is some research I'm not aware of).
As such, I can only tell you what kind of projects I did in languages with
dynamic typing. This is not the same as saying that dynamic typing is the best
fit for these kinds of projects, just that there is a particular language which
feature set as a whole seemed to be a good match for the problem.
As an example, I'm writing a MUD server as a pet project. MUDs are text-based
games where you interact with objects using commands: go north, kill orc and the
like. It's based on LPMuds' basic design, so this particular implementation is
actually more of a "multiplayer REPL": the objects are described as classes
(called blueprints) with arbitrary methods which you can inherit and instantiate
(clone).
Every blueprint needs to be reloadable on runtime: you don't want to bring down
the whole world just because you found a typo in some description. As blueprints
are normal code (not just data), reloading them may change their type
signatures, which needs to be handled gracefully (in both clones and inherited
blueprints). Besides the predefined commands, users may evaluate arbitrary code
and change the shared (persistent) environment at will. It should be possible to
attach a new method to a single clone to test it without affecting anything
else.
I used Io as an implementation language, because it provides most of these
features out of the box: whatever was missing I added in under 1k lines of
straightforward code. I was able to do so in large part thanks to a dynamic,
object oriented (with multiple, prototypical inheritance) type system of Io.
It's just an anecdote, but it's an example of a project where dynamic,
dynamically typed language is a clear win over a static, statically typed one.
[1] https://medium.com/javascript-scene/you-might-not-need-types...
[2] https://medium.com/javascript-scene/the-shocking-secret-abou...
[3] http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf