While I agree with most of what you said, the things you mentioned are more about type inference and good naming than static vs dynamic typing. (While you definitely shouldn't) You can, for example, write Haskell without ever naming a single type.
Considering the use of features like auto, I personally prefer writing unspecified variables while programming and getting the statically inferred types live from the IDE, which for example aids when composing a complicated expression whose type I don't fully know while writing.
I don't seem to follow you 100%. Are you referring to biology or to software? In a biological sense I can't really see how a trusted platform would work. And even then it wouldn't protect against internal malicious code? I was simply referring to turning Cell :: tRNA -> Protein into Cell :: HumantRNA -> Protein :)
And on a software perspective trust isn't really the issue here. Trusted buggy code is still buggy code.
Typeclasses/traits are not duck typing. A type statically needs to implement an abstract data type (with its methods and invariants). This is more of a categorization/composition effort.
I still find it unfortunate that the guy who invented JS originally wanted to make a lisp but was told to make it more like the C family. Would've been interesting to have lisp run the web. A lot of things might be different today.
The service returns a 503 after some time. Seems to be happening since a few hours ago. Doesn't matter following a direct link or entering any website through their search bar.
But romanizing doesn't solve any of those problems (except maybe having to copy/paste, but with uncommon/foreign names you'll have to re-look at it thrice either way). You're still gonna wonder if 'Sung' is the first, second or third name, because your mistake was assuming that it works like this in the first place.
Well, if you're fine with being occasionally called/written Yay-souwn (ah the mistakes that can crop in when translating names into languages with different phonetic constraints), I have no argument against that.
The author seems to be missing the point, in my opinion. While it is certainly true that often one can solve simple, seemingly innocent sub-problems within more general languages, the transitions from "I see I can solve this simple program with regex'es!" to "Then I can probably solve this other, almost identical problem as well!" and have the problem explode right into your face are subtle (almost imperceivable to a novice) and it would be a more robust solution to go for the right tools (i.e. an (x)html parser), as well as a good learning example. On a side note: regular expressions can not - by definition - parse recursive languages. A regular expression matcher that does is not a regular expression parser but an ugly-duckling in the family of context-free grammar matchers. People should learn when and how to use those.