
Ask HN: Why not static and dynamic typing? - elamje
As I have been exploring languages lately, it seems that a lot of drawbacks for amazing languages come down to the being dynamically or statically typed.<p>I’m not very knowledgeable about compilers and language design, so I wonder: Why can’t a mainstream language be designed to let the programmer choose which?<p>That is, what low level limitation prevents language designers from giving the programmers choice here?
======
gus_massa
I think that Racket vs Typed Racked is a good example. [https://docs.racket-
lang.org/ts-guide/](https://docs.racket-lang.org/ts-guide/)

Ideally, you can pick a program in Racket that doesn't specify any type, add
annotations for the types of the arguments of functions and the temporal
variables, and the compiler will infer the missing parts and ensure that there
are not errors in the types. In some programs the compiler need some help,
with a few additional annotations.

You can use the type "Any" that means "whatever", but then you must check that
the variable has the type that is necessary before using it.

------
xtagon
I don't think there is an underlying principle of compilers and language
design that strictly prevents that. Implementing a static type checker seems
like more work on the language designer, but from the end user (programmer)'s
perspective, usually it comes down to preference and it doesn't seem that
useful for the preference to be "both". If you're willing to specify types,
then you get compile time checking benefits. If that's not worth the extra
keystrokes, you might lean toward dynamic languages.

Now, that said, there actually might be something close to what you're talking
about. For one, many languages with static typing have very good type
inference, so you don't always have to write the types in your code if the
compiler can figure it out (infer it). Crystal is one of these languages (just
off the top of my head).

And among dynamically typed languages, some have static type checkers that can
be used on top of the language, optionally. So that does give you a choice.
For example, in Elixir and Erlang you can use Dialyzer to add static type
analysis.

Then still you have some languages that add static typing (and possibly other
benefits) on top of a base language by transpiling. TypeScript/Javascript are
a good example.

What would be the benefit of creating a language where static type analysis
was available, but not enforced? In my opinion, the benfit would be minimal,
because static typing works best if it's enforced -- the point is to catch
mistakes. If it's optional, how do you catch those mistakes?

~~~
elamje
Nice response. I appreciate it. I could see the case where an entire
program/project would want to be statically type checked, but when you are
running a repl or something quick you don’t want to have to specify types.

At the repl you want speed and flexibility, on a project level you might want
type checking. I don’t know if this already exists, but it seems somewhat
useful. I guess the solution is, as you said, to have a third party analyze
your code for types

------
_bxg1
Flow is a static type checker for JavaScript, and flow-runtime is a separate
project that turns your static types into runtime assertions. You can even
enable this on a file by file basis. We use this at my job to statically type
all of our front-end code, and then check API responses (the bane of static
type systems: external data) against those same types at runtime. It works
really well.

