Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP the Wrong Way

phpthewrongway.com

Post reply on HN
Print view View original

181–190 of 194 posts

Re: PHP the Wrong Way

#181

Post by joesmo »

brightball wrote: post #162
paulryanrogers wrote: post #153

Earlier quoted context omitted.

This is likely more an artifact of the PHP community and philosophy being focused on ease of use and deployment, circa early 2000's. Consider that Ruby has a few dominant frameworks--like Rails--built on a language with read-hostile features like monkey patching. Unlike Python Ruby often has many ways of doing things, and that's reflected in community gems. (EDIT: swipe-typing fail.) Regardless, there has been some c…

That's true. One of the things that I find particularly interesting is the response to this with PHP vs that of Go. As I've picked up Go, the distinct impression that I've gotten is one of total anti-framework with the idea of just pulling in the parts you needs for what you're doing. Even a general disdain for using anything that isn't in the stdlib. That seems exactly what what is being advocated for here but with…

A stupid idea is stupid regardless of language. Whether the community sees that or not also reflects on the community.

Re: PHP the Wrong Way

#182

Post by joesmo »

codedokode wrote: post #168
throwanem wrote: post #154

Earlier quoted context omitted.

> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Whereas, often, if you do use one, you end up using one, a very poor one. Sometimes you can get away with that. Sometimes you get to spend a Friday morning root-causing and reverting a production defect in a highly visible application because the developers of the extremely popular ORM you inherited failed to mention in thei…

The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something. This approach works w…

Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the opposite: total and utter shit), I'm not going to slow down all my DB queries 10x for anything, not to mention the incredibly slow development speed of now having two query languages and a million wrong ways of making simple queries and no ways of making proper advanced queries. Everything with Doctrine takes many times longer than with straight SQL even after years of working with it. I have yet to find an ORM that doesn't have egregious failings like Doctrine 2. It is inherent in the stupid concept of ORMs that implementations fail. See: http://solnic.eu/2015/09/18/ditch-your-orm.html http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and most importantly, see benchmarks for ORMs like Doctrine and observe their destructive effects on programmer productivity.

Re: PHP the Wrong Way

#183

Post by joesmo »

codedokode wrote: post #178
throwanem wrote: post #176

Earlier quoted context omitted.

So not using an ORM is bad because you then need to understand the code in detail, but even though using an ORM is good, you then need to understand the code in detail. Gotcha. Less flippantly, I've never actually used an ORM in a typed language, and I suppose it's plausible the concept offers benefits there which aren't available elsewhere, especially if arrays of mixed type aren't permissible. It sounds like your p…

ORM doesn't save you from understanding how code works. It is not a tool to avoid learning SQL or UnitOfWork pattern. But it has other advantages: you can use objects for your models, you can use lazy loading and relations between models, you don't have to save modified entities explicitly. So it helps to avoid writing low level code for saving and loading data from a database. You don't have to write routine methods…

Magento is a horrible app with one of the worst ORMs in existence. You've clearly never used it if you're touting it as an example of what to do. Because Magento is a laundry list of what not to do. ORM, EAV, XML config. Drupal may not be the greatest app out there, but it is leaps and bounds ahead of Magento. In fact, it's hard to find anything as shitty as Magento.

Re: PHP the Wrong Way

#184

Post by codedokode »

joesmo wrote: post #182
codedokode wrote: post #168

Earlier quoted context omitted.

The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something. This approach works w…

Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the oppos…

I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities).

The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around.

> http://solnic.eu/2015/09/18/ditch-your-orm.html

It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them.

He writes:

> There is no User but it’s very likely there is SignupUser.

And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them.

I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them.

I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects.

The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code).

I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there.

I also have read this article http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and I partially disagree with the conclusion. Using key-value storage instead of a database is generally bad idea. It doesn't solve "N + 1 queries" problem, it doesn't provide foreign keys (and often transactions), and you have to write messy custom code instead of shorter and better readable SQL query (example: https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQ... ).

Re: PHP the Wrong Way

#185

Post by w3clan »

We don't have to reinvent the wheel everytime we create apps or any product using framework. Like imagine , When my every product needs login / register mechanism , i would look for something that is really fast, secure and may/may not have better approach of doing that.

So, framework are basically to speed up work in same elegant way the others are doing.

Re: PHP the Wrong Way

#186

Post by throwanem »

codedokode wrote: post #184
joesmo wrote: post #182

Earlier quoted context omitted.

Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the oppos…

I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities). The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumente…

> And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others

You...really can't think in any paradigm other than object-oriented everything, can you? I mean I guess it works for you and that's great but please stop you're really scaring me now.

Re: PHP the Wrong Way

#187

Post by kbenson »

MustardTiger wrote: post #174
kbenson wrote: post #137

Earlier quoted context omitted.

Because the myriad ways public people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about all the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially cre…

> If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. No, why would it? What HTTP client framework am I supposed to be wishing they used?

Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).

Re: PHP the Wrong Way

#188

Post by MustardTiger »

kbenson wrote: post #187
MustardTiger wrote: post #174

Earlier quoted context omitted.

> If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. No, why would it? What HTTP client framework am I supposed to be wishing they used?

Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at h…

Curl isn't a framework.

>Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain?

No? What does that have to do with anything?

>Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).

Did you reply to the wrong comment by mistake or something? What does any of this have to do with me or what I said?

Re: PHP the Wrong Way

#189

Post by kbenson »

MustardTiger wrote: post #188
kbenson wrote: post #187

Earlier quoted context omitted.

Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at h…

Curl isn't a framework. >Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? No? What does that have to do with anything? >Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usu…

> Curl isn't a framework.

I wasn't under the impression we should be limiting this to frameworks. What's the difference between a framework and a library for the purpose of this discussion? I think they are functionally equivalent. I was clear to equate it to crypto originally, which doesn't really make sense when viewed as applying to frameworks only. We're a couple comments removed from that, I thought that wasn't in question. Same with an HTTP client. Frameworks don't event necessarily implement clients. I'm addressing NIH syndrome, and I don't think frameworks really deserve special consideration in any way.

> Did you reply to the wrong comment by mistake or something? What does any of this have to do with me or what I said?

See above. And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?

Re: PHP the Wrong Way

#190

Post by eonw »

MrPatan wrote: post #126
romaniv wrote: post #118

Earlier quoted context omitted.

> The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry. Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often. Not to mention that learning a new framework is not fundamentally different from learning some person's approa…

> Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often. You can't make things foolproof. Fools are very clever.

>Fools are very clever.

this is like gospel.

Post reply on HN