3 ms·

Interestingly, most of these advantages are not specific to static typing, but derive from having a language that talks about types – even a dynamic one. For ex

Interestingly, most of these advantages are not specific to static typing, but derive from having a language that talks about types – even a dynamic one. For example, most of these advantages apply to Julia as well, a dynamic language that has type declarations, which: - Lets you create typed collections so that if you insert the wrong kind of value, you get an error immediately, albeit only when code runs, not before; - Has abstract types that serve the same function as Haskell's type classes, and allow you to inherit a huge amount of functionality for a very brief type definition; - Serve as documentation of APIs; - Allow performance similar to C/C++. Another advantage that wasn't listed is that in languages that don't allow type annotations, you end up writing a lot of boilerplate type-checking code in libraries to give better error messages.

tigershark 10y ago
How can you define throwing an error at runtime instead of compile time an advantage?
- StefanKarpinski 10y ago
  I didn't claim it was. That's one of the tradeoffs you make in exchange for a simpler, more forgiving programming model (and the ability to do serious work in a REPL or notebook). However, given that Julia programs can be mostly type inferred before execution, it is possible to check for this kind of error before running a program. There have been some projects to do exactly that [1] [2], and I suspect that once Julia reaches 1.0, we'll focus more effort on static analysis tools. The point is that you don't need a static language to get many of the benefits of types, you just need your language that allows you to express type-based properties. One of the way to do that is to have a set of formal rules for deriving the type of every expression in a program, but that's not actually necessary. [1] https://github.com/astrieanna/TypeCheck.jl https://github.com/astrieanna/TypeCheck.jl [2] https://github.com/tonyhffong/Lint.jl https://github.com/tonyhffong/Lint.jl
  - WayneBro 10y ago
    You did... > For example, most of these advantages apply to Julia as well... and then you listed it as an advantage.
    - SerpentJoe 10y ago
      The advantage OP was referring to was that you could force a type warning at all, as opposed to PHP, JS etc where typed arrays don't exist (notwithstanding Uint32Array and such).
  - jblow 10y ago
    Being able to get these errors without running the code is almost all the benefit. It enables a whole class of highly effective program manipulations that are just unavailable to a non-statically-checked language.
    - StefanKarpinski 10y ago
      The claimed benefit is getting the error earlier and "at the location the erroneous value is inserted." That's exactly what happens in a dynamic language with typed collections – but, as I admitted, not at compile time. Is it better to get an error at compile time? Sure, but most of the benefit comes from the error being raised at the erroneous insertion and not later when the value is used by some completely unrelated code. Hence, my claim of getting most of the benefit. Now there are certainly other arguments to be made about "highly effective program manipulations", but that's not the case being presented by the author here.
      - jdmichal 10y ago
        Those other "highly effective program manipulations" include refactoring and modifications which involve changing parameter and return types. While I understand what you're saying, to myself it's pretty clear that there's a wide gap between these two scenarios: * Changing the collection's type and not knowing until runtime -- when your program crashes -- that it's being used wrong. * Changing the collection's type and the program refusing to compile until all usage is corrected. Because of this, I don't agree with the most modifier you're attempting to apply. The difference to me is confidence. In the former, how confident am I that I didn't miss a use-case on some branch? Considering that the program will crash or otherwise fail to operate, that seems like something I want to be pretty confident about. It's very useful to have something telling you that everything looks OK. That something can be testing, but why rely on writing good tests when we have formal proof systems available?
petre 10y ago
These are exactly some of the advantages Perl6 has over Perl5. In Perl6 you do have types but they're optional. So you can be as precise or as imprecise (typed) as you like. In D for instance you do have an auto type, yet it's still a type. An auto function that returns real or BigInt will trigger a compiler error. You need to convert the real to BigInt before any compilation can occur.
JamesBarney 10y ago
In my opinion there is a huge difference between I get an error in my compiler, and my user has a hard to reproduce error in a month when they are in the middle of a business critical task.

tigershark 10y ago

How can you define throwing an error at runtime instead of compile time an advantage?

StefanKarpinski 10y ago
I didn't claim it was. That's one of the tradeoffs you make in exchange for a simpler, more forgiving programming model (and the ability to do serious work in a REPL or notebook). However, given that Julia programs can be mostly type inferred before execution, it is possible to check for this kind of error before running a program. There have been some projects to do exactly that [1] [2], and I suspect that once Julia reaches 1.0, we'll focus more effort on static analysis tools. The point is that you don't need a static language to get many of the benefits of types, you just need your language that allows you to express type-based properties. One of the way to do that is to have a set of formal rules for deriving the type of every expression in a program, but that's not actually necessary. [1] https://github.com/astrieanna/TypeCheck.jl https://github.com/astrieanna/TypeCheck.jl [2] https://github.com/tonyhffong/Lint.jl https://github.com/tonyhffong/Lint.jl
- WayneBro 10y ago
  You did... > For example, most of these advantages apply to Julia as well... and then you listed it as an advantage.
  - SerpentJoe 10y ago
    The advantage OP was referring to was that you could force a type warning at all, as opposed to PHP, JS etc where typed arrays don't exist (notwithstanding Uint32Array and such).
- jblow 10y ago
  Being able to get these errors without running the code is almost all the benefit. It enables a whole class of highly effective program manipulations that are just unavailable to a non-statically-checked language.
  - StefanKarpinski 10y ago
    The claimed benefit is getting the error earlier and "at the location the erroneous value is inserted." That's exactly what happens in a dynamic language with typed collections – but, as I admitted, not at compile time. Is it better to get an error at compile time? Sure, but most of the benefit comes from the error being raised at the erroneous insertion and not later when the value is used by some completely unrelated code. Hence, my claim of getting most of the benefit. Now there are certainly other arguments to be made about "highly effective program manipulations", but that's not the case being presented by the author here.
    - jdmichal 10y ago
      Those other "highly effective program manipulations" include refactoring and modifications which involve changing parameter and return types. While I understand what you're saying, to myself it's pretty clear that there's a wide gap between these two scenarios: * Changing the collection's type and not knowing until runtime -- when your program crashes -- that it's being used wrong. * Changing the collection's type and the program refusing to compile until all usage is corrected. Because of this, I don't agree with the most modifier you're attempting to apply. The difference to me is confidence. In the former, how confident am I that I didn't miss a use-case on some branch? Considering that the program will crash or otherwise fail to operate, that seems like something I want to be pretty confident about. It's very useful to have something telling you that everything looks OK. That something can be testing, but why rely on writing good tests when we have formal proof systems available?

petre 10y ago

These are exactly some of the advantages Perl6 has over Perl5. In Perl6 you do have types but they're optional. So you can be as precise or as imprecise (typed) as you like. In D for instance you do have an auto type, yet it's still a type. An auto function that returns real or BigInt will trigger a compiler error. You need to convert the real to BigInt before any compilation can occur.

JamesBarney 10y ago

In my opinion there is a huge difference between I get an error in my compiler, and my user has a hard to reproduce error in a month when they are in the middle of a business critical task.