Haskell is our first choice for building production software systems

not that im advocating it per se, but couldnt you deduct the tyope based on what `zagizuga()` does with `sepulka`?

for example

  def sepulka(zagizuga)
    zagizuga.doSomething()
    zagizuga.doSomethingElse()

would infer the type of zagizuga as some object that implements two methods `doSomething()` and `doSomethingElse()`... i think that should be doable (and possibly extremely slow) right?

maybe i missed something...

> Suddenly your return type will depend on the implementation of your callees

Why would that be a problem ? It's super common in templates and has never troubled me the least

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!

It might be common practice but it shouldn't be. There are lots of reasons this is a bad idea; here's just a sampling:

1. "My return type is whatever I happen to return" circumvents the ability of the type checker to ensure correctness.

2. More generally, the purpose of a specification (a function declaration in this case) is to declare what is required of a compliant implementation, and to provide a way to check the validity of that implementation. But when you make the types all become auto-deduced, you're basically reducing the specification to a ~ shoulder shrug "it does whatever it does" ~.

3. Moreover, as I alluded to in the comment, it quickly becomes near-impossible to meaningfully separate the definition from the declaration, whether that's because you want to hide it or because you want to compile it separately. Simply put, you lose modularity. It seems like a minor thing when (as in the example) the return value doesn't depend on types inferred from other callees' return values, but as soon as that ceases to be true, you suddenly tie together the implementations of multiple functions. At that point, your functions lose much of their power to abstract away anything, since as soon as you change the return expression for one function, it has the potential to break code (up to and including causing compilation errors) in the the entire chain of callers. (!)

4. Templates end up getting re-instantiated far more often than they need to be (which can slow down both the compilation and the runtime efficiency). You almost certainly don't want '0' and '(size_t)0' to result in duplicate instantiations when dealing with sizes, for instance.

5. Issue #4 can also result warnings/errors/bugs, since now you have a function that returns a different concrete type than you likely intended, which can result in everything from spurious warnings (signed/unsigned casts, for instance) to actual bugs (later truncation of other variables whose types were inferred incorrectly as a result).

6. The code becomes difficult for a human to read too. You now no longer have any idea what types some variables are supposed to be. Not only does this hamper your ability to cross-check the correctness of the implementation itself (just as with the declarations, in #1) but unless your function is trivial, this quickly makes it harder to even understand what the code is doing in the first place, never mind what it's supposed to do.

7. Proxy types become impossible to implement, since they won't undergo the intended conversions anymore.

All this just to reduce keystrokes might be a common trade-off, but a poor one. I can come up with more reasons, but hopefully this gets the point across.

> As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system ..

When selecting a language for a recent project, that needed to run correctly, without extensive debugging that would be hard to simulate (too many states and interactions), I had a couple of important criteria:

0) checked static typing

1) ADTs (that are reasonably easy to use, read and write)

2) pattern matching (no way I'll get all the if/else right)

3) reasonably easy to write static const (pure functional) code

4) memory-safe

I've considered rust, but settled on haskell, as I needed it fast and I know haskell. While technically any Turing-complete language would work, I don't think C++ would be a fit for must-work code, even disregarding (4).

While I haven't used C++ in a while, it seems to me, encoding the constraints would be 3-10x as much code, or even more, with many checks/cracks left, and a lot of readability gone.

Clean and correct functional haskell code took a bit longer to write than say happy-path imperative python, but after fixing 2 or so bugs that manifested on pretty much the first (partial) use (like incorrect "" and a bad constant), it has been running happily ever since. I didn't even bother simulating a full system configuration before a real-world customer acceptance test, because components worked on 1-2 inputs I tried, setting up a system would take a couple of hours and I couldn't think of reasonable failure scenarios. I haven't experienced similar correctness in other languages.