[eluser]Nick_MyShuitings[/eluser]
I think the only thing that matters is that you are aware that they both output the same thing, and in the absence of the tool you could do without it.
Or perhaps more importantly... if they tool ever was inadequate for your needs, you'd be able to do it by hand. Rather then a post along the lines of "hey I can't get the XYZ function to output what I want". For another example, I've got my step-daughters who if I took their calculator away they struggle to add and subtract... that's kinda the problem with over reliance on tools without remembering how the tools work behind the scenes.
[eluser]theprodigy[/eluser]
I hope I'm not hitting below the belt with this one, or even taking this out of scope, but since we're talking about tools, shall we consider:
We can program in php, because Rasmus Lerdorf created PHP.
I'm not sure what IDE you use, but Sun created Netbeans (my IDE).
Visitors can visit my websites, because the DoD created the internet (yes, the DoD, not Al Gore :lol: )
Apache foundation create the Apache web server, which allows a server to serve our pages.
EllisLab built a great tool known as CodeIgniter, that lets us build our sites using the MVC pattern.
These are all tools that allow us to do what we do, and yet, for most of us, we would not be able to create the tools ourselves, or offer services without them.
Yes, these tools are a little different than the wrappers of form_helper, html_helper, etc, but the basics are the same. I use jQuery for some things that I would find difficult to do without it. Many of us have come to rely of firebug to point out our javascript mistakes, that we would have trouble finding without it. Some people even go as far as to spell a word in M$ Word, just to see if it was spelled correctly. But, at the end of the day, products are completed, services are finished, and clients are happy.
Isn't that what it is all about? What matters more, the client's being happy with the product they receive, or that the product was built using hand coded html rather than a helper file?
[eluser]jmadsen[/eluser]
but you are forgetting the other reasons to avoid it:
-- it is slower than writing your own string
-- you avoid optimizing your queries because to do so doesn't fit naturally into AR functions, and it is harder to spot the places where you should optimize
-- it is harder to debug
The last one is why, whenever anyone posts a query they are having trouble with, the first thing people do is ask them to "post the output of their query"
[eluser]theprodigy[/eluser]
Quote:—it is slower than writing your own string
This would be true of ANY wrapper, not just AR.
Also, using a framework is slower than writing straight PHP. So why use anything at all?
Quote:—you avoid optimizing your queries because to do so doesn’t fit naturally into AR functions, and it is harder to spot the places where you should optimize
Sometimes (not always), it is quicker to run 2 queries then to run one complex one.
Depends on whether you are looking for speed or number of hits to the db.
Quote:—it is harder to debug
Yes and no. Most of the time, the bugs come from leaving out a part of the query (which is easy to spot with or without AR), or because a variable does not contain what you think it does (which would throw an error either way).
Plus, I don't exactly agree with this statement. It all boils down to coding style. I could write something in AR, that is much easier to read than trying to write it concatenating a string to do straight sql.
Plus, the only thing a non-sql person has to do is write their query in AR, echo $this->db->last_query(), copy it, and then replace the AR code with what they copied. Now, they have the benefit of faster code, and STILL not knowing how to write SQL, AND it has the benefit of CI's escaping, that some SQL writers forget about.
[eluser]theprodigy[/eluser]
And just for the record, I'm not trying to defend using tools that you know nothing about. I still believe that knowing what the tool does is much more beneficial than not knowing. But, I don't believe that we should be going around telling people that if they don't know what the tool does, to not use it period, or that I'm better because I do know what it does.
One of the benefits to knowing what it does is being able to extend it to suit our purposes. Bend it to our will, so to speak. That is something that someone who doesn't know, would not be able to easily do.
But, on the other hand, the internet would be a much smaller place if only those that know what they were doing, were allowed to build sites. For one, there would be no reason for this forum.
Plus, where would it stop? Just because you prefer to write your SQL by hand, doesn't mean you know anything and everything there is to SQL. And, just because you may know SQL, doesn't mean you know anything and everything about PHP. And if you happen to know anything and everything about SQL and PHP, doesn't mean you know anything about the server that your code lies on. So, once again, I ask, where does it stop?
[eluser]jmadsen[/eluser]
well, for me there's nothing new coming out of this discussion and it's just getting silly, so it will stop here and now.
[eluser]InsiteFX[/eluser]
LOL! This like trying to get people on the forums to use the friggen code tags!
InsiteFX
[eluser]Basketcasesoftware[/eluser]
My (hopefully) last thoughts on this thread's new subject (being that it's been hijacked). I write wrappers that encapsulate common coding patterns. This is not a new thing - it's how Fortran got started. They only slow things down in interpreted languages, but I should point out that unless you are writing directly in the language of the target machine everything is a wrapper (that includes PHP itself). The very much help with debugging and go far in the avoidance of creating bugs in the first place. Why? Because they narrow the area of what the programmer is actually writing.
[eluser]toopay[/eluser]
This is not just about "I write wrappers that encapsulate common coding patterns" nor "speed-benchmarking" tests.
AR is initially simpler to understand and faster to write than SQL-based model code. Its efficiency in the early stages of any project is adequate. Unfortunately, these advantages disappear as the project increases in complexity: the abstraction breaks down, forcing the dev to use and understand SQL. Entirely anecdotally, based my own experience of PHP back-end development, the abstraction of AR breaks down not for 20% of projects, but close to 100% of them. Objects are not an adequate way of expressing the results of relational queries. The inadequacy of the mapping of queries to objects leads to a fundamental inefficiency in AR-backed applications that is pervasive, distributed, and therefore not easily fixed without abandoning AR entirely.
|
