Indeed, and if others that have posted in this topic would do likewise it should prove most educational for others.
Such code reviews would be more than most welcome
I agree that other languages (prime examples being java and c#) essentially force you to think in an OOP way which helps you learn but there’s no reason you can’t learn those things in PHP alone. The only barrier, and I use the term loosely, that PHP puts in your way is that it lets you get away with what, in other languages, is disallowed because it doesn’t follow the paradigm.
I disagree with this entirely. The difference fundamentally being that in procedural programming you have functions that act data given to them and in OOP you have a method that acts on the data encapsulated in the object. It’s a nuanced difference but the difference between $num->abs() and abs($num) is larger than you think. They are totally different ways of thinking.
If all you’re using classes for is to organize functions then you’re clearly not thinking in an OOP way.
Tom, I’m sure you and anyone who agrees with you knows a few more languages than PHP, because it takes learning a few languages to get used to that fact and learn how to “think like a programmer.”
One correction though that I’m sure you’re aware of that I’ll just put out for the benefit of those following the thread - not all languages are Object Oriented. And there are at least two major forms of object oriented inheritance. So thinking like a programmer to my mind speaks to learning how to do more primitive things - work with arrays, understand data types, use controls structures, work functions and write procedures.
Personally I find the dichotomy between procedural programming and object oriented programming to be false. The latter is merely a way of organizing procedures.
1 Like
Agreed. Having “cut my teeth” years ago with BASIC GOTO’s it’s not been easy to get into “OOP-think”. But splitting apart code into more manageable “chunks” doesn’t seem to me to be that much of a deviation from what logically would happen naturally during “code maturition”
1 Like
Nope, there are much more differences than that. Procedural programming is for amateurs, its good and only good for absolute newbies to learn programming, except in pure procedural languages like C in which it is the only way to go. It is a habit very easy to develop for those who used to be designers and only use PHP as embeded language for their HTML pages. But this is a habit to get rid of before its too late.
OOP on the other hand, is the standard for modern, efficient and professional programming. In real life, you wont be able to find a good job as coder if you dont know about OOP(unless you are a C or Fortran programmer, but thats not what I mean by modern programming). OOP offers the best way to organize code, and its power lies in OOA and OOD(analysis and design). It has overhead, but it makes future development a lot easier and you wont be rewriting or repeating your code often, if at all.
When I detect a newbie still writing procedural code, Id recommend him/her to switch to OOP immediately. However, the transition from procedural to OO aint that easy, just by using objects doesnt mean you are thinking the OO way. I wont say any further since it will likely to get way too long, but at least now you have the idea. As Tom said, if your definition OO is merely a way or organizing functions and procedures, you aint thinking the OO way yet.
I agree that other languages (prime examples being java and c#) essentially force you to think in an OOP way which helps you learn but there’s no reason you can’t learn those things in PHP alone. The only barrier, and I use the term loosely, that PHP puts in your way is that it lets you get away with what, in other languages, is disallowed because it doesn’t follow the paradigm.
I disagree with this entirely. The difference fundamentally being that in procedural programming you have functions that act data given to them and in OOP you have a method that acts on the data encapsulated in the object. It’s a nuanced difference but the difference between $num->abs() and abs($num) is larger than you think. They are totally different ways of thinking.
If all you’re using classes for is to organize functions then you’re clearly not thinking in an OOP way.
I too have to strongly disagree with this statement - that sort of thinking leads procedurally trained developers into treating classes as silos into which they can dump libraries of related functions.
A class that behaves like a handy container for library funcs is not an object in the proper sense. It will have a very muddled interface and no distinguishable identity of its own.
These two statements
require("database.lib.php");
$db = new Database();
should be very different things indeed.
Should this be branched off into it’s own topic? The discussion seems to be drifting away from “Are today’s major frameworks capable of enterprise capable applications?”
Remember what I said earlier about bombast and arrogance? I’m getting a bit sick of it.
There’s such a large world out there… http://en.wikipedia.org/wiki/List_of_programming_languages_by_type
Your argument is so hilariously bad you can’t even get it out of your own mouth without starting to attach caveats. Stop and think about that for a moment.
There are a ton of languages beyond C and Fortran, some quite new, that either aren’t object oriented, or do not require their user to approach them in an object oriented way.
I personally am a pragmatist. If the problem at hand is best handled by object modelling, that’s what I do. If a straightforward procedure gets the job done then I have no shame in writing such. I have nothing to prove to anyone.
[quote=“TomB, post:72, topic:114913”]
I disagree with this entirely. The difference fundamentally being that in procedural programming you have functions that act data given to them and in OOP you have a method that acts on the data encapsulated in the object. It’s a nuanced difference but the difference between $num->abs() and abs($num) is larger than you think.[/quote]
Or smaller than you think. As I said earlier, at the end of the day, it’s all jump statements to the computer.
Well, the word paradigm implies that does it not? And, unfortunately, with ways of thinking comes zealotry and all the associated anti-social behavior towards anyone who would dare use a different paradigm.
I’m well aware they are two different ways of thinking. That’s why I usually get one Hell of a laugh anytime I see Java Script code written by an old hand at Java - prototypical inheritance is far more powerful in certain contexts than classical OOP, but most classical programmers (including myself for a time) would just use prototypical inheritance to emulate classical inheritance. To truly unlock Java Script requires changing mind sets.
And then there’s the node.js programmers who try to micromanage processor transactions with callbacks to the point where their code becomes so overwrought it surpasses assembly in complexity - with none of the attendant speed advantages.
These collapses are all due to a refusal to adapt to the problem scope at hand. One of the most hilarious parts of one of Tony’s rants to me was him quoting Ramus in support of the monstrosity he calls a framework over standard PHP frameworks when, in truth, he’s calling PHP programmers out for clinging to PHP when the time has come and gone to move over to C++ or something more suited to the task at hand.
Procedural programming has a time and place. If you use object oriented programming in that time and place you’ll likely end up with an inefficient bloated pile. The reverse is also true for, as a rule of thumb, procedural programs are and should be small, rarely larger than a single class file in the first place. If you have a 9000 line procedure then congrats if it works I guess - I wouldn’t want to touch it.
1 Like
To the computer a for loop is identical to the same line of code however many times. You’re missing an important point: We don’t only write code for the computer, we also write code for humans. The only reason we think about program structure, design, how things are split up are for humans, as you say, the computer doesn’t care.
“Does the code produce the intended output” is of course always the primary concern but other questions like “Can this be achieved in a more efficient way?”, “Can the code easily be understood by another developer”, “Can the code be reused for another application?”, “Can the code be easily changed to perform a similar but different task?”, etc, etc, are equally valid when it comes to software design.
Like I said, “A different way of organizing procedures.” Also, for what it’s worth, a better way most of the time. And not just the code of the procedures, but also the concepts underlying those procedures.
That’s simply not true or a gross oversimplification. There is a huge difference. The main one is: In OOP you never call a specific implementation of a method, you call a method depending on the type of the variable you’re calling it on abs($num) will always call the same method whereas $num->abs() will call a different method depending on the type of $num
Let’s put it this way: If it were purely organisational you could change any instance of $foo->bar() to bar($foo) and the code would produce the same result… which is clearly not going to be the case.
If I say that I have no use for something, it is NOT the same as saying that they are totally useless. For example, if I say that I have no use for a bicycle pump it is because I don’t have a bicycle. That is not the same as saying that bicycle pumps are useless. People with bicycles find them very useful, and if I had a bicycle I would too.
Incorrect. This is the description of autoloaders from the PHP manual:
I do not have to write a long list of needed includes at the beginning of each script, so I do not have the problem which this solution is supposed to address. So if I don’t have the problem then I don’t need the solution.
Get the microscope off the bark and look at the whole forest. If you want to call that over simplification that’s fine I suppose. Continuing the analogy, spare me the lecture on the differences between walnut trees and chestnut trees when I’m talking about the forest as a whole.
Some people may find them useful, but I don’t, the major reason being that I do not build web sites, I build enterprise applications. These are totally different animals which need a different type of framework. I have tried writing the same type of application with some of the more popular frameworks, but I found it painfully slow. The main criticisms I have against the popular frameworks are as follows:
- They claim to support Rapid Application Development, but are nowhere near as fast as my own framework.
- They do not have the features that users of enterprise applications come to expect.
- They are not actually frameworks at all, they are merely libraries.
…which are web sites, right? Or aren’t they?
[quote=“tony_marston404, post:82, topic:114913”]
- They claim to support Rapid Application Development, but are nowhere near as fast as my own framework. [/quote]
According to what benchmark and for whom? Yourself? Could it be your being faster with your own framework is due to your “inside” knowledge compared to what you know about other frameworks and what is available in them and how they work?
What features are you talking about? I bet a lot of the “features” you miss can be gotten through plug-ins, modules, bundles, other libraries, components, etc. How many third party additions have been made for your framework?
Mere libraries? Right. They are actually more often a good number of libraries, just like any good framework should be. Remember, frameworks and modern PHP code should be modular? As a matter of fact, the Symfony dev team is working hard towards making its components (those libraries) even more modular for 3.0.
Scott
Once again it’s this very bizarre notion that “I solve the problem in a different way therefore I don’t have the problem”. Yes you do. The problem that autoloaders solve is… loading files. If you are using require_once to load your classes you… have the problem autoloaders solve, you are just solving it a different way.
As I said before it’s like saying “I don’t have the problem a car solves, I get the bus”. It conflates the problem with the solution. Just because you get the bus doesn’t mean you don’t have the problem (Transportation) it just means you didn’t solve it with a car… the same applies here.
Of course the reason you argue using these semantics is that you know the logical next step to admitting to you solve the problem with a different approach is that enables the discussion to progress to “So which approach is better?” to which you already know the answer and know yours to be measurably inferior which is why you attempt to block that discussion with factually incorrect statements like “I don’t have the problem X solves”.
Ironically, yes, those popular frameworks are working towards a more modular, component library based approach making them eminently more suitable for enterprise level development than the vendor lock-in/golden hammer approach of yesteryear’s monolithic frameworks.
1 Like
Not in my book. A web site is open to members of the public whereas an enterprise application is restricted to employees of the enterprise. For a full description read Martin Fowler’s article at http://www.martinfowler.com/bliki/EnterpriseApplication.html. The two are different animals as they require totally different features.
[quote=“s_molinari, post:83, topic:114913”]
According to my own experience, and the experience of others. Development using popular frameworks can only be timed using a calendar - my framework uses a stopwatch.
What other frameworks may be able to provide with plugins - which require effort to install and configure - are provided “out of the box” with my own framework. Here I am talking about dynamic menus, Role Based Access Control, Audit logging, Workflow, et cetera.
I suggest you look at the wikipedia definition of a framework at http://en.wikipedia.org/wiki/Software_framework. The simplest definition I have found is very easy to understand - if you have to write code to calls its components, then “it” is a library. If it has components which can call your code then “it” is a framework. You should be able to use the framework to both generate your application components and then run those components.
It does not matter how many modules a library may contain - if you still have to write reams of code to use those modules then its still a library and not a framework.