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.
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)
}
>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.
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.
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)
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.
I don't agree with that either. I have written a decent chunk of production python code last year (eg. just one module has over >10k lines) because the tools required it and I can't say I'm too pleased with how it scales to complex APIs (eg. manipulating blender scene graph). Java would undoubtedly be much worse but Java is not the only statically typed language, or should we discard all dynamically typed languages because of PHP and Perl.
If it's not a script task or glue code I prefer static typing.
Java is just a very bad implementation of static typing, it's intentionally dumbed down and limited so that you don't need to learn a lot to understand code - and this results in weak type guarantees, bloated and tedious code base and silly patterns to work arround language limitations.
C# is a much better example of a productive statically typed language in the same family, F# is even better - those are just the ones I have experience with. I would have much rather done that blender project in F# over Python if I could (sadly only python API available)
Besides even dynamic language authors are seeing value in providing static typing with the recent trend of optional/gradual typing for most dynamic languages.
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.
