3 ms·

If real world API is as chaotic as he mentioned, how can he even know the data is trustable? From his Java's example, I can't see how he can fix with dynamic l

If real world API is as chaotic as he mentioned, how can he even know the data is trustable? From his Java's example, I can't see how he can fix with dynamic language. He still needs to validate the API response and throw exception even he uses dynamic language. Unless he uses something like functional "Maybe", so he can safely process the response.

bunderbunder 8y ago
I think the crux of the issue is that the way formats like JSON and XML are typically handled in Java forces you to validate more than you need to, earlier than you need to. It makes it very difficult to comply with Postel's Law.
- klmr 8y ago
  > It makes it very difficult to comply with Postel's Law. Not really, since “handling” doesn’t mean “throw errors”. But regardless, Postel’s Law is often seen as a failure in hindsight. See the “Criticism” section on its Wikipedia page. In general you don’t want to comply with Postel’s Law.
  - bunderbunder 8y ago
    Handling shouldn't mean "throw errors". But the whole process of creating Beans or immutable POJOs and then decorating them with annotations seems to invariably lead you down a path where, if you're dealing with a particularly hoary API, you've either got to create a ridiculous number of single-use DTOs to handle all the edge cases, or define a manageable number of DTOs that unfortunately also place more stringent requirements on the input data than are strictly necessary.
    - klmr 8y ago
      Well Java is just an incredibly bad poster child for static typing. But even in Java you can do better by using modern sum types. Defining a “ridiculous number of single-use DTOs” isn’t actually a problem in languages that support this well (e.g. by allowing you to create anonymous tuples). But as you’ve said yourself: this only applies to “pretty hoary APIs”. Why not take the opportunity to create a better API (through a wrapper, if you have no control over the original API)?

bunderbunder 8y ago

I think the crux of the issue is that the way formats like JSON and XML are typically handled in Java forces you to validate more than you need to, earlier than you need to. It makes it very difficult to comply with Postel's Law.

klmr 8y ago
> It makes it very difficult to comply with Postel's Law. Not really, since “handling” doesn’t mean “throw errors”. But regardless, Postel’s Law is often seen as a failure in hindsight. See the “Criticism” section on its Wikipedia page. In general you don’t want to comply with Postel’s Law.
- bunderbunder 8y ago
  Handling shouldn't mean "throw errors". But the whole process of creating Beans or immutable POJOs and then decorating them with annotations seems to invariably lead you down a path where, if you're dealing with a particularly hoary API, you've either got to create a ridiculous number of single-use DTOs to handle all the edge cases, or define a manageable number of DTOs that unfortunately also place more stringent requirements on the input data than are strictly necessary.
  - klmr 8y ago
    Well Java is just an incredibly bad poster child for static typing. But even in Java you can do better by using modern sum types. Defining a “ridiculous number of single-use DTOs” isn’t actually a problem in languages that support this well (e.g. by allowing you to create anonymous tuples). But as you’ve said yourself: this only applies to “pretty hoary APIs”. Why not take the opportunity to create a better API (through a wrapper, if you have no control over the original API)?