DAX syntactic sugar to increase the DAX language expressivity

It took me days to finally figure out how to implement a simple algo in DAX that would have taken me less than 5 minutes to do in C or Python!

This is utterly ridiculous! So the idea is this:

Redesign the DAX syntax to make it more expressive. Note I didn't write redesign the grammar. But you could gives us some syntactic sugar to make certain computations on tables and rows more explicit.

The problem is that there is too much that is kept implicit by the DAX syntax, ie not being expressive enough to make the underlying computation flow crystal clear and as a result newcomers like me get lost in a labyrinth of confusion as to which of the multiple computational pathways to take to achieve the simplest results.

Here is a concrete example from the past few days: I had to implement a solution that could filter data not only by a date range, but also by a continuous time range within that date interval specified by a date slicer. In other words, after the date slicer specified FROM start_date TO end_date, I needed that the data table to show data starting from the start_date and start_time within that start_date all the way to the end_date and end_time within that end_date, rolling over at midnight for each day in the date interval and thus including all the time points between the start_time and end_time ACROSS all the days in the date interval AND NOT just showing the same intraday time range for each day in the date interval, which is the default slicer behavior.

To illustrate:

FROM: 12-01-2020 14:15 TO: 12-03-2020 03:30 (so 2:15 PM to 3:30 AM)
should return the following series (assuming 1 data point per hour at any minute):

12-01-2020 14:32 data
12-01-2020 15:17 data
12-01-2020 16:43 data
and so on until
12-01-2020 23:56 data

then rollover to the next day

12-02-2020 00:09 data
12-02-2020 01:23 data
...
12-02-2020 21:12 data
12-02-2020 22:30 data
12-02-2020 23:55 data

then again rollover to the next day

12-03-2020 00:15 data
12-03-2020 01:25 data
12-03-2020 02:41 data
12-03-2020 03:11 data

and done!

Isn't it mindboggling that something this simple should take a novice user hours if not days of searching through various DAX sites and books to get a grasp how DAX works with the underlying Tabular model to generate a result set?

In any procedural or OOP language with the relevant API this sort of algo would be a no-brainer to implement in less than 5 mins. And that, my friends, is a testament to poor DAX language design.