I once got dumped a BI project that was written in a visual tool. Simple things like tracing how a field was derived was impossible, because there was no search function. I could search the XML file it produced but that was impenetrable.
I once got dumped a BI project that was written in a visual tool. Simple things like tracing how a field was derived was impossible, because there was no search function. I could search the XML file it produced but that was impenetrable.
Am I allowed to condemn all textual programming based on the last textual program a company asked me to maintain? It had a single function over 1500 lines long, which took over a dozen parameters, had well over a dozen exit points, re-used variable names and values (sometimes unintentionally) between otherwise independent sections, and had zero documentation. And I had to fix a bug in it. "Impenetrable" does not begin to describe it. Text-based programming is a disaster.
Maybe you're right that it's unfair for me to dismiss the paradigm as a whole based on one bad experience. But it just seems to me that the mindset lends itself to a write-only environment.
https://www.google.com/search?q=labview+spaghetti+code
Yes you can make horrible code in text too, but it is a lot easier to not do that.
but this is mainly because those BI tools themselves and the graphical languages they use have issues.
when done properly, diagrams can be searched similarly to Haskell's hoogle, Purescript's pursuit, etc... in addition you could specify a template diagram it should match
Otoh, it does often lead to job security.