PHP needs to die. What will replace it? • Hacker News Board

Re: PHP needs to die. What will replace it?

#81

Post by eropple » Wed, Oct 05, 2011, 8:59 PM UTC

MartinCron wrote: post #64

michaelchisari wrote: post #10

The article states that php doesn't have lambdas and method chaining, although it does. They aren't well done, as per usual, but it definitely has them. Honestly, we may be best off doing a CoffeeScript style pre-processor for PHP. Because PHP isn't going anywhere, no mattter how much we may prefer other languages, PHP's popularity is one of pure pragmatism, something the language purists don't seem to understand. Ge…

Get me from 0 to "Hello, World" as fast as you can. That's how you build the next PHP. I understand why that is, but I can't help but think that it's optimizing for an edge case instead of the whole operation. I'm willing to invest a little bit longer to get to "Hello World" on day one if it means a lot less pain for every day to follow.

Most of the people using PHP almost certainly disagree with you. (Most of the people who have a clue about PHP, i.e. @fabpot and crew, may not disagree so strenuously, but I would suggest that they are the edge case.)

Re: PHP needs to die. What will replace it?

#82

Post by pak » Wed, Oct 05, 2011, 9:00 PM UTC

sciurus wrote: post #68

berntb wrote: post #25

Earlier quoted context omitted.

>>Does the author know anything about PHP at all? The author doesn't know about any other languages either, it seems. I stopped reading when he argued that PHP's assocative arrays was an advantage; hashes/dictionaries are in all the scripting languages. (Afaik, they come from AWK by the way of Perl, anyway -- they were created many years before PHP existed.)

When I read >> the critical thing Perl was lacking was PHP's wonderfully flexible "associative arrays" I grabbed my copy of "Learning Perl" from 1997. Chapter 5's topic? Hashes.

Perl hashes don't preserve order. PHP's almost always do. i.e., the order you insert keys is the order in which you will receive them back when you iterate over the array. It's similar to a LinkedHashMap in Java.

CS types might recoil at the mixture of behaviors that are baked into PHP's workhorse data structure, but most of them turn out to be quite useful. (And it makes it easier for the beginner programmer to decide what data structure to use: you have keyed data? a list of data? a set of values? doesn't matter, just use an array!)

Re: PHP needs to die. What will replace it?

#83

Post by georgieporgie » Wed, Oct 05, 2011, 9:01 PM UTC

Roughly a decade ago, PHP killed Perl. Not completely, of course; it still clings on in some environments, it has a sizable legion of die-hard fans, and legacy apps will need to be maintained in it for decades to come. But as a language for newcomers, and especially for web developers, it was already dying in 1999 and was mostly dead by sometime around 2005.

Uh. http://www.indeed.com/jobtrends?q=perl%2C+php%2C+ruby

I think newbies just found easier languages to work with than Perl for web dev, which says nothing about the use or demand for Perl in industry.

Re: PHP needs to die. What will replace it?

#84

Post by kemayo » Wed, Oct 05, 2011, 9:01 PM UTC

xd wrote: post #80

kemayo wrote: post #72

To replace PHP you need: 1. To be on all shared hosting everywhere. I.e. you need to be really easy to install, and preferably not involve long-running processes that shared hosts might choke on. 2. To be beginner friendly. No requirement of understanding MVC, or running commands in a shell (hi RoR!). Pure instant gratification. Someone's first step into using PHP is likely going to be "I want the current date in the…

Are you saying that developing an API in PHP is insane?

No, I'm saying that the stuff built into PHP is weird and inconsistent. I should change it to "sane default library" from "sane API".

My current favorite example of this (ignoring the naming scheme for string functions entirely) is that in_array and strpos are functions that perform (almost) the same task, on two different types. They take their arguments in the opposite order. strpos($haystack, $needle) vs in_array($needle, $haystack).

Re: PHP needs to die. What will replace it?

#85

Post by xd » Wed, Oct 05, 2011, 9:03 PM UTC

ajross wrote: post #77

kemayo wrote: post #72

To replace PHP you need: 1. To be on all shared hosting everywhere. I.e. you need to be really easy to install, and preferably not involve long-running processes that shared hosts might choke on. 2. To be beginner friendly. No requirement of understanding MVC, or running commands in a shell (hi RoR!). Pure instant gratification. Someone's first step into using PHP is likely going to be "I want the current date in the…

Yeah, exactly. This headline could have been written with the same justification in 1999. Yet PHP refuses to die. Clearly us hackers are missing something important.

The fact it actually solves real world problems would be a first "something important" us so called hackers are missing.

Re: PHP needs to die. What will replace it?

#86

Post by escoz » Wed, Oct 05, 2011, 9:04 PM UTC

dagw wrote: post #40

pjscott wrote: post #16

Earlier quoted context omitted.

If installing Rails (or Flask, or whatever) isn't trivial compared to the difficulty of writing the actual code, then either your project is a toy, or your web host needs to get its act together.

I take it you have never tried to get major changes to core server infrastructure approved at large bureaucratic institutions. Writing your code in php is often orders of magnitudes faster, easier and cheaper than getting a decent RoR setup installed.

That's your experience, and highly subjective. And yes, I deploy code to dozens of enterprise servers for a global company. And that company is looking into Rails, not PHP.

Re: PHP needs to die. What will replace it?

#87

Post by FuzzyDunlop » Wed, Oct 05, 2011, 9:05 PM UTC

PHP is a nightmare, but only once you learn enough about programming or development to understand what you should really be doing, and only once you've seen how other languages do it.

After that comes PHP's special flavour of OOP. I'd prefer to call it 'Do Whatever The Fuck You Like Orientated Programming' given the abundance of 'magic methods' and other functions that try really hard to make sure you've got a cheeky workaround for something you can't be bothered doing properly (creating countless security issues in the process). And that's before you start using classes as pseudo-namespaces for collections of static functions.

The disappointing side is that someone who learns PHP before anything else will have a heart attack when they realise that very little of what they know applies the same to another language.

It's so loose and care-free that it doesn't care what you do or how you do it. (Not helped by the mountains of useless tutorials and documentation that teach awfully bad practices.)

So I guess the thing I dislike about PHP is that I learnt to use it but it didn't give me good programming skills.

Re: PHP needs to die. What will replace it?

#88

Post by FooBarWidget » Wed, Oct 05, 2011, 9:09 PM UTC

joelhaasnoot wrote: post #39

generalk wrote: post #34

Earlier quoted context omitted.

One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to. For example: you can update the Rails code on the server, maybe run some data migrations or last-minute production tasks against the new codebase, and THEN tell Passenger to reload the application code. O…

Lots of PHP folks call that a disadvantage... It's nice knowing I can mess with files and after pressing F5 I'll always have the latest version. Yes, ok, caches can get out of sync, but they're easy to clear. There are furthermore no good PHP deployment automations, things Rails and Python have because of the level of complexity.

You claim that deployment automations for Rails and Python exist because of the complexity? Have you ever worked with PHP apps that are larger than 1 single file and use the database? Things like Capistrano do a lot of things that even PHP would benefit from.

Deployments are rarely atomic actions. With Capistrano, apps are stored in versioned release directories. Apache points to a 'current' symlink which points to the latest release directory. Upon deployment, Capistrano creates a new app directory, runs database migrations or updates configurations or creates asset files or whatever is necessary to upgrade the app. Only after it's done will it update the 'current' symlink and instruct the app server to restart.

Consider what happens if you upload your new PHP app with FTP. If someone visits /some_page.php while you're uploading then he could access an old version of it. Suppose some_page.php depends on common_library.php which may have been updated to the latest version in the mean time. Then things blow up because the new common_library.php is not compatible with the old some_page.php. With Capistrano, the deployment is as good as atomic.

Capistrano also supports deploying to multiple servers at the same time, and even to servers that are behind a firewall and can only be accessed through a gateway server. It supports rolling back to a previous version. And much more.

Re: PHP needs to die. What will replace it?

#89

Post by dagw » Wed, Oct 05, 2011, 9:11 PM UTC

MartinCron wrote: post #65

dagw wrote: post #40

Earlier quoted context omitted.

I take it you have never tried to get major changes to core server infrastructure approved at large bureaucratic institutions. Writing your code in php is often orders of magnitudes faster, easier and cheaper than getting a decent RoR setup installed.

major changes to core server infrastructure approved at large bureaucratic institutions It sounds like you've already lost.

How so? I find out what I have to work with, work within the limitations set, deliver what the client asks for (if I feel it can be done in a reasonable way) and collect my paycheck.

Re: PHP needs to die. What will replace it?

#90

Post by podperson » Wed, Oct 05, 2011, 9:14 PM UTC

jordanlev wrote: post #28

One word: deployment To me, the best thing about PHP is that it is so easy to deploy to pretty much any shared hosting on the planet, not to mention really easy to set up on your local machine (with WAMP/MAMP). I love Rails, but on many occasions have built projects in PHP (using a decent framework like Kohana) just because I was putting this on my client's shared hosting account and didn't want to deal with having t…

I agree completely. It's why I started using PHP and why I continue to use it.

I think the only thing around right now with a realistic shot of replacing PHP is JavaScript with node.js, but it will require widespread deployability. If and when node.js becomes easy to deploy on cheap hosts it has a huge number of wins over PHP (to begin with -- one less language to learn, and then even more importantly node.js understands the web page it's buildings and no other server-side language does this).