Hacker News new | ask | show | jobs
by hguhghuff 2591 days ago
The thing that matters is language consistency... A language with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the language adheres. Nothing here says PHP has been fixed in this regard.

Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.

The only thing that would have really interested me in this post would have been to hear that PHP had been cleaned up into a consistent syntax, but that's not what this article says.

7 comments

I've been coding in PHP for almost 20 years now. I think I can count on one hand the number of times where I have had an issue regarding inconsistent function signatures. It becomes second nature, and if I forget, the documentation is available online or in worst case built into my IDE.

I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PHP.

23 years here (php/fi in jan '96) and I probably hit the 'parameter order' issue more than you. I still need to look param order stuff multiple times per year. Normally I can get it in the IDE, but doing remote vim stuff, for example, I need to look it up.

Yes, it's technically a non-zero problem. I get it. Having spent several years in the Java/Spring world, the classic ASP world, and the Perl world... they all have problems, both with the languages and the ecosystems. There will always be people who will throw out Rust or Go or Erlang as 'better' by some metric.

For the types of projects I work on, the modern PHP stacks of the last 5-6 years are all probably the best ROI. Colleagues/friends are running medium-sized SaaS on Rails, and it works, but we compare headaches sometimes, and it's not carefree in the Rails world. There's issues there. Regardless of whether your language is 'clean' or 'discoverable', the rest of the ecosystem can still present problems.

Since you mentioned Perl, I wonder if you've tried Mojolicious at all and what you think of it? I've found it pretty nice to work in, and easily scalable to small and large projects.

That said, I don't have is a lot of experience with other frameworks in other languages to compare it to, so I don't exactly know how it compares.

That's what really gets me.

Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever think i've tried something without first checking the docs just to see about any surprises or differences)

Consistency is nice to have, but it's pretty far down the list of requirements in my opinion. If it's different for some, I can see how they wouldn't like PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque" move seem really misguided. People who program in PHP regularly don't really mind the warts, and the language has improved significantly in areas that it's users found most important. Types slowly working their way into the language, easy closures, traits, nice new operators, and the massive speed and memory usage improvements have all been very welcome improvements that have made me more productive in the language.

The time spent on "cleaning up" the standard library would be a welcome change by most, but it wouldn't really have any material impact for me or any of the other PHP devs I know.

For a while it was popular to just create your own functions with your own naming convention and parameter order, easy to do and you have whatever order is sane for you. Lots of frameworks around now so you don't even have to do that any more.
See, I code php very rarely, I review php code a bit more often, and I stumble upon these inconsistencies all the time. So because you got used to something bad doesn't mean it's not bad.
That would break too much things and the benefits will not be enough. They could add some new things, deprecated the old things and keep them all but then you get a manual twice as big. All the changes in PHP feel pragmatic, like better SQL support, better cryptography support, better defaults, better performance and less on cool looking syntax or latest cool features.

IMO pragmatic is good, especially when you have to use an existing code base and you have to upgrade it to the latest supported version you don't want a Python 3 migration story(I migrated a medium project to latest version and the only problem was a cryptographic function that was used to generate some random looking strings that was deprecated, I replaced with the new safer function and done , my project is now compatible with the older and the new version).

I don't disagree with your points -- but then it turns out that PHP is still the same old crappy language it was ten years ago.
Is that and more, I mean everyone uses classes and namespaces now and structures code better so there is this improvement. Projects use autoloaders now and things again are better.

Have a look for example http://image.intervention.io/getting_started/installation how you would resize an image if you used a framework, it is much different then you would see in a code that was written 20 years ago.

My point was, people can still shoot themselves in the foot if they read an old tutorial. This should not be possible in newer versions. That would be a true improvement in my eyes.
But then that means breaking backwards compatibility, stranding huge parts of the internet on older versions, splitting the community into "pre-massive-change" and "post-massive-change", and a LOT of work by both PHP maintainers and "users" for what will end up being a marginal increase in dev happiness and practically zero material benefit for anyone.

And that still doesn't solve the problem of bad blog posts... You can't control what others write about the language, and if someone writes some posts or has a website with bad information, the maintainers of the language can't "fix" that. The best they can do is what they already do, make sure the PHP documentation is among the best and most approachable of the languages that I've used.

It is a good point but it is a big disadvantage for the people that need the backward compatibility, is the same issue with C++ or other similar old languages that keep the backward compatibility so old code continues to work.

Though if you work on a new project or existing project that uses a framework you will not even need to do the bad search queries like "how to insert an user in a mysql table", the framework is forcing you to use the correct/safe patterns.

Most beginning level tutorials are super simplified and are not following the correct patterns, like they don't check for errors, don't clean user input etc.

You mean to say that namespaces and classes are an improvement?
Yes, you mean you want everything in a global space, you have then issues where 2 dependencies define the same type named "Task" and on dev machine a different Task is initialized then on production (it happened to me when working on an old code base that was not using namespaces).

If you are an anti OOP person then I would prefer not to debate here religions.

> Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.

People keep saying it was a huge failure, but honestly, I don't see how it was supposed to be done better otherwise. Either you make breaking changes that will impact your entire ecosystem or you don't and live with the same cruft from 20 years ago.

Rust did it with its "edition" system, where you can freely mix and match modules from the 2015 edition with modules from the 2018 edition. Unfortunately, in the Python 2 to Python 3 transition a fundamental data type (strings) changed, which would make freely mixing Python 2 and Python 3 code much harder.
In retrospect, for me many of the problems would have been fixed it they'd wrapped everything in one release, like gcc with the -std flag.

Then once someone had (say) python 2. 6 I'd know they also have python 3.2, and I wouldn't have to figure out that name of the executable to call, it would just be python, with (perhaps) either a command line option or a comment at the top of the file.

> The thing that matters is language consistency.

To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.

That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.

The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.

Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.

If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.

> That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

As you said, PHP was merely an interface to (many already existing) modules written in C. When people complain about mysql_real_escape_string() in PHP they don't realize that that is the actual name of the function in the MySQL C API. Same with the image functions (imagemagik). And so on. Some are named directly after the corresponding C standard library function.

This was actually part of the huge success of PHP -- it made available, for the web developer, a huge library of existing open source technology. This did not exist, in a scripting language, before PHP. The open source community wasn't as large.

But PHP does have high-level abstractions and, like with other languages, you would also use a framework that has high-level abstractions.

If you compare PHP to JavaScript, PHP's standard library is far superior. But it's a ridiculous comparison there as well.

> The problem is that PHP wasn't designed as language-first but a tool to make web development more accessible.

Yes, but all the ways that PHP as-a-language were less than ideal most of those have been solved now. So unless you're complaining about the standard library, there isn't much left.

> Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.

Nowadays there really just isn't that much difference in design or performance between PHP and the majority of languages you would suggest.

Genuine question, because I do not know the answer. Does it support:

Lexical scoping

Coroutines

Generators

Decorators

Generic type containers

A functional API (e.g. something like Java 8 streams)

An extensive selection of data structures (collections) included in the standard lib

?

> Lexical scoping

Yes.

> Coroutines

No.

> Generators

Yes.

> Decorators

No.

> Generic type containers

In progress. But also PHP has dynamic/weak typing and static/strong typing so this isn't strictly necessary.

> A functional API (e.g. something like Java 8 streams)

Available as a 3rd party library.

> An extensive selection of data structures (collections) included in the standard lib

https://www.php.net/manual/en/book.spl.php

Thanks for the thoughtful response. But based on your answers, PHP does lag significantly behind other modern languages. FYI the SPL you linked is quite meager compared to languages like Python and Java.

My opinion remains unchanged. Using PHP in 2019 only puts you at a disadvantage when compared to the alternatives.

> The thing that matters is language consistency... [...] Python made the big leap and fixed some huge problems when it went to python 3

And yet, here we are over a decade along and the Python project is still maintaining Python 2 and I still need to maintain a copy of Python 2 on my computer because of the number of actively maintained projects still using it. How many developer-hours that could have gone into doing something else have instead gone into this "language consistency" project?

At any point in the past 25 years someone could have forked PHP to clean the syntax up and accomplished the exact same thing -- and yet apparently nobody has seen the inconsistency as a big enough issue or time sink to do so. I would take that as prima facie evidence that this isn't nearly as important as you seem to think it is.

Meanwhile, one of the strengths of PHP in my opinion has been how carefully they have maintained and managed backward compatibility. While "move fast and break things" might be the new norm, there is still a huge contingent of developers and businesses that see value in slower, more considered change.

What are you talking about is just a syntax. Which is not an issue for a PHP dev nowadays. I am typing much more custom method names than vanilla PHP functions. And when I have, my IDE shows me the right syntax after a few keystrokes.

So, it's apparently a good reason to hate, but by no means a reason not to use PHP.

I often run into this argument - "inconsistent syntax", followed by zero proof. Then I wonder - is the person making the comment even using PHP or is the person behind the comment.. even capable programmer?

Yes, PHP has been "cleaned up" and you have always had the option to use clean, concise way of coding without language interfering or hindering you in any way.

There's no programming language out there that makes up for the sloppiness and inability of the person behind the screen.

Back in the PHP 3/4 days, a lot of related functions would have different argument orders.

str_replace(old, new) vs. stri_replace(new, old) kind of thing.