
What is the appeal of dynamically-typed languages? - luu
https://gist.github.com/non/ec48b0a7343db8291b92
======
ggchappell
There are some good points here, but this essay falls into the same trap that
so many let's-compare-type-systems discussions hit: assuming that _static
typing_ means Java-style static typing.

Yes, the mostly-manifest, nominal-oriented type systems of PLs like Java and
C++ can be wearying, and something like Python feels like a breath of fresh
air in comparison. However, a more inferred/structural approach _is_ possible
in a statically typed PL, as Haskell demonstrates so well.

Like Python, Haskell does not require you do "assert that x is a Collator"
before doing some collation. It tends not to lead to complex hierarchies. And
its standard containers are versatile and well supported.

The point here is that most of the issues discussed are not really issues with
static vs. dynamic typing. They have rather more to do with manifest/nominal
vs. inferred/structural typing, along with how much attention the PL designers
gave to minimizing overhead & boilerplate.

The essay I really want to read is "Why I Prefer Python to Haskell" \--
particularly if it is written by someone who actually _gets_ Haskell.

~~~
kazinator
Haskell provides functions like zip, zip2 and zip3 where an ordinary language
just gives you a single zip that works with any number of arguments.

That's the kind of thing you do in C. For instance Unix: dup, dup2. (Linux
adds dup3!)

That doesn't pass the "smell test", relative to all the claims about how
Haskell and its ilk are the most amazing thing since sliced bread.

~~~
codygman
Polyvariadic functions are possible in Haskell:

[http://okmij.org/ftp/Haskell/polyvariadic.html#polyvar-
fn](http://okmij.org/ftp/Haskell/polyvariadic.html#polyvar-fn)

~~~
kazinator
While this establishes existence, it seems way too cumbersome for production
use. Both creating a variadic function _and_ calling it require awkward
boiler-plate, like the verbose and cryptic signature on use_build.

------
mpdehaan2
Got to this:

"In an interesting way, it keeps you from going all-in on object-oriented
programming. You only want to create a class when a casual API user will
understand how it works and what they would use it for. "

Completely disagree. Python doesn't discourage OO at all. I think the author
has a particular programming style with Python that does not line up with the
way many people I know use it, and this may give the wrong impressions. Yes,
you can just pass around tuples, but ... don't do this :) It has quite
workable classes.

So, answering the question? What's the advantage? Dynamic language does
require, to a degree, a small amount more tests. However, type errors are also
a class of error that is very very infrequently encountered as to a problem.

I'd say that duck typing principly allowers easier mock interfaces and ability
to more easily write generic-type functions, and for unrelated reasons, such
languages have a very quick code-test loop. But their efficiency in this isn't
so much to do with typing. It's mostly the speed of this loop, stemming from a
lack of compilation, that helps. Those are not really related, but that's why
people like dynamic languages.

They have also been historically more expressive, and saved typing things, for
when type errors aren't really common (for me, they aren't), always specifying
types doesn't always help. But to be honest, I don't mind it and it's nice to
have as documentation most of the time.

I do mind compilation cycles.

The article also seems to err in that it assumes there can't be debuggers
available for typed languages, where it says "you can't see inside the
process".

The argument that people like dynamic systems because they build programs out
of trial and error seems erroneous in all. I build my programs out of tests.
This can still happen just the same and has nothing to do with a type system.

~~~
dllthomas
_" However, type errors are also a class of error that is very very
infrequently encountered as to a problem."_

As someone working every day in Python, this seems mind-bogglingly divorced
from reality.

I don't know if you mean something far more restricted by "type error" but
most of the errors I encounter - in my code, the code of my team, and the code
of those on other teams, across several projects - are errors that would have
been caught by the type checker in Haskell had I been writing similar code.
Many of them would have been caught by the type checker in C.

~~~
mpdehaan2
Hmm, that's curious, though I don't think it's ever a good idea to tell
someone they are divorced by reality :)

I think some types of developers are more likely to make type error mistakes,
and it's likely I make _other_ mistakes, sure. I've done a wide about of
massively-open source projects, and it doesn't really come up. The times I
pass the wrong object type simply doesn't happen.

Do you use keyword arguments? These help a TON with argument order, and may be
why you are having that problem.

~~~
dgreensp
When I write code and tests in JavaScript, typically the tests turn up a few
typos and "brain-os" in the code (that don't keep it from parsing). Many or
most of these would be caught by the type-checker in statically-typed
language.

Maybe you don't "see" type errors because you consider them to be failures of
test coverage, or you say, "That's not a bug, it's more of a typo?" Or you
don't work on a shared codebase?

~~~
mpdehaan2
Neither. I don't make them often, and I do work in quite shared codebases -
one of them had over 1000 contributors. I won't pretend I'm a better
developer, I surely make other classes of mistakes, usually it's "I didn't
consider the user scenario where this file didn't exist or the error path when
this file has invalid contents should really raise a better exception than a
generic stacktrace".

~~~
dllthomas
A static type checker could be of some help in both of those cases, if you use
it well.

