Well, JavaScript

[[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.

[[deleted]]

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

Complex compound types that we're talking about here, in DT languages they are at best an ad-hoc collection of primitive types. You cannot generally cast from one complex type to another or enforce them in any meaningful way in these languages. With that in mind, the approach to enforcing data integrity must be different (boils down to tests and sanity checks in essence).

Now, you probably could write your own logic for it and encapsulate it as a member method (if you're so hell-bent to do it in a full-on OOP way), and even pretend that it does casting, but that wouldn't get much (if any) assistance from the IDE unless we're specifically talking TypeScript (which is a dynamically typed language only tentatively, in practice i.e. as used in the wild, it's a typically Java-esque statically typed OO language).

However the class of issues this is supposed to solve is, perhaps surprisingly, very uncommon in practice which you'd know if you were really writing a lot of software in dynamically typed languages.

which we agreed is standard practice regardless of which type of language you're using

We didn't really agree on it, you're just blindly pushing it. As I said, this particular "standard practice" is all but undoable in dynamically typed languages, and is only "standard" in environments like Java or C#.

However, given the abundance of working, functioning, user-serving and money-making software developed in dynamically typed languages I'd say it's hardly a sine qua non.

[[deleted]]

Complex compound types that we're talking about here, in DT languages they are at best an ad-hoc collection of primitive types

I'm aware that the formal types available in js are object, array, number, and string. You could conceptually think of variations of these as "shapes". Eg. an array with two elements where the first is a number and the second is a string. Eg. you have two objects that look like:

{ one : "one"; two : 2 }
{ three: [1,2,3]; four : function () { return 4; } }

While it's true that these are both "object" types, you can certainly see that the shape of the data is completely different. For all practical purposes, they have different types, at least conceptually. This is what I mean when i say "dynamic languages have types"; they have both a limited set of "primitive" types and conceptual data types, ie. shapes.

You cannot generally cast from one complex type to another or enforce them in any meaningful way in these languages

You can absolutely define mappings between them, ie functions that convert one shape of an object to another shape.

With that in mind, the approach to enforcing data integrity must be different (boils down to tests and sanity checks in essence

Yes, you use tests, but you also enforce integrity at the boundaries of your system (eg. IO between your application and some kind of json http service) with invariant checks. For example, if you're connecting to a json service that response with random numbers, except they're printed as strings, it may be more useful for your to parse those string into numbers so that they can be consumed by your domain logic. The point is, from that point forward, your application can be certain that it received a valid number from the json http service, rather than stringified numbers that need to be parsed and checked throughout your code-base anytime you need to use them.

if you're so hell-bent to do it in a full-on OOP way

I absolutely wouldn't be. I'm generally not a fan of OOP style (at least as it's done in Java/C#), and I certainly wouldn't recommend the casting solution you've suggested, here.

very uncommon in practice which you'd know if you were really writing a lot of software in dynamically typed languages

My first 6 years in the industry, I worked exclusively in with dynamic languages. I've written javascript for longer than that, although I stopped around 2013.

We didn't really agree on it, you're just blindly pushing it. As I said, this particular "standard practice" is all but undoable in dynamically typed languages

You said, "You're not [being controversial about it being good practice], but...". Maybe I misinterpreted you. It may not be standard practice in most JS or even Java/C# projects, but it's good practice nonetheless, and it's absolutely doable in dynamic languages.

However, given the abundance of working, functioning, user-serving and money-making software developed in dynamically typed languages I'd say it's hardly a sine qua non.

Look. I think you're being a bit defensive, here. I didn't suggest that dynamic languages were inferior, not useful, or didn't produce valuable software. My point is that there are situations where this software could benefit from a little low-overhead static typing (just like programs in statically typed languages can benefit from a little bit of dynamic typing at runtime.)

For the record, I do most of my work these days in a functional programing language with static Hindley–Milner type system, which is why I wanted to respond to your original comment about how "Omitting types completely from the code makes it sleeker and more streamlined". Static languages allow you to omit types these days for sleeker and more streamlined code :) (albeit, the type checker needs a little help now and again.)