|
Suspicious Dish posted:It's a PHP language specification. It has nothing to do with PHPNH nor HHVM. well he said they were hhvm people so presumably this "specification" is related to it in some way. i'm just speculating that they are down in the dumps cause their project is gonna be useless. and not just hhvm. the idea of having a "specification" for php is silly. you might as well try to specify the arrangement of grains of sand on a beach. when you need to see how something works, take 5 seconds and try it out yourself on the real living software, don't waste 5 hours digging through dead documents
|
#
?
Jul 25, 2014 21:25
|
|
|
|
| # ? May 26, 2024 22:03 |
|
|
Php will not be eagerly adopted by the mainstream, it will be forced upon them. Forced, as in "compelled by economic reality". People will be forced to code in php, not because of 'the technology', but because no hiring manager will accept their worthless non-php knowledge. Contrary to popular belief, good technology drives out bad. This "driving out" has started as a small-scale hhvm adoption. It will rapidly escalate into Class IV hemorrhaging due to exponential optimization of the phpng runtime. The end result will be hyperphpization, i.e. "your c# skills are no good here".
|
|
#
?
Jul 25, 2014 21:28
|
|
|
Tiny Bug Child posted:and not just hhvm. the idea of having a "specification" for php is silly. you might as well try to specify the arrangement of grains of sand on a beach. when you need to see how something works, take 5 seconds and try it out yourself on the real living software, don't waste 5 hours digging through dead documents you are an artist
|
|
#
?
Jul 25, 2014 21:45
|
|
|
Subjunctive posted:I sit near the HHVM people who have been working on the PHP language specification we're about to publish. I don't know how they're ever sober enough to focus their eyes. They just radiate despair. http://dl.acm.org/citation.cfm?id=1480881.1480908 "... In PHP, assignment to variables copies the assigned values, according to its so-called copy-on-assignment semantics. In contrast, a typical PHP implementation uses a copy-on-write scheme to reduce the copy overhead by delaying copies as much as possible. This leads us to ask if the semantics and implementation of PHP coincide, and actually this is not the case in the presence of sharings within values...." poor sods
|
|
#
?
Jul 25, 2014 21:47
|
|
|
coffeetable posted:c looks like a good first language if you consider computation to be something that's done by computers well  else could it be? 
|
|
#
?
Jul 25, 2014 21:50
|
|
|
tef posted:http://dl.acm.org/citation.cfm?id=1480881.1480908 Php is an onion of failure
|
|
#
?
Jul 25, 2014 21:59
|
|
|
tractor fanatic posted:the only exception you need to remember is that [] indicates a pointer, and not an array when it appears in the parameter list. it's not an array that's decayed to a pointer, it's just a pointer. is there even a reason to have [] in a function signature?
|
|
#
?
Jul 25, 2014 22:02
|
|
|
Shinku ABOOKEN posted:is there even a reason to have [] in a function signature? void poop_out_four_characters(char buttes[static 4]); except it doesn't work
|
|
#
?
Jul 25, 2014 22:14
|
|
|
Tiny Bug Child posted:well he said they were hhvm people so presumably this "specification" is related to it in some way. i'm just speculating that they are down in the dumps cause their project is gonna be useless. no, it's a specification of the PHP5.6 behavior, so that people can agree on what the language does without hoping they thought of all the things to test in the live software. it'll be maintained by the php.net folks, we're just funding and doing the initial work. I suspect it'll be valuable to the PHPNG folks too. HHVM is optimized for the things that Facebook runs, today. There are lots of ways to make it better, and a good team doing so, and lots of bugs open for easy perf wins that just haven't mattered to our stack. PHPNG is showing well on the subset it handles today, but AFAIK they have compatibility to restore as well, and JITs are notoriously hard to make stable and robust in production environments. My JIT was faster than Chrome's at first too (and PLDI accepted our paper instead of theirs, suck it Lars Bak), but there was a lot of leapfrogging and mutual pressure, and the architecture we chose turned out to not generalize as well as it needed to. It had to be thrown out, basically, and it took a couple more years to get back to parity. I'm not dismissing PHPNG by any means, and neither are the HHVM team, but the first few weeks of a new JIT are when it looks best, because of all the asterisks. It would be pretty awesome if PHPNG obsoleted HHVM, or vice versa, but I suspect we'll end up with a world where they are better in different contexts. In the meantime, the PHP world may get to experience the ridiculous gains that JS saw during those first few years of the JS perf wars. That'll save a lot of watts around the world if it happens. Edit: digging more deeply, the PHPNG wins have been internal-representation only, which is definitely impressive. It'll be interesting to watch the teams compete, I know they both take perf pretty personally. Subjunctive fucked around with this message at 23:15 on Jul 25, 2014 |
|
#
?
Jul 25, 2014 22:50
|
|
|
Subjunctive posted:no, it's a specification of the PHP5.6 behavior, so that people can agree on what the language does without hoping they thought of all the things to test in the live software. dude you can just get a copy of php 5.6. anyone can! it's not like you have to sit there and theorize about what it does. if people don't agree on what the language does in some instance... you can just run it and find out. it's already it's own perfect specification. the only thing you get out of a hard copy is the possibility of introducing errors. imagine a religion that had no disagreement on any point of dogma because you could just go ask god. all questions can be resolved through appeal to the interpreter itself.
|
|
#
?
Jul 25, 2014 23:14
|
|
|
Shinku ABOOKEN posted:is there even a reason to have [] in a function signature? sort(T[] shitToSort);
|
|
#
?
Jul 25, 2014 23:16
|
|
|
Shinku ABOOKEN posted:is there even a reason to have [] in a function signature? template<typename T, size_t N> size_t arraylen(T(&)[N]) { return N; } 
|
|
#
?
Jul 25, 2014 23:20
|
|
|
Tiny Bug Child posted:dude you can just get a copy of php 5.6. anyone can! it's not like you have to sit there and theorize about what it does. if people don't agree on what the language does in some instance... you can just run it and find out. but you can't safely generalize from that, and the thesis only holds if you believe that the interpreter can't have bugs; php's history, like that of every language runtime I've ever used, indicates otherwise. the PHP folks seem pretty happy to have it too, FWIW. specifications are a much nicer way to reason about language features than is interpreter reading diffs. all languages start out having a single implementation; do you believe that languages should not have specifications, but just "grab the tarball of jvm/gcc/etc. and try it"?
|
|
#
?
Jul 25, 2014 23:21
|
|
|
Tiny Bug Child posted:dude you can just get a copy of php 5.6. anyone can! it's not like you have to sit there and theorize about what it does. if people don't agree on what the language does in some instance... you can just run it and find out. php: holy program
|
|
#
?
Jul 25, 2014 23:22
|
|
|
Shaggar posted:sort(T[] shitToSort); what's the length of shitToSort? if you're gonna say zero terminated then why don't you just give me a T* like you would if it was a c string (char*). it adds nothing. yeah you can look at it and figure out its an array but a proper parameter name and doc comment would serve you better. here is an actual question: does the compiler treat array and pointer params differently? are there any optimizations that run on one but not the other?
|
|
#
?
Jul 25, 2014 23:24
|
|
|
Vanadium posted:template<typename T, size_t N> size_t arraylen(T(&)[N]) { return N; } dependant types the best types
|
|
#
?
Jul 25, 2014 23:25
|
|
|
Apparently you can also declare parameters to be of anonymous (or that-function-local) struct type in C and then have a sized array in that struct, but actually calling the function gets a bit tricky/pointless.
|
|
#
?
Jul 25, 2014 23:25
|
|
|
Vanadium posted:template<typename T, size_t N> size_t arraylen(T(&)[N]) { return N; } i remember trying to use the parser generator for boost (pheonix) and the fucker was reaaalllly loving slow to build like holly poo poo i have an ssd and it still took ages
|
|
#
?
Jul 25, 2014 23:26
|
|
|
Shinku ABOOKEN posted:what's the length of shitToSort? if you're gonna say zero terminated then why don't you just give me a T* like you would if it was a c string (char*). that doesn't make any sense at all. the length of shitToSort is unknown and if you were to pass whatever the hell T* is that's probably not an array so its no good.
|
|
#
?
Jul 25, 2014 23:26
|
|
|
pointers are dumb useless poo poo that no one should use
|
|
#
?
Jul 25, 2014 23:26
|
|
|
Shaggar posted:pointers are dumb useless poo poo that no one should use here is a pointer for you 0xB16B00B5 lmao
|
|
#
?
Jul 25, 2014 23:37
|
|
|
Subjunctive posted:but you can't safely generalize from that, and the thesis only holds if you believe that the interpreter can't have bugs; php's history, like that of every language runtime I've ever used, indicates otherwise. the PHP folks seem pretty happy to have it too, FWIW. specifications are a much nicer way to reason about language features than is interpreter reading diffs. ok well now you seem to be talking about what the interpreter should do; you said the specification was to resolve questions about what the interpreter does do. different things. is some kind of formal specification the best way to handle answering "should" questions? idk. i can see it being good for some projects. i can also see a more general statement of design goals and intent working for that.
|
|
#
?
Jul 25, 2014 23:45
|
|
|
you've got it, specifying what an implementation should do is indeed the point of an implementation-independent specification. the point is that most langs don't just make things up as they go along
|
|
#
?
Jul 25, 2014 23:49
|
|
|
you need a specification of what it should do because otherwise you can't tell whether anything it does do is a feature or a bug
|
|
#
?
Jul 25, 2014 23:50
|
|
|
You must be new here, obviously anything php does do is a feature.
|
|
#
?
Jul 25, 2014 23:53
|
|
|
Tiny Bug Child posted:ok well now you seem to be talking about what the interpreter should do; you said the specification was to resolve questions about what the interpreter does do. different things. is some kind of formal specification the best way to handle answering "should" questions? idk. i can see it being good for some projects. i can also see a more general statement of design goals and intent working for that. tbc...was right ????? 
|
|
#
?
Jul 25, 2014 23:57
|
|
|
JewKiller 3000 posted:you need a specification of what it should do because otherwise you can't tell whether anything it does do is a feature or a bug hey i thought it was a dumb idea when he said it too
|
|
#
?
Jul 26, 2014 00:02
|
|
|
it's found bugs in 5.6 by identifying places that were inconsistent, I believe, but it does currently document php5.6 warts and all. I apologize for sloppy language, I thought the intent was clear. it'll probably be helpful for 5.7 as well, and specifying how language changes should impact existing behaviour. afaik it's the first time anyone has actually written down what the interpreter does, such that people can look at it and decide which way to resolve inconsistencies. my experience with language standardization is that it's basically a loop of - write down what you think the language means - see what the implementations actually do - decide whether it's an implementation or spec bug - repeat until you run out of time or questions to ask how do you feel about code documentation? clearly you can just run it to find out what it actually does.
|
|
#
?
Jul 26, 2014 00:12
|
|
|
have you considered just publishing a python spec and declaring all differences to be implementation bugs to be fixed in the next release
|
|
#
?
Jul 26, 2014 00:20
|
|
|
Subjunctive posted:all languages start out having a single implementation; do you believe that languages should not have specifications, but just "grab the tarball of jvm/gcc/etc. and try it"? I used to think specs mattered the most, then I wrote a C compiler frontend. Now I think an open source canonical implementation and good test suites are a whole lot more useful than a spec.
|
|
#
?
Jul 26, 2014 00:38
|
|
|
what's basically been done is the see-what-the-implementation-does strategy espoused above, in great detail, and then the results written down with the benefit of some abstraction. it's not prescriptive, unless the PHP-internals folks decide to make it so. it will be a good baseline for future language work, I think; people can obviously disagree about how valuable evolving PHP is.
|
|
#
?
Jul 26, 2014 01:22
|
|
|
itt we argue about prescription vs description
|
|
#
?
Jul 26, 2014 01:27
|
|
|
Otto Skorzeny posted:that's not an "exception" to anything - it's arguable that the deceptive function signature "int decay(char[])" shouldn't be legal, but the semantics are pretty clear and obvious. as for when the array type is useful, consider the case where you want to initialize a buffer with a string literal but have it be writeable later. it's totally obvious except that there are a set of unexpected exceptions, and an faq entry to explain how not to get hosed, and holy poo poo are you seriously making this argument? i can't even maintain sarcasm here holy poo poo get hosed C is a pretty good language but it has a shitload of warts, and array-pointer-decay is one of them
|
|
#
?
Jul 26, 2014 01:39
|
|
|
pee pee doo doo rasmus lehrdorf
|
|
#
?
Jul 26, 2014 02:09
|
|
|
Tiny Bug Child posted:is some kind of formal specification the best way to handle answering "should" questions? idk. i can see it being good for some projects. i can also see a more general statement of design goals and intent working for that. specs are really for people implementing or extending php, not as much for using it. specs are about how features work in detail, the bigger picture that beginners don't really need to have a deep knowledge of. although people using php should just try things out and explore, (and hey, this is a normal thing with repls like php -a), implementing a thing is a lot harder than just using a thing: Subjunctive posted:... the architecture we chose turned out to not generalize as well as it needed to. and even when you have specs, it's hard. a good spec will confine your design and implementation. if all you have is exploration there is an awful lot more backtracking involved, as you stumble on the edge cases one by one tef fucked around with this message at 02:40 on Jul 26, 2014 |
|
#
?
Jul 26, 2014 02:34
|
|
|
a move to a specification is really about interoperability and guarantees about implementations or, if you like, moving away from implementation defined things to specification defined things means the features users explore on one implementation should work the same way across implementations, as long as you're not doing invasive things
|
|
#
?
Jul 26, 2014 02:38
|
|
|
Shaggar posted:pointers are dumb useless poo poo that no one should use this is why you should never use objects in java  Subjunctive posted:(and PLDI accepted our paper instead of theirs, suck it Lars Bak) 
|
|
#
?
Jul 26, 2014 02:40
|
|
|
tef posted:this is why you should never use objects in java
|
|
#
?
Jul 26, 2014 03:26
|
|
|
turns out tef is still cool that's good
|
|
#
?
Jul 26, 2014 03:26
|
|
|
|
| # ? May 26, 2024 22:03 |
|
|
i was looking for something programming related and found tef's blog
|
|
#
?
Jul 26, 2014 03:28
|
|