4 ms·

Awesome write up. While I agree that dynamically typed languages -- by their loosely defined API requirements -- are more difficult to scale, it's not difficul

Awesome write up. While I agree that dynamically typed languages -- by their loosely defined API requirements -- are more difficult to scale, it's not difficult to add type checking and/or provide a well structured public API where necessary. I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code. I think there's a 'happy medium' to be found where type checks are required for certain inputs and a clearly defined API can be established without the need for private/internal/public syntax artifacts. I've been playing with this a bit in JS lately. Using model definitions to specify the structure and enforce validation. As well as defining facades with the ES6 module import/export syntax to define public APIs. Finer grained control (ie private vs internal) can be defined using closures that provide internal interactions while hiding the private implementation details.

naasking 11y ago
> I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code. Given this description of statically typed languages, I'm guessing you haven't tried OCaml or Haskell.
- EvanPlaice 11y ago
  I was specifically referring to statically typed OOP. You're right, I haven't tried OCaml or Haskell so I can't make a qualitative judgement on how easy/hard type coercion is in either.
  - pka 11y ago
    The need for type coercion is a very good indicator of a bad design. Haskell just forces you to deal with it right now instead of never.
- chriswarbo 11y ago
  Whilst I've found Hindley-Milner systems much nicer to use than, e.g. Java, they can still require boilerplate and "creative" workaround which wouldn't be necessary in dynamically typed languages. For example, I've recently been struggling with a Haskell library that makes heavy use of `TypeRep` values, which is fine when everything's done in a single process invocation, but very awkward when attempting to serialise/deserialise (e.g. to pass data between processes, or to suspend a computation and resume it later)

naasking 11y ago

> I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code. Given this description of statically typed languages, I'm guessing you haven't tried OCaml or Haskell.

EvanPlaice 11y ago
I was specifically referring to statically typed OOP. You're right, I haven't tried OCaml or Haskell so I can't make a qualitative judgement on how easy/hard type coercion is in either.
- pka 11y ago
  The need for type coercion is a very good indicator of a bad design. Haskell just forces you to deal with it right now instead of never.
chriswarbo 11y ago
Whilst I've found Hindley-Milner systems much nicer to use than, e.g. Java, they can still require boilerplate and "creative" workaround which wouldn't be necessary in dynamically typed languages. For example, I've recently been struggling with a Haskell library that makes heavy use of `TypeRep` values, which is fine when everything's done in a single process invocation, but very awkward when attempting to serialise/deserialise (e.g. to pass data between processes, or to suspend a computation and resume it later)