[CraigJPerry]

>> I can give them more freedom (because I know their programs won't compile if they don't line their types up

In what meaningful way can you give them more freedom? When i think about how i spend my time with junior folks, it tends to be on things like:

1. Do they understand enough of our problem domain that i can begin to describe a problem that needs to be solved?

2. Have they understood the problem i described? How confident am i that they're not going to implement a solution to the wrong problem?

We don't spend time on "hey, you passed the parameters in the wrong order here".

To put it another way based on my experience, what's more useful to a junior developer?

Option A: Hey, here's a test case, here's how to run it. I need you to change the behaviour of this component to do X instead.

Or

Option B: Hey, here's a component with well designed types. I need you to change the behaviour of this component to do X instead.

My experience has been that Option A - play with the component hands on, try things, run it, tweak the data supplied to it and observe the results - these encourage engagement. The developer will be excited even.

And for Option B, they'll be quite dejected, not that invested in the project. I can't even compile the stupid thing because of some cryptic compile error.

[sixminuteabs]

When I say more freedom, I primarily mean freedom to focus on the problem domain and freedom to contribute in a major way more quickly. Upon reflection, I realize that my expression about optimal solution was about optimality in modeling and understanding the problem domain vs. wrestling organizational programming pattern you're trying to learn / hold in your mind while also trying to solve the domain (which you don't have to do as much with scala's compiler)

And in terms of morale, I view almost the opposite of what you're saying. Because types and the compiler enforce correctness in the program and compatibility within our systems I can have a relatively junior person thinking more about the domain and knowing that they can get something "real" into prod much more quickly with almost no risk to the org. They can move on to bigger blocks of work more quickly. Solving real, big problems and making impact gets engineers jazzed up. Regarding compilation, I find the "this won't compile" phase is almost non-existent in practice. People quickly adapt from "this thing doesn't compile [insert sad longing for python]" to "this thing won't compile - somewhere there's a misalignment with what I said I'm going to do (via types) and what I'm actually doing, [insert silent acknowledgement that they would have shipped an error in python and not known it]."

I'm not seeing where the gap is between A and B except that in option A it appears that there is no compiler involved, which per the above, means that I have to ask them to focus more on exercising mental discipline about coding conventions (boring, low value add work) and also I can't allow them to contribute as quickly because the risk they threw an exception somewhere they shouldn't have (e.g.) is higher.

[CraigJPerry]

>> they can get something "real" into prod much more quickly with almost no risk to the org

What are the most common risks to an org (originating from its code) and how do types get you down to almost no risk?

When i think of common risks, most of them don't even originate inside the process's address space so the type checker is completely disconnected from the risks (e.g. hey - you misunderstood what we wanted here...). For the risks that do originate directly from the code, it's stuff like hey - your solution is quadratic time, sure your code compiles and your tests all pass but i'm telling you this won't work under prod data volumes.

I'm trying to steelman your argument and the best case i can come up with is an IO monad.