"You can hammer in nails with the side, sorta..."
Literally screaming at my monitor, trying to make PHP's =& operator make any god damned sense at all.
Fuck you, PHP.
"You can hammer in nails with the side, sorta..."
Tags: computers, doomed
Current Music: 2:54 -- Creeping ♬
53 Responses:
Using references is usually not a good idea, and deprecated. Could the solution you're looking for be that you create a design without them?
I have an array and I'm trying to store a pointer to it in two different arrays without it being copied. This apparently is rocket surgery. This language is a catastrophic piece of shit.
I had to learn PHP back in 2004 to work on a volunteer organizing tool for the DNC. I was horrified at the way it was written, but discovered quickly that PHP is like the little kid in that Twilight Zone episode -- http://en.wikipedia.org/wiki/It's_a_Good_Life_(The_Twilight_Zone) . If you don't do things PHP's way, you'll end up as a jack-in-the-box in the cornfield.
Yuck. You could dress an object up in array clothing by extending ArrayAccess, Etc. No idea what your array is, so hard to know if that's appropriate (at least by PHP's standards).
(Objects are always passed by reference. Kind of.)
(Also there isn't actually a =& operator. Try moving the & from the call to the function/method argument if it's your own function. If it's a built-in, you're hosed. Welcome to my entire living)
http://www.php.net/manual/en/language.references.pass.php#92348
Ahaha, okay, I give up.
"This is different from all you might expect if you have been programming in other OO-languages before, so you should keep that in mind."
Oh sweet lord.
Well, picking at PHP is not even funny anymore: http://phpsadness.com/
I don't think it was ever funny... well except in a mortuary humor sense.
We make jokes about things which are too grim to discuss sanely, because we've lost our sanity in working with them. :(
Perhaps try switching from using an array() to an ArrayObject (see http://uk3.php.net/manual/en/class.arrayobject.php ). Objects don't get copied (in php5 at least, php4 fucked that up too).
Iteration and $foo[$i] still work the same on ArrayObject (due to it implementing some magic interface), but any array_foo($x ....) calls have to be changed to $x->foo(...) typically. And some just don't have equivalents, at which point you end up converting back to an array, which naturally is done using a C-like cast.
Yes, yes it is. And I work with it every day.
FTFY: Using PHP is usually not a good idea, and deprecated. Could the solution you're looking for be that you create something with a proper language?
What's the 2nd best for fed-up PHPers? Node.js, Perl, or bash?
Probably depends an awful lot on what you want to do with it. These are all "scripting languages", and they're usually positioned on the easy / dynamic-typed / programming-in-the-small side of things. (Contrast with "harder", strongly-typed, compiled, programming-in-the-large languages like C++, Ada, etc. Broad generalization is broad.)
Amongst the ones you mention, Perl is the granddaddy and can do pretty much everything -- but it's baroque, and I wouldn't necessarily recommend it as a language to learn at this point. (I like it quite a bit, but I've been using it for nearly 20 years, so the adage "the most productive language is the one you know best" comes into play...)
Bash is great for quick scripts, but I find myself getting bit by quoting anytime I try to do something fancy. So I tend to save bash scripts for "automating things I do at the command line". Unsurprising.
Node.js... if you happen to be a hardcore JavaScript nerd, I can see the attraction. I would worry about it being rather young, though. (Having said that, JavaScript grew up in a connected environment, so many of the important network tools are already "built in", making it less of a big deal that Node.js hasn't had decades to build up a standard library.)
If you are interested in learning better programming habits, and doing general-purpose script programming, I highly recommend Python. It forces you to do things a certain way, and while that's frustrating to experienced programmers with established taste, it is very helpful to novices. (Think things like consistent indentation; it's mandatory in Python.) That's not to say that python is a "toy" language -- far from it. Some fairly big and productive systems have been written in it.
Finally, there's also Ruby; from what I've seen, it's pretty close to Perl on the density / baroqueness, but it has a strong web app background ("Ruby on Rails"). So it might be the closest for a straight PHP swap, especially if you're doing web stuff.
Happy hacking!
I think James was being sarcastic, but I'm impressed by the depth of your response.
Anyway, the obvious answer is brainfuck.
Well, where's the fun in failing by half-measures?
You make an excellent suggestion, although I must admit that I'm more of an INTERCAL man myself.
I've been avoiding Python because there's no automatic way to fix indentation if it gets screwed up and my universe still has the spaces/tabs mess in it. Otherwise I know it's great. Perl is my personal favorite. But I shouldn't say that because I've written much more bash over the years ("shell scripts") but I feel like it should be called "sh" or something except that's hard to pronounce.
I'm convinced that Node.js is mature enough because Microsoft has already been trying to embrace and extend it. JavaScript is one of the best known languages. If the server-side library is immature, it's probably because it's missing some idioms which should be simple enough to add.
If the fact that 9^99 evaluates to -1313205973877546535 didn't bother me, I would use Julia. Because it's awesome. Having array indexes based on 1 instead of 0 makes me feel like I am allowed the freedom to communicate with other human beings instead of only Dijkstra's graduate students by email.
Sure. Sorry if I sounded condescending -- apparently I missed some sarcasm. :-/
Ha. My complaint with those decisions is the other way around: $ for XOR is odd but workable, but 0-based arrays are mandatory.
Although, wait. Is that actually some sort of unmanaged overflow on an int64, instead of transparent promotion to bigint? If so, that's icky.
Either way, thanks for pointing me at Julia -- it does look very promising. I'm coming off a decade working in the Java / C++ salt mines, and switching to something more agile [sorry] would be nice.
How do you feel about nodejsdb?
Previously (PDF), in which making sense of PHP references turned out to be high-end programming language theory research. From the abstract: “This leads us to ask if the semantics and implementation of PHP coincide, and actually this is not the case…. The current PHP implementation has inconsistencies with these semantics, caused by its naïve use of copy-on-write.”
Science confirms it: PHP, you cray-cray.
Jed, that is a great paper; it'll be very useful for fending off the crazies who keep suggesting we use PHP. Thanks for sharing it.
I wonder if they were snickering the whole time they wrote that. Does anyone know of a quick introduction to how to read those programming language paper formulas with the horizontal bars between them?
In a simple use case it seems to work, can you give any more context?
php > $a = array('a' => 1, 'b' => 2);php > var_dump($a);
array(2) {
["a"]=>
int(1)
["b"]=>
int(2)
}
php > $b = array();
php > $b[0] =& $a;
php > var_dump($b[0]);
array(2) {
["a"]=>
int(1)
["b"]=>
int(2)
}
php > $b[0]['a'] = 3;
php > var_dump($a);
array(2) {
["a"]=>
int(3)
["b"]=>
int(2)
}
As far as I can tell, the only way degenerate tests like that appear to work is that what you're storing into the the first array is not actually the second array, but the address of the variable that once held that second array. It's a complete circus.
"So I have to fit this in here, because it bears repeating: PHP is a community of amateurs."
This this THIS. I think what's always shocked me the most is the absolute tunnel vision programmers who only use PHP have. I was stuck coding in PHP working on an affiliate billing application and after a year or two desperately trying to patch and extend the existing (and truly terrifying) code they let me start on a completely new version. My "manager" at the time was (and still is) the most hardcore loyal PHP programmer you can imagine, and I was literally at a complete loss for words when I started ranting that PHP didn't properly support true constructor overloading and he asked in all seriousness why I would ever want to do that.
(This was 4+ years ago, maybe PHP does this now? I have no idea because I fled that job soon after that and never touched PHP again.)
Thanks for the link. I've got people at work contemplating a PHP-based CMS, and I want to try to avoid that mess.
And of course, best part of that link, the part pertinent to your situation, is the "Arrays" section, with its simply stated opening: "Oh man."
Are you coding something for WordPress (I know you have before) - in which case maybe there's another way to do what you'd like?
It is a terrifying fact that PHP, despite its awfulness, nevertheless powers software that gets more usage than anything else on the planet: Facebook. (Yes, they do all kinds of machinations and use PHP as their main language and compile it to C++, but still).
And no doubt you've seen What references aren't.
Full disclosure: I am sometimes paid to code in PHP.
No, this is some bullshit related to the DNA store, which is this ancient pile of PHP that I didn't originally write but that has been an albatross around my neck ever since.
So. Legacy PHP code. Royal pain.
It could have been written in Perl, then you wouldn't have been able to read it. And would have had to reimplement it instead of editing. Maybe in ruby. It could have been written in Python, then it would have stopped running between language version updates requiring extensive editing. (and you would have 3 to 4 concurrently installed versions of python installed on the server) It could have been written in C#, then... it probably couldn't, cause it wasn't already there, otherwise .
It could be written in java/jsp, then it would have never had references to arrays in the first place.
...is that the lesson?
I think jwz is one of those high-powered mutants who can actually read Perl. In any case I would bet he'd prefer it to PHP.
Python's only had one version update requiring "extensive editing" in recent memory, and most people haven't switched to 3 yet.
Look, I'm not gonna let you sucker me into defending Perl, which is not without its own considerable amount of brain damage, but this is certainly not the first time I've considered rewriting the whole thing in Perl.
All the options are bad.
Out of morbid curiosity, which server side scripting language do you find to be the least brain damaged this decade?
I am the wrong person to ask, mostly because I do very little of this kind of bullshit.
I'm just an unfrozen caveman. Left to my own devices I'd probably use Perl. For all its other failings, Perl at least is stable.
Ruby is still a moving target. Don't build your web site using someone's "learning experience" or thesis project, unless you intend to delete or re-write your web site from scratch every six months. Rails, even more so. (People talk about it like it's a library but really Rails is to Ruby as ObjC is to C, as far as I can tell. It is its own language and that language is still in the kind of flux that means that year-old code won't work in today's release.)
And I will never, ever use Python because of the whitespace thing. Sewer rat, pumpkin pie, etc.
I would have guessed you like Node.js (e.g.) or Go.
Your injunction against using something that's still in a state of flux prevents you from relaxing into Clojure, alas (not unreasonably). "If we don't call it Lisp and we run on the JVM, it'll be cool in no time flat!"
You have to declare variables before you use them in Clojure, right? I think Go might require that too, but JavaScript is weakly typed. Also JVMs can be hundreds of megabytes.
Are there extensions to the DNA store that you would consider making, if PHP weren't such a pain in the ass? Sounds like Perl would ultimately result in less pain and allow for moving forward, instead of remaining trapped in Dante's Limbo.
Let me share with you my own rant on the topic. Don't worry - it's short, and musical:
Rasmus's Toy, to the tune of Cotton-Eye Joe.
I just love PHP!
You're being lied to:
http://blog.golemon.com/2007/01/youre-being-lied-to.html
Wow, that's the first link that made me actually understand what the fuck is going on! Thank you for that.
So basically, PHP variables are halfassed barely-deterministic inodes and the design has, in fact, escaped from INTERCAL.
If you spend long enough dealing with PHP, you end up more than a bit like Sam Neil in Event Horizon. Let me show you the beauty that is 'array_key_exists($needle,$haystack)' and 'property_exists($haystack,$needle)'.
Come, join The Blight in the Top of the Beyond.
When I quickly googled to see what the "=&" operator should do, I learned that PHP has at least one error message in Hebrew.
Good old T_PAAMAYIM_NEKUDOTAYIM?
The "fractal of bad design" metaphor is distressingly apt: it's turtles-of-shitty-design all the way down.
My favourite part of all this is that none of the scripting language choices out there are any good, really.
I like to remind people that PHP stands for “Personal Home Page” and not some recursive backronym that was probably coined by Zend as damage control. Just like the I in RAID.
Good lord, when did they redefine RAID? The original I is so much more honest.
Right. It was essentially a kind of Turing-complete templating system at first. This of course hasn't stopped people from creating a whole bunch of half-assed templating systems specifically for use with PHP. Keep in mind that vanilla PHP is not a worst case scenario; it can be made much, much worse with the addition of an "enterprise ready" templating system, framework and a bit of elbow grease.
Hah, when you say “Turing-complete templating system,” I just think of C++.