4 ms·

Articles like this are missing an important point. Namely, that generic data structures in programming languages are used to represent rich semantic data models

Articles like this are missing an important point. Namely, that generic data structures in programming languages are used to represent rich semantic data models. This is done by a process that I would call 'implementing'. It is a mapping of a certain semantic model to, often a rather limited, set of primitives. Some languages, are completely optimized for one type of data structure. Take for example the relational database, in which everything is a relation. During the implementation process some knowledge is lost. What the author is describing is a kind of merge operation. If you would know the semantic meaning of the data that is being represented, it is rather obvious what choice should be made. When a number represent a quantity, it is obvious they should be added, but when a number is a kind of identifier, like an article number, it is obvious that they should not be added. And yes, maybe in that case the number should have been better represented as a string. In the process of implementing it is often smart to represent it like a number, because it is much easier to deal with a 64-bit number than a variable length string.

noelwelsh 7y ago
Your comment in a good example of the very different world views that exist within programming. I'm not trying to bash on your comment, just illustrate the difference and show how this makes communication trickier than we sometimes acknowledge. In a modern typed language you wouldn't represent an ID as an integer or a string, you'd represent it is an ID. Then define addition as whatever makes sense for IDs. This can mean not defining the operation at all, in which case you can't compile code that tries to add IDs. This is the viewpoint that statically typed FP people take, and the viewpoint that languages like Rust take. Your view is more inline with untyped languages or languages with weak type systems like Java or Go. (Arguably Java is changing as it adopts more modern features but I don't think the culture is changing as rapidly as the language.)
- msla 7y ago
  Very few use untyped languages anymore, and only to the extent people program in assembly language or modify Deep Legacy stuff in Bliss. It's possible to lose information in a dynamically-typed language, like Python, but that's a matter of not using the language facilities, such as objects, and if you go down that route, you can write stringly-typed Haskell.
  - noelwelsh 7y ago
    My mistake. I was using "untyped" in the sense it is used in programming language theory, which is the same as the term "dynamically typed" in colloquial programmer speak.
    - msla 7y ago
      And I'm pointing out how useless of a definition that is, because it renders us unable to distinguish between some languages which do have and use type information and other languages which do not. If a language has enough type information to automatically convert a number into a string, it isn't the same as one where everything is simply a machine word. Plus, my comment about stringly-typed Haskell demonstrates that it's a property of programs more than languages anyway.
- fjfaase 7y ago
  I thought I was trying to communicate just the opposite, that during implementation all kind of semantic information is lost. One could define a type as a semantic property, which goes much further than specifying it range of valid values. Think for example about the unit of a double value. I have not seen programming languages where units are an essential part of the language. Several billion dollar disasters could have been prevented if such a language had been used. And this is apart from where a language is statically or dynamically typed. Types can also be viewed as annotations that can be used to verify the correctness of an executable specification (program). One could had a type stating that a function terminates with less than C.n^2 operations of a certain type, where n is one of the parameters of the function. These are often things that are reasoned with at the semantic domain, but are lost when the actual implementation is made. I realize that this requires a different mode of thinking about software engineering than is common among software engineers. I also wonder whether most software engineers could be called engineers, because it looks like it is more a craftsmanship than engineering, like mechanical engineering where they are able to accurately predict the properties of a certain object before it is actually being made with the help of standard methods, such as finite element analyses. I have to admit that we are working in a far more complex domain, but it seems to me that not much progress is made in the field of software engineering. Probably also because technologies are moving too fast to build a solid foundation and that the demand for solutions is too high. I am surprised how few software engineer understand that main problem boils down to the fact that computers are too slow for our demands. See: https://www.iwriteiam.nl/AoP.html https://www.iwriteiam.nl/AoP.html

noelwelsh 7y ago

Your comment in a good example of the very different world views that exist within programming. I'm not trying to bash on your comment, just illustrate the difference and show how this makes communication trickier than we sometimes acknowledge. In a modern typed language you wouldn't represent an ID as an integer or a string, you'd represent it is an ID. Then define addition as whatever makes sense for IDs. This can mean not defining the operation at all, in which case you can't compile code that tries to add IDs. This is the viewpoint that statically typed FP people take, and the viewpoint that languages like Rust take. Your view is more inline with untyped languages or languages with weak type systems like Java or Go. (Arguably Java is changing as it adopts more modern features but I don't think the culture is changing as rapidly as the language.)

msla 7y ago
Very few use untyped languages anymore, and only to the extent people program in assembly language or modify Deep Legacy stuff in Bliss. It's possible to lose information in a dynamically-typed language, like Python, but that's a matter of not using the language facilities, such as objects, and if you go down that route, you can write stringly-typed Haskell.
- noelwelsh 7y ago
  My mistake. I was using "untyped" in the sense it is used in programming language theory, which is the same as the term "dynamically typed" in colloquial programmer speak.
  - msla 7y ago
    And I'm pointing out how useless of a definition that is, because it renders us unable to distinguish between some languages which do have and use type information and other languages which do not. If a language has enough type information to automatically convert a number into a string, it isn't the same as one where everything is simply a machine word. Plus, my comment about stringly-typed Haskell demonstrates that it's a property of programs more than languages anyway.
fjfaase 7y ago
I thought I was trying to communicate just the opposite, that during implementation all kind of semantic information is lost. One could define a type as a semantic property, which goes much further than specifying it range of valid values. Think for example about the unit of a double value. I have not seen programming languages where units are an essential part of the language. Several billion dollar disasters could have been prevented if such a language had been used. And this is apart from where a language is statically or dynamically typed. Types can also be viewed as annotations that can be used to verify the correctness of an executable specification (program). One could had a type stating that a function terminates with less than C.n^2 operations of a certain type, where n is one of the parameters of the function. These are often things that are reasoned with at the semantic domain, but are lost when the actual implementation is made. I realize that this requires a different mode of thinking about software engineering than is common among software engineers. I also wonder whether most software engineers could be called engineers, because it looks like it is more a craftsmanship than engineering, like mechanical engineering where they are able to accurately predict the properties of a certain object before it is actually being made with the help of standard methods, such as finite element analyses. I have to admit that we are working in a far more complex domain, but it seems to me that not much progress is made in the field of software engineering. Probably also because technologies are moving too fast to build a solid foundation and that the demand for solutions is too high. I am surprised how few software engineer understand that main problem boils down to the fact that computers are too slow for our demands. See: https://www.iwriteiam.nl/AoP.html https://www.iwriteiam.nl/AoP.html