Live data from Hacker News

In many ways PHP is just now starting to come into its own

gist.github.com

121–130 of 133 posts

Re: In many ways PHP is just now starting to come into its own

#121
I think many developers on here evaluate programming languages solely based on technical merits without considering business needs. PHP's sweet spot currently makes it the wisest choice for many small business projects.

When you're talking about any project that's less than a thousand lines of code or so, PHP's weaknesses don't really present a major problem and its strengths (ease of deployment, ease and ubiquity of hosting, having a bunch of necessary features for websites from DB access to email built into the language) are ideal for smaller organizations, particularly those without a full-time technical staff.

Think about how many small businesses out there (restaurants, real estate agents, a simple online store) just need 1 or 2 basic dynamic elements (simple DB access, a contact form, some validation on an order form, maybe sending a confirmation email on a sale) on their website to work to enhance their business. PHP is a great choice for these types of projects - a good portion of non-technical small businesses don't need anything more elaborate than this.

I wouldn't recommend PHP for large or ambitious projects, as other alternatives like Node and Rails are likely better fits. But when you have a very simple small business project, PHP is by far the best choice for a lot of these types of projects.

Re: In many ways PHP is just now starting to come into its own

#122
post #6

Earlier quoted context omitted.

How would they fix it anyway? It was never really designed, it just evolved as a slow accretion of features using whatever syntax was convenient in the parser codebase over a couple of decades. The author makes a good point that people like me who ditched PHP in the mid-2000s should probably stop complaining about it since we don't really know the current state of affairs. The problem is when we have languages like R…

(can't reply to your reply so here goes) I'd argue that PHP came out of the gate with some pretty powerful properties, too. They hit a sweet spot of * Being there at the right time (none of the "good" languages in your book was around or usable for web dev at the time of PHP4 and PHP5 came out) * Being easy to learn - giving beginners quick rewards. * Being powerful enough to do quite a bit more than "simple web page…

"In all i feel PHP has moved the web forward tremendously."

Agreed, wholeheartedly. I truly dislike PHP as a language, but one cannot deny the massive impact it had in making web applications commonplace.

Re: In many ways PHP is just now starting to come into its own

#123
post #55
post #49

Earlier quoted context omitted.

"Personal Home Page"?

> Zeev Suraski and Andi Gutmans rewrote the parser in 1997 and formed the base of PHP 3, changing the language's name to the recursive acronym PHP: Hypertext Preprocessor. http://en.wikipedia.org/wiki/Php#History

Yes, to get back to my point, it is basically a templating language for HTML, hence the hypertext. I think the name made it clear being ambitious with it outside of HTML was going to be difficult, unless you like the challenge of making cars into airplanes, and submarines in to hang-gliders.

Re: In many ways PHP is just now starting to come into its own

#124

Earlier quoted context omitted.

Enough with the "JavaScript is a functional language" myth, please. Merely having first-class functions does not make a language a functional programming language. JavaScript does not promote the use of pure functions, referential transparency, and the minimization of state. JavaScript does not encourage the use of recursion. JavaScript has an atrociously broken type system, rather than a robust and theoretically sou…

JavaScript's design is clearly much more coherent than PHP's. Whereas PHP's developers have added features haphazardly over several years, the JavaScript language hasn't changed much since its initial design in 1995. Warts aside, having a (barely) complete initial design that was done by one person over a short time and has since been mostly left alone is an advantage. And JavaScript is flexible enough that library a…

A bad programming language that remains bad for nearly two decades isn't really any better, in my opinion, than a bad language that undergoes some change that may have mixed results in the end.

JavaScript is bad. PHP is bad. They're both bad in many of the same ways, and they're bad in different ways. None of this changes the inherent fact that they're both bad programming languages.

Of course all programming languages have "warts". Very few, however, have as many horrible and inexcusable "warts" as JavaScript and PHP do.

As an industry and as a community, we can do better than JavaScript and PHP. In fact, we have already done better in the past (sometimes many years ago), many times over.

So, yes, I will speak out against programming languages that are inherently broken and inferior, and even extremely harmful, whenever I get the chance. It's the right thing to do.

This is not about my ego, or about my "superiority", or about me at all. This is about doing things properly, as an industry and as an entire community of programmers and software developers. JavaScript and PHP are very clearly not acceptable programming languages to use, even if a lot of people make the mistake of doing so.

Re: In many ways PHP is just now starting to come into its own

#125
post #91
post #39

I'm just wondering, why should it take 15 years to get operators [] and -> to work with any subexpression (and to my knowledge it's still not 100% there)? Shouldn't it be implied and kind of automatic in a programming language? Or why should it take 15 years to adopt [...] as an array constructor in a language where arrays are one of the central data structures? Here is opinion No. 823,664,783 about PHP from a long t…

It is indeed in bad hands. No language designer / guru ever that I know ever come close to exploring its Good parts. I'm talking Anders Hejlsberg / James Gosling / Douglas Crockford level here...

I wouldn't say that Crockford really "explored JavaScript's good parts".

Rather, he just covered parts of JavaScript that shouldn't be used, and whatever wasn't completely broken was considered to be "good". It isn't truly good, however. It's just not "severely bad" like the rest of JavaScript is.

Re: In many ways PHP is just now starting to come into its own

#126
post #23

I wish people would stop trying to defend PHP against "the haters" - firstly because no amount of reasoned argument is going to change the views of fundamentalists, and secondly because they are a minority group whose opinions are unlikely to inhibit the rise of the PHP ecosystem.

The people you refer to as "haters" are usually just professional software developers. As professionals, they don't stand for the unjustifiable inferiority exhibited thoroughly by PHP and JavaScript. So of course they'll speak out against such programming languages.

And contrary to your beliefs, what they say does have an impact. We wouldn't see so much emphasis on web development using languages other than PHP and JavaScript if what you were saying is true.

Re: In many ways PHP is just now starting to come into its own

#128

Earlier quoted context omitted.

JavaScript's design is clearly much more coherent than PHP's. Whereas PHP's developers have added features haphazardly over several years, the JavaScript language hasn't changed much since its initial design in 1995. Warts aside, having a (barely) complete initial design that was done by one person over a short time and has since been mostly left alone is an advantage. And JavaScript is flexible enough that library a…

A bad programming language that remains bad for nearly two decades isn't really any better, in my opinion, than a bad language that undergoes some change that may have mixed results in the end. JavaScript is bad. PHP is bad. They're both bad in many of the same ways, and they're bad in different ways. None of this changes the inherent fact that they're both bad programming languages. Of course all programming languag…

I take issue with your recurring assertion that JavaScript is bad. Not just that it isn't to your liking, but that it's objectively bad, something that the software development community ought to avoid. JavaScript's bad parts have been discussed to death, so I won't rehash them; it's enough to point out that programmers can easily get used to avoiding or working around them. What's more important is that there are good things about JS which make it very desirable as a cross-platform, general-purpose programming language. Specifically:

1. JS is the native language of the Web platform. Because of its ubiquity, the likes of which Java, Flash, and Silverlight never achieved, the Web platform is an attractive deployment target for many apps.

2. Because of JS's role in the Web platform, it has the support of every major player in personal computing, specifically, Apple, Google, and Microsoft. Languages like Python, Ruby, and Lua have nowhere near that level of corporate backing.

3. Yet no single company owns JavaScript, so there is no patent trap as with Java or .NET. Nor is there any threat of vendor lock-in.

4. Because of the strong corporate backing and the fact that most Web browsers are now based on open-source engines, there are mature, open-source, non-copyleft implementations of JavaScript for all major desktop and mobile platforms. (The "non-copyleft" bit is in contrast with, say, Mono, whose license enables Xamarin to charge a premium for use in iOS, Android, and Mac apps.)

5. Because JavaScript is the native language of the Web platform, full-stack Web application developers basically know it to some extent, regardless of what language they prefer on the back-end. So many programmers know JavaScript, making it an attractive choice for a software company wanting to hire more programmers, or an open-source project looking for contributors.

6. Because of the competition among browser developers in recent years, all of the major JS implementations are now very fast.

7. Unlike C and C++, which are AFAIK the only languages that match or exceed JS's ubiquity, JS guarantees memory safety. This eliminate a whole class of bugs that many programmers are not equipped to deal with or prevent. These bugs often turn into security holes.

So these qualities, largely political and business-related but important nonetheless, make JS very attractive to anyone wanting to choose a mainstream, high-level, general-purpose programming language for cross-platform application development. In light of this, how can you say that JS is objectively bad?

Re: In many ways PHP is just now starting to come into its own

#129
post #104
post #80

Earlier quoted context omitted.

I would actually argue that using PHP as the templating language in a PHP MVC application has become the majority use case. Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself? There are cases where you may need to do this (if you can't "trust" the templates for example and you need to enforce som…

> Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself? From past experience: to stop shittier developers at your company putting controller logic in the templates. Using something that does nothing but templating ensures that your templates do nothing but present data.

I addressed that in my post actually. If you have shitty developers in your company who can't follow business rules, PHP isn't your problem.

Re: In many ways PHP is just now starting to come into its own

#130
post #108
post #80

Earlier quoted context omitted.

I would actually argue that using PHP as the templating language in a PHP MVC application has become the majority use case. Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself? There are cases where you may need to do this (if you can't "trust" the templates for example and you need to enforce som…

With templating systems which 'compile' templates down to php anyway, that might be a distinction without a difference.

Fair enough. I know Smarty does this and caches the PHP-ized version.

I guess the difference could come from how efficient the template-to-PHP compilation is, but I bet you're right and it's trivial in most cases.

Post reply on HN