4 ms·
This. Static typing doesn't mean tedium in modern languages. In Java and old C#, you would write stuff like this: int x = 1; BigOldClass y = new BigOldClas
by wenc 8y ago
This. Static typing doesn't mean tedium in modern languages. In Java and old C#, you would write stuff like this:
int x = 1;
BigOldClass y = new BigOldClass()
Dictionary<int, List<string>> z = new Dictionary<int, List<string>>();
int[] p = new int[] {1, 2, 3};
In modern C#, you can write cleaner code like this:
var x = 1; // type is inferred
var y = new BigOldClass(); // syntactic sugar to avoid repetition
var z = new Dictionary<int, List<string>>();
var p = new [] {1, 2, 3};
Still strongly, statically typed, and obviously typed.
- gbear605 8y agoThis is also true in Java now
- ma2rten 8y agoC++ also has auto now.
- arwhatever 8y agoFunction types don't need signatures in Java?
- nbevans 8y agoI, as a F#'er, would argue that lines 2 and 3 of the C# snippet there is not an example of type inference. But I realise this is not a mainstream opinion so please don't downvote me :)
- wenc 8y agoNo, I don't think I meant to say all the lines were type-inferred. The type inference only happens on the 1st and 4th lines. In 2 and 3 the types were explicit. All lines however are statically typed.
- barrkel 8y agoThe type is inferred on all 4 lines and the mechanism is little different; the 4th line is the most complex one, because there's a type unification required across all elements of the array, but C# and Java and other languages with overloading already need to do very similar inference with the ternary operator - the types on each side of the branch need to be unified to resolve the overload. Hindley-Milner type inference (like used in F#) isn't hugely more complex; it's more aggressive at using type variables to generalize the code, and applies type unification in more situations.
- gameswithgo 8y agoright, most languages do this now. But F# extends that further. Function signatures don't need types either. Record types can be inferred from their field names. If you write a function with no type signatures it is automatically made generic, as well. So you can often write large chunks of code with no specified types, but everything is still statically typed. Granted this is maybe not always good, sometimes it is productive to have types in the function signatures, though the IDE can supply these automatically with codelens featuers/on hover features.
- rb808 8y agoTo me that isn't an improvement. It may be "statically typed", but it isn't clearly typed, the first set is not slow to enter or read and is 100x clearer. To me var is only useful for writing generic lambdas & similar - you shouldn't use for regular variables.
- nicoburns 8y agoI agree that "1" should annotated to specify which type of integer you are using. But IMO `var foo = new Foo()` is pretty clearly of type Foo. Furthermore the type is often not what I care about (the variable name and function call names generally tell me more about what is happening on that line of code), so I'm generally pretty happy if the type is a little more hidden.
- curun1r 8y agoThe problem likely results from: var i = someFunctionWithANonObviousReturnType(); Type inference may be easy when the left-hand side is a literal, but that's often not the case. And when the left-hand side isn't a literal, it definitely optimizes writing code at the expense of reading code. You can argue that IDEs should be helping us by show us the type when we mouse over or auto-completing available methods on the variable's type, but there are situations (code review, pair programming, etc) where we can't rely on tooling to help in this regard. I get why people like type inference and I use languages that have it on a daily basis, but I've also realized that I need to adapt my coding style to it or I'll end up with code that's difficult to read. In particular, I'm constantly considering whether the code I'm writing is understandable using local reasoning only and that I'm not forcing a reader of my code (who's likely to be me several months from now) to jump to some declaration somewhere else in the code.
- melling 8y agoThen add a type in that instance. var i:ReturnType = someFunctionWithANonObviousReturnType I found that in practice I don't need it.