Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 3.0 Final is out (1998)

web.archive.org

Post reply on HN
Print view View original

161–170 of 176 posts

Re: PHP 3.0 Final is out (1998)

#161

Post by anon776 »

cutler wrote: post #61
anon776 wrote: post #40

PHP 7.x and Laravel really gave the language its big boy pants. Really fun to develop in and looks nothing like the PHP 3.x and 5.x grime.

Sadly along with Laravel and Symfony came PSR culture where idiomatic PHP, with its fanfold docblock comments and double-spaced lines of code means you're lucky if you can see a dozen lines of code on a typical screen. I don't call that productive at all.

I agree, thats some bad practice and people think its good. I am part of the Uncle Bob clean code fan club. If you need comments and a doc bloc then there is something wrong with your code.

Re: PHP 3.0 Final is out (1998)

#162

Post by 542458 »

kalleboo wrote: post #87
542458 wrote: post #18

Earlier quoted context omitted.

As somebody who loves PHP, some PHP mockery is deserved. The standard function naming and argument ordering is inconsistent and stupid. It throws errors written in Hebrew. There were fundamental decisions made that harmed web security for years. Unicode wasn’t in PHP for a long time. Getting decent performance and/or scaling was/is a major challenge. The comparison tables are questionable at best. Etc. The language i…

> Facebook has made more money with questionable PHP code than any site built with elegant pearl webscripts that I know of. Wasn't Amazon originally written in Perl?

AKAIK Amazon was a hodgepodge, with the front end being mostly C with a custom templating engine that could (eventually) run a subset of pearl for scripting. More C/C++/Java/Pearl was using for backend and internal tooling. So kinda sorta, but definitely not in a way that seems elegant to me :)

Re: PHP 3.0 Final is out (1998)

#163

Post by seanp2k2 »

kyriakos wrote: post #100
29athrowaway wrote: post #86

Earlier quoted context omitted.

If you need to cook an egg, you can serve 1 request per second with PHP and use your CPU as heat source.

Performance is the last thing one can blame php for. Its quite fast for a non compiled dynamic language and most bottlenecks are usually I/O and db access

+1, once you get the right indices in place, MySQL 4.x would scale just fine to millions of rows per table. Innodb and Percona were even better. Maatkit was amazing for tuning, as was xdebug.

When you just had expensive queries that were already optimized, you’d use IPVS, haproxy, apache, or RR DNS to help. This was before nginx existed. Static caching pages using Perl scripts to crawl the site and write out everything static as html files worked well too. Varnish was a real game-changer when that came out.

Edit: forgot about Gearman for distributing work as well. Now people probably build the same types of things using SQS and functions.

PHP was never the bottleneck, and the web could definitely “feel” faster back then on hardware an order of magnitude or two slower than we have today with these >10MiB index pages, CDNs and parallel downloads be damned.

Re: PHP 3.0 Final is out (1998)

#164

Post by waheoo »

iforgotpassword wrote: post #123
waheoo wrote: post #111

Earlier quoted context omitted.

I still don't like using foreign keys. They just make things harder to work with for very little gain. Wait for the crows.

Care to elaborate? It felt like the best thing ever when switching to InnoDB.

Elaborate on what? They're an opinion that data integrity is dependent on foreign keys containing pointers at existing data.

In systems where actual row deletion doesn't actually happen its kind of a pointless kick to the nuts.

Now I have to create things in a specific order for no reason other than foreign keys say so. When you're using uuids for reference keys you're not beholden to what order you insert you can have these things span databases or have separate systems do the insert.

For a naive example, maybe I have an order A, and two orderliness A1, A2, why do I have to create A before I create A1 and A2. Why can't I loadbalance those three operations to different systems that insert at different timings.

Eventually they all line up, and my system is resilient enough to be ok with that.

With foreign keys you're just beholden to some feigned idea about data integrity but it's mostly bullshit.

The other common situation is when you need to backup tables and restore them elsewhere in whatever order you want, foreign keys just get in the way.

Re: PHP 3.0 Final is out (1998)

#165

Post by flippinburgers »

that_guy_iain wrote: post #152
flippinburgers wrote: post #149

Earlier quoted context omitted.

I am not familiar with tooling designed to allow non-programmers to deploy. For a programmer, a single binary is trivial stuff. My point being you can drop a golang in any linux environment and it will just run. It doesn't get simpler than that.

I understand what your point is, it is just your point is invalid. You say you just drop a golang binary into any linux enviroment and it'll just run. Except it won't. If I just upload the file it won't just run. I need to run the binary. Literally, you need to do more than just upload the binary to the enviroment. Where as with PHP with many hosters you do just need to upload the files and it is deploy. As you said…

Systemd.

Whatever you think it is that is simple about php, I am certain there is plenty happening behind the covers that you are unaware of. An environment built around supporting php is required.

A compiled golang binary only needs a linux system. That is it. Very, very simple.

Re: PHP 3.0 Final is out (1998)

#166

Post by that_guy_iain »

flippinburgers wrote: post #165
that_guy_iain wrote: post #152

Earlier quoted context omitted.

I understand what your point is, it is just your point is invalid. You say you just drop a golang binary into any linux enviroment and it'll just run. Except it won't. If I just upload the file it won't just run. I need to run the binary. Literally, you need to do more than just upload the binary to the enviroment. Where as with PHP with many hosters you do just need to upload the files and it is deploy. As you said…

Systemd. Whatever you think it is that is simple about php, I am certain there is plenty happening behind the covers that you are unaware of. An environment built around supporting php is required. A compiled golang binary only needs a linux system. That is it. Very, very simple.

> Systemd

Doesn't restarted failed processes last time I checked. Maybe I'm wrong but I am pretty sure there is a reason every sys admin I know uses supervisord to manage long running processes.

> Whatever you think it is that is simple about php, I am certain there is plenty happening behind the covers that you are unaware of. An environment built around supporting php is required.

You are as wrong about that as you are as wrong about golang being as simple to deploy. You're just consisently wrong.

> A compiled golang binary only needs a linux system. That is it. Very, very simple.

Golang binary requires the deployer to have linux system knowledge. Uploading files does not require that it requires FTP client knowledge at most or in some cases the ability to use a web based file manager.

Requring knowledge core operating system functionality do deployments is not simple. Just because a techincal person can do it, does not mean it is simple. If you can not teach your grandma to do the deployment it is not simple.

Re: PHP 3.0 Final is out (1998)

#167

Post by welly »

dimitrios1 wrote: post #76
Seattle3503 wrote: post #13

Earlier quoted context omitted.

> I’m still not certain even today, if anything exists that is faster to get a dynamic site up and running than PHP. With PHP you can just start typing in your file and produce output. Even with lightweight frameworks like Flask there is boilerplate.

This ignores the monstrous complexity of setting up PHP (and php-fpm) on a host machine. I prefer fully contained targeted binaries these days.

Monstrous? It couldn't be any more simple, if you even have to go through the process of setting up PHP. Hosting options that support PHP are two a penny, probably literally.

Re: PHP 3.0 Final is out (1998)

#168

Post by bruce343434 »

tannhaeuser wrote: post #147
GuB-42 wrote: post #142

Earlier quoted context omitted.

PHP have htmlspecialchars() and parameterized queries since 2000.

1. XSS != SQL injection 2. Adding a bunch of bogus escaping routines isn't an excuse for an incredibly poorly conceived off language, or continuing using it in production in the presence of superior solutions. In fact, I'd go so far as to say if you're selling PHP solutions/consulting in this century for apps managing ecommerce or any other kind of PII, you should demand your customer signs a liability waiver. If you…

What should php do then? What's the alternative language that handles this better?

Re: PHP 3.0 Final is out (1998)

#169

Post by tannhaeuser »

bruce343434 wrote: post #168
tannhaeuser wrote: post #147

Earlier quoted context omitted.

1. XSS != SQL injection 2. Adding a bunch of bogus escaping routines isn't an excuse for an incredibly poorly conceived off language, or continuing using it in production in the presence of superior solutions. In fact, I'd go so far as to say if you're selling PHP solutions/consulting in this century for apps managing ecommerce or any other kind of PII, you should demand your customer signs a liability waiver. If you…

What should php do then? What's the alternative language that handles this better?

For traditional PHP apps wishing to continue SSR and server-side templating, integrate HTML-aware templating (PHP has always been half there considering embedded PHP is using SGML processing instructions; it "just" needs to offer additional, more sophisticated, injection-free SGML entity-based mechanisms).

For highly dynamical apps, consider porting to JavaScript on the client side, and use PHP only as a service backend language. That's what I understand newer PHP frameworks are doing; but this will only be attractive for migrating legacy PHP apps rather than bring new users.

Re: PHP 3.0 Final is out (1998)

#170

Post by bruce343434 »

tannhaeuser wrote: post #169
bruce343434 wrote: post #168

Earlier quoted context omitted.

What should php do then? What's the alternative language that handles this better?

For traditional PHP apps wishing to continue SSR and server-side templating, integrate HTML-aware templating (PHP has always been half there considering embedded PHP is using SGML processing instructions; it "just" needs to offer additional, more sophisticated, injection-free SGML entity-based mechanisms). For highly dynamical apps, consider porting to JavaScript on the client side, and use PHP only as a service back…

I don't see the upside to the effort of porting to js. You still have all of the same pittfalls. Yes, you can build a DOM with 20x the code and 1/20th the performance ... or you can just call htmlspeciachars() in php. Yup, security is tedious and you need to stay on your toes.
Post reply on HN