[Kuinox]

It's been a while i'm thinking about one:

A Relational General Purpose Language.

Not table oriented like SQL, but more OOP/Type oriented, I'm not sure exactly how I want it to be, but surely not table oriented.

No concurrency or async to worry about, you write the relations (exactly like you dont worry about SQL on concurrency while writing an SQL query).

Like a JIT/DB Engine, it has a runtime that analyze the data processed, and optimize further the queries. I believe it even could dynamically figure out of embarrassingly parallel problems and sent it to process on the GPU.

But all of this require a lot of work ^^'.

[pjerem]

Isn't that LINQ ?

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

[Kuinox]

I'm a C# dev, I know well LINQ.

LINQ has multiples issues compared to what I want to do.

It's slow (at leat 1000x slower than a for loop)

There is no query optimizer by default, and even less a runtime query optimiser.

It's directly translated to procedural code, it doesn't get compiled and translated like a query engine will do in an SQL DB.

[pjerem]

I’m far from a C# expert, I just happen to write some at work but that’s not my predilection language so you probably know better than me but, implementation appart, as a querying language, it feels pretty good.

Also, I understood that it was translated to IEnumerable queries, so, wouldn’t EF optimize the query ?

[Kuinox]

EF translate will translate your LINQ into SQL. I'm speaking about LINQ that you may write anywhere, not on a DB call in particular, there EF is not the right tool, there may be some things thats may make LINQ faster, but it's nowhere as good (it cant do much as most of the queries are little isolated queries) as a DB engine.

[stickfigure]

Not being familiar with LINQ, does it solve SQL's composability problems?

I love SQL for what it can do, but I am constantly annoyed at how inconsistent it is and how terrible it is for generating queries via software. It feels ripe for a replacement that is semantically similar but syntactically different.

[Kuinox]

LINQ is a library & C# language syntax that call this library thats allow to write SQLish like query on your C# objects.

[stickfigure]

I'm familiar with what it does (conceptually), but what I want to know is: Is it composable? Eg if I have a query and I want to add an additional filter to it, or I have a select that I want to turn into an update, is it straightforward? SQL syntax tends to make this kind of query generation difficult (though obviously not impossible).

[Kuinox]

The query is composable, not the object it process (it's still a C# object). A LINQ method return an IEnemurable(this interface allow simply to read the object one per one.)

You can add filters, groups, order, as much as you want, because each will return an IEnumerable (some methods return a child interface, like Order, which return an IOrderedEnumerable).

Then, you consume this this enumerable, most of the time with a foreach (procedural, or LINQ style, and will consume the enumerable), where you can update the values.

In the end, it's still C#: you can add side effects, where you want, even in the select, even if you shouldn't.

Most of the times, "when it tends to make this kind of query difficult" you can just consume your query with a foreach, and do the rest with the procedural style.

[dragonwriter]

D (the Date And Darwen one, not the Walter Bright one)?

https://en.m.wikipedia.org/wiki/D_(data_language_specificati...

[Kuinox]

Thanks, I didn't knew about D (I did little to no research on other languages yet).

I will read it, but mind that, I said "general purpose" I don't want this to be a language used to be only used as a Database. The whole app should be written in it.

[dragonwriter]

> I will read it, but mind that, I said "general purpose" I don't want this to be a language used to be only used as a Database.

A major point of D is to eliminate the object-relational impedance mismatch and the app language/SQL boundary by providing one language for app and database that is truly relational.

That said, I think most of the implementations (other than as libraries for existing languages, which is kind of a different thing) have ecosystem problems from not being popular, so even if they are “general purpose” languages, there's probably a heavy loft for lots of common tasks compared to languages with richer ecosystems.

[Kuinox]

Yeah, it still looks too much like SQL to me.

My idea is to make procedural looking code, but is relational all the way. I believe it's possible and would limit the issue a lot of people has with SQL/relational.