Comment by andrewflnr

5 years ago

Types like this mostly aren't about data modeling more complicated than basic sum and product types (SQL only poorly models discriminated sum types, eg ML's data or Rust's enum, which is one of my biggest gripes about it). They're about correctness, making invalid states inexpressible, and the like. Type sums and products (e.g. tuples/structs) really are a nice minimal but expressive system.

That said:

> What language does not provide sufficient abstractions for tables, columns, relations & basic data types?

A key part of the SQL data model is the primary key. I'd really love to see a programming language make PKs or something like them a first-class construct. So if we're looking for something neat to add to PLs that would actually help with business modeling, maybe we could start there?

1 comment

andrewflnr

bob1029 5 years ago

> A key part of the SQL data model is the primary key. I'd really love to see a programming language make PKs or something like them a first-class construct.

This certainly seems like an excellent place to start. Every single one of my domain types starts like:

  public class MySpecialType
  {
    public Guid Id { get; set; } = Guid.NewGuid();
    //...
  }

Having some notion of a first class identity that I could leverage without having to explicitly add a public Id property would be worth looking at.

But, what about the relational aspect? Identity is trivial to solve IMO. How do we canonicalize this idea of relations between types? The way I do this today is:

  public class MyRelatedType
  {
    public Guid Id { get; set; } = Guid.NewGuid();
    public Guid? MySpecialTypeId { get; set; } 
    //...
  }

And then I just tie it all together with LINQ statements as appropriate.

Is there a better way to express this idea with some shiny new language constructs? I feel like I am running out of physical lines of code to golf with here.

The only thing I can think of that is more concise than my above code examples would be SQL.