Programming

An indisputable fact is that static typing and compilation virtually eliminate an entire class of runtime bugs that plague dynamically typed languages, and it's not an insignificant class.

If you add a type checker to a dynamically typed language, you've re-invented a strongly typed, compiled language without adding any of the low hanging fruit gains of compiling.

Studies are important and informative; however, it's really hard to fight against the Monte Carlo evidence of 60-ish years of organic evolution: there's a reason why statically typed languages are considered more reliable and fast - it's because they are. There isn't some conspiracy to suppress Lisp.

Honestly I'm surprised this is even still discussion. I plan to read this, but who out there is arguing against static typecheckers? And yes, I know it's probably the verifiable NPCs on Twitter.

My conclusion is that it is hard to empirically prove that "static type systems improve developer productivity" or "STS reduce number of bugs" or any similar claim. Not because it looks like it is not true, but because it is hard to control for the many factors that influence these variables.

Regardless of anyone's opinion on static/dynamic, I think we still must call this an "open question".

It feels more solid to have a complex program covered by tests, yes, but how can this be confirmed in an objective way? And if it can, for which kind of software is this valid? Are the same methodologies adequate for web programming as for industrial embedded devices or a text editor?

Worth noting here that tests should primarily serve as a (self-checking) specification, i.e. documentation for what the code is supposed to do.
The more competent your type checking is and the better the abstractions are, the less you need to rely on tests to find bugs in the initial version of the code. You might be able to write code, fix the compiler errors and then just have working code (assuming your assumptions match reality). You don't strictly need tests for that.

But you do need tests to document what the intended behaviour is and conversely which behaviours are merely accidental, so that you can still change the code after your initial working version.
In particular, tests also check the intended behaviour of all the code parts you might not have realized you've changed, so that you don't need to understand the entire codebase every time you want to make a small change.

Note that this post is from 2014.

Will read, looks interesting and I already agree with the premise but,

please people, add metadata (date, author, institution) and a bit of formatting to your pages. Not much, 10 lines of global CSS would help already.

I know far too little about compilers & interpreters to have anything to say about performance so I’ll leave that subject to wiser programmers.

What I can say about the usage itself of dynamically vs statically typed languages is that I struggle with assessments that attempt to quantify the differences between the two paradigms. I’ve come to consider programming has a craft, and as such the qualitative properties of the tools, and especially the languages, matter significantly.

I’ve been switching back and forth between dynamic and static languages lately. Although dynamic languages do feel more straight to the point, static languages are easier to navigate through. All that typing information can be harnessed by intellisense and empower the non-linear reading needed to understand a program. That’s valuable for the whole life cycle of the software, not just the time to reach initial release. It’s kind of a rigid vs fluid dichotomy.

Thanks for posting this! That blogsite is always very productive reading.

I don't get the obsession with the scientific method. Movie quote: "we don't live in the courtroom, your Honor; do we?". You can eliminate outliers like experts and students, hobby projects and lives-at-stake projects; everything you are left with is a good reflection of the industry. Example: any study with Java versus Python has to count.

I have no real experience with dynamic languages, so I can understand where the blog responses about dynamic languages having extra bugs come from. But they miss the important point about dynamic languages allowing for non-trivial solutions in fewer lines of code - matching that would basically need to be implemented in the static language, with the accompanying code bloat, under-implementation, bugginess, etc.

I think the reference to 0install's porting is real experience of the difference between Python and OCaml. Caveat: author Thomas Leonard is a seriously expert practitioner.