|
Plorkyeran posted:I do think he's overstated the degree to which it's a problem, though. PHP's arrays are pretty obviously the result of a bunch of features being crammed in rather than any sort of design, but the end result isn't all that bad. I think this is by and large PHP's problem in general, not just that specific corner of it. Instead of the design of the language being carefully thought out and designed with attention to detail and an appreciation of how all the pieces will fit together, PHP has developed as a series of ad-hoc solutions to problems that were considered in isolation. That's why the whole thing comes off as so ill-considered, why myfunction()[0] didn't work for so long, etc. It's just a series of "good enough" improvements that don't gel with one another. In contrast to other languages that are more "curated", PHP just coalesced over time. This also ensures a plentiful supply of odd behaviours that have to be maintained in order not to break existing code, which makes it hard to fix the problem parts of the language. I don't really think there's an easy way to fix things at this stage. The best that can be hoped for is to try to get more advice out on the internet that tells newbies how to do PHP "the right way", in other words getting them to use error reporting, getting them to write maintainable code, avoiding the mysql_* functions and so on. In the end PHP can't be wholly fixed and it will always be something that serves as a bit of an object lesson, something that people can look at and say "ah, so that is why such and such other language is designed the way it is".
|
#
?
Jul 6, 2012 23:59
|
|
|
|
| # ? Apr 19, 2024 21:45 |
|
|
code:
|
|
#
?
Jul 7, 2012 00:08
|
|
|
More Tales from The Boss. Today, one of our external servers stopped working suddenly. It was up, it was running, but for some reason the heartbeat on it wasn't working properly (and the heartbeat drives the whole box, basically; it uses that time to get new jobs. This is a horror all to its own, but I didn't design this.) Restarting the server didn't help; restarting the program that manages the heartbeat didn't help. Since it talks over SSL, Wireshark was out of the question*. Basically, he was stumped! (I personally stopped caring since I couldn't do anything about it.) It turns out that the clock on that box was a day ahead. And... It also turns out that our SSL certificates expire tomorrow. Oops. Oh well -- a quick call and our SSL cert is extended and all is good! So surely we'll be setting a reminder or something on our calendars for next year, ri-- quote:I set it two days ahead! That way next time this happens only this one will go down and we'll have two days to extend it!  You would think after the "One year ahead doomsday" switch he put in a different program that he really would've learned by now. For that one, he needed a date in the future; not too far into the future, but far enough that it would be a ways off. So he set it for a year past that day. Lo and behold, one year later, it suddenly stops working, everything grinds to a halt, and nobody has any idea what went wrong... until he suddenly realizes what day it is, goes in, and then sets it a year ahead again. Even after I told him that he can just take the current date and add a year to make it less bomb-y (VB6).  *: Wireshark can decode SSL if you give it the cert, but I am not allowed to touch this server for whatever reason. I have physical access -- I can literally go to our colocation facility and mess with them -- but I can't actually remote into them for whatever reason. EDIT: Oh, I should also mention that this wonderous program he wrote has no sort of health/sanity checks or error reporting, either. It's basically a hard-coded black-box of VB6 vomit that somehow manages other programs/scripts and oh god it's just awful. So of course in a failure condition it doesn't actually send out an alert or use a backup method, it just ceases to function. The sad part is that the fix to this is something I wrote in my spare time that just checks if we've gotten a heartbeat out of it in the last few minutes. If not, it sends out an email and tries to stop anything from assigning jobs to that box. Good times. Zamujasa fucked around with this message at 00:20 on Jul 7, 2012 |
|
#
?
Jul 7, 2012 00:16
|
|
|
I think it's time to look out for a new job 
|
|
#
?
Jul 7, 2012 00:32
|
|
|
Plastic Snake posted:
It took me a minute to figure out what was going on, but once I did, I'm not sure what other result you were expecting.
|
|
#
?
Jul 7, 2012 00:37
|
|
|
KaneTW posted:I think it's time to look out for a new job Believe me, I'm getting there. It was fun overhearing how the big boss here loves "social misfits" like me because we have trouble finding and keeping jobs, so he gets to pay us poo poo. I found out a few days before that I make $14/hr while my coworker (who does basically the same thing I was doing on the side) makes $20/hr.Good times. E: Oh, they're also planning on hiring some "director" who can give us two programmers deadlines to meet, because clearly there's nothing wrong with that idea. Nope.
|
|
#
?
Jul 7, 2012 00:46
|
|
|
Plastic Snake posted:
https://www.youtube.com/watch?v=zCh7z5EwYF8&t=1s
|
|
#
?
Jul 7, 2012 01:51
|
|
|
pokeyman posted:It took me a minute to figure out what was going on, but once I did, I'm not sure what other result you were expecting. MDN posted:The parseInt function converts its first argument to a string, parses it, and returns an integer or NaN. If not NaN, the returned value will be the decimal integer representation of the first argument taken as a number in the specified radix (base). For example, a radix of 10 indicates to convert from a decimal number, 8 octal, 16 hexadecimal, and so on. For radices above 10, the letters of the alphabet indicate numerals greater than 9. For example, for hexadecimal numbers (base 16), A through F are used. >>> "" + 1/0 "Infinity" >>> parseInt("I", 19) 18 >>> parseInt(1/0, 36) 1461559270678 >>> parseInt("Infinity", 36) 1461559270678 
|
|
#
?
Jul 7, 2012 07:27
|
|
|
We've covered php.js already, right?phpjs.org posted:php.js is an open source project that brings high-level PHP functions to low-level JavaScript platforms phpjs.org posted:we think of it as a challenge to port everything and decided to also port low-level PHP functions like strpos even though it may have a JavaScript counterpart (String.indexOf). (emphasis in original)
|
|
#
?
Jul 7, 2012 19:05
|
|
|
quote:PHP is a language with many high-level functions and while they're not always implemented as consistently as we'd like (mostly to blame on its underlying C parts), it has a huge following familiar with its syntax so it makes sense to pick its API as a reference.
|
|
#
?
Jul 7, 2012 19:36
|
|
|
quote:PHP is a language with many high-level functions and while they're not always implemented as consistently as we'd like (mostly to blame on its underlying C parts) Err... what??? How can you possibly push the blame onto C.
|
|
#
?
Jul 7, 2012 19:40
|
|
|
That Turkey Story posted:Err... what??? How can you possibly push the blame onto C. Presumably he's saying that PHP functions are inconsistent because so many of them are thin wrappers around C library APIs that are inconsistent with each other. It's a plausible explanation that excuses nothing.
|
|
#
?
Jul 7, 2012 19:52
|
|
|
That Turkey Story posted:Err... what??? How can you possibly push the blame onto C. It's true though, a lot of php's issues are because the authors are terrible/lazy C programmers.
|
|
#
?
Jul 7, 2012 20:45
|
|
|
Pretty sure the method naming and parameter order consistency issues are not because of the C API, they are because of the PHP devs. It's stuff like mysql_escape_string that are thin wrappers over the C API. Nevertheless, the php.js people have faithfully replicated those issues for no good reason whatsoever.
|
|
#
?
Jul 7, 2012 21:07
|
|
|
pokeyman posted:We've covered php.js already, right? quote:porting more also opens up php.js to all kinds of thought excercises and study purposes. No. gently caress you. If you're thinking that something like this is remotely desirable JavaScript code:
|
|
#
?
Jul 7, 2012 21:31
|
|
|
pokeyman posted:We've covered php.js already, right? The best part is that most of the people who write compilers for other languages to target JS do so because they want clearer syntax and semantics than JS, not worse.
|
|
#
?
Jul 7, 2012 23:51
|
|
|
I've seen things you people wouldn't believe. Servers running PHP off the shoulder of Javascript. I've watched C-strings glitter in the dark near the NAND gate. All those… moments will be lost in time, like tears… in rain. Time to die.
|
|
#
?
Jul 8, 2012 14:42
|
|
|
Mustach posted:I've seen things you people wouldn't believe. Servers running PHP off the shoulder of Javascript. I've watched C-strings glitter in the dark near the NAND gate. All those… moments will be lost in time, like tears… in rain. Time to die. The original spoof version of that was good as well: "I have seen things you people would not believe... I've seen Sun monitors on fire off the side of the multimedia lab. I've seen NTU lights glitter in the dark near the Mail Gate. All these things will be lost in time, like the root partition last week. Time to die..."
|
|
#
?
Jul 8, 2012 18:24
|
|
|
pokeyman posted:It took me a minute to figure out what was going on, but once I did, I'm not sure what other result you were expecting. It makes perfect sense once you know what's going on. Less of a horror and more of a funny quirk, I guess. And I wasn't being sarcastic, I actually do love Javascript.
|
|
#
?
Jul 8, 2012 19:07
|
|
|
Imagine what you get when you start with a horrible, ugly, slow language (Objective-C), and you selectively discard some (but not all C-isms), replacing them with a sprinkling of JavaScript, Pascal and Ruby. Finish it off with a dash of pure crazy, and you get this, the Eero Programming Language. Amazingly the guy behind it actually wrote a full Clang module to support it. Some of the epic features: - (Mostly-)Optional semicolons - Removal of braces in favour of indentation-level blocks, except where you have to explicitly put "end" to mark the end of some special blocks - Removal of certain C language features for "safety" (goto, switch fall-through) - Magic extraction of variable names from method calls based on the last camel-case word in the method name - Automatically adding "NS"- prefix to typenames if it can't find the type
|
|
#
?
Jul 11, 2012 03:26
|
|
|
Cirian posted:Imagine what you get when you start with a horrible, ugly, slow language (Objective-C), and you selectively discard some (but not all C-isms), replacing them with a sprinkling of JavaScript, Pascal and Ruby. Finish it off with a dash of pure crazy, and you get this, the Eero Programming Language. Anyone who thinks switch fall-through isn't a good feature should write a state machine.  Heh, NSNSSomeType errors.
|
|
#
?
Jul 11, 2012 04:16
|
|
|
Geekner posted:Anyone who thinks switch fall-through isn't a good feature should write a state machine. Even then it's better to goto top; and reenter the switch. But I like to play dirty and explicitly goto the next switch statement instead of implicitly falling through. code:
|
|
#
?
Jul 11, 2012 04:36
|
|
|
Fall-through should be removed, but in turn you should be able to goto switch labels.
|
|
#
?
Jul 11, 2012 04:36
|
|
|
Cirian posted:- Magic extraction of variable names from method calls based on the last camel-case word in the method name This is one of those ideas that's great until you think about it.
|
|
#
?
Jul 11, 2012 05:31
|
|
|
I gotta say, I like it. Maybe my extended use of JavaScript has corrupted me.
|
|
#
?
Jul 11, 2012 06:41
|
|
|
I can't decide if implementing faux namespaces by specifying a default prefix for unknown types is brilliant or insane.
|
|
#
?
Jul 11, 2012 06:52
|
|
|
I like the way Go handles switch statements. It's sort of the reverse of C; breaking at the end of a case is the default, and there is a fallthrough keyword if you actually want to continue to the next case.
|
|
#
?
Jul 11, 2012 07:51
|
|
|
Rothon posted:I like the way Go handles switch statements. It's sort of the reverse of C; breaking at the end of a case is the default, and there is a fallthrough keyword if you actually want to continue to the next case. But then how will I implement my Duff's Device shortly and succinctly?
|
|
#
?
Jul 11, 2012 07:59
|
|
|
Geekner posted:Anyone who thinks switch fall-through isn't a good feature should write a state machine. The other day I wrote a post about possible changes to switch statement flow through. The concept may or may not be a horror (I'll leave that up to you to decide), but not quite as much of a horror as this piece of documentation from PHP: quote:Note: Note that in PHP the switch statement is considered a looping structure for the purposes of continue.
|
|
#
?
Jul 11, 2012 08:37
|
|
|
bobthecheese posted:The other day I wrote a post about possible changes to switch statement flow through. Maybe I'm missing something, but isn't your example just equivalent to a switch nested inside of a while loop: code:
|
|
#
?
Jul 11, 2012 09:04
|
|
|
No. He changed the semantics of continue in a switch case. It acts like fallthrough but requires re-evaluation of the variable versus the cases. So the value of 2 would fall in at case 2, normally fallthrough to case 3, hit continue, and then fall back in at the penultimate case, case $s > 0. It would not match case $s > 4; with normal fallthrough, it would hit that. Unless I completely misunderstood your question.
|
|
#
?
Jul 11, 2012 09:50
|
|
|
bobthecheese posted:The other day I wrote a post about possible changes to switch statement flow through. The concept may or may not be a horror (I'll leave that up to you to decide), but not quite as much of a horror as this piece of documentation from PHP: While "switch is a looping structure" looks peculiar at first glance, there is a sensible enough reason for it. PHP supports breaking/continuing in nested loops using statements like "break 2" or "continue 3", and with this being the case it makes sense to regard switch as a looping structure for the purposes of "continue", because it is one for "break" by necessity and otherwise the 2 (say) in "break 2" and in "continue 2" would refer to different levels in the nested loop hierarchy, which would be far more confusing. You could argue that allowing developers to name the loops would make more sense, but given that they used numbers instead using "continue sees switch as a loop" is the only sane way to go.
|
|
#
?
Jul 11, 2012 11:50
|
|
|
pseudorandom name posted:Fall-through should be removed, but in turn you should be able to goto switch labels.
|
|
#
?
Jul 11, 2012 13:32
|
|
|
Rothon posted:I like the way Go handles switch statements. It's sort of the reverse of C; breaking at the end of a case is the default, and there is a fallthrough keyword if you actually want to continue to the next case.
|
|
#
?
Jul 11, 2012 13:49
|
|
|
Generating an unused record ID as part of creating a new record on our DB can take more than a minute unless the database instance has run some code specific to that record type in the past. This is likely to have been done for common record types for all instances, but for less-common record types? Who knows! And it might vary by DB instance. It's also difficult to test for because the issue that the workaround code avoids doesn't exist in development databases, meaning if you forget the issue will be caught in release testing at the earliest. [edit: to be fair, it could also be caught on our QA instances, but it's possible for the workaround to be in place on the shared QA instances already] ozymandOS fucked around with this message at 20:23 on Jul 11, 2012 |
|
#
?
Jul 11, 2012 20:13
|
|
|
BP posted:Generating an unused record ID as part of creating a new record on our DB can take more than a minute unless the database instance has run some code specific to that record type in the past. This is likely to have been done for common record types for all instances, but for less-common record types? Who knows! And it might vary by DB instance. Why not use an autoincrement?
|
|
#
?
Jul 11, 2012 20:24
|
|
|
Golbez posted:Why not use an autoincrement? That is what is used by most record types. The problem is that we can define ranges of record IDs that can only be used by us (ie a customer record can never use that ID). We have code that checks this & a few other conditions when evaluating whether an ID received from the increment process is appropriate to use. Typically the range of predefined record IDs is the first 100000 or 1000000 IDs--and when you attempt to create a record at a customer site, unless you've manually updated the "next ID" for the autoincrement, it will happily loop through this range, attempting to validate each ID for use and then realizing that it can't use the ID. This can take quite a while. The right thing to do (IMO) would be for the validation code to be smart enough that when a record ID is checked that is inside of a range of unusable records, increment to the next ID outside the range instead of incrementing by 1. Instead we only increment by 1, and devs get caught off-guard as this fact about ID generation is not very well known.
|
|
#
?
Jul 11, 2012 20:42
|
|
|
BP posted:The right thing to do (IMO) would be for the validation code to be smart enough that when a record ID is checked that is inside of a range of unusable records, increment to the next ID outside the range instead of incrementing by 1. Instead we only increment by 1, and devs get caught off-guard as this fact about ID generation is not very well known. Not sure about your use case, but I don't think so. Don't base business logic decisions from auto-incrementing primary keys. Use a separate field or data-type to indicate whatever business case you have.
|
|
#
?
Jul 12, 2012 00:50
|
|
|
Am I the only one who thinks things like Order ID's should just be generated with a UUID? It would solve SO many problems.
|
|
#
?
Jul 12, 2012 01:01
|
|
|
|
| # ? Apr 19, 2024 21:45 |
|
|
trex eaterofcadrs posted:Am I the only one who thinks things like Order ID's should just be generated with a UUID? It would solve SO many problems. IIRC there are some issues in using UUIDs for auto-generating keys in some databases. It's been a while since I looked into it so that might not be an issue anymore. Even so, using UUIDs doesn't seem to solve his problem since what they need is a way to differentiate two of the same record types. They are using a 'reserved' part of the PK key space which, with UUIDs, would be about a bajillion times worse. It sounds like they just need a separate field.
|
|
#
?
Jul 12, 2012 01:10
|
|