handmade.network » Forums » The need for dynamic typing
robhickman
Robert Hickman
5 posts
#17131 The need for dynamic typing
2 weeks ago Edited by Robert Hickman on Jan. 5, 2019, 6:51 p.m. Reason: Initial post

Within a closed system, where the author/team defines the nature of the entire system, including any network protocols, static typing works well as the code of the whole system can easily reference the same struct/enum definitions for instance. However with communication between unrelated systems over a network I believe that this model fails, as the data in this model does not include a definition of it's type. It isn't self describing as the meaning of the data is left in the source file.

In my opinion, having self describing data is better in a general case, as one does not need to understand the content of some data to write a parser. While they do have problems, JSON and XML are examples. They allow one to read data from a provider (website or whatever) and parse it without having to write a parser for every single API one may want to use.

If using such a system, the types are only known when the data is received, and is thus only known at run-time. Implementing this statically would entail duplicate state (the type definitions), which could be onerous to keep updated. You could conceivably have a description of the types provided by an API which gets compiled to type definitions for a given language, but it still seems needlessly complicated to me, vs just supporting dynamic typing.

In my opinion, both static and dynamic typing are useful tools, and languages should have support for both. I tend to agree with the 'less abstractions' point of view held by this community, but I don't think this excludes the possibility of a implementation-documented dynamic type system, with language syntax. I also don't believe this to be fundamentally incompatible with a data-oriented approach.
ratchetfreak
427 posts
#17132 The need for dynamic typing
2 weeks ago

For the parser itself having a dynamic layer isn't the worst idea.

however you will end up mapping those dynamic types back to static ones soon enough
robhickman
Robert Hickman
5 posts
#17192 The need for dynamic typing
1 week, 1 day ago

I'm more talking about the ability to flow type information through a system at run-time. While you may map this to static types for processing, a system should also be able to carry data through it without caring what that data is. Void* doesn't carry type information, something like a struct{int type, void* value} is implementing a rudimentary dynamic type system and I have no desire to deal with that*. C style unions have the problem noted above in that they are only known to the implementation language.

I primarily work in dynamic languages but find many of the ideas given in handmade hero and john's talks interesting. I can see instances where applying these things would be useful, but have no interest in switching fully to something like C++, due to the above. I also feel that foreign function API's are needlessly verbose in many cases. Maybe JAI will provide some sane means of carrying type data at run-time, it certainly has a lot of interesting ideas.

* Having no standard for dealing with this at a language level is a problem as it means that every system rolls it's own, and by that nature cannot easily interact with other systems by other developers in the same language.
notnullnotvoid
Miles
20 posts / 1 project
#17194 The need for dynamic typing
1 week, 1 day ago

The argument that fully dynamic types are useful at a language level seems intuitively plausible on its surface, but for all the hundreds of times I've heard it stated, I have yet to hear any specific examples of a case where it's especially useful.

For example with JSON and XML APIs, sure, you can parse them into some kind of generic data structure in memory, but you still need to know how the data is laid out within that structure to do anything really useful with it. So it's not a fundamentally different situation from receiving binary data, you're just adding an extra step in the middle.

Maybe you could make the argument that plaintext APIs are "self-documenting" because you can read their results in a text editor, but from experience I haven't found this to be true. In practice, you still end up having to read the documentation to be sure you know what you're doing. And even then, textual vs. binary interfaces is quite orthogonal to the question of static vs dynamic types, except to the extent that some dynamically typed languages happen to have syntax-level support for certain formats like JSON, as opposed to just library-level support. I see this language-level support as a convience to be sure, but one that's not nearly worth all the drawbacks of a dynamically typed language.