[jfabre]

I have to agree, I've done over 5 years of C# and then went to ruby and never looked back. Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence. I have to admit I don't have experience with the extremes which would be Haskell and Clojure.

The amount of cruft I had to type in C# just to get shit done... It's all implicit in ruby thank god for that.

I never EVER have to check the type of a variable at runtime. I always know its type just by looking at its name. Is it enforced in ruby? Of course not. Ruby assumes I'm an adult and I know that I'm doing.

[mwcampbell]

> Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence.

At 40 years old, I've seen enough of my own incompetence that I'll gladly accept things that can mitigate it. As for excellence, I suppose static typing would have prevented a handful of clever hacks that I did in Python and Lua when I was in my 20s, 12+ years ago. Truthfully though, my memory of that period has faded enough that I'm not sure, and I doubt that any of those hacks were crucial for the products that I was developing at that time. Yes, a type system as primitive as Java's at that time would have felt like a straitjacket. The same might have also been true for C#. But modern static type systems are much more flexible, and I don't think I've rejected a language based on its static type system in the past several years. (I've recently done a project in Elixir, but that was despite its dynamic typing, not because of it.)

[handrous]

> I always know its type just by looking at its name. Is it enforced in ruby? Of course not. Ruby assumes I'm an adult and I know that I'm doing.

TIL taking notes of things you want to be reminded of in the future is for children and the incompetent.

[malfist]

How in the world does type checking lower the ceiling on excellence?

[cle]

I"m guessing by rejecting perfectly valid and correct programs that are unable to be type checked. There is a large space of "false negative" programs that a type checker will reject, but that could be perfectly correct. E.g. compare Python-esque duck typing with nominal typing.

[novok]

You can have that by using Any as your type if you so wish typically and escape the type system for those rare circumstances.

Also C# suffers a similar issue with what I call "unproductive Java bureaucracy", since it's basically Microsoft Java. Bureaucracy is not static typing. You can also have full dynamic dispatch and still have static typing too.

[jfabre]

Tbh I'm conflating multiple things, I've heard a lot of good things about Haskell.

But in C# for example, if the system was not designed with dependency injection and everything being an interface it's very hard to build a test harness since you can't mock anything. Which means everything has to be tested manually. (I haven't done any C# in a long time, maybe it's not the case anymore)

So you have to create an interface and classes for every implementations for every type in the system just so I can change its type dynamically. By the time you're done with all the cruft, you forgot what you were about to code.

I'm infinitely more productive in Ruby compared to C#. But I can understand dynamic languages not being welcoming to juniors, since they can code themselves into pitfalls that will bite them later.

[bmm6o]

> But in C# for example, if the system was not designed with dependency injection and everything being an interface it's very hard to build a test harness since you can't mock anything. Which means everything has to be tested manually.

I wouldn't have put it like that, but I think I know what you mean. Mocks for unit testing do require that you have defined an interface to implement, which means that every class that you want to be mocked out needs to have an interface extracted. It is extra work. Overall I think the tradeoff is worth it, myself, especially if your IDE can automated extracting an interface. But it is dumb work that a smarter language/type system could avoid.

[magicalhippo]

> [...] which means that every class that you want to be mocked out needs to have an interface extracted. It is extra work.

If you define the interface first, then you can simply copy-paste that into the class definition and off you go implementing it. Hardly any more work at all.

[jayd16]

https://docs.microsoft.com/en-us/visualstudio/test/isolating...

This and other libraries can supersede method modifiers.

[twelve40]

i'm guessing maybe sometimes type checkers make you jump through the hoops to pass, and the OP finds that distracting? To me though, the benefits of type checking far outweigh the cost.

[inertiatic]

>I always know its type just by looking at its name.

Do you ever feel the names are getting too verbose and it would be great to have tooling that would allow you to get that information on mouse-over instead of having it make your lines almost unreadable?

I mean, there's a reason mathematics have decided to keep variable names short instead of having the names contain all the context.

[mbrodersen]

> lowers the ceiling on excellence

There is zero real world evidence for that statement. The smartest developers I have ever worked with love types. The not-so-smart ones couldn’t figure out how to use types well and their code was a buggy mess. Not evidence of anything of course but certainly a sample point.

[ylyn]

> also lowers the ceiling on excellence

> I never EVER have to check the type of a variable at runtime.

> I always know its type just by looking at its name

I guess you've only ever written web backends and menial things like that?