He never said he doesn’t find it useful - only that his framework doesn’t need it. He made that pretty clear…
No, he specifically said “I have no use for them.” “No use” = “not useful”.
That’s not what that means and you know it.
If you have “no use” for something, you are by definition saying it is “Not useful”. If you use something it is, by definition, “useful”. I’m not sure how you’re reaching a different conclusion.
If you honestly can’t see the difference between the two then I can understand why this thread has been going on for months.
Let’s flip it around, Tony, in his own words is actively avoiding using autoloaders because “he has no use for them”, or in other words “he doesn’t think they’re useful”.
I’m not sure what’s tripping you up…
Precisely. I have no use for autoloaders in my framework simply because I do not have the problem for which they are the solution. It is those developers who implement a solution just because it is there and not because they have the problem for which it was designed who are creating bad code.
- Do you have more than one class in your system?
- Are those classes in different files?
If yes to the above (and based on the previous thread I know that is true) then you have the problem which autoloaders solve. Your argument, again, rests on this idea of “I don’t have the problem that X solves” because you don’t correctly understand what the problem being solved is.
No, I’m not sure what tripped you up.
I don’t know how Tony’s quote is relevant other than being demonstrably and factually incorrect. Tony solves the problem in a different way but he does have the problem which autoloaders solve.
It’s like saying “I don’t have the problem that a car solves, I get the bus”. It’s a non-sequitur. The problem is transportation, the bus is an alternative solution, you still have the problem.
1 Like
Yup, I’d actually call it an improper paradigm. I said it earlier, Tony is living in his own world and his argumentation is only a defence of that world and absolutely has nothing to do with the actual arguments at hand and why the arguments go in circles. It is also why he constantly comes back to his own framework and doesn’t speak about “frameworks” in general or about OOP practices in general or about coding in general. He can’t, because his paradigm doesn’t let him. He just needs to realize, he is in that paradigm and it does him no good to be in it.
It reminds me of a story I once read in a self-help book about success. The story was to demonstrate what it means to think one thing and be totally wrong about it. It goes like this.
A man got onto a subway train and sat down next to another man. There were two children, around 8 or 9 years old, running around the train and basically misbehaving badly. Yelling. Screaming. It was obvious the children belonged to this man, because they kept running back to him saying, “Daddy, when will we get home?”. They kept on with their bad behavior.
The man sitting next to the father was becoming irate. He was thinking, “Why in the world doesn’t this guy correct his children? What a lousy father. All he does is look out the window. Doesn’t he realize the children are being obnoxious and annoying the other passengers?”
Then one of the children came running back and basically bounced off the leg of the man. “That’s it”, he thought. “I have to say something now!” He turned to the father.
“Don’t you think you should do something about your children? My God, I’ve never seen such poorly raised children in my life!”
The father turned his gaze to the man slowly with what looked like tears in his eyes. He said, “Oh. I’m so sorry. We are coming from the hospital, where the children just lost their mother. I guess this is their way of working off their pain.”
The man sitting next to this father, now felt really bad. He had been given a totally new paradigm of the situation. He is no longer upset with the father or the children.
You see, the man could have stayed irate and in his first paradigm. Or, he could have just stayed quiet and not said anything. That could be bad for the blood pressure though and if he had of stayed quiet, he would never have learned the new paradigm. Luckily for him, the new paradigm was easy to change to. He started playing with the children and they turned out to be lovely children after all. The father thanked him for his help and the two actually became good friends.
For Tony, I would think his hard work is what is keeping him in his self-created OOP paradigm, which is fine. He just needs to realize he is in it and either should just keep quiet, or accept the new paradigm and stop arguing and instead just LEARN!
Scott
1 Like
Indeed: http://www.logicallyfallacious.com/index.php/logical-fallacies/174-sunk-cost-fallacy
The problem with Tony’s approach in general is not that it’s antiquated or full of bad practices. In itself, that is fine. The issue occurs when he tries to justify his poorly written code to us and himself and makes claims that “X is EVIL” or that his knowing violation of important programming principles makes the principles, rather than his code, bad. Or he finds some way to pretend he is following the principles (See his argument that his 9000 line class follows SRP). It’s the incessant thought process of “If my code doesn’t already do it then it’s wrong” which leaves zero scope for improvement that really holds Tony back.
1 Like
Exactly. That logicallyfalicious site is interesting.
I think this fallacy hits the nail on the head: http://www.logicallyfallacious.com/index.php/logical-fallacies/183-willed-ignorance
Scott
1 Like
Nope they are not capable of writing enterprise applications, only Radicore can. Read Tony Marston’s article here and you will understand why. So take his advice, stay away from PHP major frameworks. You wont regret it, I promise ya! XD
I’m starting to seriously doubt this thread has any point other than bashing Tony. There is sometimes a thin line between bashing a person and bashing their ideas. The ideas Tony has put forth have not stood the test of time, but that doesn’t mean everything he’s had to say is foolish or without merit. Still it’s hard to pick those moments out and its very hard to take anyone seriously when they are making bombastic statements like those in the links above and throwing around obviously intended to be insulting acronyms like “Keep It Complicated Knucklehead.”
Lost in the shuffle of insults flying both ways is an interesting problem to me - that of deferment which I’ve sometimes derisively called ‘busybox coding.’ Some frameworks are more guilty of it than others and the worst of the lot begs the question of whether they are solving anything at all.
Let me first explain what I mean by deferment.
An application or code block can basically do one of two things with a problem - solve it or defer it elsewhere - be it a user setting through the admin panel, or config or what have you. Defer too much and what have you actually accomplished?
Magento is one of the worst offenders here - it’s config xml files are so complicated they constitute a programming language in and of themselves, and a very rotten one at that which has no mechanisms for providing error messages or conflicts at all. It’s built on Zend Platform, a poster child for over engineering among PHP frameworks.
Those who’ve been around awhile know I have a distinct dislike for template engines. The reason for this is PHP is a template engine - or at least it was. It’s now become a rapid prototyping and development language, something it wasn’t meant to be. It was meant to be a template engine for C++ apps. C and C++ can still blow the doors off PHP in sheer performance, but even an expert C programmer can’t match PHP for dev speed (stability and security are another thing).
Since C is compiled configuration deferment makes sense - recompiling code is a pain. But in PHP there’s a reason, albeit different, to use config files - to ease code upgrades and the sharing of code across large multi-person projects. As long as there’s a reason and that reason is understood do it. If not - then don’t.
At the end of the day it’s all jump statements anyway. I started with Commodore 64 BASIC, found that too ponderous to be workable and figured out how to do work in 6502 assembler. A higher level language is deferring. Building in PHP is faster than in C.
Building in Symfony 2 with Twig is faster than PHP, but the code will be slower than straight PHP and slower still than C. Building in Drupal 8 is even faster and takes considerably less skill - indeed you don’t necessarily need to be able to program at all, but a Drupal 8 site will be slower than a custom Symfony 2 site, slower than straight PHP…
With the larger projects like Symfony I’m beginning to seriously question the wisdom of having them live entirely in PHP and I’m thinking on the idea of taking at least the most heavily used pieces of that framework and writing a mirror to them in C++
The reason this loss of computer performance is tolerated at the enterprise level is a programmer’s time is nearly always more valuable than the computer’s processing time. I work in advertising - my employer needs me to be able to put out roughly one small site a week and a major one each month - I can’t do that if I code them all from the ground up. I need something to save time.
Deferment and it’s sister - premature abstraction - are pernicious. Knowing when to refactor out something is often as important as knowing how. Defer too much and you end up with Zend Platform - a framework that does nothing PHP cannot, not even save developer time.
I finally caved for at least one template engine - Twig, because unlike Smarty and all the other’s I’ve so far seen it has the ability to grant templates some degree of inheritance, which is useful. Still, the idea of running a template engine in a template engine amuses me. Then again, running a virtualized machine with Vagrant/VirtualBox on top of a normal machine also is in some ways amusing. But the reasons for both remain the same - saving time.
But that is something to keep an eye on - when you scoot something out into a config file, always ask why. If you’re abstracting out a process before you’ve used it, let alone needed to use it multiple times, you’re likely wasting time. And a lot of old hands have seen (and done) a lot of this sort of tail chasing. It’s an easy trap to fall into. It doesn’t make any of us knuckleheads stupid.
I am going to say one thing inflammatory though, and those who it applies to know who they are. If you are trying to come off as elite because of a mastery of PHP (perceived or otherwise), don’t. Just don’t. It’s just a scripting language, and a very crappy one at that (it pays my bills, but it’s probably the worst programming language ever evolved cause it wasn’t designed that’s for sure).
PHP doesn’t take a rocket scientist to figure out. If you can write code in C or assembly and write it well then you’ve got room to talk - and I say this without the ability to use either of those languages well - and my hazy memories of 6502 assembly is hardly relevant today anyway. I’m saying this because this thread and its brethren have had a bit more bombast than they need and have for awhile now, so cool it down.
2 Likes
I am guilty of throwing some mud Tony’s way. And I don’t deny it either. He hasn’t deserved anything better. He started the mud slinging with the tone in his blog posts. Some might say two wrongs don’t make it right. Tell that to the reddit crowd.
As for the problem of deferment, I think Tony is guilty of that the most. He differs back to his work and uses it as his proof for his misconceptions about OOP and his reasonings for not using well known, established design patterns and best practices. It is fine he doesn’t want to use them or follow them. It is not ok to for him to say they are wrong or “evil”, because he can’t use them or doesn’t want to.
Scott
And why I post here and not on reddit.
Scott
@tony_marston404 I believe that your framework is covered by GPL so could you place it up for review in the PHP forum? Remember it’ll likely receive both positive and negative comments
Wouldn’t that take an open mind for critique?
Scott
1 Like