Re: Re (tilly) 1: DBI vs DBIx::Recordset vs princepawn vs chromatic

[princepawn]

And yes, I identified many of the same items that chromatic did. If you are lining up long chains of variable names and hoping that you have the same number, in the same order, then you are going about things in the wrong way.I don't agree with you. Such programming is possible in DBI and in some cases is appropriate. I see DBI just like I see assembly language or something. It isn't very structured, but it is very fast. In some cases, where you want optimal speed, then a "portable database assembly language" like DBI is the tool of choice

It is not hard for me to look at the list of things that you are saying are improved in DBIx::Recordset and tell that the abstraction, at least as you are describing it, would not be appropriate for the actual situations that I am coding against at work. Please describe these situations in detail and show why, otherwise I am afraid I have nothing as hard data showing the inadequacy of Recordset in application-level programming. OPEN CHALLENGE. PLEASE FILL IT.

Furthermore understand, that DBIx::Recordset inherits from DBI so you can always call retrieve the underlying DBI database handle and make DBI method calls.

And princepawn, I sincerely hope that you read this, get off your high horse, and learn something useful. what high horse? I do agree with your discussion of misuse of globals... and the newer version of this article corrects this, but under editorial pressure to get the article out the door fast, I left the old code in there. I have learned a lot about globals since then, especially from you. As a result, all my programs use strict; use warnings; use diagnostics;

Your entire idea of selecting * from a table and having your code figure out how to handle that is a stupid idea. I spent a good deal of energy in that post trying to explain to you why that was bad and what a saner approach is. "Stupid idea" is a qualitative, unsubstantiated assertion. Maybe you could instead show why it is a bad idea and show all of us what would be better. I am afraid that you are under-informed here, and part of it has to do with how I presented Recordset perhaps. The fact is that binding a typeglob to a select leads to a tie of a scalar, array and hash within the namespace of that typeglob. The scalar is used for object-oriented access to the table, the array is used to (lazily and memory-efficiently) iterate through the set of records matching the query and hash is used to access the columns of the current records in the recordset. This is in contrast the the manual decision-making required with DBI in which you must decide whether to get your data back as an array, arrayref, or hashref. So the bottom line is the process is automatic.

Apparently you didn't listen. Somehow I am not surprised. You don't appear to spend much time listening. You think that the rest of the world should listen to you though. Then why waste your energy talking to what you believe is a brick wall? I don't ignore people, I am here, particularly in this thread, to hear WITH LIVING PROOF AND EXAMPLES, of what you think about the two modules and their relationship and I would like to hear about other related modules, such as DBIx::Abstract and BingoX::Carbon. What is your goal in responding to me? I am perplexed

The fact is that right now you clearly have so little appreciation of basic principles of how to program that I don't care about your opinion on what modules you like. You simply lack the skill level necessary to make judgements on that that I would find even remotely useful. Who was that talking about a high horse? <grin>

[tilly]

This will be heated, but I really do not intend it to be a flame. However those who like to skip heated discussions should skip this post. If you think that heated discussions are always inappropriate for the Monastery, please drop a -- in the bucket first. But I actually think this is going somewhere. I believe this is constructive.

(UPDATE In case it isn't obvious, this is a reply to princepawn. "You" means princepawn, not the whole monastery.)

First of all I don't care whether you disagree with me. I am giving you my professional judgement of what the facts are. Take or disregard as you will. But as far as you disagree with my rant, I believe you either are mistaken or are missing key details.

For instance a case where you are out and out wrong is that repetitive code is sometimes necessary for efficiency. If you really need the efficiency of repetitive code, then preprocess your code to autogenerate the repetitive stuff. But the code that you maintain should avoid having that kind of fragility.

For instance a key detail you miss is that I work in a small company. While there is considerable differentiating of what we do with data, there is little differentiation between what data we work with and what access we need. Therefore everything you said about authentication and permissions is completely irrelevant to me.

Now I admit it. I find dealing with you very, very frustrating. You are obviously not a stupid person. You go out, put a lot of work in, learn about a lot of stuff. But you really seem to have no appreciation for how to rate what you learn, what principles to pay attention to, what goals you can aim for. I covered part of this in Re (tilly) 1: Topics in Perl Programming: Table-Mutation Tolerant Database Fetches with DBI.

Perhaps I can summarize it by saying that you appear to be motivated by the desire to accomplish neato things in a gee whiz manner. That may be fun, but that isn't what software engineering is about. What software engineering is about is managing complexity. That does not mean avoiding complexity, although it is good to avoid unneeded complexity. That means that as programmers we are asked to accomplish complex tasks, and over time we will be asked to both build on what we did, and modify it often at the same time! This is inherently hard and inherently leads to confusion.

The aim of software engineering is to make dealing with these necessarily complex situations a managable task. Being straightforward is good. Being straightforward to the point of having an unwieldy amount of code that has to be maintained just so is bad. Hiding information under an interface is good. Having interfaces multiply like rabbits so that nobody can ever learn the system is bad. Not reinventing wheels is generally a good idea. But avoiding doing so when the wheel doesn't work, is inappropriate, or leads to the above issue about having too many components is bad. Having idioms, ways of saying things that are instantly recognizable and allow people to "chunk" code to higher levels is good. Turning your idioms into cut and pasted mistakes scattered through your code is bad. Having policies and procedures and change control is good. Having the paperwork reach a point where you do not get the job done is bad.

Every good thing you can do has a corresponding cost. The key is to understand both the benefits and the costs so that you can evaluate situations, understand the trade-offs, then find and implement an appropriate solution. That is what we are paid to do. We have jobs because somebody thinks we can be trusted to do that, and we should try to do it well.

However you have not a hope of succeeding unless you understand that that is the goal, it is the point. It is what is important.

Now you are not stupid. You know that, I know that. I honestly believe that you are capable of staying aware of this principle, and paying attention to the trade-offs. Apply some of that desire to go off and learn lots of stuff, go read some stuff by Steve McConnell. But most importantly, just constantly try to evaluate how every tool and idea you run across helps and hinders (they all do both) the ability to manage the inherent complexity that we have to work with. Think less about what you want to do, and how you are going to do it. Think about why you are doing things, and think through ways it can go wrong.

I really believe that you can do that. I would love to see you do that. I promise you that if you do do that, you will improve. You will develop a sense of what things are design mistakes and what are good ideas. You will develop an ability to anticipate what is going to lead to trouble and head it off. You will be able to write code that isn't painful for people like chromatic and myself to read. Some of these things will happen faster than others.

But until you do that you will continue to crank out code, designs, and questions that make good programmers wince. And without you knowing how to judge good from bad, we will continue having trouble explaining to you the whys and wherefores of where we disagree with you.