Code Comparing Issues

These are various issues that may come up when comparing code examples, such as the same scenario written in different languages/paradigms.

Counting libraries and Other Low-Level Operations

(Moved/copied from ProceduralMethodologies. May require editing clean-up)

And while it "is not realistic to build modules from scratch" whatever, I don't care - I don't expect you to build it from scratch. But if you include chart-drawing modules, YOU NEED TO COUNT THE PARADIGMS AND LOC USED IN THAT MODULE, otherwise you are "cheating" when you're saying "which paradigms your solution uses". Your 'solution' and which 'paradigms' it uses is the whole package, not just the little piece you want to count. Just counting the little pieces you want to count is the very definition of cherry-picking.

Usually one uses off-the-shelf tools to generate [charts] because it is rarely economical to roll your own (Although I've done it before), and often one cannot count the lines of code because it is proprietary and compiled/encrypted. I don't know what metric you use to claim "better" anyhow. You need to be clear what you find better, why its better, and how you are measuring. I cannot do that for you because I don't share your betterment feeling. If most purchase components to do charting, why do you want to include it in YOUR comparison? Something smells fishy here. I don't expect one to count the code needed to execute a Print statement under the cover, so why should charting be any different? --top

You can't excuse your cherry-picking by saying the data you need is inaccessible. Imagine a situation where you "purchased a component to do charting" where all you had to do was feed it the raw data and a basic description of the report you wanted and out pops HTML and PNG... i.e. exactly what your product is supposed to do. Then you can say, "hey! look at my procedural solution! it takes data, and passes it (unprocessed) straight to this other component, and out pops a report!". What did you prove about procedural? Exactly nothing. If you wish to be scientific, you are responsible for counting up everything in your solution that lies between receiving the report specification and outputting the HTML file. And why should charting be included in the comparison? Because the charts are part of many reports, and HTML - the output format YOU chose - lacks higher-level support for chart descriptions. Technically, you should include the 'Print' statement, too, if you 'Print' to the HTML file; it is also between receipt of the report specification and output of the report.

I meant the internal code to execute the print statement. There may be quite a lot going on in the OS or compiler to print. Which library functions (or macro substitions) are counted in the code volume comparisons and which are not? And how do we count something for which we don't have the source code?
I also meant the internal code to execute the print statement. And if you can't count something because you don't have the source-code, the usual solution (for a challenge like this) is to write your own source-code for it, or find another solution for which the source-code is available.
If "print" is among some finite list of statements that you don't want to count for you OR the opposition in the challenge, that is fair. But you can't use that to advocate not counting the "DoMyHomeworkForMe?" procedures... not if you wish to prove anything about the methodology you're choosing. Is it your intent to prove that procedural is better at creating a specification of a chart for this other tool? or that it is (more wholistically) better at creating the report? If you really want a tool that does the charting, put it in the rules of the challenge... e.g. allow pseudo-code that goes from some specification of a chart to producing the actual chart, and say that the real problem is creating the specification for the chart.

As proposed in ChallengeSixVersusFpDiscussion, perhaps fat libraries are the key to productivity, not newfangled paradigms. And you haven't addressed the Print statement issue, and all the assembler inside the compiler/interpreter, etc. Where is the point where we stop counting?

You seem to want the entire world to build you a super-library so that you can do anything you want by invoking a procedure. Your ignoring of the magic behind the curtain is the source of your cherry-picking. And I did address the 'Print' statement... see the last sentence of the prior statement. EVERYTHING in the process between receipt of report specification and output of the report should be counted. The 'magic' in the interpreter should be counted, too. It is also part of the 'business process... delivering'.

Another take:

The discussion above relates to a challenge between OO and Procedural that was issued largely between top and someone other than myself in the discussion on ProceduralMethodologies. It is my impression that Top feels he doesn't need to count the code he doesn't see, and that he feels it is simultaneously legal to answer a procedural challenge by cobbling together a bunch of off-the-shelf tools to do the job.

I readily commend using tools to do the job in a true business scenario, but I strongly believe that it is a horribly inappropriate response to a challenge. It's rather like claiming that 'BourneAgainShell' can beat many languages in the ComputerLanguageBenchmarksGame simply by passing its parameters to the highest-ranked solution.

If you are ComparingCode or methodologies, the right thing to do is make sure that both pieces of code solve the same problem. And if one solution does so by cobbling together other pieces of code (existing libraries, processes, partial solutions, etc.) then those other pieces of code must also be counted in the comparison in order to have the whole set of code that is 'solving the same problem'. That is, of course, supposing such solutions aren't blatantly violating the 'rules' of a fair 'challenge', which should disqualify them entirely. Does that mean low-level code underlying things like 'Print', too? Yes. Of course it does, if your solution does any 'Print'-ing. If you wish you could change the rules of the challenge a bit to exclude code for a particular set of pseudo-code level operations (and it wouldn't be unusual to do so for 'Print' or at least an unformatted 'file-write <filename> <string>'), but any such selection of operations that needn't be counted will be finite and limited. You don't get to add to the set a magic 'SolveThisProblem <inputs>'.

I believe Top is 'cheating' when he lauds praises upon ProceduralMethodologies when what he is actually doing is writing glue-code for other partial-solutions. He shouldn't be praising 'P/R' for that. He should be praising 'ToolCombinationApproach' or some other lamely named methodology that can fit in alongside his 'FeatureBuffetModel' et al. In that case, it becomes plain that his solution has a major weakness: it provides very few answers for solving the problems when a solution doesn't already exist. However, it also has its strengths, such as reasonable cost for industry-strength solutions. If he wishes, he can then go on to argue that 'Procedural' is better than all alternatives at glue-code (a dubious claim at best). But it isn't the same as arguing that procedural is better at 'custom biz apps' (whatever that means).

In the challenge above, top's job is to provide a procedural/relational solution to creating nested reports (in HTML) given some declarative specification of the report as input (which would depend upon the other guy's, since he told the OO guy to go first). If the report-spec involves diagrams with nestable charts and sub-diagrams, as I suggested, then top's solution (to solve the same problem) would need to also write diagrams with nestable charts and sub-diagrams. It would, I believe, provide a clear challenge where OO comes out 'ahead' of the procedural solution by most measures one would care to make, though I'm leaving the proof to the challengers.

But if top chooses to grab a bunch of charting software and ignore the paradigm it uses, that solution strikes me as remarkably similar to the bash-script in the ComputerLanguageShootout?. If top wanted to be a real winner, he could even do exactly that: take the other challenger's solution, write a 'procedural' bash script that calls it, and call the job done! Look! Procedural does the job in one line! Never mind the code behind the curtain...

In fair code comparing challenge, you can't go grab somebody else's solution and say that your code solved the problem. That is, very plainly, 'cheating'.

--BlackHat

Again, the hypothetical task is to convince a rank-and-file custom biz developer of the benefits of OOP. The challenge is NOT systems software and packaged tools. I for one have not challenged those domains (SS and PT). Why would you demonstrate stuff that nobody seems to be challenging? You make it sound like I am trying to pull a trick/cheat here. But I am merely focusing on the practicalities of comparing based on what say a domain business owner would care about. --top

BlackHat disagrees. Rank-and-file custom biz developer already believes market hype about benefits of OOP, even though they shouldn't (at least not for the reasons it is hyped).

In my observation, most custom biz app developers like to use pre-existing OO packages, but the code they write is mostly procedural.
Biz app developers can and should take advantage of pre-existing packages where they exist; there is no sense reinventing the wheel for custom apps (that aren't being sold in their own right). To do otherwise is simply wasteful.
But while your experience with 'custom biz apps' relates mostly to 'custom reports', my own experience relates mostly to 'custom GUIs for distributed command and control of particular multi-million dollar automated vehicles'. You've been told this before, by different people, and in different ways, but many of us people-who-aren't-you believe you are hasty in your generalization from your own experience as to what constitutes 'custom biz apps'. Every time you say that procedural or whatnot is better for 'custom biz apps', we see that as our territory, too, or we otherwise have in mind some 'custom biz app' that has little or nothing to do with 'custom report generation'. Thus, we view you as speaking bullshit since none of your arguments support 'procedural' as being better at what we legitimately consider to be a 'custom biz app'. Further, our counter-arguments make no sense to you because you're sitting there wondering, 'why the hell is this guy talking about distributed command and control and high-level security-protocols when I was talking about custom biz apps?' - where, by 'custom biz apps', you mean 'report generation'. Perhaps you should just call it 'report generation' and drop 'custom biz app' from your standard vocabulary. Procedural is better at 'report generation'? With that I'd readily agree, so long as the report itself is relatively fixed-format and doesn't have too much nesting. As far as reports that are flexible format and with flexible nesting charts and diagrams and such... I'll leave that argument to the challenger.
What you describe sounds my like an engineering domain, sometimes called "process control" IINM. Anyhow, I never said custom biz apps were only reports. You are putting words in my mouth. -- top
What I describe sounds to me like custom applications for a business that just happens to be involved with engineering. Therefore "custom biz app". QED. As far as putting words in your mouth, count up the number of times you say something like: "It sounds like you are mostly talking about GUI engines." or "That doesn't sound like custom biz apps. That sounds like 'process control'." Make your own conclusions as to how someone else views it. You've never attempted to define 'custom biz app', and you don't have a right to do so even if you wanted to: it's well enough defined to everyone else just by looking at the component words: "custom" "business" "application". If you wish to avoid confusion, avoid using it.
I did NOT bring up "nested reports". It was not me, but another individual who is not me. Is this clear? -- top
I haven't said you did. I know who the challenger is. But you have brought up reports often enough that they're still worthy as an example of what you -do- consider to be a 'custom biz app'.

Anyhow, if your claim is that procedural is better when a solution already exists because procedural can call that solution, then why aren't you making that very clear every time you praise procedural? Here is your corrected script for the future: "Top: OO is bad. Procedural is better than OO when a solution already exists." Repeat ad nauseam.

I was hoping for coded sample of this so called "nested report" so that we don't have to make generalities. (BTW, I already provided PayrollExample with inspect-able code if you want something existing to dissect.) And I did not make a claim about procedural being better. It was an OO claim that sparked this all.

[I'm working on a coded sample. Please be patient, as I'm working on it in addition to my usual duties. BTW, the specific claim of Top's that kicked this off was "I see procedural and relational [as] a kind of Yin and Yang where they naturally complement each other with little or no fighting over territory (unlike say OO and relational)." (See ProceduralMethodologies) That seems to imply that procedural is considered "better", at least in terms of its use with relational (i.e., SQL, presumably) systems.]
You guys have "interesting" memories of this. Let me de-interest them. Here is the real quote that kicked this off: "I have never found any down-side to introducing object-orientation, and it frequently makes certain aspects -- e.g., nested forms, nested reports, data-grids with arbitrary cell contents, re-usable abstractions, implementing stubs or MockObjects? for testing purposes, etc. -- considerably easier to develop and maintain." (emph. added) -- I simply asked for evidence of one of them, nested reports, because I felt it would be the easiest to demonstrate on a wiki. --top
- [...Which was posted in response to your claim that, "I see procedural and relational [as] a kind of Yin and Yang where they naturally complement each other with little or no fighting over territory (unlike say OO and relational)." Go see ProceduralMethodologies. It's still there.]

I'm not actually a promoter of OO, and plan to leave the 'nested report' challenge to the challenger, who isn't me. Encapsulation (via lexical closure and interface polymorphism) and runtime configuration of computation (e.g. test configurations, construction of runtime objects that represent calculations-to-be-performed or actions-to-be-executed) are the two things I consider of value about OO languages. The large set of OO methodologies, however, especially those regarding domain-based object models and inheritance, I consider to be deeply flawed in some very fundamental ways. Since I don't generally approve of OO, I don't attempt to defend it. But I do demand that attacks on it be fair, just as I would attacks on Relational or Procedural.

[Indeed. I see little reason to promote or deprecate any paradigm, approach, or methodology. They are merely tools. Any tool can be used appropriately or inappropriately depending on the requirements and circumstances.]
Please remind the person who used the phrase "considerably easier to develop and maintain" of this. --top
[But it's true, and it was posted in response to your claim that OO and relational are "fighting over territory." I also find it easier to turn bolts with a wrench than a hammer. That is neither deprecation nor promotion (well, all right, maybe a little, but I am by no means an OO weenie), but an appreciation for applying the right tool to the job.]
I don't claim to have any objective evidence of "ying and yang". It is a subjective feeling so far and that was an informal statement. The only evidence that comes to mind is the lack of fat contorted bloated procedural-to-relational mappers, unlike when OO and relational come into contact. As far as your hammer comment, this is possibly related: ParadigmPotpourriMeansDiminishingReturns and AreOoAndRelationalOrthogonalDiscussion.
[I quite agree with your aversion to ObjectRelationalMapping. I've found an effective solution to its ills: I don't do it. I think the idea derives from the misguided notions that (a) object-orientation should be primarily about modeling domain objects; and (b) object-oriented modeling -- for data management purposes -- is superior to relational modeling. This, as myself and others have argued elsewhere (somebody insert where, please), is an approach that leads to creating simulators instead of information systems. The former are certainly of value, but the latter are generally what we're looking for in the usual business application development domains. Top, I sometimes wonder if your objection to object-oriented development isn't as much about OO per se as it is about the philosophical approach to object-orientation that leads to object-oriented databases and their mutant second-cousin, ObjectRelationalMapping. If that is the main substance of your objections to OO, then I largely agree.]
Well, I do agree that modeling the domain directly (products, employees, etc.) in OO is where it fails the most, as somebody described in OopBizDomainGap. But as far as stuff outside of that, like report formatters, they are rather small, independant little services OO is not going to offer much over a procedural API. That's why I'd like to see the "report nester" in action doing all the wonderful brochure things that OO allegedly does according to proponents. ("Reuse" seems to have fallen out of favor is a key claim of OO, by the way. If that's your claim, you are the minority.) --top
[Report formatters are "rather small, independant [sic] little services"??? ~*Boggle*~ Report generators of any reasonable functionality are hulking beasts. See CrystalReports, for example. Indeed, it'll take some effort to produce my nested report generator example not because I need to build it up, but because it'll take some time to boil down some of my pre-existing code (from a C++-based report generator I wrote some years ago) so it's meaningful without all the exception-handling, widow/orphan-avoiding, page-number-counting, subgroup-handling, font-size-twiddling, preview-generating, realign-to-fit-the-page, output-device-whatnot cruft that would otherwise obscure the essence of the thing.]
- Crystal-reports is an "off-the-shelf tool" (COTS). It is not a custom biz app. Anyhow, how about you describe the nature of the app before digging into the code. What are the requirements, and why couldn't you use a COTS to help you, for example? Did the customer really want that much control over every detail? (Please put answer under NestedReportsExample.) I once wrote a custom charting utility where I controled every vector (output to HP PCL). But it was a non-typical scenario where we ran out of budget for COTS, but had spare labor. It was to some extent MentalMasturbation on my part. The situation allowed me to go above and beyond what is "normal". I later rewrote it to use a COTS when company decided to phase out ExBase in favor of VB/VBA. --top
- [Yes, of course CrystalReports is an "off-the-shelf" tool. The point is that it's a hulking beast, as report generators tend to be. The app in question was designed to allow the repair department of a telephone company to perform statistical analysis of live and archived repair data -- such as current average downtime, most common types of failure, number of repair tickets currently awaiting service, and so on -- and produce their own custom reports from these. At the time, I presume there was a sound business case for having the app custom-developed, but I don't recall what it was. It's also possible that (at the time) there was no off-the-shelf software that did what was required, as we're going back a bit here -- the C++ source code files are dated from October 1990 to November 1991.]
- That's a bit long ago. I'm sure there's more options now.
{I hear top now... "That doesn't sound like a custom biz app. That sounds like a report engine." The reason top and his 'custom biz apps' get away with being 'small, independent little services' is because he doesn't provide many 'features' or much 'flexibility' unless the tools he's gluing together can already provide them.}
[If that's the case, then what Top calls "developing custom biz apps" is what most folks call "systems integration."]
You are putting your words in my mouth again. I generally use HelpersInsteadOfWrappers now. I've given up making The Ultimate Generic Thing. Each app or shop has different needs and rather than strive to jam gazillion features into a single generic packrat util, such as a report formatter, I now mix, match, and customize parts as needed. Related: GenericBusinessFrameworkUnobtainable. Anyhow, I look forward to examining your OO "nested report" framework to see how OO makes it "better" than a p/r equivalent. --top
{Helpers and Wrappers, top, are both tools for "systems integration". You shouldn't complain about us putting words in your mouth unless they're the wrong words. Just remember that the p/r equivalent must solve the same problem to be 'equivalent'... I look forward to examining your 'p/r equivalent' and seeing whether it really deserves that term. The way you describe it, perhaps it should be the 'p/ r/ oo/ functional/ cobbled-together-pieces-of-you-don't-know-what equivalent'. Integration with relational doesn't deserve a higher titular standing than does integration with any other "systems software" and "packaged tools" you utilize.}
You worded it as if it was mutually-exclusive, as if I was mis-labelling an "A" as a "B". Systems integration is more of a technique than a domain.
{When I quoted my imaginary model of you, I worded it as I believe you tend to word it... except more clearly, by including the first sentence. And I don't agree about systems integration being more a technique than a domain.}
Somewhere there is a big miscommunication. I'm not in the mood to sift and parse it down right now. Just produce the @$!#* code and/or specs. I don't wanna argue about words of late. The only reason I took it this far is because you accused me of purposely manipulating language. I should just ignore such accusations rather than get defensive.

DecemberZeroSeven

CategoryMetrics, CategoryExample