5 ms·

> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assign

> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assigned to that variable, thereby increasing programmer productivity Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc). Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. > ...since the variable types are not declared in the source code, the source code becomes difficult to understand and extend > For programmers working on the large code base written in dynamic languages, it is hard to understand the control flow of the program if the types are not available at the compile time. Dynamic languages as a result of their "dynamicness" tend to allow much better expression of control flow when compared to static languages. Only recently available statically typed languages have targeted expressiveness as a first class goal in designing the language. In fact, statically typed languages are notorious for obtuse control flows as a result of their type enforcement (see C, C++, Golang)

saagarjha 8y ago
> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc) I think it’s importatnt to mention that in Swift this lookup has exponential behavior, and can time out if the expression is too complex.
- hellofunk 8y ago
  I’ve always wondered why Swift and Kotlin, which are two very similar languages of approximately the same age, have such widely different compiler stability. Kotlin feels quite solid and mature, while Swift sometimes just feels like one big hack. Considering the enormous resources Apple has compared to JetBrains, I find it strange their trajectories have been so very different.
  - continuational 8y ago
    JetBrains business is all about understanding programming languages - Java in particular. And Kotlin is very, very close to Java.
    - vorg 8y ago
      With Kotlin, JetBrains was able to see what went wrong when previous JVM languages Scala and Apache Groovy each tried to be a better Java, and not repeat their mistakes, e.g. excessive operator overloading in Scala, or lack of scalability in Groovy.
  - saagarjha 8y ago
    Swift is one of the most complicated languages I have ever used, similar in complexity to C++. It’s also adding features relatively quickly. I think some of the earlier releases didn’t focus as much as they should have on stability, and that this technical debt is being repaid now.
jcelerier 8y ago
> Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. hahaha. Just getting people to adopt `auto` in C++ is an uphill battle. People want to write types.
- lasagnaphil 8y ago
  Sometimes writing out the types make the code clearer (while auto is good for long type names like std::vector::iterator). And although this is an edge case, if you use template-expression libraries like Eigen, you are forbidden to use auto (otherwise the template deductions don’t work properly)
  - vnorilo 8y ago
    I'm curious of when this would actually happen. Some kind of recursive implicit specialization? AFAIK auto x=foo; is just sugar for decltype(foo) x=foo; rather than MLish inference.
    - jcelerier 8y ago
      The problem with the technique used by Eigen (and also Boost.Spirit among a few other famous libs), called expression templates, is that it leverages the fact that the references to temporaries in function calls will be maintained until the end of the expression. The last operation in the expression (assignment to a specific type) will do processing to preserve those temporaries, compute the result, etc... e.g. it more or less looks like this in a trivial case : #include <cstdio> template<typename T1, typename T2> struct add { add(const T1& t1, const T2& t2): lhs{t1}, rhs{t2} { } const T1& lhs; const T2& rhs; constexpr auto get() const { return lhs.get() + rhs.get(); } }; struct integer { const int& i; constexpr const int& get() const { return i; } }; int f(); int main() { auto x = add{add{integer{f()}, integer{f()}}, add{integer{f()}, integer{f()}}}; } Here, storing the value in `auto` is wrong because by the time the expression has ended, the references point to stuff that isn't in scope anymore Hence the solution is to introduce a type that will actually do the computation or store the result during the expression ; but before C++11 you had to introduce a type here anyways, which is what was done and of course it worked.
whateveracct 8y ago
> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way. Hell, in Haskell inference can take you pretty far, and you can defer type errors til runtime in development and basically get an opt-in dynamically typed experience!
- truculent 8y ago
  > you can defer type errors til runtime in development dumb question: is there any reason you'd actually want to do this?
  - naasking 8y ago
    It's useful for prototyping, where your solution is always in flux and incomplete, but you need to test that some module is working correctly (like a hardware interface).
  - whateveracct 8y ago
    I've never done it, but if you're used to a Python/JS/etc-like dev cycle and the idea of up-front type errors annoys you, Haskell has a perfect solution.
mcintyre1994 8y ago
Yep I think working in a language with full inference and just annotating a few non-obvious types to help out whoever’s reading the code is a really nice pattern. I learned functional programming at my last job with Ocaml, and did rely quite a bit on editor tooling to give the type of things which could have been annotated, so it’s definitely a tricky balance in teams. But I use Scala now and I wish it inferred types half as well, giving almost every type is really verbose and does feel like Java sometimes. The compiler speed is probably an issue for providing the same kind of tooling there though even if you could avoid giving most types. I guess I’m basically agreeing with you - the combination of an ultra fast compiler and complete type inference is amazing to work with.
IshKebab 8y ago
That hasn't been my experience with Rust at all. Autocomplete never works.
defertoreptar 8y ago
> Dynamic languages as a result of their "dynamicness" tend to allow much better expression of control flow when compared to static languages. That may be, but I'll be damned if Golang's verbose type casting hasn't saved me from some bugs over the years. Also, I think there's an argument for type declarations being expressive in their own right. I like seeing what types a function receives and returns. It's a quick jumping off point when trying to understand what the function does.
htfy96 8y ago
Now both Java10 and C++11 have auto type inferences: var and auto keywords respectively

saagarjha 8y ago

> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc) I think it’s importatnt to mention that in Swift this lookup has exponential behavior, and can time out if the expression is too complex.

hellofunk 8y ago
I’ve always wondered why Swift and Kotlin, which are two very similar languages of approximately the same age, have such widely different compiler stability. Kotlin feels quite solid and mature, while Swift sometimes just feels like one big hack. Considering the enormous resources Apple has compared to JetBrains, I find it strange their trajectories have been so very different.
- continuational 8y ago
  JetBrains business is all about understanding programming languages - Java in particular. And Kotlin is very, very close to Java.
  - vorg 8y ago
    With Kotlin, JetBrains was able to see what went wrong when previous JVM languages Scala and Apache Groovy each tried to be a better Java, and not repeat their mistakes, e.g. excessive operator overloading in Scala, or lack of scalability in Groovy.
- saagarjha 8y ago
  Swift is one of the most complicated languages I have ever used, similar in complexity to C++. It’s also adding features relatively quickly. I think some of the earlier releases didn’t focus as much as they should have on stability, and that this technical debt is being repaid now.

jcelerier 8y ago

> Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. hahaha. Just getting people to adopt `auto` in C++ is an uphill battle. People want to write types.

lasagnaphil 8y ago
Sometimes writing out the types make the code clearer (while auto is good for long type names like std::vector::iterator). And although this is an edge case, if you use template-expression libraries like Eigen, you are forbidden to use auto (otherwise the template deductions don’t work properly)
- vnorilo 8y ago
  I'm curious of when this would actually happen. Some kind of recursive implicit specialization? AFAIK auto x=foo; is just sugar for decltype(foo) x=foo; rather than MLish inference.
  - jcelerier 8y ago
    The problem with the technique used by Eigen (and also Boost.Spirit among a few other famous libs), called expression templates, is that it leverages the fact that the references to temporaries in function calls will be maintained until the end of the expression. The last operation in the expression (assignment to a specific type) will do processing to preserve those temporaries, compute the result, etc... e.g. it more or less looks like this in a trivial case : #include <cstdio> template<typename T1, typename T2> struct add { add(const T1& t1, const T2& t2): lhs{t1}, rhs{t2} { } const T1& lhs; const T2& rhs; constexpr auto get() const { return lhs.get() + rhs.get(); } }; struct integer { const int& i; constexpr const int& get() const { return i; } }; int f(); int main() { auto x = add{add{integer{f()}, integer{f()}}, add{integer{f()}, integer{f()}}}; } Here, storing the value in `auto` is wrong because by the time the expression has ended, the references point to stuff that isn't in scope anymore Hence the solution is to introduce a type that will actually do the computation or store the result during the expression ; but before C++11 you had to introduce a type here anyways, which is what was done and of course it worked.

whateveracct 8y ago

> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way. Hell, in Haskell inference can take you pretty far, and you can defer type errors til runtime in development and basically get an opt-in dynamically typed experience!

truculent 8y ago
> you can defer type errors til runtime in development dumb question: is there any reason you'd actually want to do this?
- naasking 8y ago
  It's useful for prototyping, where your solution is always in flux and incomplete, but you need to test that some module is working correctly (like a hardware interface).
- whateveracct 8y ago
  I've never done it, but if you're used to a Python/JS/etc-like dev cycle and the idea of up-front type errors annoys you, Haskell has a perfect solution.

mcintyre1994 8y ago

Yep I think working in a language with full inference and just annotating a few non-obvious types to help out whoever’s reading the code is a really nice pattern. I learned functional programming at my last job with Ocaml, and did rely quite a bit on editor tooling to give the type of things which could have been annotated, so it’s definitely a tricky balance in teams. But I use Scala now and I wish it inferred types half as well, giving almost every type is really verbose and does feel like Java sometimes. The compiler speed is probably an issue for providing the same kind of tooling there though even if you could avoid giving most types. I guess I’m basically agreeing with you - the combination of an ultra fast compiler and complete type inference is amazing to work with.

IshKebab 8y ago

That hasn't been my experience with Rust at all. Autocomplete never works.

defertoreptar 8y ago

> Dynamic languages as a result of their "dynamicness" tend to allow much better expression of control flow when compared to static languages. That may be, but I'll be damned if Golang's verbose type casting hasn't saved me from some bugs over the years. Also, I think there's an argument for type declarations being expressive in their own right. I like seeing what types a function receives and returns. It's a quick jumping off point when trying to understand what the function does.

htfy96 8y ago

Now both Java10 and C++11 have auto type inferences: var and auto keywords respectively