5 ms·

I honestly find it so annoying when return types aren't annotated. It's considerably less overhead for me when I can look at the signature and see the return ty

I honestly find it so annoying when return types aren't annotated. It's considerably less overhead for me when I can look at the signature and see the return type, even if a few characters are added.

jasonhansel 6y ago
Agreed. I think Rust had the right approach here: require type annotations for function parameters & return values, but perform type inference within functions. That makes it obvious when a function's public interface (so to speak) has changed.
- aszen 6y ago
  Not really, rust is unusable for interactive programming because of this reason. I understand that's not rust target domain but still there's downsides to be had with their approach.
  - ImprobableTruth 6y ago
    >rust is unusable for interactive programming because of this reason I'm not sure I understand, could you elaborate more?
    - capableweb 6y ago
      Lots of current and potential issues around interactive programming in Rust are outlined and discussed here: https://github.com/rust-lang/rfcs/issues/655 https://github.com/rust-lang/rfcs/issues/655
  - identity0 6y ago
    You mean like a REPL? Most languages are unusable for interactive programming. And it's not a downside if it stops use in a domain that was nobody's goal.
    - aszen 6y ago
      Yes, just pointing out the trade offs here. Btw many functional languages have quite good interactive experiences, (ocaml, f sharp, Haskell , clojure all have decent repl's). Usually they work instantly for small sized projects.
      - identity0 6y ago
        Have you ever seen a procedural language with a good REPL? Python maybe, but definitely no compiled procedural garbage-collectorless language. The "needing to put type signatures" is completely unrelated. I have no idea how that would stop Rust from being good in a REPL.
        lstamour 6y ago
        Sure: https://cdn.rawgit.com/root-project/cling/master/www/index.html https://cdn.rawgit.com/root-project/cling/master/www/index.h... Can’t speak to its quality, but there’s nothing stopping someone from writing a repl from a sufficient compiler API... and “good” is only limited by inference quality and runtime performance. IDEs are pretty snappy at showing you autocomplete as you type regardless of whether the language has a garbage collector. And performance - well, that’s what caching would be for, and an optimized compiler design that only needs to recompile changed code... I would also point out the “auto” keyword in CPP likely saves folks a lot of typing ;-) I know it and similar inferences changed my mind on the whole static vs dynamic debate...
aszen 6y ago
My experience with f sharp and recently with the new Haskell langauge server has been that not having written type annotations is a no issue because the language tooling still shows them above the function definition and better yet can autogenerate them. So I think this is more of a tooling issue, do keep in mind global type inference is really handy for interactive programming in the repl and short scripts. Type inference
- ragnese 6y ago
  I've not had the chance yet to play with OCaml or Haskell in earnest, but it's on my list. One thing that I'm fascinated and terrified by is the global type inference. Doesn't it get really hard to figure how how you're allowed to call things? Does it make your IDE experience slow? Similar to one of the things mentioned in the OP, I would think that the type hints would be super helpful to the compiler/analyzer.
  - aszen 6y ago
    I would say it works surprisingly well 90% of the time. The main help type hints give to the compiler is that it can generate better error messages for when things do go wrong, apart from that there is no major difference. As I mentioned earlier it's a powerful feature, and has its uses, especially when you are still trying to figure the types of your program. For an easier taste of global type inference you can try elm language, it's also a good stepping stone to learning haskell
Xenoamorphous 6y ago
Exactly, and if I declare that a function returns a string, and then edit its code and add a return statement that returns a number by mistake, the compiler will tell me right away. If I didn’t declare the return type then the function will silently now infer the return type to be “string | number” (which might or might not break compilation elsewhere).
breck 6y ago
VSCode shows return type on hover, and could easily show it all the time via an inline secondary notation, if desired. no need for more tokens.
- int_19h 6y ago
  The problem is that the type it infers is not necessarily the type you want to be exposed on that export. And then it's quite possible to have a bug in implementation of the function that results in a type that's outright wrong. Types are a subset of contracts. Contracts are best explicit at the API boundary - which is to say, on exported functions and members of exported classes.
  - breck 6y ago
    Agreed—there are times you definitely need to specify the type. I have them every week, but still find it the exception rather than the rule, and easier to adjust for those, than adjust for the more common case.
Etheryte 6y ago
Looking at the votes on my comment jump up and down, I was very surprised to find that my opinion is apparently very controversial. I find this very intriguing, and I'd like to hear from your side. From your perspective, doesn't IDE intellisense and the like cover that use case? Or do you prefer to have all of that information visible all the time?

I honestly find it so annoying when return types aren't annotated. It's considerably less overhead for me when I can look at the signature and see the return type, even if a few characters are added.

jasonhansel 6y ago

Agreed. I think Rust had the right approach here: require type annotations for function parameters & return values, but perform type inference within functions. That makes it obvious when a function's public interface (so to speak) has changed.

aszen 6y ago
Not really, rust is unusable for interactive programming because of this reason. I understand that's not rust target domain but still there's downsides to be had with their approach.
- ImprobableTruth 6y ago
  >rust is unusable for interactive programming because of this reason I'm not sure I understand, could you elaborate more?
  - capableweb 6y ago
    Lots of current and potential issues around interactive programming in Rust are outlined and discussed here: https://github.com/rust-lang/rfcs/issues/655 https://github.com/rust-lang/rfcs/issues/655
- identity0 6y ago
  You mean like a REPL? Most languages are unusable for interactive programming. And it's not a downside if it stops use in a domain that was nobody's goal.
  - aszen 6y ago
    Yes, just pointing out the trade offs here. Btw many functional languages have quite good interactive experiences, (ocaml, f sharp, Haskell , clojure all have decent repl's). Usually they work instantly for small sized projects.
    - identity0 6y ago
      Have you ever seen a procedural language with a good REPL? Python maybe, but definitely no compiled procedural garbage-collectorless language. The "needing to put type signatures" is completely unrelated. I have no idea how that would stop Rust from being good in a REPL.
      - lstamour 6y ago
        Sure: https://cdn.rawgit.com/root-project/cling/master/www/index.html https://cdn.rawgit.com/root-project/cling/master/www/index.h... Can’t speak to its quality, but there’s nothing stopping someone from writing a repl from a sufficient compiler API... and “good” is only limited by inference quality and runtime performance. IDEs are pretty snappy at showing you autocomplete as you type regardless of whether the language has a garbage collector. And performance - well, that’s what caching would be for, and an optimized compiler design that only needs to recompile changed code... I would also point out the “auto” keyword in CPP likely saves folks a lot of typing ;-) I know it and similar inferences changed my mind on the whole static vs dynamic debate...

aszen 6y ago

My experience with f sharp and recently with the new Haskell langauge server has been that not having written type annotations is a no issue because the language tooling still shows them above the function definition and better yet can autogenerate them. So I think this is more of a tooling issue, do keep in mind global type inference is really handy for interactive programming in the repl and short scripts. Type inference

ragnese 6y ago
I've not had the chance yet to play with OCaml or Haskell in earnest, but it's on my list. One thing that I'm fascinated and terrified by is the global type inference. Doesn't it get really hard to figure how how you're allowed to call things? Does it make your IDE experience slow? Similar to one of the things mentioned in the OP, I would think that the type hints would be super helpful to the compiler/analyzer.
- aszen 6y ago
  I would say it works surprisingly well 90% of the time. The main help type hints give to the compiler is that it can generate better error messages for when things do go wrong, apart from that there is no major difference. As I mentioned earlier it's a powerful feature, and has its uses, especially when you are still trying to figure the types of your program. For an easier taste of global type inference you can try elm language, it's also a good stepping stone to learning haskell

Xenoamorphous 6y ago

Exactly, and if I declare that a function returns a string, and then edit its code and add a return statement that returns a number by mistake, the compiler will tell me right away. If I didn’t declare the return type then the function will silently now infer the return type to be “string | number” (which might or might not break compilation elsewhere).

breck 6y ago

VSCode shows return type on hover, and could easily show it all the time via an inline secondary notation, if desired. no need for more tokens.

int_19h 6y ago
The problem is that the type it infers is not necessarily the type you want to be exposed on that export. And then it's quite possible to have a bug in implementation of the function that results in a type that's outright wrong. Types are a subset of contracts. Contracts are best explicit at the API boundary - which is to say, on exported functions and members of exported classes.
- breck 6y ago
  Agreed—there are times you definitely need to specify the type. I have them every week, but still find it the exception rather than the rule, and easier to adjust for those, than adjust for the more common case.

Etheryte 6y ago

Looking at the votes on my comment jump up and down, I was very surprised to find that my opinion is apparently very controversial. I find this very intriguing, and I'd like to hear from your side. From your perspective, doesn't IDE intellisense and the like cover that use case? Or do you prefer to have all of that information visible all the time?