IMO one of the key missing points here that is not really considered, is that when you use a well documented and relatively mature framework, it greatly simplifies some of the non-programming related aspects of software development, particularly with regard to getting new developers up to speed, and ensuring that even your junior-most developers are able to contribute without having to become heavily acquainted with your specific implementation of authentication, file uploads, routing, etc.
PHP the Wrong Way
61–70 of 194 posts
Re: PHP the Wrong Way
#62Is it me or is the author confused about the distinction between a library and a framework?
To me, a framework implies inversion of control: you don't call the framework's code; the framework's code calls your code.
Granted, he skirts the issue with phrases like "A framework is a system that helps you build software, but at the same time it forces you to work within the limitations and restrictions of the framework itself", but this describes what a framework achieves, not what it is.
Call me pedantic, but this I find this indicative of poor understanding, and this article raises a number of red flags along these lines, such as this gem:
>PHP on the other hand was created from the beginning by Rasmus Lerdorf as a set of tools written in C that would enable you to easily and quickly develop dynamic HTML. As such PHP was, and still is, a framework in and of itself.
Uh... what?
Maybe I'm overstepping my bounds, but this article is furthering certain stereotypes about PHP-programmers.
Re: PHP the Wrong Way
#63PHP community had always been anti-frameworks and anti-libraries. I worked at company where use of third-party libraries was entirely forbidden on most projects. I think it's because: - Quality of PHP frameworks is low (at least it was last time I used it) - PHP parses and evaluates whole libraries and framework code on each requests. There's proprietary commercial (lol!) software to enable at least caching of byteco…
If you haven't used PHP since composer became a standard in projects, you don't know modern PHP.
Re: PHP the Wrong Way
#64Earlier quoted context omitted.
> Are you aware that php has a built in auto loader that supports namespaces and is written in C? What are you referring to?
Probably spl_autoload [1]. [1] https://secure.php.net/manual/en/function.spl-autoload.php
that's what I thought poster might have meant, but.... it's not an autoloader, it's a way of registering autoloader code.
Re: PHP the Wrong Way
#65Earlier quoted context omitted.
You may be drowning in the kool-aid. It is very easy to write tiny secure code in PHP without a framework. Of course if you're building a social network, then it will run into some of those potential security issues. But for most of the small problems you're using PHP to solve, you really don't need to be a security expert as long as you're not piping user input directly to your database or OS. It's kind of the point…
> It is very easy to write tiny secure code in PHP without a framework Actually it isn't, like at all. A open source framework will always be more secure than the code you "easily write", because a larger pool developers can review,audit,test and fix that code.
Sure, the framework code will be more secure. But you still need to solve your problem and your framework isn't going to do it. So you have to write code.
The code you do write is going to be more secure if you know what's going on. If it's on top of a billion line framework, you might accidentally break the security without even realizing it. No legions of framework developers reviewed, audited, tested or fixed your actual code.
Re: PHP the Wrong Way
#66Is it me or is the author confused about the distinction between a library and a framework? To me, a framework implies inversion of control: you don't call the framework's code; the framework's code calls your code. Granted, he skirts the issue with phrases like "A framework is a system that helps you build software, but at the same time it forces you to work within the limitations and restrictions of the framework i…
No, you are correct. Most developers today would understand a framework includes your code, as where with libraries, your code includes them.
Re: PHP the Wrong Way
#67I just skimmed the website, and I am still not sure if it's meant seriously or if it's some kind of joke? Feels a bit contradictory eg. "dont use framework" vs "make software secure by default". Isn't a security one of the gains of using frameworks, beside other things? You would need to be a security expert to cover all potential security issues when writing something from a scratch.
You can also build horribly insecure applications with a framework. A framework does not absolve you from thinking, which seems to be the point the author is making.
There's a difference between frameworks and libraries and of course it is a good idea to use trusted crypto implementations and avoid NIH syndrome, but a large part of security is including it in the design process from the start.
You can't just assume "the framework will handle it", or "bcrypt is all I need" or "the opsec team will find all the problems".
It rather sounds like you're expecting the author to hand you a magic-bullet solution, which is rather the whole point of the article: there isn't one. You do need to know what you're doing.
Re: PHP the Wrong Way
#68Earlier quoted context omitted.
The very existence of PHP is a contradiction, so I wouldn't sweat to much about it. But speaking of boolean logic, negating "always use a framework" does not yield your interpretation.
"The very existence of PHP is a contradiction" Uhm no for me coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes. PHP is a hammer, bla…
PHP is pretty objectively bad. For every thing PHP does decently well, something else does it better.
Except for this one weird trick: PHP absolutely bulls-eye nothing-but-net nailed deployability before deployability was even a word. In 2000, you could download an installer that set up Apache, MySQL and PHP on your Windows box (and it worked, first time and every time), you could fire up Notepad and 15 seconds later look at "Hello World" in your browser. Then you could upload that PHP file to a web hotel at $10/month and the world could see that same Hello World perhaps 10 minutes after that.
Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.
That's why PHP is so popular.
1: in zero-to-one deployability for a new user -- the full development and deployability experience just a tiny bit up the learning curve is orders of magnitude better.
Re: PHP the Wrong Way
#69So the author considers following PSR guidelines beyond 1 and 2 to be "the wrong way"? PSR-4 is the currently accepted best practice for autoloading and while it "may [have] a direct effect upon how you code your software," it's the optimal approach for 99% of projects I've encountered. Following community interoperability guidelines is what allows developers to move away from monolithic frameworks and compose projec…
> currently accepted best practice for autoloading According to who? FIG? Are you aware that php has a built in auto loader that supports namespaces and is written in C? > compose projects based on the packages they need. Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development, where you end up with 50 "micro-frameworks" or "utility lib…
> According to who? FIG?
According to the vast majority of authors of the most widely used and tested PHP libararies.
> Are you aware that php has a built in auto loader that supports namespaces and is written in C?
You mean the autoloader builtins that composer uses under the hood already? This is better than a 1 line include how exactly?
> Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development
I don't understand what you're saying here, everyone should be writing their own libraries from scratch? It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.
Re: PHP the Wrong Way
#70Earlier quoted context omitted.
It's really easy to make up statistics on the spot with absolutely no source. I very much doubt that people would be getting paid to write any code if they couldn't implement a single for loop in their primary programming language.
PHP was the first language I ever used professionally. The code I wrote - the code every single one of my colleagues wrote - was atrocious. We were paid bottom dollar ($30k in 2008) to write absolute shit code. The PHP community in my area was the same. All newbies, all paid barely more than a fast food manager, all writing code that could be taken down by a HS student with Fiddler. I'm sure different experiences exi…
My experience mirrors yours exactly but with one difference - we were using .NET (C# specifically).
I'm now a professional .NET contractor (among other things) and looking back at the code we wrote 7 years ago terrifies me. Thankfully I'm not responsible for maintaining it anymore.
I suppose the point is that incompetence is language-agnostic. :)