4 ms·

Don’t languages like F# remove much of the verbosity of a type system? In fact, we’re finally loving away from that verbosity in general. Swift, for example,

Don’t languages like F# remove much of the verbosity of a type system? In fact, we’re finally loving away from that verbosity in general. Swift, for example, lets me write declarations like this: var done = false let language = “russian” let languages = [“english”, “french”, “german”, “russian”] let dictionary = [1:"english", 2:"french", 3:"german", 4:"russian"] The types are implied. The use of ‘let’ means immutable. I believe F# goes even farther but the verbose typing of a generation ago is almost gone.

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 ago
  This is also true in Java now
  - ma2rten 8y ago
    C++ also has auto now.
  - arwhatever 8y ago
    Function types don't need signatures in Java?
- nbevans 8y ago
  I, 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 ago
    No, 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 ago
      The 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 ago
  right, 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 ago
  To 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 ago
    I 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 ago
      The 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 ago
        Then add a type in that instance. var i:ReturnType = someFunctionWithANonObviousReturnType I found that in practice I don't need it.
gameswithgo 8y ago
yes, type inference is pretty comprehensive, function signatures don't usually need them even.
gchadwick 8y ago
> verbose typing of a generation ago is almost gone Worth pointing out such type inference is hardly a new idea e.g. see the ML type system: https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) which Wikipedia says first appeared in 1973. This actually traces its roots to the typed lambda calculus which predates electronic computers. However I think it is fair to say that type inference systems are finally appearing in more 'mainstream' statically typed languages (for example the auto keyword in C++ and your Swift examples).
- melling 8y ago
  Yes, immutability, pattern matching, type inference, etc are not new ideas. Pattern matching is another concept that’s making its way into popular programming. https://www.bignerdranch.com/blog/pro-pattern-matching-in-swift/ https://www.bignerdranch.com/blog/pro-pattern-matching-in-sw... https://stackoverflow.com/questions/2502354/what-is-pattern-matching-in-functional-languages https://stackoverflow.com/questions/2502354/what-is-pattern-... C# and Java are also adding this feature. We’re taking the long way to becoming Haskell and oCaml programmers.
- brianberns 8y ago
  F# comes from ML by way of OCaml.

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 ago
This is also true in Java now
- ma2rten 8y ago
  C++ also has auto now.
- arwhatever 8y ago
  Function types don't need signatures in Java?
nbevans 8y ago
I, 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 ago
  No, 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 ago
    The 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 ago
right, 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 ago
To 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 ago
  I 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 ago
    The 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 ago
      Then add a type in that instance. var i:ReturnType = someFunctionWithANonObviousReturnType I found that in practice I don't need it.

gameswithgo 8y ago

yes, type inference is pretty comprehensive, function signatures don't usually need them even.

gchadwick 8y ago

> verbose typing of a generation ago is almost gone Worth pointing out such type inference is hardly a new idea e.g. see the ML type system: https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) which Wikipedia says first appeared in 1973. This actually traces its roots to the typed lambda calculus which predates electronic computers. However I think it is fair to say that type inference systems are finally appearing in more 'mainstream' statically typed languages (for example the auto keyword in C++ and your Swift examples).

melling 8y ago
Yes, immutability, pattern matching, type inference, etc are not new ideas. Pattern matching is another concept that’s making its way into popular programming. https://www.bignerdranch.com/blog/pro-pattern-matching-in-swift/ https://www.bignerdranch.com/blog/pro-pattern-matching-in-sw... https://stackoverflow.com/questions/2502354/what-is-pattern-matching-in-functional-languages https://stackoverflow.com/questions/2502354/what-is-pattern-... C# and Java are also adding this feature. We’re taking the long way to becoming Haskell and oCaml programmers.
brianberns 8y ago
F# comes from ML by way of OCaml.