[bradley13]

Um...I think his point is clear? First, you understand your data, and decide how to represent it. Only then can you write code to work with that data.

Poor programmers dive into methods and algorithms, and then try to force their data to match. Which almost never works.

[SoftTalker]

Pretty much. A manager early in my career would say “get the data model right and the code will write itself” and I’ve found that to be mostly true.

[_a_a_a_]

It wasn't clear. If he meant data structures then say data structures. If he meant something different or broader by 'data model' then I don't know what that was.

I value plain, simple code and equally plain, simple writing. I am becoming dismayed at the trend towards fancy labels on basic things. A while back someone talked about 'affordances' in C# which sent me into a tailspin because I thought there was some significant area of the language I'd never encountered. Turns out he just meant attributes and methods.

[pessimizer]

"Data model" isn't a confusing term, and "data modeller" is a profession. They work on data models.

[SuperCuber]

"modeling your data" is terminology that I encountered before, not sure why you find it unusual /shrug

[_a_a_a_]

@pessimizer, @SuperCuber - So educate me. Let's base it on something I've actually done, a code analyser. For this you parse the code into an AST, and to deal with lexical scopes of declarations of procedures/variables etc. you have a stack of symbol tables.

So we've got a tree (the AST), we've got a symbol table for the current scope (a hash table of <id, info> pairs), and we have a stack of symbol tables (a stack).

A tree, a hash table and a stack. Those are data structures. What more needs to be added to this definition to turn it from "data structures" into a "data model"?

Firstly this is a serious question, secondly I have a great deal of experience of defining data structures to solve problems, so I can't see what adding an abstract term is doing.

You could say that the extra something is the specification/maintenance of the correct interrelationship between those data structures (and I'd agree), and there's a word for that: it's called 'code'. I genuinely don't understand what you're getting at and I'd genuinely like to know.

[_a_a_a_]

And no answer :-( It does rather defeat the point of discussion here if people say things they won't back up. I don't know if I've changed your mind, you certainly haven't given me any reason to change mine, so why post?

[SuperCuber]

Unfortunately HN doesn't notify of replies need to go digging for then in "threads"

I'll give you an example from a ongoing side project of mine: https://github.com/SuperCuber/facto_rs/blob/master/src/model...

Hopefully the Rust syntax is not too much of a distraction here, but enough to focus on the `struct` and `enum` parts (an enum in rust can be "one of" the variants, like tagged union or sum type in other languages, or | operator in typescript). The project is a live wallpaper/screensaver that is a simulation of something like a combination of the games Factorio and Mini Metro.

I had in mind what I wanted to happen - a grid containing a rail network with trains running between different nodes.

What I call the model is the representation of the things in the code: I could store the train's position in terms of [float,float] and a facing Direction, but instead I choose to store it in terms of List<[int, int]> of grid tiles that it plans to go through, then an int for its current position in the list, and then a single float between 0 and 1 representing how far into the tile it's moving.

The two possible solutions have pros and cons, and there are other solutions as well that are equally valid I'm sure. In my mind, the process of "modeling your domain/problem space" is about deliberately thinking about these things and choosing what you think is the best.

[_a_a_a_]

I completely, fully get what you're saying and I've done this trade off between various data structures for a very long time, but my question wasn't about that, but the difference between data structures and data models. Put simply, it was a question of terminology used rather than technique applied.