Comment by RobinL
4 days ago
I would argue that's about how the data is stored. What I'm trying to express is the idea of the programming language itself supporting high level tabular abstractions/transformations such as grouping, aggregation, joins and so on.
Implementing all of those things is an order of magnitude more complex than any other first class primitive datatype in most languages, and there's no obvious "one right way" to do it that would fit everyones use cases - seems like libraries and standalone databases are the way to do it, and that's what we do now.
Sounds a lot like LINQ in .NET (which is usually compatible with ORMs actually querying tables).
Map/filter/reduce are idiomatic Java/Kotlin/Scala.
SELECT thing1, thing2 FROM things WHERE thing2 != 2;
val thingMap = things.map { it.thing2 to it.thing2 }.filter { it.thing2 !=2 }
Then you've got distinct(), sorting methods, take/drop for limits, count/sumOf/average/minOf/maxOf.
There are set operations, so you can do unions and differences, check for presence, etc.
Joins are the hard part, but map() and some lambda work can pull it off.
Yeah, that's LINQ+EF. People have hated ORMs for so long (with some justification) that perhaps they've forgotten what the use case is.
(and yes there's special language support for LINQ so it counts as "part of the language" rather than "a library")
Ah, that makes more sense. Thanks for the clarification.