4 ms·

Static Typing Where Possible, Dynamic Typing When Needed (2011) [pdf]

43 points by i_feel_great 11y ago

Animats 11y ago
Since that paper, there's been some convergence in this area. Explicitly typed function parameters and inferred local variables now seem to be the way things are going. Go and Rust take that route. It's been retrofitted to C++, with "auto". Python seems to be headed that way, although the proposal is to have type declarations that are not checked for backwards compatibility reasons, which creates its own problems.
- simplify 11y ago
  I am definitely biased (being the creator and all), but I like the approach JS Zero[1] is taking. Everything is written in a sound, subset of JavaScript, but you can always use an `assume` tag as an escape hatch, allowing you to write "normal" JavaScript when you really need it. For example, if you're reading records from a SQL database, you don't have to bother wrestling with the type system – just tell it what your data looks like! :) let Pet = Object.of({ name: String, happiness: Number }) $assume `fetchPets : (Number) => Promise( Array(Pet) )` function fetchPets (minHappiness) { return db('pets').select('*').where('happiness', '>', minHappiness) }
  - knocte 11y ago
    [1]?
    - jmiwhite 11y ago
      See: Assumptions http://js-zero.com/spec/#type-annotation-syntax http://js-zero.com/spec/#type-annotation-syntax
    - simplify 11y ago
      http://js-zero.com/ http://js-zero.com/
- moonchrome 11y ago
  >there's been some convergence in this area. Explicitly typed function parameters and inferred local variables now seem to be the way things are going. Go and Rust take that route. It's been retrofitted to C++, with "auto". That feeling when even C++ is less verbose than Java ... another "lambda" feature.
  - smt88 11y ago
    Verbosity isn't bad in and of itself. It serves as extra documentation, for one thing. Code that is written once is read at least twice, and often many more times than that.
    - moonchrome 11y ago
      Except that's exactly my problem with it - you can get used to shortcuts and the IDE will generate the types so writing the code is not an issue - navigating through this pointless verbosity hurts readability because there's too much noise to filter out - Java verbosity is noise not signal. Just the physical eye movement and scrolling is wasting time and energy on pointless things. Python doesn't have types at all and it reads like pseudocode. This is not arguing against types - having types is valuable in the bigger picture - at interface declaration/global scope - but at local scope it's implied in the context and if you need help figuring some specific out you can just use IDE (you can't argue "that makes you depend on a IDE" - verbosity like Java makes IDE and code generation a requirement for productivity - this just makes it a nice to have tool)
      - EvanPlaice 11y ago
        This, so much this. I hear Java devs argue in favor of using static types because the type checking and IDE autocomplete lets them write code faster. Dynamically typed languages are great because you don't have to write as much code to provide comparable functionality. The best quality code that's also the easiest to maintain is the code you don't have to write to begin with. I used to contribute to an OSS library for parsing raw network frames into structured protocol data. 50%-60% of the code was type coercion and design pattern boilerplate to work around the type system. I saw similar networking code written in JS and was in awe at how little code it took to accomplish the same. It was easily an order of magnitude less code. Types are good for handling some edge cases. When types are required by default, it just adds a ton of unnecessary noise.
koder2016 11y ago
Two answers to "language ceremony": - smarter humans (keeping a map of type interactions in mind, unit testing type interactions); - smarter computers (local/global inference and static analysis). I bet on computers.
rurban 11y ago
Everything is good and fine, but you cannot have good type inference with dynamic typing and optional static typing. You cannot infer anything about untyped variables, only constants and functions/ops with return types. You can in stricter languages, where the type of a variable is not allowed to change, but in a dynamic languages type inference is limited to explicitly typed variables. You can infer a bit with function signatures and esp. with return types of your internal ops, but everything ends with your normal variable. I also miss the argument that optional static types enable a proper FFI syntax.
- sitkack 11y ago
  Lots of uncited assertions...

43 points by i_feel_great 11y ago

Since that paper, there's been some convergence in this area. Explicitly typed function parameters and inferred local variables now seem to be the way things are going. Go and Rust take that route. It's been retrofitted to C++, with "auto". Python seems to be headed that way, although the proposal is to have type declarations that are not checked for backwards compatibility reasons, which creates its own problems.

simplify 11y ago
I am definitely biased (being the creator and all), but I like the approach JS Zero[1] is taking. Everything is written in a sound, subset of JavaScript, but you can always use an `assume` tag as an escape hatch, allowing you to write "normal" JavaScript when you really need it. For example, if you're reading records from a SQL database, you don't have to bother wrestling with the type system – just tell it what your data looks like! :) let Pet = Object.of({ name: String, happiness: Number }) $assume `fetchPets : (Number) => Promise( Array(Pet) )` function fetchPets (minHappiness) { return db('pets').select('*').where('happiness', '>', minHappiness) }
- knocte 11y ago
  [1]?
  - jmiwhite 11y ago
    See: Assumptions http://js-zero.com/spec/#type-annotation-syntax http://js-zero.com/spec/#type-annotation-syntax
  - simplify 11y ago
    http://js-zero.com/ http://js-zero.com/
moonchrome 11y ago
>there's been some convergence in this area. Explicitly typed function parameters and inferred local variables now seem to be the way things are going. Go and Rust take that route. It's been retrofitted to C++, with "auto". That feeling when even C++ is less verbose than Java ... another "lambda" feature.
- smt88 11y ago
  Verbosity isn't bad in and of itself. It serves as extra documentation, for one thing. Code that is written once is read at least twice, and often many more times than that.
  - moonchrome 11y ago
    Except that's exactly my problem with it - you can get used to shortcuts and the IDE will generate the types so writing the code is not an issue - navigating through this pointless verbosity hurts readability because there's too much noise to filter out - Java verbosity is noise not signal. Just the physical eye movement and scrolling is wasting time and energy on pointless things. Python doesn't have types at all and it reads like pseudocode. This is not arguing against types - having types is valuable in the bigger picture - at interface declaration/global scope - but at local scope it's implied in the context and if you need help figuring some specific out you can just use IDE (you can't argue "that makes you depend on a IDE" - verbosity like Java makes IDE and code generation a requirement for productivity - this just makes it a nice to have tool)
    - EvanPlaice 11y ago
      This, so much this. I hear Java devs argue in favor of using static types because the type checking and IDE autocomplete lets them write code faster. Dynamically typed languages are great because you don't have to write as much code to provide comparable functionality. The best quality code that's also the easiest to maintain is the code you don't have to write to begin with. I used to contribute to an OSS library for parsing raw network frames into structured protocol data. 50%-60% of the code was type coercion and design pattern boilerplate to work around the type system. I saw similar networking code written in JS and was in awe at how little code it took to accomplish the same. It was easily an order of magnitude less code. Types are good for handling some edge cases. When types are required by default, it just adds a ton of unnecessary noise.

koder2016 11y ago

Two answers to "language ceremony": - smarter humans (keeping a map of type interactions in mind, unit testing type interactions); - smarter computers (local/global inference and static analysis). I bet on computers.

rurban 11y ago

Everything is good and fine, but you cannot have good type inference with dynamic typing and optional static typing. You cannot infer anything about untyped variables, only constants and functions/ops with return types. You can in stricter languages, where the type of a variable is not allowed to change, but in a dynamic languages type inference is limited to explicitly typed variables. You can infer a bit with function signatures and esp. with return types of your internal ops, but everything ends with your normal variable. I also miss the argument that optional static types enable a proper FFI syntax.

sitkack 11y ago
Lots of uncited assertions...