4 ms·

Ask HN: Why not static and dynamic typing?

• xtagon 8y ago
  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 8y ago
    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 8y ago
  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.
• gus_massa 8y ago
  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.