Let's say that I grant that particular absurdity. This is what we get:
== is transitive over any scalar type, like every other language.
Even cooler, it is transitive over any two scalar types -- that means it's transitive over more combinations of types than most other languages where == does type conversion.
The most you can say is that it is not transitive over three or more scalar types simultaneously. Fine, but then again, neither is == in any other language!
His nonsense "proof", of course, is still embarrassingly wrong.
Let's hope this puts this particular waste of everyone's time to rest.
That the operator does the type conversion for you is completely irrelevant. == is transitive. Remember, you can't test two values for equality if they're different types! (They're members of different sets that do not intersect, after all.) You'll get the exact same behavior in any other language if you do the type conversion yourself. Does that mean == in statically typed languages isn't transitive? Of course not!
The fact that things internally are bat shit crazy does not change that fact.
Lol, if by "bat shit crazy" you mean both well defined and completely obvious. Had you paid attention in logic 101, you wouldn't have parroted such a ridiculously bad "proof". I mean, it's pretty obvious on it's face that it's nonsense. I'm astonished that you thought it was legitimate -- I had thought you either copy/pasted it without thinking, or just thought you could pull a fast one!
what the evaluator does inside is retarded, and causes transitivity not to hold
No, it's not retarded. It's EXACTLY what you'd expect if you did the type conversion yourself! That the operator does it for you out of convenience is irrelevant. Why does it do any conversion? Because you can't test values of different types for equality!
Clearly, your play-pretend "proof" which is, as I've painfully explained to you, complete and total nonsense mathematically. Why are you still defending it? It's dead. It should be clear to you by now that it's neither mathematical nor a proof.
Copy/paste a better argument; preferably one that's legitimate. This one doesn't work, your "mathematical proof" is neither, and I'm tired of explaining simple shit to you.
There is a (admittedly outlined) mathematical proof that transitivity does not hold in my replies to you. Feel free to tell me why that's bullshit.
Damn, you're thick! It's like talking to a pile of rocks!
Your example is bullshit. It's just like the bullshit proofs like "1=2" or "the missing dollar" It's all a bit of misdirection designed to confuse idiots. Here, you're using types to do the misdirection:
for a = b you have "abc" == true which is evaluated as true == true// true for a = c you have "abc" == 0 which is evaluated 0 == 0// true for b = c you have true == 0 which is evaluated as 1 == 0// false
The first premise comparing two booleans, the next two are evaluating two integers. It's all a bit of misdirection, as it ultimately says NOTHING about the relationship between a,b, and c because a,b, and c are not identical between each premise. Mathematically, your "proof" doesn't make any fucking sense at all.
Fixing it so the types you actually compare match gives you: for a = b you have "abc" == 1 which is evaluated as 0 == 1// false for a = c you have "abc" == 0 which is evaluated 0 == 0// true for b = c you have 1 == 0 which is evaluated as 1 == 0// false
As you can see, a = b is false when the types are ints and not bools.
Given a != b and a = c we assume that b != c (Look at that, b != c. It works just fine!)
Take away the bullshit, and your "proof" vanishes in a puff of logic.
If your response is "if you think that's broken, go and use another language", then you're not being very convincing are you;)
Considering that wasn't my response, I think I'm okay.
Clearly you don't actually understand what transitivity means.
I know exactly what it means. I also explained why your claim that that property didn't hold was total bullshit.
It being documented is not the same thing as it being sane, or well designed, or sensible in a programming language;)
Fine, but you haven't given any actually reason why it's "insane" or "poorly designed". As I've already pointed out, it works exactly like other dynamically typed languages! Christ, what the fuck is so hard about this? Just because you don't like dynamic typing does not mean that all dynamically typed languages are "fundamentally broken".
Wow, if you don't think these things are fundamentally broken, the programming community is more fundamentally broken than I realised. Really? People don't realise that mathematicians have worked out sets of consistent rules that give nice properties?
You're a moron. First Your == isn't transitive claim is false, as I've explained. It's not my fault you didn't understand it. Second, you clearly don't understand programming languages! For example: any OOP language that includes both incapsulation and inheritance (what *actually* are fundamentally opposed) is demonstrably incoherent. A bit worse than a bullshit claim about an operator, that like in may languages, does some type conversion before testing. (Again if you compare what is actually tested for equality, you'll see why your example is bullshit. I'll be that you can come up with a similar bullshit example in your prefered language!)
I did make a mistake. I missed the Q1 2013 announcement from the day before.
RIM is ahead of the curve in a number of areas: Security (obviously) and device management (still leagues ahead of competing products) are the two easy ones to hit. Their new OS is far more advanced, technically speaking, than iOS and Android. (Just take a look at this for just one cool thing.)
Their new UI is geared toward multitasking, it's incredibly slick, and well ahead of Android (which would require major changes to address) and iOS (which simple can't be adapted for similar functionality.) On that front, the competition has a long uphill battle to match RIM. Really, you really need to see it in action. The PlayBook just gives you a taste of what a real mutitasking experience on a mobile device can be. What we're seeing wtih BB10 is taking things to the next level. They also have the best mobile/tablet integration on the market, check out what you can do with Bridge.
They've solved the dual use problem of a work and personal phone with the full security and remote management enterprises demand and the total freedom users demand with Balance. Fusion provides the most comprehensive device management tool on the market, allowing Andorid, iOS, BB, etc. devices to all be managed seamlessly with a single application -- of course, other platforms don't have the same fine-grained control you get with BB devices, that's not something RIM can fix for them!
Less impressive, they have the best HTML5 support of any mobile browser (tablet), beating out many desktop browsers. BB10 brings even better support (as we've seen already) to both tablets and phones with very impressive score well ahead of other up-coming mobile browsers. (On phones, they're currently on par with Android 4 on OS7 handsets.)
They have a fantastic suite of development tools, including an NDK, offering developers more options for development than any other platform. Cascades (for UI development) is simply unmatched. (They acquired TaT, one of their best acquisitions to date, which is responsible for Cascades. Check it out if you're a developer.)
They've formed strong partnerships in the auto industry, leveraging that aspect of their QNX acquisition giving them a strong early lead in a market Apple is trying to break in to. Given that RIM has the objectively better technology, and QNX already has a long history in the auto industry, Apple has a hard fight in a market they clearly see as profitable enough to be worth pursuing.
The type system allows you to treat everything the same,
"I don't understand the type system and I don't like it" is not a fundamental problem of the language. If you want static typing, use C.
Heh, if you want to see what a totally screwed up type system actually looks like, take a look at Java.
and ends up with all kinds of crazy inconsistencies, like the fact that == is not transitive... "abc" == true is true; "abc" == 0 is true; true != 0.
Wow, total fail! First, go read about how the == operator works and how types are converted between one another. Now, make a table and see what is actually being tested for equality. Oh, the magic bullshit vanishes and it turns out the transitive relation really does hold? Too funny! Heh, you can actually make a bullshit example like yours in many modern languages. Of course, it's still total nonsense -- but I'll bet it'll still convince morons that you're brilliant and the the language is "fundamentally flawed".
Want to try and fix the above problems with "==" by using "==="?
Ummm... No. You use == and === where appropriate. Read the fucking documentation. This isn't complicated. Any idiot can figure this out. (Wait, that's wrong. judging from this thread, not every idiot can handle something this simple.)
Well, that has its own problems – suddenly "==" compares the types of objects, while "===" doesn't...
Gee, I wonder why that is. If only I wasn't a total moron and could puzzle out why that's perfectly sensible... (Seriously, if you can't see what this makes perfect sense, I can't help you. It only looks inconsistent if you don't know anything about programming languages.)
What do you think NULL++ is in PHP? What about NULL--? What about "null"++ or "null"--?
Who cares? If you find yourself in any of those situations, you very obviously have bigger problems. I recommend switching professions to something more your speed, like "highway construction flag holder".
To directly answer your question, null++ behaves exactly the same way it does in other dynamically typed languages. So $a=null; $a++; $a will have a value of 1 It's the same, for example, in javascript. The string case "null"++ (well, $a=null; $a++; so that you can actually try it out.) is different between them because strings aren't the same kind of thing in js and php. PHP behaves like perl and returns "nulm" javascript will return NaN. Again, if you find yourself in a situation where this is relevant, you've probably made more than one horrible mistake.
Want to change it? Well, you can't really – that would change pretty much everything about the language.
Why would you want to change it? It's not broken! That you can't handle dynamic typing is not a fault of the language -- why it baffles you so, I'll never know.
There are plenty of legitimate gripes about PHP. This is not one of them. Go, and find an actual reason.
Missed some tricks from C, but once I learned how to properly program in an object oriented fassion things got a lot easier.
You should tell some one. As it stands now, no one can agree on what OOP even means, let alone how to "program in an object oriented fashion".
Hell, two of the most commonly cited "essential properties" of OO, encapsulation and inheritance, are opposed to one another! Not only is the paradigm ill-defined, the most common definitions are fundamentally incoherent!
Why this fad didn't die in the early 90's I'll never know. Objects can be handy. Let's keep those around. Oh, and bring back agents; those made sense. OOP, on the other hand, needs to die and die quickly. While we're at it, the GoF need arrested and tried for crimes against humanity -- and anyone who's ever created a FactoryFactory tried as an accomplice. I can only begin to imagine how many billions of dollars they must have cost the global economy...
If pressing a button that says 'Coffee' pours you tea instead, "it's documented" is not a valid excuse.
What? == compares two values for equality. It's not like it multiplies them together and returns the square root!
PHP pretends to be a C-style language, with curly braces and whatnot - indeed, it's often cited as one of its advantages. Once that context is established, one would expect operator == to behave in a certain way - or at least to not behave in a certain way. Java, C#, JavaScript and a dozen other languages with similar syntax manage it just fine. PHP does not.
Ah, that's where you're wrong. == behaves similarly in other languages as well. JavaScript uses C-style syntax and 10=="10" -- oh, and "1e3"==1000 there as well. JS doesn't do the conversion if both the l and r operand are strings, sure, but you're less likely to encounter that case than you are in the typical PHP use case where you are much more likely to want to compare two strings as if they were numbers.
In the case of PHP that is, and should be, the expected behavior. Thinking about it now, I suspect that the author purposefully chose examples like "1e3"=="1000" because to the naive reader it looks like the operator is doing something completely incomprehensible, when in reality it's doing exactly what any sane person would expect it to do. That's just plain dishonest and further erodes the author's credibility -- making a terrible article even worse.
One of the basic principles of solid PL design is the principle of least surprise.
Sure. And PHP's == operator does not in any way violate that!
Why are we arguing over this tiny point? My point was that the article wasn't very good and that you'd do well to find a better article.
A language that routinely violates it for no reason whatsoever is a poorly designed language, period.
Okay, but the == operator in PHP rather obviously doesn't qualify. It behaves exactly as expected in the most common use cases. If it didn't do the conversion, the behavior of that operator would astonish new users more! (i.e the behavior of == would be more, not less, astonishing.)
Though I'll note that you'd be hard-pressed to find a language with nothing that violates that principle for no reason whatsoever, the holy C included.
Again, I'm not defending PHP -- this is not a discussion about how good or poor the language is. This is about the article and how shitty it is. I recommended that you find a better article as this one is unconvincing and poorly written. I even offered to help you find a better article.
But in PHP, in practice, == is so convoluted that it's effectively something that you shouldn't ever use, because the chances of it having semantics that you didn't intend in corner cases is too high. So why it's there?
It's there because you'll only have problems in extremely rare/unusual cases. In day-to-day use (e.g. web-based CRUD app) it works just fine. User inputs a number in a field, your script gets it as a string, and you later use that in a comparison treating it like a number (because that's what it's supposed to be). It works fine in that case, and does exactly what is says on the tin. It can really only cause a problem if you don't know what the operator is doing. (This is true of any operator: lot's of problems caused by ^ in other languages because the developer thought it did something completely different that what it actually does.)
To be honest, I've never once seen it cause a problem. Sure, it seems weird if your used to static typing, but the behavior is very well documented and not exactly difficult to follow. If you don't like it, or that behavior is likely to cause you problems, just use a different operator. (I don't use * when I want to subtract because * does not work that way.) Otherwise, == is rather convenient and, above all, actually makes sense to use most of the time in the context that PHP is most often used.
Really, it's not that different that the "weird" behavior you seemingly get in languages where + is used for string concatenation and addition. Obviously, if you know the basics of the language you're working in, neither == nor the double-duty + will cause you any more problems than the ^ operator. (Though you could make an argument that + pulling double duty is bad language design as the typical work-around is rather hackish.)
Note that this has nothing to do with language being "typeless", which PHP isn't anyway
Yes, that's why I put the word "typeless" it in quotes: so you and everyone else would know what I mean without either one of us needing to be pedantic, eventually ending up in a stupid argument about what to call PHPs type system. Well, I thought we could avoid that. That'll teach me. I'll never try to be clear without being needlessly precise again.
If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value.
Sorry, I don't understand what the problem is here? It's like complaining that the ^ operator in C is used for XOR when it's used for exponents in other languages or that = does assignment instead of a comparison in one language when it does both in other languages depending on context.
If you don't want a straight string comparison instead, you need to use a different operator (===). The complaint is equivalent to "I don't like this operator, I want to use the other one!" with the justification being "I don't understand how it comes up with 1000 from that crazy 1e3"
That's why I don't think the article is very good. it's not well thought out, virtually none of his complaints are supported/justified and when they are (he tries to justify his complaint), they don't show any real problem with the language other than "I don't like it" and sometimes "I don't understand it". Using the same standard he does, you could write a rant of similar-length about nearly every programming language.
To someone who isn't convinced, it's just not convincing. I would really recommend you find a better article that criticizes PHP. I can try to find one for you if you'd like.
RIM doesn't agree with you. Shipments of new phones are down about 1/2 what they were 2 years ago.
Again, their *user-base* is growing rapidly. Two years ago RIM was selling more smart phones than Apple. They were experiencing massive growth. That they're shipping few phones than two years ago isn't cutting in to their user base at all. Indeed, there are more BlackBerry users world-wide this quarter than in the previous quarter.
I agree that RIM has a good product, just not that it is comparable to Apple / Android offerings in terms of OS, software or hardware.
Take a second look at their current offerings (the 9900 is a solid high-end phone.) and remember that that is all legacy now. Take a look at their new OS and what we know about the new hardware. Hell, take a look at the developer preview devices, they're really good hardware-wise (the display is even better than Apples so-called 'retnal' display) and remember that that hardware is outdated compared to the hardware on the soon-to-be-released BB10 handsets.
They're not exactly behind in hardware and software -- and their new stuff puts them a ahead, at least as far as the software goes (it's just impossible to stay ahead of Android phones in terms of hardware for more than week with so many high-end devices released throughout the year). Their other great features like security and data efficiency are just icing on an already sweet cake.
Frankly given their data efficiency I think they should move down market.
This is precisely what RIM is doing in developing countries, where they've made significant inroad in emerging markets like India. On the enterprise side, they recently released an OS7 Curve without a camera to cater to users and organizations that can't have a camera or camera phone for whatever reason. Still, the money is in the high-end in western markets. I believe, based on what we know about BB10 and the new hardware, that they can recapture a large chunk of that market. They were the #1 selling smartphone brand less than two years ago, and the brand still carries a lot of weight -- just not on Slashdot.
Apple in 1997 was near death because they were slowly going from tiny to very tiny.
They were 90 days from insolvency when SJ came back. They were rapidly dying, not slowly shrinking.
RIM, in contrast, has no debt, a growing customer base, and their first quarterly loss (the latest one) was due to an inventory write-down (e.g. a paper loss).
They have a clear plan moving forward, a fantastic new OS, and a brilliant suite of dev tools. They've been very successful at developer outreach and their once anemic app ecosystem is rapidly nearing the 100k mark. They have made some great acquisitions and formed some great partnerships. They're in a MUCH better position that Apple was.
Oh, and that brilliant new OS? You'll see it Q1/2013 at the earliest.
WSJ posts bullshit from the rumor mill? I didn't check the article, but I'll bet it's a BGR post blindly barfed up. No official announcement, all signs point to a fall release.
I agree that there is a market (smaller than all of consumerdom, but not negligible) of people who want the security that BB offers, but I don't know if RIM will continue to be the company that offers it.
They're the ONLY company that can. No one else has ever come close. Besides, there's more to BB than just their best-in-class security. They're ahead of the curve in a lot of different areas.
Please, I'd LOVE to revisit this in one years time.
I have used PHP and I dont see what the complaint is. It provides specific functionality and is supported on many servers. It works and it is easy to use.
That's where you've gone wrong, people hate PHP because it's easy to use. I mean, we can't let just anyone write software! High-level languages should be as complicated as possible to discourage the have-nots!
Seriously, I truly believe that this is at the root of the PHP hate. It's the same reason that VB got bashed -- it let any idiot easily hack together an app, and any idiot did. Maintaining some inexperienced developers VB code was painful, and they blamed the language for daring to let non-experts write code. Nevermind that *they* got their start in BASIC on the C64 their parent's living room back in the 80's (a simple language that let them get up and running quickly). They're "professionals" now, and only professionals should be allowed to write code! (Hey, they wrote a FactoryFactoryFactory last week, after all. That's what experts do!)
There are legitimate gripes about the language, but I don't know of a single language that you can't complain about endlessly. It's "cool" to hate on PHP right now, however, so that's what the rock-star level super-programmers do -- they follow the latest fad blindly.
The problem with that article is that the author doesn't offer anything to readers who aren't already in complete agreement with him. A summary might read: "It's hard to explain why I think PHP is shit, but it is. It's like a box of tools that are okay, but not quite what you want." An analogy is fine, but it needs specific examples that support the analogy. Otherwise all he's saying is "I think PHP is bad because it's not very good" -- not the most convincing argument
Well, that's not fair. He does *try* to give a few examples, though the majority are "I don't like this or that syntax" or "I think it should be different" though he does seem to miss the "why", iirc, every single time.
He trys in the operator section about the behavior of == , however his example "1e3" == "1000" makes perfect sense and is exactly what you'd expect if both strings were converted to some number type before comparison. (iirc, C's atol would convert "1e3" to 1000) My advice to him on that point would be to read the documentation to learn how typing works -- it's not C, and you need to be especially careful with types in "typeless" languages like PHP. I guess "it's typeless" could be a valid complaint, but is more likely to start a holy war than a productive discussion about the merits of the language!
Indeed, the majority of his complaints just don't make sense. Take "Appending to an array is done with $foo[] = $bar", for example. What's wrong with that? Is it somehow worse than "$foo[count($foo)] = $bar;" or "array_push($foo, $bar);"?
I'd find a better article criticizing PHP. This one just isn't very good. Well, it's too big to criticize in its entirety, so it's got that going for it. (That is, you could easily defend it by saying "you didn't address X")
Closures are best avoided. They're not well understood (even by professionals), they're hard to read and understand, and (while occasionally handy) have extraordinarily limited use.
Of course, closures are the new hot thing right now so they're misused all over the damn place! I've even heard morons say that they can't imagine developing without them. Odd, as they got along just fine before they discovered them!
There have been a few times when I've been tempted to use closures. In every case it was because I had made a stupid design decision. A bit of extra thought and a bit of re-factoring and cleaner, faster, easier-to-maintain code was the result.
That is to say, in my experience, closures are a "code smell". If you see a place they may be convenient, stop immediately and re-think what you're doing!
That they're poorly understood is the only real reason closures and the whole "multi-paradigm" language fad has gained so much traction. If this discussion is any indication, developers HATE anything that's easy to use and they HATE that newbies write bad code. (Hint: they'll write bad code in any language, they're new to it!)
When I was 10 or 11 I was very nervous about letting people see my code. Why? If they saw how easy this programming thing was, then they wouldn't think I was smart or special in any way. I grew out of it, but it doesn't look like a lot of developers here have.
They WANT complexity. They don't want tools that are easy to use -- then they wouldn't be special! They love writing cryptic code that's difficult to understand. After all, they understand it, so that must mean they're 'smarter' than everyone else! They WANT to latch on to the latest fad like they've been waiting for it their entire lives, it makes the feel like they're "ahead of the game". Hell, why else would perl get so much love and php so much hate? Php is great for the same tasks that perl is great for, yet the easier-to-use language is panned and the one that practically encourages you to write unreadable code is praised!
Once they mature, they're learn that writing code that's easy to read and maintain is the single most important thing you can do. They'll learn that you don't get modularity for free just because you're using OOP (quite the opposite, in fact) and how proper modularity let's them write clean code that's easy to maintain. They may even learn that anyone who writes a FactoryFactory needs to be hung in the public square, and why doing something clever is a horrible idea 99.96% of the time.
So, yes, development by fad (using closures in languages like c# and js, AOP, hell, even OOP) is a horrible, horrible idea. It makes insecure developers feel important, sure, but that is the only benefit it brings.
How this got modded interesting, I'll never know. You didn't actually say anything!
PHP has some fundamentally wrong assumptions in its design,
Okay, now you're going to tell us about them, right? See, that would actually be interesting.
you can't fix it without just making it something that isn't PHP.
Oh, I guess not...
PHP has some warts, sure, but the most common criticism has been just inconsistent naming. There used to be some moaning that it was "object oriented", which I and many others considered a plus, but that's hardly "fundamentally wrong". I guess I'm missing something here?
Please, enlighten us lusers. How did you come to your your undoubtedly well-reasoned conclusion?
RIM is in MUCH better shape than Apple was at their low. They have a brilliant new OS, solid top-of-the-line hardware, and are still the only viable option where mobile security is important.
Sony has posted how many quarterly losses lately?
The last quarter was their first loss since the idiotic "RIM is dead" meme started (oddly enough, when they were still the #1 smartphone vendor). Their user-base is still growing rapidly. RIM is about as far from dead as you can get.
It sounds like the person filing the bug report would have rather they created a real_number_format function rather than fix a bug in the existing number_format function.
real_number_format() had a bug. Luckily, we're all rock-star level super-programmers so good that we went right in to the industry from HS (who needs college?) that only work on the biggest and most amazing projects and always produce amazing code.
So I created real_number_format_new(). Well, the lusers on team didn't get that quite right, but we used it everywhere and some code might have depended on the bug, so I created really_new_number_format()
After skipping over a work mate's new_real_number_format_final(), I'm currently on really_final_new_real_number_format()
It's shorter, both in original code size and in the number of documentation pages required to understand it.
Code size, yes and no. Yes in what you typed, no in what your page needs to function.
Absolutely No to "number of documentation pages required to understand it" As I pointed out, you need to know more about javascript to understand the jquery version than you do the plain js version. You also need to understand css selectors and jquery. I'm not buying it.
Further, the jquery version is harder to read and debug than the plain js version. Sure, it only takes a few extra seconds to parse out the jquery version, but multiply the number of cryptic lines of jquery (you know, by using it in practice) and start the inevitable chaining and you've got a maintenance nightmare!
To save a few seconds of typing you've traded efficiency, readability, maintainability, and bloated the page with a fat library.
Thanks. I assume you mean this one [amazon.com]. I'll check it out.
Slashdot Mirror
Don't confuse them with facts. The Slashdot parrots need memes. Facts tempt them to reason and form options, a sin of the highest order.
Try this instead: "Huur! Durrr! RIM is teh dead! Everything they've ever done sucked, lol!" -- That'll even get an AC a +5 Insightful.
Let's say that I grant that particular absurdity. This is what we get:
== is transitive over any scalar type, like every other language.
Even cooler, it is transitive over any two scalar types -- that means it's transitive over more combinations of types than most other languages where == does type conversion.
The most you can say is that it is not transitive over three or more scalar types simultaneously. Fine, but then again, neither is == in any other language!
His nonsense "proof", of course, is still embarrassingly wrong.
Let's hope this puts this particular waste of everyone's time to rest.
Sigh, I guess math isn't your strong suit!
That the operator does the type conversion for you is completely irrelevant. == is transitive. Remember, you can't test two values for equality if they're different types! (They're members of different sets that do not intersect, after all.) You'll get the exact same behavior in any other language if you do the type conversion yourself. Does that mean == in statically typed languages isn't transitive? Of course not!
The fact that things internally are bat shit crazy does not change that fact.
Lol, if by "bat shit crazy" you mean both well defined and completely obvious. Had you paid attention in logic 101, you wouldn't have parroted such a ridiculously bad "proof". I mean, it's pretty obvious on it's face that it's nonsense. I'm astonished that you thought it was legitimate -- I had thought you either copy/pasted it without thinking, or just thought you could pull a fast one!
what the evaluator does inside is retarded, and causes transitivity not to hold
No, it's not retarded. It's EXACTLY what you'd expect if you did the type conversion yourself! That the operator does it for you out of convenience is irrelevant. Why does it do any conversion? Because you can't test values of different types for equality!
Clearly, your play-pretend "proof" which is, as I've painfully explained to you, complete and total nonsense mathematically. Why are you still defending it? It's dead. It should be clear to you by now that it's neither mathematical nor a proof.
Copy/paste a better argument; preferably one that's legitimate. This one doesn't work, your "mathematical proof" is neither, and I'm tired of explaining simple shit to you.
There is a (admittedly outlined) mathematical proof that transitivity does not hold in my replies to you. Feel free to tell me why that's bullshit.
Damn, you're thick! It's like talking to a pile of rocks!
Your example is bullshit. It's just like the bullshit proofs like "1=2" or "the missing dollar" It's all a bit of misdirection designed to confuse idiots. Here, you're using types to do the misdirection:
for a = b you have "abc" == true which is evaluated as true == true // true // true // false
for a = c you have "abc" == 0 which is evaluated 0 == 0
for b = c you have true == 0 which is evaluated as 1 == 0
The first premise comparing two booleans, the next two are evaluating two integers. It's all a bit of misdirection, as it ultimately says NOTHING about the relationship between a,b, and c because a,b, and c are not identical between each premise. Mathematically, your "proof" doesn't make any fucking sense at all.
Fixing it so the types you actually compare match gives you: // false // true // false
for a = b you have "abc" == 1 which is evaluated as 0 == 1
for a = c you have "abc" == 0 which is evaluated 0 == 0
for b = c you have 1 == 0 which is evaluated as 1 == 0
As you can see, a = b is false when the types are ints and not bools.
Given a != b and a = c we assume that b != c (Look at that, b != c. It works just fine!)
Take away the bullshit, and your "proof" vanishes in a puff of logic.
Now go and sin no more.
If your response is "if you think that's broken, go and use another language", then you're not being very convincing are you ;)
Considering that wasn't my response, I think I'm okay.
Clearly you don't actually understand what transitivity means.
I know exactly what it means. I also explained why your claim that that property didn't hold was total bullshit.
It being documented is not the same thing as it being sane, or well designed, or sensible in a programming language ;)
Fine, but you haven't given any actually reason why it's "insane" or "poorly designed". As I've already pointed out, it works exactly like other dynamically typed languages! Christ, what the fuck is so hard about this? Just because you don't like dynamic typing does not mean that all dynamically typed languages are "fundamentally broken".
Wow, if you don't think these things are fundamentally broken, the programming community is more fundamentally broken than I realised. Really? People don't realise that mathematicians have worked out sets of consistent rules that give nice properties?
You're a moron. First Your == isn't transitive claim is false, as I've explained. It's not my fault you didn't understand it. Second, you clearly don't understand programming languages! For example: any OOP language that includes both incapsulation and inheritance (what *actually* are fundamentally opposed) is demonstrably incoherent. A bit worse than a bullshit claim about an operator, that like in may languages, does some type conversion before testing. (Again if you compare what is actually tested for equality, you'll see why your example is bullshit. I'll be that you can come up with a similar bullshit example in your prefered language!)
The 9900 is a 2 year old phone.
If you're this misinformed, I'm not even going to read the rest. It's pretty clear that you don't have a clue.
I did make a mistake. I missed the Q1 2013 announcement from the day before.
RIM is ahead of the curve in a number of areas: Security (obviously) and device management (still leagues ahead of competing products) are the two easy ones to hit. Their new OS is far more advanced, technically speaking, than iOS and Android. (Just take a look at this for just one cool thing.)
Their new UI is geared toward multitasking, it's incredibly slick, and well ahead of Android (which would require major changes to address) and iOS (which simple can't be adapted for similar functionality.) On that front, the competition has a long uphill battle to match RIM. Really, you really need to see it in action. The PlayBook just gives you a taste of what a real mutitasking experience on a mobile device can be. What we're seeing wtih BB10 is taking things to the next level. They also have the best mobile/tablet integration on the market, check out what you can do with Bridge.
They've solved the dual use problem of a work and personal phone with the full security and remote management enterprises demand and the total freedom users demand with Balance. Fusion provides the most comprehensive device management tool on the market, allowing Andorid, iOS, BB, etc. devices to all be managed seamlessly with a single application -- of course, other platforms don't have the same fine-grained control you get with BB devices, that's not something RIM can fix for them!
Less impressive, they have the best HTML5 support of any mobile browser (tablet), beating out many desktop browsers. BB10 brings even better support (as we've seen already) to both tablets and phones with very impressive score well ahead of other up-coming mobile browsers. (On phones, they're currently on par with Android 4 on OS7 handsets.)
They have a fantastic suite of development tools, including an NDK, offering developers more options for development than any other platform. Cascades (for UI development) is simply unmatched. (They acquired TaT, one of their best acquisitions to date, which is responsible for Cascades. Check it out if you're a developer.)
They've formed strong partnerships in the auto industry, leveraging that aspect of their QNX acquisition giving them a strong early lead in a market Apple is trying to break in to. Given that RIM has the objectively better technology, and QNX already has a long history in the auto industry, Apple has a hard fight in a market they clearly see as profitable enough to be worth pursuing.
The type system allows you to treat everything the same,
"I don't understand the type system and I don't like it" is not a fundamental problem of the language. If you want static typing, use C.
Heh, if you want to see what a totally screwed up type system actually looks like, take a look at Java.
and ends up with all kinds of crazy inconsistencies, like the fact that == is not transitive...
"abc" == true is true; "abc" == 0 is true; true != 0.
Wow, total fail! First, go read about how the == operator works and how types are converted between one another. Now, make a table and see what is actually being tested for equality. Oh, the magic bullshit vanishes and it turns out the transitive relation really does hold? Too funny! Heh, you can actually make a bullshit example like yours in many modern languages. Of course, it's still total nonsense -- but I'll bet it'll still convince morons that you're brilliant and the the language is "fundamentally flawed".
Want to try and fix the above problems with "==" by using "==="?
Ummm... No. You use == and === where appropriate. Read the fucking documentation. This isn't complicated. Any idiot can figure this out. (Wait, that's wrong. judging from this thread, not every idiot can handle something this simple.)
Well, that has its own problems – suddenly "==" compares the types of objects, while "===" doesn't...
Gee, I wonder why that is. If only I wasn't a total moron and could puzzle out why that's perfectly sensible... (Seriously, if you can't see what this makes perfect sense, I can't help you. It only looks inconsistent if you don't know anything about programming languages.)
What do you think NULL++ is in PHP? What about NULL--? What about "null"++ or "null"--?
Who cares? If you find yourself in any of those situations, you very obviously have bigger problems. I recommend switching professions to something more your speed, like "highway construction flag holder".
To directly answer your question, null++ behaves exactly the same way it does in other dynamically typed languages. So $a=null; $a++; $a will have a value of 1 It's the same, for example, in javascript. The string case "null"++ (well, $a=null; $a++; so that you can actually try it out.) is different between them because strings aren't the same kind of thing in js and php. PHP behaves like perl and returns "nulm" javascript will return NaN. Again, if you find yourself in a situation where this is relevant, you've probably made more than one horrible mistake.
Want to change it? Well, you can't really – that would change pretty much everything about the language.
Why would you want to change it? It's not broken! That you can't handle dynamic typing is not a fault of the language -- why it baffles you so, I'll never know.
There are plenty of legitimate gripes about PHP. This is not one of them. Go, and find an actual reason.
Missed some tricks from C, but once I learned how to properly program in an object oriented fassion things got a lot easier.
You should tell some one. As it stands now, no one can agree on what OOP even means, let alone how to "program in an object oriented fashion".
Hell, two of the most commonly cited "essential properties" of OO, encapsulation and inheritance, are opposed to one another! Not only is the paradigm ill-defined, the most common definitions are fundamentally incoherent!
Why this fad didn't die in the early 90's I'll never know. Objects can be handy. Let's keep those around. Oh, and bring back agents; those made sense. OOP, on the other hand, needs to die and die quickly. While we're at it, the GoF need arrested and tried for crimes against humanity -- and anyone who's ever created a FactoryFactory tried as an accomplice. I can only begin to imagine how many billions of dollars they must have cost the global economy...
If pressing a button that says 'Coffee' pours you tea instead, "it's documented" is not a valid excuse.
What? == compares two values for equality. It's not like it multiplies them together and returns the square root!
PHP pretends to be a C-style language, with curly braces and whatnot - indeed, it's often cited as one of its advantages. Once that context is established, one would expect operator == to behave in a certain way - or at least to not behave in a certain way. Java, C#, JavaScript and a dozen other languages with similar syntax manage it just fine. PHP does not.
Ah, that's where you're wrong. == behaves similarly in other languages as well. JavaScript uses C-style syntax and 10=="10" -- oh, and "1e3"==1000 there as well. JS doesn't do the conversion if both the l and r operand are strings, sure, but you're less likely to encounter that case than you are in the typical PHP use case where you are much more likely to want to compare two strings as if they were numbers.
In the case of PHP that is, and should be, the expected behavior. Thinking about it now, I suspect that the author purposefully chose examples like "1e3"=="1000" because to the naive reader it looks like the operator is doing something completely incomprehensible, when in reality it's doing exactly what any sane person would expect it to do. That's just plain dishonest and further erodes the author's credibility -- making a terrible article even worse.
One of the basic principles of solid PL design is the principle of least surprise.
Sure. And PHP's == operator does not in any way violate that!
Why are we arguing over this tiny point? My point was that the article wasn't very good and that you'd do well to find a better article.
A language that routinely violates it for no reason whatsoever is a poorly designed language, period.
Okay, but the == operator in PHP rather obviously doesn't qualify. It behaves exactly as expected in the most common use cases. If it didn't do the conversion, the behavior of that operator would astonish new users more! (i.e the behavior of == would be more, not less, astonishing.)
Though I'll note that you'd be hard-pressed to find a language with nothing that violates that principle for no reason whatsoever, the holy C included.
Again, I'm not defending PHP -- this is not a discussion about how good or poor the language is. This is about the article and how shitty it is. I recommended that you find a better article as this one is unconvincing and poorly written. I even offered to help you find a better article.
Damnit, I skipped the rest:
But in PHP, in practice, == is so convoluted that it's effectively something that you shouldn't ever use, because the chances of it having semantics that you didn't intend in corner cases is too high. So why it's there?
It's there because you'll only have problems in extremely rare/unusual cases. In day-to-day use (e.g. web-based CRUD app) it works just fine. User inputs a number in a field, your script gets it as a string, and you later use that in a comparison treating it like a number (because that's what it's supposed to be). It works fine in that case, and does exactly what is says on the tin. It can really only cause a problem if you don't know what the operator is doing. (This is true of any operator: lot's of problems caused by ^ in other languages because the developer thought it did something completely different that what it actually does.)
To be honest, I've never once seen it cause a problem. Sure, it seems weird if your used to static typing, but the behavior is very well documented and not exactly difficult to follow. If you don't like it, or that behavior is likely to cause you problems, just use a different operator. (I don't use * when I want to subtract because * does not work that way.) Otherwise, == is rather convenient and, above all, actually makes sense to use most of the time in the context that PHP is most often used.
Really, it's not that different that the "weird" behavior you seemingly get in languages where + is used for string concatenation and addition. Obviously, if you know the basics of the language you're working in, neither == nor the double-duty + will cause you any more problems than the ^ operator. (Though you could make an argument that + pulling double duty is bad language design as the typical work-around is rather hackish.)
Note that this has nothing to do with language being "typeless", which PHP isn't anyway
Yes, that's why I put the word "typeless" it in quotes: so you and everyone else would know what I mean without either one of us needing to be pedantic, eventually ending up in a stupid argument about what to call PHPs type system. Well, I thought we could avoid that. That'll teach me. I'll never try to be clear without being needlessly precise again.
Why the hell would you expect the strings to be converted to some number though, when both operands are strings?
Because that's the documented behavior
If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value.
Sorry, I don't understand what the problem is here? It's like complaining that the ^ operator in C is used for XOR when it's used for exponents in other languages or that = does assignment instead of a comparison in one language when it does both in other languages depending on context.
If you don't want a straight string comparison instead, you need to use a different operator (===). The complaint is equivalent to "I don't like this operator, I want to use the other one!" with the justification being "I don't understand how it comes up with 1000 from that crazy 1e3"
That's why I don't think the article is very good. it's not well thought out, virtually none of his complaints are supported/justified and when they are (he tries to justify his complaint), they don't show any real problem with the language other than "I don't like it" and sometimes "I don't understand it". Using the same standard he does, you could write a rant of similar-length about nearly every programming language.
To someone who isn't convinced, it's just not convincing. I would really recommend you find a better article that criticizes PHP. I can try to find one for you if you'd like.
RIM doesn't agree with you. Shipments of new phones are down about 1/2 what they were 2 years ago.
Again, their *user-base* is growing rapidly. Two years ago RIM was selling more smart phones than Apple. They were experiencing massive growth. That they're shipping few phones than two years ago isn't cutting in to their user base at all. Indeed, there are more BlackBerry users world-wide this quarter than in the previous quarter.
I agree that RIM has a good product, just not that it is comparable to Apple / Android offerings in terms of OS, software or hardware.
Take a second look at their current offerings (the 9900 is a solid high-end phone.) and remember that that is all legacy now. Take a look at their new OS and what we know about the new hardware. Hell, take a look at the developer preview devices, they're really good hardware-wise (the display is even better than Apples so-called 'retnal' display) and remember that that hardware is outdated compared to the hardware on the soon-to-be-released BB10 handsets.
They're not exactly behind in hardware and software -- and their new stuff puts them a ahead, at least as far as the software goes (it's just impossible to stay ahead of Android phones in terms of hardware for more than week with so many high-end devices released throughout the year). Their other great features like security and data efficiency are just icing on an already sweet cake.
Frankly given their data efficiency I think they should move down market.
This is precisely what RIM is doing in developing countries, where they've made significant inroad in emerging markets like India. On the enterprise side, they recently released an OS7 Curve without a camera to cater to users and organizations that can't have a camera or camera phone for whatever reason. Still, the money is in the high-end in western markets. I believe, based on what we know about BB10 and the new hardware, that they can recapture a large chunk of that market. They were the #1 selling smartphone brand less than two years ago, and the brand still carries a lot of weight -- just not on Slashdot.
Apple in 1997 was near death because they were slowly going from tiny to very tiny.
They were 90 days from insolvency when SJ came back. They were rapidly dying, not slowly shrinking.
RIM, in contrast, has no debt, a growing customer base, and their first quarterly loss (the latest one) was due to an inventory write-down (e.g. a paper loss).
They have a clear plan moving forward, a fantastic new OS, and a brilliant suite of dev tools. They've been very successful at developer outreach and their once anemic app ecosystem is rapidly nearing the 100k mark. They have made some great acquisitions and formed some great partnerships. They're in a MUCH better position that Apple was.
Oh, and that brilliant new OS? You'll see it Q1/2013 at the earliest.
WSJ posts bullshit from the rumor mill? I didn't check the article, but I'll bet it's a BGR post blindly barfed up. No official announcement, all signs point to a fall release.
I agree that there is a market (smaller than all of consumerdom, but not negligible) of people who want the security that BB offers, but I don't know if RIM will continue to be the company that offers it.
They're the ONLY company that can. No one else has ever come close. Besides, there's more to BB than just their best-in-class security. They're ahead of the curve in a lot of different areas.
Please, I'd LOVE to revisit this in one years time.
I have used PHP and I dont see what the complaint is. It provides specific functionality and is supported on many servers.
It works and it is easy to use.
That's where you've gone wrong, people hate PHP because it's easy to use. I mean, we can't let just anyone write software! High-level languages should be as complicated as possible to discourage the have-nots!
Seriously, I truly believe that this is at the root of the PHP hate. It's the same reason that VB got bashed -- it let any idiot easily hack together an app, and any idiot did. Maintaining some inexperienced developers VB code was painful, and they blamed the language for daring to let non-experts write code. Nevermind that *they* got their start in BASIC on the C64 their parent's living room back in the 80's (a simple language that let them get up and running quickly). They're "professionals" now, and only professionals should be allowed to write code! (Hey, they wrote a FactoryFactoryFactory last week, after all. That's what experts do!)
There are legitimate gripes about the language, but I don't know of a single language that you can't complain about endlessly. It's "cool" to hate on PHP right now, however, so that's what the rock-star level super-programmers do -- they follow the latest fad blindly.
The problem with that article is that the author doesn't offer anything to readers who aren't already in complete agreement with him. A summary might read: "It's hard to explain why I think PHP is shit, but it is. It's like a box of tools that are okay, but not quite what you want." An analogy is fine, but it needs specific examples that support the analogy. Otherwise all he's saying is "I think PHP is bad because it's not very good" -- not the most convincing argument
Well, that's not fair. He does *try* to give a few examples, though the majority are "I don't like this or that syntax" or "I think it should be different" though he does seem to miss the "why", iirc, every single time.
He trys in the operator section about the behavior of == , however his example "1e3" == "1000" makes perfect sense and is exactly what you'd expect if both strings were converted to some number type before comparison. (iirc, C's atol would convert "1e3" to 1000) My advice to him on that point would be to read the documentation to learn how typing works -- it's not C, and you need to be especially careful with types in "typeless" languages like PHP. I guess "it's typeless" could be a valid complaint, but is more likely to start a holy war than a productive discussion about the merits of the language!
Indeed, the majority of his complaints just don't make sense. Take "Appending to an array is done with $foo[] = $bar", for example. What's wrong with that? Is it somehow worse than "$foo[count($foo)] = $bar;" or "array_push($foo, $bar);"?
I'd find a better article criticizing PHP. This one just isn't very good. Well, it's too big to criticize in its entirety, so it's got that going for it. (That is, you could easily defend it by saying "you didn't address X")
Nonsense! I've been waiting for a damn flying car for years.
Probably because heavier-than-air flight is just impossible.
Indeed. It's fast and reliable.
There are innumerable stories relating failed COBOL-on-a-mainframe to Java-on-commodity-hardware "upgrade" projects for a reason.
Using a lambda that is called immediately just to create a new scope is a hack, plain and simple.
Holy shit, I actually agree with you! (Well, almost. It sure as hell feels like a hack, like I'm doing something horribly wrong.)
There are other ways to limit polluting the global namespace. The module pattern is just plain bad.
Closures are best avoided. They're not well understood (even by professionals), they're hard to read and understand, and (while occasionally handy) have extraordinarily limited use.
Of course, closures are the new hot thing right now so they're misused all over the damn place! I've even heard morons say that they can't imagine developing without them. Odd, as they got along just fine before they discovered them!
There have been a few times when I've been tempted to use closures. In every case it was because I had made a stupid design decision. A bit of extra thought and a bit of re-factoring and cleaner, faster, easier-to-maintain code was the result.
That is to say, in my experience, closures are a "code smell". If you see a place they may be convenient, stop immediately and re-think what you're doing!
That they're poorly understood is the only real reason closures and the whole "multi-paradigm" language fad has gained so much traction. If this discussion is any indication, developers HATE anything that's easy to use and they HATE that newbies write bad code. (Hint: they'll write bad code in any language, they're new to it!)
When I was 10 or 11 I was very nervous about letting people see my code. Why? If they saw how easy this programming thing was, then they wouldn't think I was smart or special in any way. I grew out of it, but it doesn't look like a lot of developers here have.
They WANT complexity. They don't want tools that are easy to use -- then they wouldn't be special! They love writing cryptic code that's difficult to understand. After all, they understand it, so that must mean they're 'smarter' than everyone else! They WANT to latch on to the latest fad like they've been waiting for it their entire lives, it makes the feel like they're "ahead of the game". Hell, why else would perl get so much love and php so much hate? Php is great for the same tasks that perl is great for, yet the easier-to-use language is panned and the one that practically encourages you to write unreadable code is praised!
Once they mature, they're learn that writing code that's easy to read and maintain is the single most important thing you can do. They'll learn that you don't get modularity for free just because you're using OOP (quite the opposite, in fact) and how proper modularity let's them write clean code that's easy to maintain. They may even learn that anyone who writes a FactoryFactory needs to be hung in the public square, and why doing something clever is a horrible idea 99.96% of the time.
So, yes, development by fad (using closures in languages like c# and js, AOP, hell, even OOP) is a horrible, horrible idea. It makes insecure developers feel important, sure, but that is the only benefit it brings.
How this got modded interesting, I'll never know. You didn't actually say anything!
PHP has some fundamentally wrong assumptions in its design,
Okay, now you're going to tell us about them, right? See, that would actually be interesting.
you can't fix it without just making it something that isn't PHP.
Oh, I guess not...
PHP has some warts, sure, but the most common criticism has been just inconsistent naming. There used to be some moaning that it was "object oriented", which I and many others considered a plus, but that's hardly "fundamentally wrong". I guess I'm missing something here?
Please, enlighten us lusers. How did you come to your your undoubtedly well-reasoned conclusion?
. Second, their "brilliant new OS, solid top-of-the-line hardware" combination isn't slated to come out for another year
This fall isn't "another year" away.
RIM is in MUCH better shape than Apple was at their low. They have a brilliant new OS, solid top-of-the-line hardware, and are still the only viable option where mobile security is important.
Sony has posted how many quarterly losses lately?
The last quarter was their first loss since the idiotic "RIM is dead" meme started (oddly enough, when they were still the #1 smartphone vendor). Their user-base is still growing rapidly. RIM is about as far from dead as you can get.
It sounds like the person filing the bug report would have rather they created a real_number_format function rather than fix a bug in the existing number_format function.
real_number_format() had a bug. Luckily, we're all rock-star level super-programmers so good that we went right in to the industry from HS (who needs college?) that only work on the biggest and most amazing projects and always produce amazing code.
So I created real_number_format_new(). Well, the lusers on team didn't get that quite right, but we used it everywhere and some code might have depended on the bug, so I created really_new_number_format()
After skipping over a work mate's new_real_number_format_final(), I'm currently on really_final_new_real_number_format()
It's shorter, both in original code size and in the number of documentation pages required to understand it.
Code size, yes and no. Yes in what you typed, no in what your page needs to function.
Absolutely No to "number of documentation pages required to understand it" As I pointed out, you need to know more about javascript to understand the jquery version than you do the plain js version. You also need to understand css selectors and jquery. I'm not buying it.
Further, the jquery version is harder to read and debug than the plain js version. Sure, it only takes a few extra seconds to parse out the jquery version, but multiply the number of cryptic lines of jquery (you know, by using it in practice) and start the inevitable chaining and you've got a maintenance nightmare!
To save a few seconds of typing you've traded efficiency, readability, maintainability, and bloated the page with a fat library.
Thanks. I assume you mean this one [amazon.com]. I'll check it out.
Yep, that's the one. A few pages you might also find of interest:
Slides from Estelle Weyl's presentation at OReilly's Fluent Conference
JQuery without JQuery