
Static Typing Where Possible, Dynamic Typing When Needed  (2011) [pdf] - i_feel_great
https://www.ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04meijer.pdf
======
Animats
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.

~~~
moonchrome
>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
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
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
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.

~~~
moonchrome
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.

------
rurban
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
Lots of uncited assertions...

