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

25 Years of PHP

jetbrains.com

Post reply on HN
Print view View original

281–290 of 426 posts

Re: 25 Years of PHP

#281

Post by ragnese »

jimmaswell wrote: post #271
ragnese wrote: post #255

Earlier quoted context omitted.

I feel like your reply needs a little more context. Is the first part of responding to my claim of "effectively no top level functions"? If so, my response is that no public code seems to use them and they're much more of a pain in the butt to use because the PSR-whatever autoloader stuff only picks up classes. It's way more idiomatic to write static methods on a class- exactly like Java. "Everything" is a reference…

No public code uses echo, strlen, function_exists, is_array, count, or intval? I find this really hard to believe.

I'm trying to give you the benefit of the doubt here, but I'm really suspecting that I'm just falling for a troll.

I'm talking about WRITING PHP code. You don't WRITE top level functions. Every data type you WRITE is a reference type.

In C++, it is common to write top level functions in a namespace for others to use. In C++ you can write a class/struct and pass it to function BY VALUE. In Java and PHP you cannot pass by value, except for primitives (which you cannot author yourself).

Your PHP code will be semantically almost-identical to a similar project in Java. Not so with C++.

Re: 25 Years of PHP

#282

Post by sfteus »

donatj wrote: post #134
jonny383 wrote: post #6

PHP is damn fast now, no joke. And with all of the modern features it's actually not so bad to work in. I'm becoming increasingly puzzled every time I see PHP hate now, especially when I read tired comments like "just use rails". Laravel is arguably as good or even better than rails at this point, and PHP 7+ is definitely light years faster and lighter. One thing that still sucks is package management / composer.

This is honestly the first I’ve ever heard anyone complain about composer. Having experienced a number of other package managers, composer is by far my favorite. Like have you spent any time with npm? Composer is light years ahead in reliability and expectations matching reality.

The amount of fighting I've had to do with setting up NPM for legacy applications, or with any sort of virtualization is insane. I no longer set up Node/NPM on anything automated without NVM, since they seem to drop support for old packages at random. You have to jump through a ton of hoops to make NVM play well when it's effectively installed by root but ran by another user within the container. Running NPM in a unix VM on Windows means you have to update everything with --no-bin-links since symlinks aren't well supported, and there is no fallback. It's baffling that they haven't had some sort of manual copy management when a symlink can't be created.

Meanwhile, I setup composer in a docker file in 4 lines (download, run, move to bin, cleanup), and it works everywhere for any user, respects permissions, etc. I don't think I've run into a single error on composer that wasn't something like a mis-typed command, package, or a host being down.

Re: 25 Years of PHP

#283

Post by malinens »

thkim wrote: post #194
elric wrote: post #32

I wrote a lot of PHP from 1999-2008. First as a hobby, then professionally. From 20 LOC guestbooks to payment gateways used to process millions in payments. It wasn't until recently that I was sure I'd written more code in any other language than PHP. These days I'll occasionally poke around with it or patch a bug, but that's about it. Is it a perfect language? No. But which language is? (I can hear the Lisp crowd gr…

Nothing "wrong" with PHP itself, but it's clearly not designed for modern web programming patterns which makes it feel outdated. No separation of model-view-controller, not friendly for API or AJAX, no class structure until later add-on, and so on.

it's the most friendly kanguage for ajax. Nothing beats json_encode in simplicity

Re: 25 Years of PHP

#284

Post by [deleted] »

spacedcowboy wrote: post #229
ragnese wrote: post #224

Earlier quoted context omitted.

You're moving the goalposts. PHP was a great option in 1995. It is not today (except as a basic scripting language, where you and I agree completely. I would use PHP as soon as my bash script gets to about 100 lines). Your post here is arguing about 1995 or whatever. The post I replied to was full of present-tense about "just use the good parts" and "all languages have issues", etc.

That's ... fair comment. My apologies, I have a bad habit of not clicking on parent to see what the context of a post is.

[deleted]

Re: 25 Years of PHP

#285

Post by lillesvin »

ragnese wrote: post #277
lillesvin wrote: post #269

Earlier quoted context omitted.

Yeah, I noticed after I'd missed your reply there the first time around. Sorry. I'm still confused about the array keys though. I'm not sure I understand the example you gave in your other comment. And I'm also curious which Apache and Nginx has PHP installed and enabled by default.

The array key thing doesn't crop up often, but I've had it happen. Sometimes you are parsing something, such as "all files in this directory" and want to use the filename as the key and maybe store metadata or something as the value. Well, the second one of those filenames looks like a number, you're basically screwed. Now your array has some string keys and some int keys and operating on it is inconsistent at best.…

Yeah, alright, I understand your example now but I would argue that it's more of a problem with actually using filenames as array keys than it is a problem with PHP.

Even so, wouldn't you be able to ensure that it's a string by doing `$array[(string)$filename] = ...`? (Again, I don't think using filenames for array keys—in any language—is a good idea but we're theorycrafting here.)

Re: 25 Years of PHP

#286

Post by ragnese »

meritt wrote: post #232
ragnese wrote: post #230

Earlier quoted context omitted.

For sure. But let's be clear- I'm not "demanding" anything. I don't want PHP to change, I don't want to use PHP at all. I don't like dynamic languages. BUT. Today's "best practices" for PHP are to use typehints everywhere. And there are language changes in the works to add MORE typing to PHP.

> I don't want to use PHP at all. I don't like dynamic languages. Okay, so don't? I think individual languages are better when they don't add every feature under the sun that happens to be popular in the moment. PHP doesn't need threads and it sure as hell doesn't need async. PHP multiprocessing works the old way just fine (fork). > Today's "best practices" for PHP are to use typehints everywhere. Yeah, and it's a re…

The problem isn't about a preference between dynamic types and static types. I do think the tacked-on type system of PHP is pretty poor. But even without the mediocre type system, PHP still sucks. You want dynamic? Do Clojure, Lisp, Python (eh), Elixir. PHP and its broken foreach loops and lack of concurrency need not apply (and who in the world believes that forking a process is a good enough for EITHER concurrency OR parallelism for a backend programming language in this day and age?).

Re: 25 Years of PHP

#287

Post by conradfr »

mschuster91 wrote: post #46
jonny383 wrote: post #6

PHP is damn fast now, no joke. And with all of the modern features it's actually not so bad to work in. I'm becoming increasingly puzzled every time I see PHP hate now, especially when I read tired comments like "just use rails". Laravel is arguably as good or even better than rails at this point, and PHP 7+ is definitely light years faster and lighter. One thing that still sucks is package management / composer.

> One thing that still sucks is package management / composer. How? I mean, what are the problems with it?

Personally it's mostly composer update and require that fail in docker or a VM because of the memory requirements, otherwise it works well.

Also I hate json for config files because you can't comment things.

Re: 25 Years of PHP

#288

Post by DonHopkins »

ragnese wrote: post #168
waheoo wrote: post #157

Earlier quoted context omitted.

I dont agree with you at all. Why are you building arrays with mixed key types? Why do you want type hints? Why do you need generics in a dynamically typed language? Php has pthreads. They just arent needed that often. Async is being worked on You didnt mention it but immutable types are also being worked on. Everything people complain about php over tends to actually make its way into the language eventually. I dont…

> Why are you building arrays with mixed key types? It happens on accident. All keys are converted to ints if they can be. So if you read a file that is called "123", it'll suddenly become an int key whereas all the rest will be strings. That's absolutely insane. > Why do you want type hints? The same reason anybody does. It is a contract and it makes your code more well-documented, more robust, and more correct. The…

“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act.”

— Ken Pier, Xerox PARC, Preface to The Unix Haters Handbook

https://web.mit.edu/~simsong/www/ugh.pdf

Re: 25 Years of PHP

#289

Post by ragnese »

lillesvin wrote: post #285
ragnese wrote: post #277

Earlier quoted context omitted.

The array key thing doesn't crop up often, but I've had it happen. Sometimes you are parsing something, such as "all files in this directory" and want to use the filename as the key and maybe store metadata or something as the value. Well, the second one of those filenames looks like a number, you're basically screwed. Now your array has some string keys and some int keys and operating on it is inconsistent at best.…

Yeah, alright, I understand your example now but I would argue that it's more of a problem with actually using filenames as array keys than it is a problem with PHP. Even so, wouldn't you be able to ensure that it's a string by doing `$array[(string)$filename] = ...`? (Again, I don't think using filenames for array keys—in any language—is a good idea but we're theorycrafting here.)

> Yeah, alright, I understand your example now but I would argue that it's more of a problem with actually using filenames as array keys than it is a problem with PHP.

No. Just no. There is no reason, a priori, that you can reason that filenames shouldn't be keys in a hashmap. I think you're just projecting from "can't be done reliably in PHP" to "software should not do it" which are NOT the same things. Seriously. What is it about filenames that causes you to think "No. There's never a good reason to map a filename to data without defining a whole new type"? What other things scream out to you that should never get to be keys for dictionaries? Names? Planets? Flavors of candy? Would you really believe this if you were working in another language?

It's exactly this reasoning that drives me nuts about PHP. You can point out the most insane behavior and someone always comes by and says "Nothing to see here. Just don't do that." Or "I just know not to do that, therefore PHP is fine."

> Even so, wouldn't you be able to ensure that it's a string by doing `$array[(string)$filename] = ...`? (Again, I don't think using filenames for array keys—in any language—is a good idea but we're theorycrafting here.)

Nope. Doesn't fix it. Because it's only converted to an int after being passed in. $filename was already a string. You're casting a string to a string and PHP, in all its wisdom, is then making it an int.

And I think it speaks to my point that you tried and failed to solve the issue. That's not an affront to you, by the way. It's more evidence that PHP is impossible to do correctly.

Re: 25 Years of PHP

#290

Post by meritt »

ragnese wrote: post #286
meritt wrote: post #232

Earlier quoted context omitted.

> I don't want to use PHP at all. I don't like dynamic languages. Okay, so don't? I think individual languages are better when they don't add every feature under the sun that happens to be popular in the moment. PHP doesn't need threads and it sure as hell doesn't need async. PHP multiprocessing works the old way just fine (fork). > Today's "best practices" for PHP are to use typehints everywhere. Yeah, and it's a re…

The problem isn't about a preference between dynamic types and static types. I do think the tacked-on type system of PHP is pretty poor. But even without the mediocre type system, PHP still sucks. You want dynamic? Do Clojure, Lisp, Python (eh), Elixir. PHP and its broken foreach loops and lack of concurrency need not apply (and who in the world believes that forking a process is a good enough for EITHER concurrency…

Okay. Good luck.
Post reply on HN