this post was submitted on 19 Jun 2025

41 points (100.0% liked)

Programming

21332 readers

141 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

UlrikHD@programming.dev

Literature review on the benefits of static types, by Dan Luu (danluu.com)

submitted 2 weeks ago* (last edited 2 weeks ago) by HaraldvonBlauzahn@feddit.org to c/programming@programming.dev

70 comments fedilink hide all child comments

Summary by Dan Luu on the question about whether for statically typed languages, objective advantages (like having measurably fewer bugs, or solving problems in measurably less time) can be shown.

If I think about this, authors of statically typed languages in general at their beginning might not even have claimed that they have such advantages. Originally, the objective advantage was that for computers like a PDP11 - which had initially only 4 K of memory and a 16-bit adress space - was that something like C or Pascal compilers could run on them at all, and even later C programs were much faster than Lisp programs of that time. At that time, it was also considered an attribute of the programming language whether code was compiled to machine instructions or interpreted.

Todays, with JIT compilation like in Java and the best implementation of Common Lisp like SBCL being at a stone's throw of the performance of Java programs, this distinction is not so much relevant any more.

Further, opinions might have been biased by comparing C to memory-safe languages, in other words, when there were perceived actual productivity gains, the causes might have been confused.

The thing which seems more or less firm ground is that the less lines of code you need to write to cover a requirement, the fewer bugs it will have. So more concise/expressive languages do have an advantage.

There are people which have looked at all the program samples in the above linked benchmark game and have compared run-time performamce and size of the source code. This leads to interesting and sometimes really unintuitive insights - there are in fact large differences between code sizes for the same task between programming languages, and a couple of different languages like Scala, JavaScript, Racket(PLT Scheme) and Lua come out quite well for the ratio of size and performance.

But given all this, how can one assess productivity, or the time to get from definition of a task to a working program, at all?

And the same kind of questions arise for testing. Most people would agree nowadays that automated tests are worth their effort, that they improve quality / shorten the time to get something working / lead to fewer bugs. (A modern version of the Joel Test might have automated testing included, but, spoiler: >!Joel's list does not contain it.!<)

Testing in small units also interacts positively with a "pure", side-effect-free, or 'functional' programming style... with the caveat perhaps that this style might push complex I/O functions of a program to its periphery.

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?

top 50 comments

sorted by: hot top controversial new old

[–] sxan@midwest.social 20 points 2 weeks ago (4 children)

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.

[–] HaraldvonBlauzahn@feddit.org 2 points 2 weeks ago (1 children)

you've re-invented a strongly typed, compiled language without adding any of the low hanging fruit gains of compiling.

This is aside from the main argument around static typing which claims advantages in developer productivity and eventual correctness of code.

Now, I think it is generally accepted that compilation with the help of static typing enables compilation to native code which leads to faster executables.

Now, did you know that sevral good Lisp and Scheme implementations like SBCL, Chez Scheme or Racket compile to native code, even when they are dynamically typed languages? This is done by type inference.

And the argument is not that these are as fast as C or Rust - the argument is that the difference might be significantly smaller than what many people believe.

[–] sxan@midwest.social 4 points 1 week ago (2 children)

Now, did you know that sevral good Lisp and Scheme implementations like SBCL, Chez Scheme or Racket compile to native code, even when they are dynamically typed languages? This is done by type inference.

Compiled or not, inferred or not (Go has type inference; most modern, compiled languages do), the importance of strong typing is that it detects typing errors at compile time, not at run time. Pushing inference into the compile phase also has performance benefits. If a program does type checking in advance of execution, it is by definition strongly typed.

[–] HaraldvonBlauzahn@feddit.org 1 points 1 week ago (2 children)

So, if type checking at compile time is universally good, why are there (to my knowledge) no modern and widely used Languages, perhaps with the exception of Pascal and Ada, where all arrays or vectors have a size that is part of their type?

[–] TehPers@beehaw.org 4 points 1 week ago

C, C++, and Rust come to mind as other languages with sizes as part of an array's type. This is necessary for the compiler to know how much stack memory to reserve for the values, and other languages that only rely on dynamically sized arrays and lists allocate those on the heap (with a few exceptions, like C#'s mostly unknown stackalloc keyword).

[–] sxan@midwest.social 4 points 1 week ago (5 children)

Maybe it depends on your definition of "part of", but

a := make([]int, 5)
len(a) == 5
len("hello") == 5

Arrays in Go have associated sizes.

But that's beside the point; what does array size metadata have to do with strong typing?

load more comments (5 replies)

load more comments (1 replies)

[–] HaraldvonBlauzahn@feddit.org 1 points 2 weeks ago (1 children)

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.

Then why is the SBCL implementation of Common Lisp about as fast as modern Java? I linked the benchmarks.

[–] sxan@midwest.social 12 points 2 weeks ago (1 children)

Java is still interpreted. It compiles to bytecode for a virtual machine, which then executes a for a simulated CPU. The bytecode interpreter has gotten very good, and optimizes the bytecode as it runs; nearly every Java benchmark excluded warm-up because it takes time for the huge VM to load up and for the optimization code to analyze and settle.

Java is not the gold standard for statically typed compiled languages. It's gotten good, but it barely competes with far younger, far less mature statically typed compiled languages.

You're comparing a language that has existed since before C and has had decades of tuning and optimization, to a language created when Lisp was already venerable and which only started to get the same level of performance tuning decades after that. Neither of which can come close to Rust or D, which are practically infants. Zig is an infant; it's still trying to be a complete language with a complete standard library, and it's still faster than SBCL. Give it a decade and some focus on performance tuning, and it'll leap ahead. SBCL is probably about a fast as it will ever get.

[–] HaraldvonBlauzahn@feddit.org 2 points 2 weeks ago (1 children)

Java is still interpreted. It compiles to bytecode for a virtual machine, which then executes a for a simulated CPU. The bytecode interpreter has gotten very good, and optimizes the bytecode as it runs

Modern JVM implementations use just-in-time (JIT) compilation of bytecode to native machine code. That can be faster than C code which is optimized without profiling (because the optimizer gets relevant additional information), and for example in the Debian computer languages benchmark game, for numerically-intensive tasks it runs typically at about half the speed of the best and most heavily optimized C programs.

And now, I have a bummer: These most heavily optimized C programs are not written in idiomatic C. They are written with inline assembly, heavy use of compiler intrinsics and CPU -dependent code, manual loop unrolling and such.

[–] TehPers@beehaw.org 4 points 2 weeks ago

TIL there's such a thing as idiomatic C.

Jokes aside, microbenchmarks are not very useful, and even JS can compete in the right microbenchmark. In practice, C has the ability to give more performance in an application than Java or most other languages, but it requires way more work to do that, and it unrealistic for most devs to try to write the same applications in C that they would use Java to write.

But both are fast enough for most applications.

A more interesting comparison to me is Rust and C, where the compiler can make more guarantees at compile time and optimize around them than a C compiler can.

[–] HaraldvonBlauzahn@feddit.org 1 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

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.

Well, going back to the original article by Dan Luu and the literature he reviews, then why do we not see objective, reproducible advantages from this?

[–] verstra@programming.dev 11 points 2 weeks ago

Because it is hard to design a study that would capture it. Because it is hard to control many variables that affect the "bugs/LOC" variable.

[–] BatmanAoD@programming.dev 10 points 2 weeks ago

Partly because it's from 2014, so the modern static typing renaissance was barely starting (TypeScript was only two years old; Rust hadn't hit 1.0; Swift was mere months old). And partly because true evidence-based software research is very difficult (how can you possibly measure the impact of a programming language on a large-scale project without having different teams write the same project in different languages?) and it's rarely even attempted.

load more comments (1 replies)

[–] verstra@programming.dev 9 points 2 weeks ago (1 children)

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".

[–] FizzyOrange@programming.dev 1 points 2 weeks ago (1 children)

I think we still must call this an “open question”.

Not sure I agree. I do think you're right - it's hard to prove these things because it's fundamentally hard to prove things involving people, and also because most of the advantages of static types are irrelevant for tiny programs which is what many studies use.

But I don't think that means you can't use your judgement about it and come to a conclusion. Especially with languages like Python and Typescript that allow an any cop-out, it's hard to see how anyone could really conclude that they aren't better.

Here's another example I came across recently: should bitwise & have lower precedence than == like it does in C? Experience has told us that the answer is definitely no, and virtually every modern language puts them the other way around. Is it an open question? No. Did anyone prove this? Also no.

[–] verstra@programming.dev 2 points 1 week ago (1 children)

Well, you can conclude anything using your reasoning, but that does give the high degree of certainty that is sought after in the studies reviewed in the article.

Again, I'm not saying that I don't believe static type checkers are beneficial, I'm just saying we cannot say that for sure.

It's like saying seat belts improve crash fatality rates. The claim seems plausible and you can be a paramedic to see the effects of seat belts first-hand and form a strong opinion on the matter. But still, we need studies to inspect the impact under scrutiny. We need studies in controlled environments to control for things like driver speed and exact crash scenarios, we need open studies to confirm what we expect really is happening on a larger scale.

Same holds for static type checkers. We are paramedics, who see that we should all be wearing seat belts of type annotations. But it might be that we are some subset of programmers dealing with problems that benefit from static type checking much more than average programmer. Or there might be some other hidden variable, that we cannot see, because we only see results of code we personally write.

[–] FizzyOrange@programming.dev 2 points 1 week ago (6 children)

No I disagree. There are some things that it's really infeasible to use the scientific method for. You simply can't do an experiment for everything.

A good example is UBI. You can't do a proper experiment for it because that would involve finding two similar countries and making one use UBI for at least 100 years. Totally impossible.

But that doesn't mean you just give up and say "well then we can't know anything at all about it".

Or closer to programming: are comments a good idea, or should programming languages not support comments? Pretty obvious answer right? Where's the scientific study?

Was default case fallthrough a mistake? Obviously yes. Did anyone ever do a study on it? No.

You don't always need a scientific study to know things to a reasonable certainty and often you can't do that.

That said I did see one really good study that shows Typescript catches about 15% of JavaScript bugs. So we don't have nothing.

load more comments (6 replies)

[–] TehPers@beehaw.org 6 points 2 weeks ago (3 children)

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.

[–] BatmanAoD@programming.dev 4 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Notably, this article is from 2014.

[–] TehPers@beehaw.org 1 points 2 weeks ago

Thanks. I couldn't find a date on it.

[–] FizzyOrange@programming.dev 2 points 2 weeks ago (1 children)

You'd be surprised. Every time I try to introduce static type hints to Python code at work there are some weirdos that think it's a bad idea.

I think a lot of the time it's people using Vim or Emacs or whatever so they don't see half the benefits.

load more comments (1 replies)

[–] HaraldvonBlauzahn@feddit.org 2 points 2 weeks ago* (last edited 2 weeks ago) (12 children)

As far as I know, there is still no scientific evidence that static type checking is generally better (in terms of developer productivity - not performance of a compiled program) by any objective measure.

load more comments (12 replies)

[–] BatmanAoD@programming.dev 6 points 2 weeks ago (7 children)

Note that this post is from 2014.

load more comments (7 replies)

[–] tetrislife@leminal.space 2 points 2 weeks ago (1 children)

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.

[–] HaraldvonBlauzahn@feddit.org 5 points 2 weeks ago (5 children)

I don't get the obsession with the scientific method.

Because actually knowing and understanding something is better than believing stuff. There is a lot of stuff that sounds plausible but is wrong.

load more comments (5 replies)

[–] luciole@beehaw.org 2 points 2 weeks ago (1 children)

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.

[–] HaraldvonBlauzahn@feddit.org 2 points 2 weeks ago (1 children)

There are also in-between approaches. Python for example has optional typing (for type checks with mypy), whereas Lisp/SBCL allows type hints for performance. Racket and Clojure allow to add types as pre-conditions (Typed Racket and Clojure Soec).

And many modern languages like Scala or Rust mostly need types in the function signature - the rest of the time, types are usually inferred. Even languages which were rigorously typed in the past, like C++, have the auto keyword added which activates type inference.

[–] luciole@beehaw.org 2 points 2 weeks ago (1 children)

Oh I love it when the language has advanced type inference! I have fond memories of tinkering with Haxe.

[–] verstra@programming.dev 2 points 2 weeks ago (1 children)

Hindley-milner type inference for the win!

It's hard to implement, but the result is a statically typed language, mostly without type annotations.

load more comments (1 replies)

[–] verstra@programming.dev 2 points 2 weeks ago (1 children)

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.

[–] verstra@programming.dev 2 points 2 weeks ago

Or post to gemini instead

load more comments