A truly complex (in the mathematical sense) dependency graph

All off topic discussions go here. Everything from the funny thing your cat did to your favorite tv shows. Non-programming computer questions are ok too.
Post Reply
User avatar
Schol-R-LEA
Member
Member
Posts: 1925
Joined: Fri Oct 27, 2006 9:42 am
Location: Athens, GA, USA

A truly complex (in the mathematical sense) dependency graph

Post by Schol-R-LEA »

This thing is utterly terrifying.

Image

(Sorry about how big it is. Apparently, this version of PHPBB is too old to support image size limits - a feature introduced more than ten years ago...)

How do you get a dependency graph so complicated that it displays both a high fractional dimension and significant self-similarity? You know what, forget it, I don't want to know...

Apparently, this is an extreme example of softcoding gone mad:
Remy Porter wrote:What you’re seeing here is the relationship between stored procedures and tables. Circa 1995, when this application shambled into something resembling life, the thinking was, “If we put all the business logic in stored procedures, it’ll be easy to slap new GUIs on there as technology changes!”
The final paragraph is pretty awful, too:
Remy Porter wrote:By the time Thomas [a new developer on the project, and the person who submitted the story to The Daily WTF] came along to start a pseudo-greenfield GUI in ASP.Net, the first and simplest feature he needed to implement involved calling a 3,000 line stored procedure which required over 100 parameters.
I feel nauseated just reading that...
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
simeonz
Member
Member
Posts: 360
Joined: Fri Aug 19, 2016 10:28 pm

Re: A truly complex (in the mathematical sense) dependency g

Post by simeonz »

Schol-R-LEA wrote:Apparently, this is an extreme example of softcoding gone mad
The article says:
What you’re seeing here is the relationship between stored procedures and tables.
This could, or rather should mean indirect relationship. Stored procedures can after all call other stored constructs. For example, I just checked (because my SQL is rusty and I was never a top dog) that inline table valued functions in SQL server are expanded in the outer query and have no detrimental impact on the performance and query execution plan. On the other hand Oracle's table functions are rigid - pipelining and multithreading is possible, but only when explicitly requested. That is, in Oracle, it appears that the table function crates a black box and a barrier for the optimizer. What I mean to say is that stored procedures need not be "softcoding" per se, depending on the technology you are given to work with. But apparently, their solution did not adapt well to its scale, for whatever reason.
Post Reply