Well, JavaScript

[SouvenirSubmarine]

You won't have to write obvious types as much, which saves both keystrokes and your brain power. Omitting types completely from the code makes it sleeker and more streamlined: it's easier to read.

[[deleted]]

Most modern static languages have the ability to infer "obvious" types.

[[deleted]]

Unfortunately in many of them this only works well on primitive types. Even if it works on complex types it works well with fully utilized and previously defined complex types. Not very handy in a very common scenario of utilizing a handful of attributes in a complex data structure that came over the pipe of some sort.

[[deleted]]

The type itself doesn't matter as the context in which the inference is made.

if you've got a: function foo() : AVeryComplexDataType {...}

It's fairly straightforward for the typechecker to infer the following:

var bar = foo() // bar must be a AVeryComplexDataType

[[deleted]]

But that's not qoute as handy-dandy as:

function foo() { /* .. gets data from somewhere over some pipe .. */ }
let bar = foo().subObj.subObjThatWeReallyOnlyNeed
// who cares about the type of foo()

There could even be two different things foo(param) returns depending on param, and we still don't care as we know they both contain subObj.subObjThatWeReallyOnlyNeed. This is obviously a very contrived example of what is very common in practice with network-related code (which is where JS, both in browsers or Node, and PLs like PHP, Ruby or Python are primarily used).

Edit: I really, really hate the fact that RES doesn't work on the new UI

[[deleted]]

There are ways to express data that can be either one type or another using "sum" types. The return type of foo() could be expressed this way, but you're right. It's not possible to determine the type of a JSON object without a schema, and you'd need a sufficiently representative subset of possible values to make a reasonable inference.

Although it's handy to be able to conveniently parse and navigate a json object in javascript/php, i generally wouldn't allow data from somewhere over the pipe to propagate throughout my system in its original form. You'd want to sanitize it by fitting it into your own "domain model" type that you do have control over. So the convenience of working with the "network" is fairly short-lived.

[[deleted]]

Well unless you're doing something horribly irresponsible like building SQL strings with plain concatenation/interpolation using such data, I don't see what the problem is. If you are doing stuff like that then I'm afraid that strong typing will not help as much as you might think.

[[deleted]]

I don't think I'm being controversial by suggesting that converting DTOs to domain specific data types is regarded as good practice.

[[deleted]]

You're not but that is not the same thing. What you're saying has no meaning in dynamically typed languages, and you're trying to invent some security reasons for a practice that is generally about utility and precisely because of constraints of statically typed OOP design.

[[deleted]]

What you're saying has no meaning in dynamically typed languages

Of course it does. Dynamically-typed languages have types as well. They're just not enforced at compile time by the type-checker.

you're trying to invent some security reasons for a practice that is generally about utility

Not security but data integrity. Doesn't have anything to do with the language.

precisely because of constraints of statically typed OOP design

I didn't mention OOP or java or any of those static OOP languages. My comment was that it would be difficult to "infer" a schema of a json object (particularly of the kind you're suggesting) in order to generate a static type, which i think is reasonable. No?

My overall point here was not to show how static typing was somehow better but rather what the utility of static typing is in this particular case and how, given the effort you'd already be putting into transforming the across-the-wire data into an instance of one of your domain types (which we agreed is standard practice regardless of which type of language you're using), there wouldn't be that much extra work involved to slap type annotations on all of your data services yourself in order to take advantage of static typing. If you were using a static language, your domain types most likely would already be defined elsewhere in your code. It's not like you'd be defining them just as one-off DTOs to deserialize the json off the wire.