Live data from Hacker News

PHP – The Right Way

phptherightway.com

341–349 of 349 posts

Re: PHP – The Right Way

#341
post #277
post #149

Earlier quoted context omitted.

Certainly. One mistake was that PHP was chosen, when it really was unfit for the task at hand. Another one was that CMSes like WP or Drupal were shoehorned into projects that were really unfit for them. etc. But also being unable to upgrade underlying PHP versions due to breaking changes, or just p*ss-poor, bug-ridden PEAR packages. As well as the language design prohibiting proper TDD, isolation, etc. I explicitly s…

I would imagine that your team picking WP or Drupal and attempting to shoehorn in your use case had more to do with your projects failing than PHP itself. I see that happen a lot in the wild, and not just with PHP. I bet you could have picked a python/node/c#/go CMS with a similar outcome.

I consider WP and Drupal (And Joomla and magento etc) all part of the PHP ecosystem. I consider them part of PHP.

Just like Rails is part of the Ruby ecosystem. Technically, it is wrong to blame Ruby for poor design decisions made in Rails. Like Rails monkeypatching stdlib classes. But Rails can monkeypatch stdlib classes because Ruby lets it. It did a lot of monkeypatching stdlib classes, because it was common thing to do in the Ruby ecosystem back then. So, I therefore, place just as much blame on those poor decisions in Rails as I place them on the language, Ruby. Whats more: I blame both for promoting this idea in the first place. A new dev may open the Rails code and conclude "if a popular framework is doing X, X is probably a good way to solve my issue".

The latter is, and always has been, my largest gripe with PHP. No, WP is not a good example to learn proper PHP development, but it is the thing most new PHP devs encounter PHP and are then stuck with horrible "best practices" for the rest of their carreer.

Re: PHP – The Right Way

#342
post #242

Earlier quoted context omitted.

Better tools lead to better outcomes if all rest remains the same, so I don't think that holds true even if we ignore the fact that languages (and their communities!) incentivize different things and can certainly lead to better code. Its certainly a lot easier writing good Python than good C, for a quick example.

True, but they are somewhat different tools with different purposes, writing an operating system in Python is a bad idea and doing web in C is cumbersome. Thus I wouldn't blame Python if I used it for something it wasn't designed for, similar I wouldn't blame the screwdriver if I used it for punching a nail into a board. There seems to be a constant drive to have one language to rule them all, instead of using specia…

> it is actually designed with that in mind.

One of the gripes that I -and many- have is that PHP wasn't ever "designed" in the first place.

This is changing. Has changed. But for people, like me, who started with PHP back in the 3.x days, and left in the 5.x days, PHP has a bad history. It might overcome this, or already have. But the history sticks to it.

And it begs the question: why make PHP into a new Python, or Ruby or JS, if we already have a Python or Ruby or JS (or Typescript)? Because if any language is actually designed (for a broad sense of that term) for the Web, it is JavaScript.

Re: PHP – The Right Way

#343

Earlier quoted context omitted.

Do you deploy to Linux images on AWS? I'm actually very interested in your dev setup. Do your devs use Linux machines? What IDE?

Great questions. I am going to write a detailed article about it because you are not the first person asking these. We have two deployment modes: - lambda - ec2 instance Depending on how you would like to target Lambda you have multiple options. On ec2 too. We use VS Code on both Linux and MacOS. The tooling is kind of meh at the moment, Ionide is not ready for prime time we run into issues frequently with it. We are…

Terrific, thank you!

I still use EC2 for everything, I haven't explored Lambda yet. I look forward to your article, thank you. Is dev.l1x.be where it will be posted?

Re: PHP – The Right Way

#344

Earlier quoted context omitted.

Great questions. I am going to write a detailed article about it because you are not the first person asking these. We have two deployment modes: - lambda - ec2 instance Depending on how you would like to target Lambda you have multiple options. On ec2 too. We use VS Code on both Linux and MacOS. The tooling is kind of meh at the moment, Ionide is not ready for prime time we run into issues frequently with it. We are…

Terrific, thank you! I still use EC2 for everything, I haven't explored Lambda yet. I look forward to your article, thank you. Is dev.l1x.be where it will be posted?

Yes I am posting it there. Probably after a bit of a design update.

Re: PHP – The Right Way

#345
post #266

Earlier quoted context omitted.

> not only integers and floats, but also strings, lists and dictionaries as mutable value types (copy-on-write) Lists and dictionaries are also mutable in Python. Strings are not. With CoW, are your referring to garbage collection? (value that is no longer assigned to a name will eventually be purged). That would be independent of (im)mutability, so I'm not sure I understand.

Pretty sure they meant immutable in that quote.

No, I didn't! PHP's string and array types are neither immutable nor a reference type. In this way they are very different from what Python, JavaScript etc do.

Re: PHP – The Right Way

#346
post #248

Earlier quoted context omitted.

With copy-on-write: $a = ['a']; $b = $a; $a and $b both point to the exact same bit of memory. Thus passing an array between functions is zero-cost. When you do: $b[] = 'b'; // append 'b' a new array is allocated, the old data copied to it, and 'b' appended to it (basically, but IIRC, it is a bit more optimized than that).

So basically what FP languages do?

Well, what PHP does similarly avoids the risk of accidentally mutating shared values, but it's not the same:

• the value is locally mutable

• no duplication happens when you want to modify it and there is only a single reference

Re: PHP – The Right Way

#347

Earlier quoted context omitted.

> not only integers and floats, but also strings, lists and dictionaries as mutable value types (copy-on-write) Lists and dictionaries are also mutable in Python. Strings are not. With CoW, are your referring to garbage collection? (value that is no longer assigned to a name will eventually be purged). That would be independent of (im)mutability, so I'm not sure I understand.

so is object(array,map,etc) in javascript, many scripting languages have non-primitives mutable, the OP seems wrong on this claim(e.g. only PHP does that)

They aren't value types in JavaScript or Python, they're reference types (as are all types in those languages). Mutable value types are different from both mutable reference types (Python list, JS Array, strings in both languages, etc) and immutable reference types (Python and JS strings, Python tuples…)

Re: PHP – The Right Way

#348
post #342
post #242

Earlier quoted context omitted.

True, but they are somewhat different tools with different purposes, writing an operating system in Python is a bad idea and doing web in C is cumbersome. Thus I wouldn't blame Python if I used it for something it wasn't designed for, similar I wouldn't blame the screwdriver if I used it for punching a nail into a board. There seems to be a constant drive to have one language to rule them all, instead of using specia…

> it is actually designed with that in mind. One of the gripes that I -and many- have is that PHP wasn't ever "designed" in the first place. This is changing. Has changed. But for people, like me, who started with PHP back in the 3.x days, and left in the 5.x days, PHP has a bad history. It might overcome this, or already have. But the history sticks to it. And it begs the question: why make PHP into a new Python, or…

PHP was made for the web and yes it was never formally designed, more of an ad hoc evolution, thus string functions differ from array functions and so on.

Today however in respect to the many improvements, not only for the language itself but also to tooling, frameworks and libraries, this is largely irrelevant.

And this is also the case when it comes to history, the past is the past, when comparing technologies it needs to be an up to date comparison and not how it was 20 years ago. And with a relevant comparison PHP has won that every time, today as in the past.

But it seems like many out there carry around these grievances about PHP and even if they know that PHP has changed they can't let go, thus we are no longer in the realm of technology but in the realm of the human psyche.

JavaScript early days was similar to PHP early days, ad hoc evolution made by one person. It was much later JavaScript became more formally designed with committees, standards and backed by billion dollar companies.

But JavaScript was actually never designed for the web, it was designed for the DOM, a browser technology. It was much later that JavaScript got things like template literals, tagged templates and multiline strings, these things are essential when doing web, things that PHP has had from the start.

If your language can't put out a proper HTML document without doing tricks it sucks as a web language. Early days of JavaScript was full of unreadable string concatenation, arrays as string builders and just a bunch of functions calls to the DOM API. It was awful.

Because PHP is a community driven language and it is not backed by billion dollar companies, PHP does not afford to invent new language constructs out of the blue or take the risk of designing fringe features that could potentially alienate large group of programmers, PHP needs to stay mainstream so to speak, thus the design of PHP is largely affected by what is happening in other languages, good and bad.

Funny thing here is that much of the criticism against PHP is that it is becoming a Java like language, where Java on the other hand is designed language, but still Java has become a mess with things like Collections, Iterators, Iterables and Streams - all work differently and requires clunky casting between them, and then the checked exception and unchecked exception debate, especially combined with Streams where checked exception is non-compatible.

Thus somewhere along the line a language that historically was designed becomes a language based on evolution because of the simple fact that we still can't predict the future. Therefore the "not designed" argument can eventually be applied to every other other mature language or at least large parts of it.

Re: PHP – The Right Way

#349
post #28

Earlier quoted context omitted.

There is 'use as'. But it is infuriating having to namespace your code when a folder name/heirarchy could do.

Doesn't that shield you from FS/OS impl though? I often found it the only reasonable explanation (for java too)

I still haven't worked out how to phar.

Is this problematic for archive distribution?

Post reply on HN