I feel like it probably isn’t worthwhile to litigate the merits of static typing every time there is a HN post that’s vaguely adjacent to the topic.

For the amount people care about it, there isn’t much evidence in either direction. And most studies that do exist are limited to small programs typically written by novices. Yale’s Singapore campus are going to be running two instances of the same course in parallel soon, one in python and one in ocaml. Perhaps that will provide a datapoint about learning the languages but maybe there will just be a lot of selection bias or library or environment or teacher differences. And how easy it is to learn a language probably isn’t the main datapoint to care about anyway.

> there isn’t much evidence in either direction

Oh, I think there are great evidences, such as: dialyzer, or ruby3 and python3 shifting towards type signatures everywhere and gradual typing, or recent racket focus on typed racket. Oh, and the rise of typescript of course.

I mean, I've abandoned Python years ago, and I was quite surprised when I discovered python people are adding type annotations everywhere.

Sure, gradual typing is not a strictly enforced as in statically typed languages, but seems people are agree that modularity and abstraction without type signatures is painful in sufficiently large programs.

What you have described is an anecdote rather than any study that attempts to be impartial which is what I really meant when I wrote ‘evidence.’ I’m sorry for not being clear enough.

I don’t feel like this anecdote is evidence because I don’t think it’s inconsistent with the trend towards more static types over the last 5-10 years or so. For this anecdote to be convincing I would need to think that programming language design happens because of carefully thought out and researched decisions and quick feedback as good languages are used and bad languages are dropped, but I don’t believe this.

This is not an anecdote by definition, since these languages represents quite a huge marketshare (and most of the rest langs are already statically typed).

Yes, this is not a sound rigid empirical proof, it's an observation (i.e. unlike the case of anecdotal, you can measure the marketshare of user, how many do use dialyzer or typescript, etc etc). We can't simply ignore any observations that are not scientifically rigid, otherwise the whole edifice of philosophy or even some natural sciences should simply perish.

I don't think you can just omit that. I'm a fan of Lakatos here, if I have some observation, I think one need at least as convincing evidence or more rigid one to prove otherwise.

> because of carefully thought out and researched decisions

I think it's a better evidence exactly because it's what language users are asking about, and what large chunk of language users choose to use when they got a choice. This shows that quite a big share if not majority of programmers value type annotations.

> I think it's a better evidence exactly because it's what language users are asking about, and what large chunk of language users choose to use when they got a choice. This shows that quite a big share if not majority of programmers value type annotations.

To be clear, this is where I disagree. I don’t want to claim that people don’t think hard about language design or that users aren’t asking for these features as I think both of those statements are true. But I strongly disagree that languages doing things (and those languages being popular) is good evidence that those things are good.

I think a lot of language design is driven by fashion (ie keeping up with what similar languages are doing) and I claim that this is a more convincing reason for python having some gradual typing.

I think large number of people is moving to/from from python for gradual typing in aggregate, and I don’t think it’s happening on the margin either. I think any wise decisions about languages are more likely to be driven by practical considerations (what do people know, what are they used to, what can people be hired for, what libraries are available, what platforms are supported, what performance is required, and so on).

Just because python has a large market share, it doesn’t mean it’s users are supporters of gradual typing, it just means that they thought python was a good idea when they first started using it and they haven’t justified the cost of changing to something else. The users didn’t choose gradual typing they just chose “upgrade the language to the next version”

Even if I agreed with your claim that many users asked for gradual typing, I don’t agree that in aggregate users ask for things that will be good for them or good in general. Maybe users are just trying to figure out a way to say “we want our programs to be less buggy” and think this might help. I think there are better examples in programming language design of what can happen if you keep giving users what they are asking for.

It would if python actually encouraged runtime coding.

In my opinion dynamic programmers need to embrace the runtime environment and use it as part of their development methodology. Unfortunately most popular dynamic languages have woeful runtime environments.

yep, i was going to say the same thing, the biggest issue with dynamic vs static is maybe people are missing the point:

dynamic languages (like smalltalk) were designed for live coding where the results are immediate, when that is broken and coding is done in a "dead" environment of course dynamic typing will cause problems that arent caught until runtime... but the original idea was one shouldnt have had to wait until runtime in the first place!

So, Common Lisp and Smalltalk?

Any others?

I'd imagine some Scheme environments are good as well, like Dr Racket.

Unfortunately the same amount of effort that has been applied to static type checking has not been applied to dynamic language environments.

It would have been very interesting to see what could be possible with the more advancement.

Factor for sure

> Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.

You cannot get mad at errors you don't know about.

Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.

In my experience, you quickly develop an intuition for where things are going wrong with interpreted languages.

Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object"

Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.

The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can solve that but these colleagues who are regularly breaking the code are actually using IDEs and it somehow still does not help. I have come to think that code that is not compiled and/or otherwise type checked is just not very serious and certainly not worthy of production environments.

> your program is only fully type checked when all code paths are executed.

The solution to this is to make sure that, during testing, all code paths are executed. And that’s something you should be doing anyway, to find bugs that aren’t type errors.

I've worked with Python codebases that had very extensive test suites and I've still encountered many cases of bugs slipping through that a static type check would have caught. Its really hard to make sure tests are fully comprehensive. About the best you could do is generative property-based tests, but then the feedback loop is not great as it may take minutes, hours, days or weeks for a particular problem case to be generated, while the static check would have caught it at compile time or even interactively in your IDE.

I don't hate dynamic languages, but this is a pretty major weak spot for them, in my personal opinion, and one that's bitten me a number of times.

That is impossible with almost all non-trivial software. Testing proves only the presence of errors not their absence.

> Testing proves only the presence of errors not their absence.

I've never thought of it that way, but that totally makes sense.

You can think of the compiler for a statically typed language doing exactly that at runtime for a subset of potential errors -- the type errors. Some people claim that they never make them and they may well be correct. I do commit such errors so compiler is a friend, but a pedantic friend.

I am all for high test coverage. One should not underestimate the effort in that, though. Some time ago I covered some two thousand lines of code completely in tests. As in, all code paths, checking all side effects. Kind of an effort in the spirit of "dealing effectivly with legacy code" by Michael Feathers. They were quite non-trivial and it took me about two months. Doing such a thing may not always be feasible. Also if code is written by others they may have covered fewer code paths in tests than one would have liked. A type checker will check all code paths but the tests that your predecessor failed to write are not checking anything.

having just spent an hour over vscode live share with a student who's learning javascript, I have a pretty good idea.

But I've worked with people who saw all compiler errors as things of the devil and wanted to defer as much as possible to runtime.

faculty helps students debug their code?? where?

I'm in france haha. why wouldn't you help a student who asks you kindly ?

Parent is probably referring to situations where faculty are too busy researching, writing grants, or just plain don't feel like it, and tell students something like

"go play with it"

"look it up"

"google it"

"read the fudging manual"

Of course, there are many great faculty who _do_ care greatly about teaching and always help students.

At my Uni we had students from higher years do volunteer time during lab sessions for lower year students. You would just wander around the lab helping random people who were stuck.

Sometimes there would be some proffessors there too to help you out.