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.
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.
Edited by Robert Hickman
on
Reason: Initial post
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
however you will end up mapping those dynamic types back to static ones soon enough
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.
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.
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.
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.
Another thought I had about this is databases. An SQL database for instance is essentially dynamically typed, given that you can change the type of a column with ALTER TABLE. It is a more specified form of dynamic typing, yet it is still dynamic.
There is type information in the database, yet in static languages there is no straightforward way to make use of this information for checking in the program. The type system has no knowledge of anything external to it, and in my opinion that is a problem.
Dealing with this often entails manually duplicating the schema of the database within the application. In my opinion it would be better if a type system was able to 'reach out' and get this kind of external data by itself, and JAI's compile-time meta-programming may well be able to do that.
There is type information in the database, yet in static languages there is no straightforward way to make use of this information for checking in the program. The type system has no knowledge of anything external to it, and in my opinion that is a problem.
Dealing with this often entails manually duplicating the schema of the database within the application. In my opinion it would be better if a type system was able to 'reach out' and get this kind of external data by itself, and JAI's compile-time meta-programming may well be able to do that.
@notnullnotvoid
Not ignoring you, and I agree with your points in principle but it took some time to think of a reply. What I'm talking about is a middle ground. I see no technical reason why a language can't offer such syntactic niceties in addition to static type checking. Both static and dynamic typing have applications and they can co-exist.
What the generic structure does is allow a system to parse some data without needing to duplicate the state (type data) of it's structure in every application which may want to read it. Sure you may want to map some part of it to native types. I think that the need to read documentation is more a failing of the design of the data format. It's a misalignment between the available types the represented data, such as needing to represent a date as a string, due to a lack of a 'date' type.
To a large extent what I'm taking about is the ability to treat types as first class data, and the title of the thread is probably misleading. In my opinion, a type system should allow types to be generated by code at compile time. If I already have types defined in a database, the program should be able to generate the equivalent structures in a languages type system without needing to manually duplicate this state. The only way to do that with C/++ is to have some other program generate that data and dump it into a header file. In my opinion needless complexity and error prone.
Not ignoring you, and I agree with your points in principle but it took some time to think of a reply. What I'm talking about is a middle ground. I see no technical reason why a language can't offer such syntactic niceties in addition to static type checking. Both static and dynamic typing have applications and they can co-exist.
What the generic structure does is allow a system to parse some data without needing to duplicate the state (type data) of it's structure in every application which may want to read it. Sure you may want to map some part of it to native types. I think that the need to read documentation is more a failing of the design of the data format. It's a misalignment between the available types the represented data, such as needing to represent a date as a string, due to a lack of a 'date' type.
To a large extent what I'm taking about is the ability to treat types as first class data, and the title of the thread is probably misleading. In my opinion, a type system should allow types to be generated by code at compile time. If I already have types defined in a database, the program should be able to generate the equivalent structures in a languages type system without needing to manually duplicate this state. The only way to do that with C/++ is to have some other program generate that data and dump it into a header file. In my opinion needless complexity and error prone.
Edited by Robert Hickman
on