Forum Discussion
Calculated column analysis
Except that if you read the very next post Anonymous , I didn't have to hard code anything. There is literally a single function in as in 1 function, uno Función, one function that does exactly what isThisABug is trying to do. So how does a having a single function that is explicitly designed to do exactly the job that is trying to be done constitute a square peg? This is like calling a hammer a "square peg" for the job of pounding a nail. The CONCATENATEX function was literally designed to do the exact job at hand. It wasn't an accident that there are parameters for sorting. It isn't just a novel use of something that wasn't designed for purpose. There is literally no other reason that sorting functionality would have been included in CONCATENATEX other than to solve this problem. So, calling it a square peg is nonsense. It's absolute nonsense.
Plus, the original ask was "how to use DAX table expressions to improve the code". I may be mis-reading things but I don't believe it said "Hey, please chastise me".
Are there advantages and disadvantages to both approaches. Yes. But calling DAX a square peg when it has a function that has been specifically engineered, and I mean purpose built, to accomplish the task at hand is just being...well...I'll just leave it there.
And what do dataflows have to do with anything and data mashup. Yeeesss, of course Microsoft would use M code for data flows because it's literally the same operation as importing data... So... Surely a simple calculated column using a function purpose built for the task is not data mashup? At least not in the same vein as true data mashup.
And BTW this is an unwinnable argument. There is nothing that is possible today in Python or R or Ruby or any other trendy programming language that couldn't be done in any earlier programming language like C or Java or for that matter COBOL or Fortran. It all reduces to 1's and 0's eventually but shockingly people still use the language they feel like using in the end. I could just as easily make an argument that everyone that uses Power Query instead of EMML is crazy but it would all just be pontification and hot air because nobody really cares as long as they can get the job done. I mean Power Query...really? It doesn't even have mashup design portability and interoperability of mashup solutions. What kind of noob would use such a thing? What a terrible tool for the job! I mean Power Query is laughably inferior! There's no embedded scripting support for JavaScript, JRuby, Groovy or XQuery. And no parallel syntax for concurrent processing. I mean, you would have to be a complete and utter maroon to use Power Query for something like data mashup, it's completely ill suited for the task compared to EMML!
And hence why these kinds of debates are pointless...
There are different programming languages for different purposes. Doing everything in one is a sign you don't understand a single thing about programming. The fact that something is possible in a language does not mean it should be done. I don't have time to explain such simple things.
Your tirade above only shows too clearly you've got a lot to learn, Mr. Gregory.
Best
D
- Greg_Deckler6 years agoCommunity Champion
Just so we're clear then Anonymous , so that we can all agree and be friends, having a native, built-in function in a programming language that is purpose built for a particular task and then using said pupose built function for exactly the task for which it was designed constitutes putting a square peg in a round hole. Right? That's what we're going with? Everyone agrees with that?