Having a rubbish TI editor is a good thing.

[whitej_d]

I'll say something that might be controversial, but I haven't had anywhere near enough coffee and I have a small baby that doesn't like sleeping so I'm past caring today!

I like that the TI editor is rubbish. Sames with the rules editor. If you ask me the number one issue with TM1 systems is that there is far too much code and logic hidden away in rules and particularly TI processes. It very quickly becomes impossible for business users to understand what is going on, and it becomes very hard for anyone but the person who built it to maintain.

The problem is - TI is not a programming language. It has no array structures (except the cubes themselves of course) and no object oriented concepts to enable the writing of code in a simple, clear, easy to follow or easy to manage way (Bedrock only makes things worse in my opinion!)

TI is primitive scripting, and as a result it should be treated as such and written in the shortest possible number of lines. Having a really rubbish editor at least encourages me to treat TI like the basic tool it is and think about cube design, dimension design etc to overcome complexity rather than writing pages and pages of TI code, or horrendous nested if statement in rules! For every piece of logic, or if statement inside a TI process, it becomes increasingly difficult to understand the result from the source.

I appreciate a fair few people will disagree with me here, but if you ask me, being able to understand the output of a TM1 system is of equal or more importance than actually getting the correct output, and any code in TI makes understanding the output hard!

[lotsaram]

I'll say something that might be controversial, but I haven't had anywhere near enough coffee and I have a small baby that doesn't like sleeping so I'm past caring today!

I like that the TI editor is rubbish. Sames with the rules editor. If you ask me the number one issue with TM1 systems is that there is far too much code and logic hidden away in rules and particularly TI processes. It very quickly becomes impossible for business users to understand what is going on, and it becomes very hard for anyone but the person who built it to maintain.

The problem is - TI is not a programming language. It has no array structures (except the cubes themselves of course) and no object oriented concepts to enable the writing of code in a simple, clear, easy to follow or easy to manage way (Bedrock only makes things worse in my opinion!)

TI is primitive scripting, and as a result it should be treated as such and written in the shortest possible number of lines. Having a really rubbish editor at least encourages me to treat TI like the basic tool it is and think about cube design, dimension design etc to overcome complexity rather than writing pages and pages of TI code, or horrendous nested if statement in rules! For every piece of logic, or if statement inside a TI process, it becomes increasingly difficult to understand the result from the source.

I appreciate a fair few people will disagree with me here, but if you ask me, being able to understand the output of a TM1 system is of equal or more importance than actually getting the correct output, and any code in TI makes understanding the output hard!

@Admins - could we break this out to a separate thread?
There hasn't been a juicy discussion topic for a while and this could be one.

[David Usherwood]

I will add that I have been guilty in the past of building things which are far too complex, and will probably be guilty of it in the future too! Don't want to sound like I'm preaching, but the drive should be towards simplifying things, not towards making it easier to do complicated things.

Einstein is worth quoting:

Everything Should Be Made as Simple as Possible, But Not Simpler

http://quoteinvestigator.com/2011/05/13 ... in-simple/

[qml]

@Admins - could we break this out to a separate thread?
There hasn't been a juicy discussion topic for a while and this could be one.

Yes please! We haven't had a flame war far too long!

When we're done with this subject we could revive "Code Indentation: Spaces vs Tabs" or "Time Dimensions: Single vs Multiple", to name a couple.

[qml]

Ok then. Let me start by dissecting this:

The problem is - TI is not a programming language. It has no array structures (except the cubes themselves of course) and no object oriented concepts to enable the writing of code in a simple, clear, easy to follow or easy to manage way (Bedrock only makes things worse in my opinion!)

TI is primitive scripting, and as a result it should be treated as such and written in the shortest possible number of lines.

Any scripting language is by definition a programming language (one being a subtype of the other). The TI scripting language is therefore most definitely a programming language, regardless of any real or perceived shortcomings, which every programming language has. The fact that it's lacking certain data types or other concepts does not make it any less of a programming language; it is only a reflection of the purpose for which this proprietary scripting language was created. And let me just say that for that purpose (which is ETL) it is incredibly feature-rich and versatile and lets you manipulate almost every aspect of a TM1 server.

I'll address other claims you make in separate posts later.

[whitej_d]

Any scripting language is by definition a programming language (one being a subtype of the other). The TI scripting language is therefore most definitely a programming language, regardless of any real or perceived shortcomings, which every programming language has. The fact that it's lacking certain data types or other concepts does not make it any less of a programming language; it is only a reflection of the purpose for which this proprietary scripting language was created. And let me just say that for that purpose (which is ETL) it is incredibly feature-rich and versatile and lets you manipulate almost every aspect of a TM1 server.

I pretty much agree with all of this so far, and I will accept your semantic correction that TI is technically a programming language. But I challenge anyone to easily reconcile source data to target cube if there are more than 3 If statements on the data tab! If there's enough code that it needs a separate text editor to keep track of and maintain, then I would worry that reconciling loads would be almost impossible.

I'm not saying a better text editor wouldn't be welcome, or that those who choose to use them shouldn't, as I'm sure there are many valid reasons why those of us who know what we're doing may write lengthy TI scripts to achieve some of the more bespoke requirements out there, but I hate it when people who don't understand TM1 very well default to doing everything in TI because they don't properly understand feeders, or they have the wrong shape cube for the logic and they get round it by serialising everything in TI.

I personally hate Bedrock for the same reason. Yes, it can save a lot of time, and yes, some of it is quite clever and well written, and yes, I do use some of the bedrock TIs if they fit my needs, but I find they encourage people to work in TI, rather than think of an overall design based on cubes/dimensions/rules/TI. I saw this today:

Code: Select all

  
   If (DIMIX (cDimName ,sEl) = 0 );
                ExecuteProcess ( 'Bedrock.Dim.Element.Create' , 'pDimension' , cDimName,'pElement', sEl,'pElementType','N');
   EndIf;
   

Maybe I'm missing something obvious, but what on earth is the benefit of Bedrock in this case when native TI would achieve the same in less than half?

Code: Select all

DimensionElementInsert(cDimName, '', sEl, 'N');

TI should be clean, simple and short. If it's not, then mix it up with some intermediate cubes/rules and other clean, simple TI processes to give an overall solution people can understand!

[Steve Rowe]

Lol, OP if you keep talking about Bedrock I'm going to have to split the topic again....

My thoughts...
TI vs Rules and traceability audit trail.

We build systems to meet our users needs. Generally these are "I want my numbers quickly" not "I want my numbers quickly and I want to understand exactly where they come from all the time." Again generally rules don't (pre-MTQ) scale massively well and this can lead to a TI driven approach rather than rules. Of course it all depends on the requirements and the priorities of the user.

I hate it when people who don't understand TM1 very well default to doing everything in TI because they don't properly understand feeders, or they have the wrong shape cube for the logic and they get round it by serialising everything in TI

Agreed but the counter statement "I hate it when people think that rules are inherently better than TI as means of delivering downstream results from the loaded data" is equally valid.

Scarcity of Rule and TI Editor functionality.
I can honestly say that I've been doing it for so long that I'm quite happy in the TI and rule editor (bar the font size, that can a really killer in some environments "Is that dust, a comma, a full stop, a semi-colon. Damn it's a dead pixel!).

Oh and advance notice, I'm hoping this can be kept as a fun debate between experienced TM1 devs who all know that there is almost definitely nearly never a global right answer where TM1 is concerned.

[Edward Stuart]

Does a 'bad' TI editor/ rules editor encourage good programming? Arguably it does, you are forced to dig in and discover the source of issues before you can see it in action or learn about the debugging opportunities you can develop yourself. However, when under pressure to deliver then inevitably shortcuts are taken. I think we'd all happily take a good IDE with step through capability etc.. etc.. because we'd only be getting more than we currently have.

I've seen many solutions with individual rules for months in an attempt to improve performance or to 'just get it working'. Is this wrong? Is the user experience different for this? No, providing rules are saved in advance of future months then the solution meets the requirement, it may not include best practice regarding maintenance but it works

I am still under the impression that the majority of TM1 Developers come from a Finance background and have an interest in Systems. This is changing but in the main we are looking at users with no or little structured training in programming and the official IBM training course perhaps providing around 10% of the knowledge required to build robust TM1 solutions

Should the Masters course be brought back... in my opinion yes but only if the test format was changed

[whitej_d]

Should the Masters course be brought back... in my opinion yes but only if the test format was changed

They'd also have to translate the Spanish examples into at least English!

Perhaps I'm going through the 'trough of disillusionment' in my own TM1 hype cycle, but I'm starting to think that the tech systems world is changing, and TM1 under IBM's stewardship is getting left behind. Tools like Tableau have essentially killed the original concept of BI, and things like Alteryx look to be putting the traditional role of ETL away from IT and dev's and more into LoBs. Everything is becoming user friendly and 'self service' yet TM1 still requires coding in TI, and the rather abstract application of rules and feeders. I love it, but I can start to see why companies struggle to manage applications without dedicated teams of experts.

Planning Analytics looks great, but even in the less developed markets of the world where I now operate, the most common response when we show it is 'Oh, it's just like Anaplan/ Tableau/Qlikview'.

I may be contradicting my original statement about the rubbish TI editor being a good thing by calling for a modern, intuitive, easy approach to developing models, but really my underlying point is that TM1 is, in general, too complicated. I'm not convinced that in the modern tech world it needs to be anymore.

Another point to consider on coding in TI - why not use Java instead? It has all the data structures and object oriented features to write really good, efficient code, and no shortage of experts in the world who can use it (they're usually cheaper than TM1 consultants too), and loads and loads of add-on libraries. With the Java Extensions, it has pretty much all of the TI commands for working with TM1 objects. Combine with the REST Api and you can do everything TI can do with much more flexibility and with a nice UI and proper debugging tools etc. It's probably got much better performance when doing calculations and loops etc...

[George Regateiro]

Perhaps I'm going through the 'trough of disillusionment' in my own TM1 hype cycle, but I'm starting to think that the tech systems world is changing, and TM1 under IBM's stewardship is getting left behind. Tools like Tableau have essentially killed the original concept of BI, and things like Alteryx look to be putting the traditional role of ETL away from IT and dev's and more into LoBs. Everything is becoming user friendly and 'self service' yet TM1 still requires coding in TI, and the rather abstract application of rules and feeders. I love it, but I can start to see why companies struggle to manage applications without dedicated teams of experts.

Planning Analytics looks great, but even in the less developed markets of the world where I now operate, the most common response when we show it is 'Oh, it's just like Anaplan/ Tableau/Qlikview'.

Yes there can be too much complication, but I have yet to be convinced about the Tableau's of the world. Yes they look nice but as the solution grows (and it will) people will want the enterprise features offered by more traditional BI tools. I am an not sure that Tabeau will be able to scale. The self service idea has been around as this holy grail but the truth of the matter is that when the rubber hits the road developing maintainable software and reporting is hard and time consuming, in 10 years time the same statements about TM1 could easily apply to Tableau. People that want to jump on Tableau as the end of enterprise reporting forget things like the audits that a centralized group handles. We are dealing with that now where folks were not prepared to take on the SOX compliance of the items they wanted to distribute via Tableau.

Another point to consider on coding in TI - why not use Java instead? It has all the data structures and object oriented features to write really good, efficient code, and no shortage of experts in the world who can use it (they're usually cheaper than TM1 consultants too), and loads and loads of add-on libraries. With the Java Extensions, it has pretty much all of the TI commands for working with TM1 objects. Combine with the REST Api and you can do everything TI can do with much more flexibility and with a nice UI and proper debugging tools etc. It's probably got much better performance when doing calculations and loops etc...

I absolutely love the REST API and use it across all my servers, but I have not seen any Java or .NET based solution that can get me something working and in a users hands as quickly as TI and Rules. I think TM1 is transitioning into a good blend of both the core engine and these newer technologies, but there is alot to be said about the simplicity of building a TM1 model over what will most likely turn into an drawn out custom coding effort.

[iansdigby]

A very interesting discussion. Here's my input:
- A simple editor can be a good thing because once you learn syntax etc. thoroughly, you can code quickly; arguably more so than with a fancy editor. Intellisense is great, but...
- The whole point of Bedrock I believe is to leverage modular programming. It does require acceptance across the developer community that the Bedrock TIs work reliably every time; I have been using them in earnest for several years in different organisations and apart from one or two niggles they do work perfectly every time. For a contractor like myself it is infinitely easier to look at a Bedrock TI call when debugging and know that the only problem with it, despite admittedly sometimes being verbose, would be an incorrect formulation of the call.
- The originator of this thread argues that the least code possible is desirable - but Bedrock very much facilitates this.
- My one real complaint is the size of text in the TI editor, which is not just inconvenient, but negligent in terms of disability inclusion. I have poor eyesight and it's just not fair having no way to enlarge it. Such a small thing to put right (no pun intended - but hey what a pun ).