← Back to context

Comment by bob1029

5 years ago

I feel like we don't really need highly-evolved type systems for practical problem solving. On the contrary, I have found that the plethora of available ways in which to model a problem domain can cause more harm than if a more constrained set of tools were made available.

What problem domain is so complex that it cannot at least be modeled in SQL (or Excel)? What language does not provide sufficient abstractions for tables, columns, relations & basic data types? Why would you want to take a clean domain model that the business agrees upon and then start perverting it with things like polymorphism? Performance is often something thrown around as an excuse to de-normalize schemas, but typically when I ask someone to actually measure it we find that LINQ/SQL/etc is more than fast enough to get the job done for all practical intents & purposes.

2 comments

bob1029

Reply
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?

  • 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.