Hacker News Reader

Comment by xd | Hacker News Reader

I bumped into an old friend recently and he and his wife work at a real estate company. They were raving about this new system they are a couple of years into the development of and how it's built on this great "Kubernetes" system.. they asked what I develop my products with and I almost felt embarrassed to say PHP and a couple of servers in two locations for redundancy that run Archlinux with a LAMP (LNMP? I guess with NGINX/MariaDB these days) stack .. same thing I've used for 20 years now (I was one of the first AL volunteers). When I asked what language their system is developed in they said Kubernetes, of course.

Anyway, it kind of reminds me of the days when everyone was developing a PHP Framework .. I've never used one and if I was to apply for a PHP job I'd be unlikely to succeed as I'm very specialised in getting shit done.

View on HN

Thing is if you understand php you dont really need a framework. Sure composer packages are a must to avoid rewriting whats out there, but a framework not so much. When i conducted interviews i was shocked at how many php devs had no clue about what an sql injection is, they almost all answered “the framework does it for you” and it was such a basic thing.

Oh god ORM's, pointless waste of time and just an excuse not to learn SQL.. almost as bad as the #1 PHP fallacy; Smarty (which is still a thing).

But “what if we switch to a different database engine”? Yet i’ve never seen that happen!

Edit: wait smarty still a thing!?

I used Postgres when I first started out in ~2002 but it was slow, really slow, I switched to MySQL and it was fast and the customers happy. The MyISAM table engine was shit hot(fast) but it took me years to get my head around constraints and then indexes etc to actually get a basic level of competence and realise MyISAM was a bunch of trade off's for performance. Anyway I loved PG and still do romanise it.. what if I stayed.. what could have been.. but it didn't get the job done, for me.

Edit: oh yeah Smarty is still a thing and so is PHPClasses.org whilst I think about it.. I've nothing against PHPClasses apart from it tries to pass itself off as something other than it is.. an amateur coders exchange.

This point of view is a fallacy itself. ORMs are about productivity and maintainability. Some of us write enterprise applications where ORMs are a godsend. They're not a replacement for being knowledgeable in SQL whatsoever.

It's just my opinion based on 20+ years of developing data management solutions across thousands of customers.. any framework employs a set of beliefs and that creates a box you are constrained to think in, hell SQL is one of them boxes. You say "They're not a replacement for being knowledgeable in SQL whatsoever." .. so what are they then?

Edit: I once spent/wasted almost 2 years of my life trying to develop the ultimate ORM. In the end I replaced it for a simple directory structure of API end points where every .php file does a specific job with good old SQL queries in there.

Not sure if you've used Entity Framework, but you can do compos (with logic) amazing complex queries with relatively little code in a way that is statically typed and super easy to maintain. I'm talking about pulling heavily structured data from the database without having to pull from flat tables and structure it yourself server side.

Also working with databases with thousands of tables and relationships, hundreds of developers, weekly database schema updates, etc..

We still use raw SQL, stored procedures, jobs, profiling to understand current db hotspots, etc.. ORMs have their time and place just as everything else.

But you can already write amazingly complex queries in sql, and structure them as objects directly using pdo. If there are hundreds of developers working against the same codebase then that codebase is too large. If you need to query hundreds of tables in one go you need to consider denormalisation or using a document storage.

The ORM code will be 10x smaller than the generated SQL, especially for structured data and composing queries.

Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs.

I didn't even get into entity tracking which is a whole other heavily used huge use case for an ORM.

I feel like someone debating the merits of Typescript 10 years ago. Raw SQL is a mess to maintain for the same reasons.

Can you show me an example of the 10x less code?

You're going to get a huge reduction in code for all sorts of things, especially when navigating multiple relations, grouping, sub-selects, etc..

  var results = db.myTable
    .where(x => x.value > 6)
    .where(mySpecialConditionalLogicFunction)
    .select(x => { 
      thing = x.relation.relation.relation.value, 
      thingList2 = x.relation.relations
        .groupby(y => y.value)
        .select(g => g.count)
        .orderby(y => y.value)
        .take(5),
      thing3 = x.relations
        .where(z => z.relation1.value < z.relation2.value)
        .select(z => z.relation.value)
        .max(),
      thing4 = myReusableSelectDTOfunction,
      etc..

The sql for this would be very dense, hard to read/maintain. Especially when building structured objects, grouping, filtering etc.. Those composable sub-select functions often build common dtos which ensure the same structured data is sent regardless of the api. And if the dto is updated, all queries inherit it automatically.

This brings fond memories of my early stages where i became fond of the method chaining pattern. I became fascinated by it when using doctrine.

However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems.

The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code.

Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.

Take a single line from my example 'x.relation.relation.relation.value'

The SQL would be

  select w.value
  from x
  join y on y.relation=x.relation
  join z on z.relation=y.relation
  join w on w.relation=z.relation

1 line for the ORM, 5 lines of SQL. Please give an example where the SQL is less than what I typed in the previous comment.

In addition compiling will validate the ORM code generates valid SQL. On the other hand compiling will not validate a SQL string.

'Custom functions' are just larger versions of the anonymous functions in my example. Very easy for other developers to go to the reference and understand.

Hold on, we are talking php here. There is no code compiling.

Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead.

I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language.

Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs.

Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.

With hundreds of developers and millions of lines of code - yes Typescript and ORMs will completely eliminate entire classes of bugs, and be a force multiplier when it comes to productivity.

You should never rule out a tool as 'unnecessary' even if you can't think of any possible reason for it. Try to keep an open mind here, you may not know everything.

Totally agreed re keeping an open mind. But after having used all the niceties you describe i understood that php itself is a fractal of poor design and practices. Gave up on using literally everything you described and ended up writing better code at a fraction of the time.

I do recommend reflecting on things as not knowing everything goes both ways.

I am concerned how much your posts center around you writing code and not a team. Are you concerned about maintainability? Have you written software with large teams before and have had to maintain that software over a number of years?

All good code starts with the individual. In the PHP world it starts with the collective, not much room for creativity on the assembly line, and any such attempts are met by endless debates over petty code reviews - many of which can be replaced by linters.

Of course i wrote in large teams, thats why i know that a large codebase with hundreds of people working on it is usually a sign of either bad practice (the monolith that grew too much) or high turnover (php work places are often toxic and filled by mediocrity).

Instead of ignoring my advice on maintainability, consider breaking your code into smaller chunks and write less code that doesnt solve self inflicted issues (ie your complex queries across hundreds of tables, dtos that dont solve much, custom functions for stuff that can already be done in sql). Once you do the above you wont need all of the overhead you describe and so specific to php.

My code usually lasts a good number of years, often even after i’m no longer working on it. It’s difficult to break and easy to maintain. At least thats the feedback i get from repeat clients. The teams i lead have easily delivered code that generates returns in the billions. All without the mess you describe.

It's interesting how you can observe thousands of developers utilizing Typescript and ORMs. Code bases with millions of lines. And have someone like you assume that these tools are 'useless' and solve 'self-inflicted' problems. Assume that large code bases are 'bad practice'. Assume 'breaking' something up is some amazing insight and will simply fix problems and not create new ones. Also assuming that we're not aware of these things already and have not evaluated these options such as plain javascript and raw sql.

You really think you're that above everyone else? No doubts that you might be missing something?

I appreciate your passion for php and i like our otherwise enjoyable debate, but instead of projections and a misuse of the term “assume” i would appreciate counter arguments.

Hrm I haven’t been talking about PHP, but ORMs and static typing.. If you’re working in PHP then yea I see how you’re still using raw sql probably. I don’t know of any enterprises that don’t use either .Net or Java for their large line of business apps. Definitely not PHP, static typing is relatively new to it.

I think we’d need to know a lot more about each other’s projects and experiences to continue as this debate has become a bunch of generalizations.

They're a convenience for 99.9% of use cases. For the other 0.1%, I write SQL, but to be honest, I've never had to yet.

You can deliver business value with boring glue code.

So you have 0.1% SQL skill .. work on it.

Actually a flat 0%.

Well, that the issue with php devs.

Oh I don't know any PHP, sadly. That's probably another issue with us.

You think you did a funny but you’d be surprised how many php devs dont know php.

Oh, all of them.

There is merit in this - once a php dev does get to know the language they move away to other languages. So you are indeed left with people that dont know the language.

I will be bias here as I made my own ORM (for typescript and postgre, no less), but I have to hard disagree. As other comments have pointed out, ORMs are about productivity, getting persistence done quickly.

Also what you just said is widely applicable - by your thinking, all programming languages are "a waste of time" and an excuse to not learn how to write binary files/machine code by hand?

Also, it doesn't have to be black and white - ORM or no ORM. No one is forcing you to choose between using an ORM for all of your persistence or not using an ORM for anything. It is continuous - you can use ORMs for a *proportion" of persistence logic.

Few more points, but I think the drift is caught.

“ Also, it doesn't have to be black and white - ORM or no ORM

The sad state of the php world is that there is no other option but to use it. If something is on fashion then it _must_ be adopted. Writing your own is considered insanity and so is taking a different path than the mass, regardless of for good reason or not.

I ask this question a lot too, and yeah it’s shocking to see how many that believe things like magic quotes or some other unknown layer solve everything.

Magic quotes is of course very different from an ORM doing the application-specific encoding. It’s just very worrying when people don’t know which layer of the stack sanitizes for them.

For those of you young enough to not have witnessed php. Magic quotes used to be a popular configuration option that would sanitize all GET and POST inputs to make it safe to use in sql. Needless to say, it didn’t work and instead corrupts user data that is not intended to go through sql.

Reply on news.ycombinator.com