WhatsApp Rolls Out End-To-End Encryption to Its Over 1B Users - <AUTHOR> https://www.eff.org/deeplinks/2016/04/whatsapp-rolls-out-end-end-encryption-its-1bn-users <comment><USER3> It's great that WhatsApp can't see my cat pictures anymore. But there are 2 privacy and free speech issues that are not met.

Firstly META DATA. They know who I contact, when I contact them and how frequently. So people could derive information about me based on who I talk to.

Secondly, they can ban me.

Perhaps the EFF need to add more criteria to their secure message score card. [https://www.eff.org/secure-messaging-scorecard](https://www.eff.org/secure- messaging-scorecard)

But on the whole, a positive move.

<comment><USER4> When the client is a phone and the service is rapid messaging, how do you even begin to solve the metadata problem?

Even with opaque routing the phone company can correlate activity times.

<comment><USER5> There's never a single right solution, but if traffic analysis was the issue, endpoints could introduce latency, use Tor, sync/mix traffic with other endpoints via P2P, inject fake traffic, etc. - though if the core system leaks metadata, this would be pointless.

<comment><USER6> Messaging apps are often used outside, with limited bandwidth, and are highly interactive. I would be annoyed to wait more than 0.5 sec until my message is delivered.

Maybe an "ultra-secure" mode could be created, and if you enable that for a chat, traffic could be routed through tor. And you would have a separate list of "ultra-secure" contacts, which are not based on phone-numbers.

<comment><USER4> Special routing for the ultrasecure messages highlights that they were requested to be ultrasecure and makes correlation easier (by reducing the candidate pool).

<comment><USER6> Right, but it would be like the ISP knowing that you use Tor. Useful, but not that much if you do it constantly.

This ultra-secure mode for example could send a 1 KB packet every 15 minutes, weather you are talking with someone or not. Something would also need to be done to incoming packets, so that they won't stand out. I'm sure there is a suitable protocol out there. This would increase latency and reduce capacity, but this is why it's called ultrasecure, some inconveniences are expected.

</comment></comment></comment></comment></comment></comment><comment><USER7> Apps that force you to give them (and everyone else) your phone numbers for .. ummm ... "contact discovery" and yet talk about privacy are a bit of a contradiction.

No plausible reason for why apps like WhatsApp (and Signal) couldn't use e-mail addresses for this. Or at least provide it as an alternative. It's even problematic for people who change phone numbers, have multiple phones, want to use desktop clients, etc

My opinion: if it requires a phone number, it's not really interested in privacy. Move on.

<comment><USER8> I feel there is no relation to privacy here. It's also the practical choice. Emails can be easily created to by people pretending to be someone else. If you have someone's number on your phone, there is a good chance you have communicated with them before and have thus done some authentication. You can keep creating new email ids to spam people. That becomes very difficult with numbers.

<comment><USER7> Sure there is. My phone number is private information. And it can trivially be traced back to me (no possibility of anonymity).

I don't necessarily want to share it with everyone I want to talk to. Or every company that makes a chat app.

I'm pretty sure Snowden didn't start out by giving his phone number around...

Plus every successful chat app before WhatsApp (from ICQ, XMPP apps, MS Messenger, Google Chat, Facebook Messenger) was fine without this requirement.

Is the hypothesis that it is now impossible to have a successful chat app without it being tied to a phone number?

We are not discussing a convenience "option" the user can skip but rather a requirement for these apps to work.

<comment><USER9> WhatsApp is a mobile messaging app. It's a drop-in replacement for SMS. There would be absolutely no reason for _anyone_ to use WhatsApp if they were just another chat app with their own contact discovery that's not based on phone numbers. Their market share would be miniscule.

No one is forcing you to use a messaging app which is using your phone number as an identifier to contact anyone you don't want to see your phone number.

<comment><USER7> No one is forcing anyone to make claims about privacy either.

1) New social networks tend to replace old social networks: I'm not forced to use it but, for example, I can't go back to XMPP because others don't use it anymore. Meaning the option is not to communicate.

2) If everyone, including open-source developers (e.g. Signal), are doing this now and no-one is developing alternatives that run on modern platforms and are easy to use in non error-prone way w/o phone numbers, what exactly are the options even disregarding social network effects?

3) I doubt it's fully clear to many people what can be inferred from metadata related being trivial to prove who they spoke to and when. E.g. if it had been trivial for the NSA to know that one of its contractors was chatting with reporters it would've been game over for Snowden. In courts, circumstantial evidence like this can still be (and has been) used to imply guilt. Implying privacy under these circumstances seems unwise.

4) WhatsApp is mobile, fast, reliable and easy to use; Most of their competition at the time it launched and even now can't match that. This includes FB Messenger, Skype, Google, MS Messenger, etc I'm not sure it is proven that their success is entirely due to phone numbers. I've seen lots of people exchange phone numbers just for whatsapp.

<comment><USER9> > 1) New social networks tend to replace old social networks: I'm not forced > to use it but, for example, I can't go back to XMPP because others don't use > it anymore. Meaning the option is not to communicate.

Right, but this is a _mobile messaging app_. There are still hundreds of _desktop_ (or: not primarily mobile) messaging apps out there, many of which are _very_ popular, and they're not going away any time soon. Phone numbers are how mobile phones are usually identified, and to ask a _mobile_ messaging app to use something else for identification is, to put it bluntly, quite silly.

> 2) If everyone, including open-source developers (e.g. Signal), are doing > this now and no-one is developing alternatives that run on modern platforms > and are easy to use in non error-prone way w/o phone numbers, what exactly > are the options even disregarding social network effects?

There's nothing in the protocol that forces anyone to use phone numbers as identifiers. The current users of the Signal protocol just _happen_ to be mobile messaging apps, where it makes sense to use phone numbers as identifiers.

> 3) I doubt it's fully clear to many people what can be inferred from > metadata related being trivial to prove who they spoke to and when. E.g. if > it had been trivial for the NSA to know that one of its contractors was > chatting with reporters it would've been game over for Snowden. In courts, > circumstantial evidence like this can still be (and has been) used to imply > guilt. Implying privacy under these circumstances seems unwise.

Now you're talking about metadata, and that's a different topic entirely. Merely using a pseudonym instead of your phone number as an identifier is going to do exactly _nothing_ to prevent any of the things you mentioned. If you want to hide your metadata, you should be looking at something like vuvuzela[1]. No one claimed that WhatsApp is doing any of that.

> 4) WhatsApp is mobile, fast, reliable and easy to use; Most of their > competition at the time it launched and even now can't match that. This > includes FB Messenger, Skype, Google, MS Messenger, etc I'm not sure it is > proven that their success is entirely due to phone numbers. I've seen lots > of people exchange phone numbers just for whatsapp.

I'd argue that they wouldn't have been able to reach critical mass without phone number-based contact discovery. That they were the only ones who did it _right_ at the time doesn't mean the two aren't related.

[1]: [https://github.com/davidlazar/vuvuzela](https://github.com/davidlazar/vuvuzela)

<comment><USER7> > . Phone numbers are how mobile phones are usually identified, and to ask a > mobile messaging app to use something else for identification is, to put it > bluntly, quite silly.

I disagree it's silly.

> There's nothing in the protocol that forces anyone to use phone numbers as > identifier

I'm aware. But there's also no alternative to phone number now. So my point stands until this changes.

> Merely using a pseudonym instead of your phone number as an identifier is > going to do exactly nothing to prevent any of the things you mentioned

Yes it does if the pseudonym can not be connected to me. That requires other security/privacy measures but phone numbers prevent that.

> No one claimed that WhatsApp is doing any of that.

If you say something is great for privacy but don't include the asterisks it's misleading.

> I'd argue that they wouldn't have been able to reach critical mass without > phone number-based contact discovery.

No one has proven it either way. I can't be certain they would've been successful, you can't they wouldn't. But I do submit as evidence of my hypothesis that several social networks were successful on mobile without it (e.g. Twitter, Instagram and Facebook).

<comment><USER9> > But I do submit as evidence of my hypothesis that several social networks > were successful on mobile without it (e.g. Twitter, Instagram and Facebook).

All of those examples use phone numbers as (at the very least) a secondary contact discovery mechanism on mobile. All but Instagram had existing user bases when they went into the mobile market. None of them are primarily a messaging app.

Do you have an example of a _popular_ mobile messaging app without phone number-based contact discovery?

<comment><USER7> Do you have an example of a popular mobile messaging app other than WhatsApp

<comment><USER9> WeChat has over 650 million users, mostly in China. Quoting Wikipedia: "WeChat allows people to add friends by a variety of methods, including searching by username or phone number, adding from phone or email contacts [...]"

<comment><USER7> Good one.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> EFF should stop with this silly scorecard. I hate the thing because it's inaccurate and incoherent (arguments I've made ad nauseam elsewhere on HN), but on this thread you can see another good reason: it makes EFF the ref, and crowds always try to work the ref.

So whatever "score" WhatsApp gets, it's the wrong score, because: not open source; because: runs on iPhones; because: metadata; because: Facebook is evil, &c.

<comment><USER11> But the point the EFF makes is very important. If the code is not open source, we just cannot verify the security of the application. All applications must be considered unsafe unless we can review the code. We can't review Whatsapp's source code, and therefore Whatsapp is to be considered unsafe.

So yeah, Whatsapp has made a probably positive move, but it is still largely unsafe.

<comment><USER12> But if the code is open source, we _can_ verify it's security?

Heartbleed and Shellshock, the two most significant vulnerabilities found in heavily used open source software, were found by vulnerability testing and not code inspection. So while being open source is a nice-to-have attribute for a piece of software, that's as far as it goes. Painting open source as being a magical wand that wishes away all our security troubles is completely out of order.

Edit: I'll go further. It's become dismayingly apparent that very little systematic code review of open source software in order to secure it is actually taking place. It now seems quite possible that the most thorough investigations of software vulnerability, via code analysis or any other techniques, are carried out by those wishing to exploit them. They are well funded and highly motivated. Looked at in that light, the balance may well tip towards open source actually increasing the likelihood of software vulnerabilities being exploited maliciously.

The open source community has a long way to go if it's going to clearly demonstrate that it's model is advantageous, and complacent pronouncements of it's assumed superiority like this aren't going to achieve that.

<comment><USER13> > But if the code is open source, we _can_ verify it's security?

No - the code could be "open source" but unreadable. But if it's not open- source there's definitely nothing we can do.

> Heartbleed and Shellshock, the two most significant vulnerabilities found in > heavily used open source software, were found by vulnerability testing and > not code inspection. So while being open source is a nice-to-have attribute > for a piece of software, that's as far as it goes

a) afl-fuzz and the like require access to the source code.

b) Those were the vulnerabilities that made it into production. They tell you nothing about what proportion of potential vulnerabilities were stopped by it being open source.

<comment><USER10> Fuzzers _do not_ require source code. That is absolutely false. Afl-fuzz does, but you badly overplayed your hand by adding "and the like". Fuzzing proprietary closed source protocols by instrumenting closed-source binaries is a bread-and-butter software security project that virtually any application security consultant can do effectively.

<comment><USER14> And even afl has qemu-mode, although I have no idea how well that works.

</comment></comment></comment></comment></comment></comment><comment><USER15> This is quite a cavalier recommendation for proprietary unaudited (for the public at least) spyware that uploads your phone book to a company participating in PRISM.

<comment><USER16> WhatsApp doesn't upload your phone book. All contact info resolution is done locally.

<comment><USER15> How does the app figure out another telephone number has a WhatsApp account? How does it fetch profile information for that telephone number without communicating the desire to fetch it to WhatsApp? Perhaps WhatsApp ships their entire profile photo and telephone number database to every phone

<comment><USER16> There are two things here: a) the app can take a snapshot of your phone book, upload it, associate it with your own WhatsApp account, and then keep the remote version synchronised; and b) the app can periodically perform disparate requests to the central directory server to query the profile information for each number. As far as I know, WhatsApp uses approach b. These two may seem similar but in approach b, WhatsApp the service wouldn't learn of any contact removals. WhatsApp the app would, of course, but the service wouldn't. Now, with some simple filtering and statistics, WhatsApp the service can deduce your phone book with some certainty, but I believe most would agree that it is materially different from actually uploading your phone book.

<comment><USER9> > Now, with some simple filtering and statistics, WhatsApp the service can > deduce your phone book with some certainty, but I believe most would agree > that it is materially different from actually uploading your phone book.

No, not really. Both implementations give WhatsApp a complete list of all my contacts. The fact that one of those implementations _might_ not be 100% accurate because of deleted contacts changes nothing - if you're someone who's worried about a third party having your contact list, it doesn't make sense to think "but hey, they don't know I removed $FOO last week, so their list isn't 100% accurate!".

Both implementations mean you'll have to take their word on what they will and won't do with the data, so there's really not much of a practical difference.

</comment></comment></comment></comment></comment><comment><USER17> Doesn't appear to mention metadata at all.

While metadata is somewhat tangential to the actual encryption, it's still a vital part of a truly secure messaging platform - who we talk to reveals quite a lot about us.

I'm not sure how solvable this is without sacrificing the usability that makes whatsapp as nice to use as it is, and I certainly don't want to take away from how great it is that they've done this - but it is important not to lose sight of the fact that encrypting the contents of your messages is only one part of the puzzle.

<comment><USER18> It's the same problem with Signal actually ;) All the communications of the official clients are sent to some "official" Signal Amazon servers (see [https://github.com/WhisperSystems/Signal- Android/blob/master...](https://github.com/WhisperSystems/Signal- Android/blob/master/build.gradle#L166-172)).

Doing end to end encryption is nice, but I really think that having a decentralized AND standard architecture is also very important.

</comment></comment><comment><USER19> Too bad 8/10 of your contacts have automatic backups to iCloud or Google Drive enabled. Kind of defeats the idea of "end-to-end". More like end-to-end-to- cloud.

<comment><USER20> Apps can control the content that they backup to Google, I'm going to guess Apple has something similar.

[http://developer.android.com/training/backup/autosyncapi.htm...](http://developer.android.com/training/backup/autosyncapi.html)

</comment></comment><comment><USER21> That's nice. What I really want to know is, can Mark Zuckerberg read my messages? Do WhatsApp servers have access to the private keys needed to decrypt my communications? If the answer to those questions is "yes", then it's great that we are now protected from most cybercriminals, but the NSA is probably monitoring our messages. If the answer to those questions is "no", I may actually decide to start using WhatsApp.

<comment><USER22> They cannot read your messages. The entire idea behind this is to give them a claim of technical infeasability if they are served with a warrant. However, if there is/will be some sort of back door to cease encryption without the user's knowledge, that's another matter which really would require it being open source.

<comment><USER23> How will it being open source guarantee you that the app you downloaded from the platform's store is using the exact same code?

<comment><USER24> You can compile the binary yourself and match the SHA1 against the binary downloaded from the store. It seems quite trivial.

<comment><USER25> It's not that easy. Due to toolchain and platform differences, there is no guarantee that your compiler will produce the same binary as the official distribution. This is why deterministic, reproducible builds are a growing area of interest right now.

</comment></comment></comment></comment></comment><comment><USER26> EFF recommending closed source clients, erm they just drop in my esteem.

<comment><USER27> They deduct points as it's still open source. And they are more applauding the fact that WhatsApp - probably the most widely used messaging app currently - has adopted strong end to end encryption, something which other clients have been loathe to do.

This is a win. To disregard everything that WhatsApp and Signal have accomplished because WhatsApp isn't open source is silly.

<comment><USER28> No but to blindly trust in it is silly. Even openssl had a heart-bleed bug that persisted for years without most people realizing it. All it takes is one bug for the entire thing to be useless.

<comment><USER27> And heartbleed is also than example of open source not being totally secure. It was a bug that persisted for years before it was found - and OpenSSL is open source.

It's just as foolish to blindly trust OSS. There will always be holes - <USER2> main point to OSS is not to combat these, as they will exist regardless. Rather, it is so one might know exactly what they're installing/using, without having to trust the corporation behind it.

<comment><USER28> no it's foolish to trust something that hasn't been independently reviewed. How can EFF recommend something that hasn't even been subjected to an independent security audit?

</comment></comment></comment></comment></comment><comment><USER29> But WhatsApp requires a phone number, and requires that the recipient (of your message) have your number in their contacts list (or at least you should have their number in your contacts). Once your number (and your contacts') have been leaked to WhatsApp, enough metadata has been leaked to make communication risky.

Why doesn't WhatsApp allow anonymous communication? I should be able to create ephemeral WhatsApp "IDs", and anyome who knows my "ID" should be able to communicate with me anonymously and securely, no strings attached.

</comment><comment><USER30> This is a bit weird. I don't believe WhatsApp are lying but there's absolutely no proof they're not.

I could release a closed source app with a bunch of padlocks in it and copy/paste their white paper and have exactly the same level of proof of security. Would I get a 7/10 from EFF?

<comment><USER31> If you had the credibility of a billion dollar company behind you saying that you're not making it up, then probably.

<comment><USER32> I didn't know credibility was measured in dollars.

<comment><USER31> Reputational damage is higher for entities with more money. Therefore their credibility of not doing something that causes reputational damage is higher.

<comment><USER33> > Reputational damage is higher for entities with more money.

In what world? Big business figured out a long time ago that most of the time their bad actions _won 't be noticed_ by most people. The rest can often be fixed with some inexpensive spin and PR. Their reputation is only damaged when a scandal is _very_ large and in the right place and time to be noticed.

A "billion dollar company" necessarily has a strong profit motive. It's also subject to the codes and regulations of the country in which they operate. The former damages their credibility (they will do what is profitable, not what is moral), and the latter makes communication platforms suspect (government involvement).

Of course, we don't have to speculate - this is Facebook. They are not only part of Prism, but their entire business is based on surveillance. Not only do they have _zero_ credibility for respecting privacy, they are actively _hostile_.

<comment><USER31> You're disputing that it causes reputational damage, not that reputational damage scales with money.

I'm _not_ saying that they'd lose reputation from "not respecting privacy". That's not considered that bad by the general public. I'm saying that they'd lose reputation from "claiming to release a feature while lying through their teeth about it".

</comment></comment></comment></comment></comment></comment><comment><USER34> It's important to point out that all the Whisper Systems code is open source ([https://github.com/whispersystems/](https://github.com/whispersystems/)). So if you have concerns, go read their code. Some of the best minds in security have, and they've come away with good things to say. There's a desktop version of Signal coming, which I'd personally be inclined to use over WhatsApp, but this is still a fantastic move.

</comment><comment><USER35> It's an improvement, but proper end-to-end encryption on unsafe devices is about as useful as seat belts on an airplane.

<comment><USER36> So it protects you from bad turbulence but in a catastrophe you are still screwed.

</comment></comment><comment><USER37> I am still trying to wrap my head around privacy in the modern age, and this triggered something for me - this is the end of the privacy-at-a-distance problem.

There is a large body of law around making distance communication private ("secure in ones papers" I think is the phrase from American law. Not allowing people to steam open your letters etc)

This move, which I am including the inevitable "pgp emails using whatsapp collected public/private keys" seems destined to end the problem - two hundred years of law, one code release.

Really sure an email app will be next now they are building a base of secure keys

Edit: it's now the purview of regulation to require me to keep / handover private conversations as pre-Snowden and that seems a good thing. It forces surveillance to be active and open once again

</comment><comment><USER38> I am so cynical (or is that realistic?) these days, that I would not trust the encryption on WhatsApp as far as I can throw a large, adult saltwater crocodile.

<comment><USER39> They implemented a known & vetted encryption protocol with expert consultation from the outside.

Its one of the most widely distributed apps in the world & thus likely to have lots of people looking at it.

If you don't trust it, is there any possible encryption scheme you would trust?

<comment><USER40> I think the general trust issues people have are

\- metadata / contact lists in the hand of Facebook

\- a proprietary binary that _claims_ to use said encryption schemes

Scenarios that you could come up with:

The next version of WhatsApp sends unencrypted data again.

WhatsApp encrypts for your recipient just fine, but also encrypts the same message for the great Facebook skeleton key.

Basically trust is a bigger problem than you acknowledge here, I think. If you trust the encryption scheme, even the specific encryption implementation, then you still need to trust the (binary, closed) application. Ignoring the metadata issue completely for now.

<comment><USER20> >The next version of WhatsApp sends unencrypted data again. >WhatsApp encrypts for your recipient just fine, but also encrypts the same message for the great Facebook skeleton key.

Both of these can and would show up in an analysis of the code.

</comment></comment></comment></comment><comment><USER41> web.whatsapp.com still works, so clearly it's possible for something outside my phone to gain access to my phone generated keys. That doesn't seem backdoorable to me /s.

<comment><USER9> WhatsApp Web communicates directly with your phone. You have to authorize the session from within the app. Communication between your browser and the app is end-to-end encrypted.

<comment><USER41> I hadn't thought about re-encrypting the messages for end to end communication with the browser so it's a plus that the phone doesn't have to give away its keys _but_ there exists a mechanism for the phone to retransmit the messages, because we can't see the source we have no idea if there's a way for WhatsApp to trigger this remotely and as such create a back door.

<comment><USER9> The existence of this feature has no implications on the question of whether or not there's a backdoor in the client. The current implementation requires approval by the _client_. A hypothetical backdoor could be anywhere, and you wouldn't know about it unless you check the bytecode.

</comment></comment></comment></comment><comment><USER42> This is quite a big win for privacy. If you use Whisper, Tor or most of the other privacy minded communications mediums, you are in a small minority so you stand out. Because a very large part of the population is using Whatsapp this allows you to communicate privately without standing out.

</comment><comment><USER43> What happens when I log on to WhatsApp Web? How they send my private key from my phone to my web browser?

<comment><USER44> They do not. They create a e2e connection between your phone and your browser. Everything goes threw the phone.

<comment><USER45> To post a follow-up comment, what happens when you lose your phone, or simply move to a new phone? Presumably you've lost all of your private keys (I mean...obviously they must not upload them or this would all be farce), message history, etc, right?

<comment><USER42> Your message history is lost unless you back it up yourself. Your contacts receive a message stating you changed the key once you send them a message or they send you one. I'd presume any messages that were sent before you activated the new key, but not received yet, cannot be decrypted any more.

I do not know how this works with push messages though; it used to be such that these can only be sent as-is so the server would need the key.

</comment></comment></comment></comment><comment><USER46> Has the WhatsApp code been audited by trusted third parties? I know it's not quite as good as it being open source, but if we had people we trust audit it, that seems like a good step. Also, disassembly and teardown.

I think something this big needs people to really really scrutinise it.

</comment><comment><USER47> How does the WhatsApp encryption model differ from Apple's iMessage encryption model?

\- In iMessage, Apple handles key distribution, so if I'm in your contacts, I know the keys for all of your Apple devices. (I'm guessing the private key stays on the device, but I'm not sure).

\- iMessage seems to provide no way of verifying someone's key fingerprint.

\- On the other hand, whatsApp seems to force you and your contacts to meet at a Starbucks so you can distribute and sign each other's public keys. Interesting.

What other differences are there?

(to make this easier, let's assume that both companies implemented the system the way they claim they did)

<comment><USER45> The app automatically distributes public keys, to my knowledge, and the QR code is merely a validation mechanism to ensure that no MITM is substituting keys.

The EFF seems to think the QR code thing is the bee's knees. In practice, I would wager less than 0.1% of users will make use of that functionality. It's more of a placebo.

<comment><USER42> If there is widespread snooping even a small percentage of users verifying their keys will expose it.

<comment><USER45> If there was widespread snooping, it would imply either WhatsApp collaboration or compromise, in which case the app could show whatever they wanted it to show (or they could just upload all of the private keys, which they may very well do in any case).

However I was talking about QR code versus the widely known fingerprint. The EFF seems to think the QR code is just a huge improvement, but I just don't think it will see any usage at all over the fingerprint, but instead it provides the illusion of security ala "look there's this complex thing...and some people must be validating it...so I'll just trust it."

</comment></comment></comment></comment><comment><USER48> Fantastic news - gets us closer to most Internet traffic being encrypted.

I have seen complaints that meta data is not hidden, that is, there is a record with who you communicate with.

I might have an unpopular opinion here, but I don't think that having the meta data unhidden is in general such a bad thing. I am happy having my communications secure but having who I communicate with potentially public knowledge. Fair compromise.

For whistleblowers, protecting metadata is important, so use something else.

</comment><comment><USER49> Garden path questions:

What's the easiest way to get a copy of your own WhatsApp private key from your phone?

What's the easiest way to get a copy of your friend's WhatsApp private key from their phone?

What if the phone is rooted, or you can root it?

What if they won't hand you the phone?

What if they are on your specially built wifi?

What if you have a fake cell tower?

What if you have a real cell tower?

What if you have a different makes/models of phone?

for fun: s/phone/debian laptop/g

</comment><comment><USER5> Get the sense that EFF didn't even talk to any of the parties involved before posting their review, and to me, given how much weight they carry in the community, it's unclear why they didn't.

</comment><comment><USER43> Why some people got "you are end to end encrypted with your friend" while their same friend got "the connection is not end to end encrypted with your friend"?

<comment><USER50> Because one end in this "end-to-end" is you, and the other is Facebook's government-facing data storage.

</comment></comment><comment><USER51> Is there a way to build and deploy whatsapp from source?

</comment><comment><USER28> What? How can you give it 6/7 stars if you don't even know what holes are in the code?

<comment><USER52> Perhaps by knowing that the distributed binaries will be disassembled and inspected? The same way it would have to be examined even if there was a GitHub repo out there claiming to be the code used?

<comment><USER45> You've made this claim multiple times now. Do you really honestly believe that disassembled binary code sees the same scrutiny or gained confidence that open source code does? Have you ever analyzed disassembled code?

It is non-trivial. No one is going to disassemble this and say "Yup, it passes". That doesn't happen.

<comment><USER52> As a matter of fact I am certain they will be dissassembled and examined. For the bounty, for the PR and noteriety if you can find a bug or be the one to star in the "<big company> screwed up or lied to us" story of the week. In general, for lots of reasons that seem to motivate a select crowd who have the skills to actually pull this off.

If you have the source code it makes the disassembly and examination of whatis distributed a lot easier, but it is not a necessary pre-requisite.

</comment></comment></comment></comment><comment><USER53> I hope I can get my friends to switch to actor IM [1] or some other open source solution that doesn't suck. In the end all these chat systems turn into crap full of ads even if they aren't spying on you.

[1] [https://actor.im/](https://actor.im/)

<comment><USER18> Seems centralized and doesn't rely on a standard. If I were you, I would forget this solution as well.

<comment><USER44> You can set up your own server. They want to devlop a federated protocol. So they are the only ones that actually have stated a goal to devlop something like that. OWS would probebly do it as well if they had the time and money.

They already have the best clients in the buissness, if they manage to get the crypto and the federation right, it would be fantastic. They also have some support for using their web and desktop clients with email. I wish the Actor guys the best of luck.

<comment><USER18> "They want to develop a federated protocol". There is already one, it's a IETF standard, deployed accross the globe and have already hundreds of clients and several serious servers : XMPP.

<comment><USER44> I just restated what they said, if you are so convinced that XMPP would solve all their problems, then I suggest you go to them.

I dought that they don't know already [1], and I also think they have put a lot of thought into spending their money on devloping everything again.

[1] [https://github.com/actorapp/actor- platform](https://github.com/actorapp/actor-platform)

Actor Messaging platform, modern replacement for Jabber/ejabberd</comment></comment></comment></comment></comment>


He Loved Opium, Murder and Wordsworth - <AUTHOR> http://www.nytimes.com/2016/10/30/books/review/he-loved-opium-murder-and-wordsworth.html?_r=0 <comment><USER2> Thomas De Quincey's works are on Gutenberg: [http://www.gutenberg.org/ebooks/search/?query=Thomas+De+Quin...](http://www.gutenberg.org/ebooks/search/?query=Thomas+De+Quincey)

Confessions of an English Opium Eater, which is autobiographical, is his most famous work.

</comment><comment><USER3> Finally got in through the Google referrer (provided by the web link which brings you to a Google search for the article's name), after unblocking Cloudflare and Google in order to solve a captcha where I had to identify street signs and then storefronts for Google's image identification algorithms, after which I had to whitelist NYT cookies, about 12 scripts, and a few static image domains.

Anddd that was my 5 minute break, back to work.

<comment><USER4> Why not just open in an incognito window? That always works for me.

<comment><USER3> That doesn't get me in? Maybe it's because I'm on a VPN.

The captcha's from Cloudflare not liking VPNs, and the bunch of whitelisting is just from their site being very bloated and me not wanting to load unneeded crap.

</comment></comment></comment><comment><USER5> For the lazy:

[https://www.google.com/search?q=He+Loved+Opium,+Murder+and+W...](https://www.google.com/search?q=He+Loved+Opium,+Murder+and+Wordsworth&oq=He+Loved+Opium,+Murder+and+Wordsworth)

<comment><USER3> There's also the "web" link between the post, provided by HN. It points to the same URL.

</comment></comment><comment><USER6> Usually you can find one or two people complaining that stories like this shouldn't be on HN, but I'd like to flip that one time and encourage people to keep posting them. I enjoy the sensation of clearing my palate, as I take my tech news from many proverbial firehoses, and the flavors are not always savory.

</comment><comment><USER7> Please stop linking to the NY times and their crappy paywall

</comment><comment><USER8> Blocked by paywall.

<comment><USER9> On top of that I just tried to sign up for an account. I don't want to connect Google or Facebook so I tried to use their registration. It wasn't possible to do in Chrome. I decided try the nytimes.com homepage and I could probably sign up there but the registration is over an insecure http page.

I switched to Safari and was able to create an account. Went back to Chrome and still couldn't login. Not worth it.

<comment><USER10> I opened the "web" link under the story headline in an incognito/private window and clicked the nytimes link. No account, registration, etc.</comment></comment></comment>


Usability improvements in GCC 8 - <AUTHOR> https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/ <comment><USER2> A lot of good stuff, reading C++ errors is like learning an extra language on top of the C++ language, I can't wait to try it out.

> How do I get at some private field?

That one is interesting! I wonder how smart it is.

For instance in the following example:

        class foo
        {
        public:
          std::pair<int, int> get_coordinates() const { return std::make_pair(m_x, m_y); }

        private:
          int m_x;
    	  int m_y;
        };

        void test(foo *ptr)
        {
          if (ptr->m_x >= 3)
            ;// etc
        }

I wonder if the compiler would be able to figure out that m_x is accessible via `ptr->get_coordinates().first` ?

<comment><USER3> [author of the blog post here]

Sadly, gcc 8 isn't smart enough to do that yet; I only implemented it for simple "return name_of_field;" accessors.

But it's an interesting idea, which I've filed as: [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895) \- thanks.

Are there other cases where idiomatic C++ might lead to such an indirect suggestion being appropriate for accessing the field? (std::tuple, I suppose, but I'm not sure how often that would arise in practice...)

<comment><USER2> thanks for taking time to reply!

Having some modest compilers knowledge, I'm already impressed that the first use case is possible. It's already covering many uses cases where people use simple Getters, so thanks for the work.

Yes returning std::tuples of an object state or something might be a valid use case, but as you say, I'm not sure how often this would occur!

</comment></comment></comment><comment><USER4> Ever so once in a while, I see stuff like this, remember my C++ days, and feel excited about trying to write more C++… and then I snap out of it, like remembering why you broke up with an ex-lover in the first place.

No, but seriously, this is great stuff, and I am always happy to see gcc get better. The next time I write C++, which I'll try to do for GNU Octave, I'll be very grateful for better diagnostics. I already am, since gcc keeps getting better and better.

</comment><comment><USER5> One improvement I'd like to see is a simplified error message for mismatched overloaded calls. If you make an overloaded call for which the is no matching conversion or if the conversation is ambiguous the compiler will "helpfully" dump a list of possibly matching overloaded function signatures. The list can be hundreds of lines long. For example, when you try to pipe a class to std::cout that doesn't have an std::ostream &operator<<(std::ostream &, const X &).

Perhaps instead of dumping the complete function signatures it could show one function signature followed by a list of types accepted as the second parameter. Since the signatures are otherwise the same. Such improvements could also reduce template error spew.

<comment><USER3> Thanks; I like that idea.

I've filed it as: [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920)

</comment></comment><comment><USER6> The UX of development tools is such an incredibly fundamental thing to fix.

Back in the day it was acceptable to build things without thinking how easy they were to use, indeed being "easy" was somehow a bad thing, like people who used to deride users of Mac OS.

The same applies to development tools, you aren't dumb if your tool is unhelpful, and if it takes 5 seconds less to see a problem, multiply that by how often that problem is encountered around the world, and you're making a significant difference to productivity.

Not to mention developer sanity. Why should designers have nice tools and we get tools that hate us?

</comment><comment><USER7> Fantastic work, I hope this is just the beginning.

</comment><comment><USER8> Fantastic! My thanks to David Malcolm for this work. I think this will help a lot of people.

</comment><comment><USER9> These are great investments to make! Keep up the good work!

<comment><USER3> Thanks! Any ideas for other improvements? (even if it's just fixing "paper cut"-style little annoyances)

<comment><USER10> A bit picky but I think it's useful:

You improved this:

> q.c:2:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before > 'int'

with this:

> q.c:1:6: error: expected ';' before 'int'

(etc.)

If I were asked to explain why I did not like the old error, I would say it was showing me implementation details about the parser instead of an error aimed at my human brain.

Following that logic, the most human readable error I can think of here would be that we expect a ';' _after_ `int i`. As humans we don't actually care about the next token in the sequence, even if we know the parser had to process it to arrive at the error. That would also eliminate the entire line "int j;".

Otherwise the output is visually confusing-- you have an arrow pointing one's eye to the missing semicolon, but the underlined referent token is two line breaks away from it. Underlining the preceding "i" would put the emphasized token and missing semi right next to each other.

<comment><USER3> Thanks - a few other people pointed this out, and I agree.

I've filed this one as: [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887) and hope to fix it in gcc 9.

<comment><USER10> Great!

Without knowing much about how compilers work under the hood, its difficult to gauge how ergonomic I can expect them to be while remaining deterministic. If you had told me it's actually NP hard to always select the token before the missing semicolon I would have said, "Oh, ok." :)

</comment></comment></comment></comment></comment><comment><USER11> Awesome GSoC project. Well done.

</comment><comment><USER12> Making C less of a pain, nice</comment>


How Google Killed the Longtail of Search - <AUTHOR> http://www.seobook.com/learn-seo/infographics/longtail-fail.php

<comment><USER2> This was a great summary. I don't know that going from 20-25% unique searches to 16% is "killing", though. Some of that is just going to come from the space of possible search strings getting used up.</comment>


Founders who raised seed rounds, what were your target Series A metrics? - <AUTHOR> <comment><USER2> active daily users and impressions</comment>


Sed -i - <AUTHOR> -i is a "non-standard FreeBSD extension"
I have never understood the use for it.  To save typing?
If we deny sed permission to write to any other file will it still work?
Could it be that there is an ephemeral temp file created?  ed makes them, vi makes them.  Is sed different?
What if the filesystem is a ramdisk?  Does -i make any practical difference then?  I always use a ramdisk as my filesystem.
I always found it easier to just avoid -i
This way I get portability.
The above applies only to BSD sed.
Not sure if GNU sed ever lacked the -i extension. <comment><USER2> For convenience. And script clarity. If you have a move after standard sed, half of the commands in that group are for housekeeping. Sed -i makes the line more explicit.</comment>


Parking Reform Will Save the City - <AUTHOR> https://www.citylab.com/perspective/2019/09/parking-lot-urban-planning-transit-street-traffic-congestion/598504 <comment><USER2> " _One space_ in a parking structure, therefore, costs more than the _entire net worth of more than half of all Hispanic and black households in the country._ "

If only Citylab ever bothered to fact check, they'd have caught what a ludicrous statement that is.

<comment><USER3> I suspect you're getting caught on a grammatical issue or a typo. He's _not_ referring to the net worth of all of those households _combined_. I'd re-read the sentence (perhaps just a little more charitably this time).

What do you make of the other points he makes?

<comment><USER2>
      He's not referring to the net worth of all of those households combined

That's _exactly_ what is written; it's not ambiguous. You can try to argue that he _meant_ something different.

      What do you make of the other points he makes?

It's already proven wrong.

In areas with commerce but no parking, the "parking" demand is just externalized upon others, mainly in the form of "double parking" (stopping in traffic lanes).

Those carfree San Franciscans are still using Amazon and Doordash and Ubereats and Chewy and grocers etc. like crazy, creating _more_ vehicle trips (and of _larger vehicles_ ) than if they drove and picked up their own purchases in combined trips like to/from work.

It's like Leonardo DiCaprio and Roger Waters flying their private jets across oceans to give speeches about how _everyone else_ releases too much CO2.</comment></comment></comment>


Best web dev craigslist ever - <AUTHOR> http://seattle.craigslist.org/see/cps/2104208821.html

<comment><USER2> "de-fucking" is a growth industry.

</comment><comment><USER3> "fuck" was said 36 times. Must be the best ever...</comment>


Google's QUIC protocol: moving the web from TCP to UDP - <AUTHOR> https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ <comment><USER2> If you're looking for a proven protocol that's better suited to transferring vast amounts of data across the globe, while being based on UDP, and you have been using rsync or bittorrent, here's something that's less known but offers a good speed advantage: [https://en.wikipedia.org/wiki/UDP- based_Data_Transfer_Protoc...](https://en.wikipedia.org/wiki/UDP- based_Data_Transfer_Protocol)

Please don't complain about Sourceforge, UDT is an old project: [http://udt.sourceforge.net/](http://udt.sourceforge.net/)

And here's their distributed filesystem built on top of UDT: [http://sector.sourceforge.net/](http://sector.sourceforge.net/)

Edit: Protocol-level security is being worked on for UDT5, but in the meantime there's a Rust-based experimental attempt at replacing SCP with UDT-based solution: [https://github.com/mcginty/shoop](https://github.com/mcginty/shoop)

<comment><USER3> Re: SourceForge, my understanding is that the previous owners sold SF in the past few months. The new owners have apparently taken down the malware and are working to try and restore it to its former name, despite the large incline of that hill.

[https://www.reddit.com/r/sysadmin/comments/4n3e1s/the_state_...](https://www.reddit.com/r/sysadmin/comments/4n3e1s/the_state_of_sourceforge_since_its_acquisition_in/)

<comment><USER2> Given that gforge is a fork of the original sourceforge code, it's probably possible to host a mirror to not repeat the loss of projects as happened with Google Code. There's just too much abandoned code on there, and most of it is still valuable. And even stuff not useful today is still valuable for archival purposes. Is there already a neocities like attempt at doing that?

</comment></comment></comment><comment><USER4> For the interested: A working group to standardize QUIC was accepted into the Transport and Services area of the IETF at the last meeting in Berlin a couple of weeks ago [1].

The WG charter is this one [2]:

Define a new standards track IETF transport protocol based on deployment experience with QUIC. Four focus areas:

* Core transport work: wire format, basic mechanisms

* Security: TLS 1.3 to protect QUIC header and payload

* Application semantic mapping: initial focus on HTTP/2

* Extension to multipath for migration and load sharing

[1]: [http://etherpad.tools.ietf.org:9000/p/notes- ietf-96-quic?use...](http://etherpad.tools.ietf.org:9000/p/notes- ietf-96-quic?useMonospaceFont=true&showChat=false)

[2]: [https://www.ietf.org/proceedings/96/slides/slides-96-quic-0....](https://www.ietf.org/proceedings/96/slides/slides-96-quic-0.pdf)

<comment><USER5> > * Security: TLS 1.3 to protect QUIC header and payload

That seems odd. QUIC's crypto is much nicer than any TLS version or draft last time I looked.

</comment></comment><comment><USER6> Interesting stuff and a good technical overview. I remember hearing something about this a while ago but I hadn't seen the details. I found the time spent on the need to unblock 443/udp on server firewalls amusing because that's the absolute least concern I would have about the protocol.

I know Google has the most genius geniuses working for them, but it's important to be wary of the risks of this sort of thing. Not that TLS/SSL itself has a fantastic track record, but replacing the TLS handshake with something new and shorter _and_ mixing it with a protocol that can accept incoming packets from multiple source IPs sounds like a recipe for a thousand new security vulnerabilities. If not in Google's code, then in the other implementations. Researchers, take note.

</comment><comment><USER7> The post didn't discuss The backoff behavior of QUIC. For TCP, a dropped packet results in a halving of the data rate to help with assumed congestion of the network.

Does QUIC act as a good network citizen? Are they experimenting with different approaches?

<comment><USER8> TCP congestion control is one of the main offenders in holding back high speed broadband. It can take minutes for TCP to discover the link bandwidth and a single lost packet can cut performance in half and the ramp back up to full speed may never happen.

Is congestion collapse still a risk on today's internet? Do we need such aggressive congestion control?

<comment><USER9> Congestion control is as important as ever. Your packets can traverse links of just a few Mbps then 1Gbps then back down to a few Mbps, all within your own house on the way from your computer to your ISP's network. Common consumer networking equipment will do extremely stupid things in the face of congestion, such as storing packets in a FIFO buffer more than one second long. Initial window sizes still need to be small because there will always be users at the fringes of a wireless network where speeds are low enough that a burst of a few dozen full-size packets is a major call-dropping problem.

The best solution is for AQM and ECN to be deployed widely, so that congestion can be identified and dealt with before it gets bad enough to require drastic rate decreases. QUIC currently cannot use ECN because those bits of the IP header typically aren't accessible from the APIs for UDP. Modern TCPs operating on networks that keep buffering delays low and signal congestion without dropping packets don't have trouble determining link bandwidth quickly.

</comment></comment></comment><comment><USER10> Somewhat of a meta observation - we seem to be entering an era where mantras like "Those who write their own networking protocol are doomed to re-create TCP, badly" are becoming less true, at least for a small subset of the programming population.

It's fascinating to watch some of the foundations upon which we do our work being shaken up a bit. I just hope they settle into more stable and more secure foundations, not just "better".

<comment><USER11> Virtually no one has access to a network they own end to end that is big enough to create and test a credible alternative. Google, and the tiny number of people inside it who work on this stuff, are one of probably 10 orgs in the world qualified and well placed to do it. Other contenders would be MS, US Navy, Apple..who else?

</comment></comment><comment><USER12> Is packet loss in the real world random or correlated?

TCP's head-of-line blocking problem goes away if packet loss turns out to be correlated — lose a packet belonging to one stream within the connection, and you're going to lose packets belonging to other streams as well, so QUIC doesn't help.

Is packet loss in the real world random or correlated?

<comment><USER13> With Forward Error Correction the packet loss issue is somewhat mitigated.

<comment><USER14> I think the question is: If I have a 1000 packets and I lose 10 is the packet loss spread out of is it clustered? If it's clustered you'll have to retransmit anyway.

<comment><USER13> Interleaving the FEC can also avoid bursts. The tradeoff is the more you interleave, the higher the latency on reconstruction. They could do something like using round trip time to calculate the number of packets in the air and interleave based on that.

I was working on this type of stuff 15 years ago and now might be the time to do it. Bandwidth keeps increasing but latency stays the same, so it makes sense to waste some bandwidth to improve latency.

</comment></comment></comment></comment><comment><USER15> UDP based and Encrypted from the get-go? sounds like Daniel Bernstein, ~6 years ago..

[1] [https://curvecp.org/index.html](https://curvecp.org/index.html)

[2] [https://www.youtube.com/watch?v=K8EGA834Nok](https://www.youtube.com/watch?v=K8EGA834Nok)

<comment><USER16> wow. any reason why it hasn't caught on?

</comment></comment><comment><USER17> Total networking layman here. Am I understanding correctly the author uses a bit outdated example to show how quic can be theoretically faster for the initial connection while at the same time admits TCP fast open will reduce RTT?

Also, with quic you actually receive 10% less data, but then saying a packet retransmit would take longer is not convincing to me. It should depend on how many packets are lost (on average) like 1 RTT = 20 UDP packets * 10% thus using quic/FEC on a stable network would actually _decrease_ performance and drive up data plan costs.

Also I don't see why a few packets matter that much to actually introduce a new networking stack with all of its own problems from e.g. increasing complexity. Just opened a news site on desktop, it was over 2 MB in size without the ads. If we should be concerned about percentages, we would surely be cutting down on the JS/CSS bloat first.

<comment><USER18> TCP has a few ugly problems that enhance each other. First you need to wait till all the handshaking stuff is done and then you can't even transmit with full speed.

If you use UDP, you have to implement much of the TCP stuff yourself. But you can use the experience with web connections to implement it and leave out things that weren't needed.

<comment><USER9> > [...] and then you can't even transmit with full speed.

This is nothing specific to TCP. "Full speed" is a fundamentally unknowable quantity in advance in the general case. It varies with time and endpoints. If you try to start a connection transmitting at the full speed of your first-hop link (the only one you have any chance of knowing the bandwidth of), you just put the congestion control a hop or more away from the box that has the information necessary to do it right.

QUIC can have an advantage in re-using a connection in situations where multiple sequential TCP connections might have been made. Probing for link bandwidth fewer times is not the same as not having to probe for link bandwidth. And HTTP/2 has already addressed the most common case of this without abandoning TCP.

<comment><USER18> Ah, didn't know this.

I thought this was bacause of the tsc slow start

</comment></comment></comment></comment><comment><USER19> Shouldn't this eventually be put in OSI layer 4 (on top of IP instead of on top of UDP) ?

<comment><USER20> The problem is, we've basically lost L4. Too many networks (firewalls, and especially NATs) just don't pass anything but protocols 6 (TCP) and 17 (UDP). Even ICMP is not always reliably available (leading to all sort of weird PMTU issues[1]), or heavily filtered.

I think that's why many good protocols (e.g. SCTP) are rare sights and frequently aren't even considered as an option.

[1] Yes, some idiots just block ICMP completely because they heard it's "secure" and make DHCP or PPP cap MTU at 1200 with "uh, it works just fine" attitude.

<comment><USER21> It's too late for IPv4, but maybe a strong push could get a protocol like SCTP supported on IPv6 networks?

<comment><USER20> Given that IPv6 doesn't normally use NAT (and for IPv4, it's NAT, not firewalls, is the primary source of problems why non-TCP/UDP protocols don't work in practice) it's a possibility that it would be okay.

IPv6 adoption is a problem, though. I think despite all IANA efforts to push v6, we'll be stuck with IPv4 for long years.

</comment></comment></comment></comment><comment><USER22> As I read this post, QUIC has been introduced at least partly to solve the problem of head-of-line blocking. Head-of-line blocking in turn has become a problem since the adoption of HTTP/2, formerly known as SPDY, which is the protocol Google previously foisted upon the world. So the core protocols involved in the web are now the playthings of Google, and when Google screws up the answer is yet another new and shiny protocol with unknown sideeffects.

I know this misconstrues Google's role in all of this somewhat, but it's an interpretation that crossed my mind.

<comment><USER23> And it does ring true.

</comment></comment><comment><USER24> Do mobile networks (cellular networks) these day commonly allow anything but TCP? (or even HTTP? Most firewalls block anything that is not HTTP/HTTPS)

<comment><USER25> Lots of video games (including mobile) use UDP so I'd be very surprised if mobile networks blocked UDP.

<comment><USER26> In Finland, the big operators use CGN by default. So if it works, it only works as a one-way street and p2p or hosting your game at home is no-go.

At least one operator allows you to lift the restriction though. With money.

</comment></comment></comment><comment><USER27> > The QUIC protocol implements its own crypto-layer so does not make use of > the existing TLS 1.2.

So in addition to proving lower layer solution to things like network congestion they also have to prove their crypto layer? Sounds like an equally large task, if not larger.

And even if all TCP implementors decide to adopt the next task is to make servers and clients adopt the crypto layer.

</comment><comment><USER28> How about creating QUIC protocol tuneling tool (which would be needed on both sides of connection) - for example for tuneling mysql tcp traffic between client and server in configurations where those are on diffrent networks? (pings >1ms)

</comment><comment><USER29> I think before googlers stopping add dramas to our daily drop sorry typo, job. Maybe I kindaly sort of suggest them dedup the www and provide web-wise random file access.

</comment><comment><USER16> How long until this becomes a transport over BATMAN?</comment>


Verizon to finally get iPhone - <AUTHOR> http://online.wsj.com/article/SB10001424052748704739504576068170230339348.html?mod=e2tw

<comment><USER2> This carrier exclusivity thing on the US amuses me.

In the end, consumers are the ones hurt, 'cause it limits the available choices.

Here in Brazil we have regulatory agencies that set up rules against that kind of thing. SIM locking by carriers is also illegal here. (Not actually _illegal_ , but they're _legally required_ to unlock the phones for you without additional cost)

I'm pretty sure a lot of other countries have similar rules, or am I wrong?

<comment><USER3> Hong Kong and Singapore has similar rules by their authorities. In one way you can say US prefers to practice free market. Or you can say US government does not care about their citizens. Or US government treats their corporations better than people.

</comment></comment><comment><USER4> Hopefully this time it is real - not because I am going to buy one but because the "analysts" can finally shut up and end their endless hype/crusade of Verizon iPhone.

<comment><USER5> Out of curiosity, does anyone seriously know who these "analysts" are and what their job actually entails?

<comment><USER4> I've wondered about the same. Here is the public info about one such analyst Gene Munster - [http://www.piperjaffray.com/1col.aspx?id=7&analystid=131](http://www.piperjaffray.com/1col.aspx?id=7&analystid=131) . Some choice bits - "specializing in Internet" , "holds a bachelor's degree in financial management and new venture strategies from the University of St. Thomas" "coverage includes Google, Yahoo!, Amazon, Baidu, and MercadoLibre" . Sounds like a good gig to me!

Someone should compile information about these tech analysts, their educational qualifications, their official job details (organizations they work for, job duties they perform over a typical year, their goals and objectives etc.), the data they work off of, their predictions from 2008 onwards, hit/miss ratio, stock price fluctuations attributable to their predictions and any other interesting tidbits.

May be something sinister will come out of it or may be not - but it will still be interesting to look at.

<comment><USER6> Small world. I specialize in internet, too.

</comment></comment></comment></comment><comment><USER7> Too little too late.

I just got off a call with my wife (SV to the Bay Bridge, iPhone to iPhone) and it only dropped 4 times.

I just relocated to my number to SV a couple of months ago and I only had to call 4 times to get all the features back to what they were. Plus I got over being mad about having no message at all for callers to my old number.

Also, I really don't mind calling AT&T every couple of months to find out why _that_ charge was on my freakishly high bill. I love the way all the call center people are trained to take an extra 15-30 seconds per call expressing AT&T's caring attitude. That script doesn't need to be shortened at all.

I never wonder if an unemployed poor person on a pay-as-you-go plan has lower costs and fewer customer service problems. And I got over the shock of the difference between the high margin Apple experience and the high margin AT&T experience. Really, I have.

Nope. AT&T has nothing to worry about.

<comment><USER8> AT&T's reception problems seem to be mostly concentrated in a few large cities -- most notably NY and SV/San Fransisco.

I'm a longtime AT&T customer and recent iPhone owner. I've lived in Milwaukee and Phoenix, and their reception is on par with the other carriers in those cities. NY and SV are, in my opinion, the last places you'd want poor service (because it will be discussed nationwide), but I don't think that their reception is so terrible generally nationwide.

I agree that their customer service is pretty lackluster -- then again, I've heard plenty of Verizon customer service horror stories.

(Please chime if you're in another city and have unusual reception woes, my limited experience is not necessarily representative)

<comment><USER9> North Scottsdale was spotty when I lived their two years ago. Anything near the McDowell's is likely to drop calls or have no reception at all on AT&T, while Verizon was fine. I actually had no problem with AT&T (Cingular at the time), many years before, but it seems as data phones became more popular, AT&T's network quality dropped.

I've since moved to Seattle, and AT&T is atrocious. There is hardly a day where calls don't drop and I find myself on Edge in the middle of the city far too often.

</comment></comment></comment><comment><USER10> Looks like all the "groundless" speculation was dead on. A Verizon iPhone has been predicted for a long time, and we knew that there was an exclusivity contract with ATT whose term had to be met, but the claims of vapor have gone up in a puff of smoke.

I know of several people who wanted iPhones but refused to give up Verizon's cell network for ATT. The biggest gap in cell network satisfaction--based on the word of mouth in my circles--is between those two. Now that this is happening, iPhone is sure to maintain a permanently substantial market share down the line; not as high unit sales as Android devices, but more than enough to finance continued development of what I consider to be the best value for a phone on the market, which is all I care about.

<comment><USER11> > _the claims of vapor have gone up in a puff of smoke._

Really? Sure, it's finally happened, but people have been predicting a Verizon iPhone "next week / month / quarter" for, literally, years. It was practically inevitable, seeing as Apple has no ideological qualms with multiple distributers in other countries.

<comment><USER12> If I recall correctly, Verizon was Apple's first choice for US carrier, but refused to play ball with Apple's (admittedly unprecedented) demands.

</comment></comment></comment><comment><USER13> If it doesn't actually happen on Tuesday, I will refuse to get my hopes up ever again.

<comment><USER14> There are times when I seriously get confused, did I buy an iPod Touch or an iPhone?

Calls between me and other iPhoners just end up in a sometimes hilarious tennis match of dropped calls and callbacks.

</comment></comment><comment><USER15> No LTE, the infamous metal strip will be almost complete flush with glass top & bottom, metal strip will only be segmented once, instead of 3 times, mostly resembles an iPhone 4 otherwise. Talk & data simultaneously. No Vzw bloat on board. iOS 4.3.x (just changes for cdma).

If you're considering downvoting this, wait until Tuesday to do so :)

<comment><USER16> Talk and data at the same time isn't technologically possible on cdma. How do you figure they'll pull it off?

<comment><USER17> [http://pocketnow.com/tech-news/simultaneous-voice-data- comin...](http://pocketnow.com/tech-news/simultaneous-voice-data-coming-to- cdma)

<comment><USER16> Ahhhh. I had missed that article last year. Thanks!

</comment></comment></comment></comment><comment><USER18> I am absurdly excited about this, mostly because I am in hate with my Droid.

However, the gmail and contacts integration on Droid is top notch. Am I going to be less happy on iphone?

<comment><USER19> gmail on iphone sucks - because of apple

<comment><USER20> Well, considering most of the cloud integration goodness on iPhone is only possible with Google products, I don't think you can complain too much. iPhone is just as Google-dependent for the full experience as is Android. I will say that Google needs to develop a G-Mail app on par with its Android equivalent for iOS, but using the default mail client with IMAP works just fine in reality; it is the same basic experience as any other third party client.

<comment><USER19> Apple doesn't allow 3rd party mail clients.

</comment></comment></comment></comment><comment><USER21> It will be interesting to see what this does to Verizon's Droid pricing. If Verizon adopts similar plans to AT&T with a cheap, limited, data add-on, a Verizon iPhone could be just as big a boost to Android.

</comment><comment><USER22> Device specs for the Verizon iPhone 4 can be found here:

[http://pdadb.net/index.php?m=specs&id=2548&c=verizon...](http://pdadb.net/index.php?m=specs&id=2548&c=verizon_iphone_4_apple_iphone_3,2)

EDIT: Just so I can understand what I've done wrong, would one of the down- voters please explain why the specs leaked in March/April last year are not relevant? Thanks!

<comment><USER23> Since it claims the phone will be running 4.0.2, I'd say these are a little more speculation than fact.

<comment><USER22> Heck, you always need take leaked specs with a grain of salt, if not a whole shaker of salt, a lime, and a shot of tequila. I think your down-vote was a bit reactionary.

Those leaked specs have been on the pdadb for at least 9 months even though the device was only just officially announced during CES this week. I _think_ the verizon iphone specs have been up there since shortly before (March 2010) the release of the iPhone 4 (June 2010), hence the iOS version it was claimed to be running (during the end of development/prototyping). The first "preview" of iOS 4.x was in April 2010.

Similar was true for Droid2 and Droid2-Global specs being available 9-12 months _prior_ to device releases/announcements. In both those cases, the leaked specs matched up very well with the eventually released products.

Even when a device is "finished" (hardware engineering-wise) the lead times for manufacturing ramp-up and marketing build-up can be many months.

EDIT: Added rough dates to leak and iOS releases

<http://en.wikipedia.org/wiki/IOS_version_history>

</comment></comment></comment><comment> brown9-2 I'm currently inside the 30 day window return as a brand new iPhone/AT&T customer; I wonder if any minor differences in this phone or in Verizon's service (I really haven't had any problems with AT&T so far in the NYC area, I make very few voice calls) would be impetus enough to switch.

Anyone care to speculate where the smart money might be on choosing AT&T or Verizon for service?

<comment><USER24> re: getting the Verizon iPhone:

      Reminder: date of product announcement != ship date

<comment><USER25> Ship date is likely very soon, Apple didn't tell their retail employees they couldn't take vacations this month for nothing.

</comment></comment></comment><comment><USER26> Fingers crossed that T-mobile won't be too far behind. I really love my T-mobile plan.

<comment><USER27> I assure you that your T-Mobile plan will not be available for use with a T-Mobile iPhone.

<comment><USER26> Whatever it ends up being, I'm sure it'll be a better deal than ATT/V.

<comment><USER27> Pricing game theory suggests that T-Mobile should undercut AT&T by a small margin at most.

</comment></comment></comment></comment><comment><USER28> The WSJ has had a particularly good record on Apple announcements shortly before they happen (the iPad announcement, the case program in response to antennagate), so I think we can be pretty confident about this.

</comment><comment><USER29> This is total speculation; back in Sept. I was thinking about the white iPhone 4 and how it was delayed. I can see it only being available on Verizon (for a limited time) followed by specific colors for different carries, much like KitchenAid does for their blenders.

I would be surprised if Sprint and T-Mobile didn't have the iPhone within the year (if Verizon does indeed get it soon)

<comment><USER30> I'm crossing my fingers on T-Mobile. I gave my mom a jailbroken iPhone 3G a few months ago, after she returned her third consecutive T-Mobile feature phone in as many weeks.

She's never been happier with a phone ('so easy to use,' 'doesn't make me feel like an idiot,' 'so many capabilities'), and I'd love to get her onto an up- to-date one with 3G data capabilities.

I'd just tell her to move onto AT&T but, in my experience, their network in the Twin Cities is even worse than San Francisco's.

<comment><USER31> Really? I've never once had an issue with my iPhone 4 and AT&T anywhere in the Twin Cities. I have perfect 3G coverage pretty much everywhere I go.

<comment><USER30> I've had spotty reception trouble around Minneapolis, but Uptown has always been the worst. For instance, I usually can only get a single bar of reception inside Spyhouse on 25th and Hennepin on my iPhone 4, and 2 outside if I'm lucky.

Also, I should mention that this experience was from Summer 2010. Maybe there were some issues with ATT's network in July, or maybe they've been bringing a lot more capacity online over the past few months.

<comment><USER32> T-Mobile in the Twin Cities seems to have been going down hill (brother has it). The company is cool, but their service is poor. His wife's iPhone is doing great (Woodbury / St. Paul area). Also, one or more cell companies had towers on the old 35w bridge before it fell down and I seem to remember an article talking about problems arfterwords. T-mobile used to work fine down I94, but now much west of St. cloud is dead.

// sorry about above, deleted comment because I saw this thread

</comment></comment></comment></comment></comment><comment><USER20> This is certainly going to increase some iPhone marketshare in my area where AT&T has essentially no service. I know some people already that have iPhones and an additional cheap phone from Verizon or somebody to be able to reliably communicate.

</comment><comment><USER33> is this why at&t dropped the iphone 3gs to $50 today?

[http://www.engadget.com/2011/01/06/atandt-selling- iphone-3gs...](http://www.engadget.com/2011/01/06/atandt-selling-iphone-3gs- for-50-starting-tomorrow/)

<comment><USER34> I'd say no, totally unrelated, since:

a) it wasn't today b) that phone is now dated and was only $99 before; $50 less isn't a big deal considering that the real price includes a 2-yr contract

<comment><USER35> Yes, but smart phone buyers are going to enter a contract regardless. The iPhone contract is no more expensive than competing smart phones' contracts. When carriers compete on price, they're almost always competing on the price of the device itself.

I mean, really, did anyone expect the iPhone to drop from $499 to $49 in three years?!

</comment></comment></comment><comment><USER36> And now the wait begins for iPhone to come to Sprint. I think I'm safe buying a Galaxy S next month as I doubt it'll happen within the next 2 years.

</comment><comment><USER37> Why would anyone stay with at&t after this. I see this as a perfect pair trade. Hey, use the profits to pay for phone/data bill :)

</comment><comment><USER38> It might be time to buy more Qualcomm stocks as it will be the provider for the CDMA chip.</comment>


Referring someone for a job - why does it suck and an idea how to make it work - <AUTHOR> http://piotrzaniewicz.com/referring-someone-for-a-job-why-does-it-sucks

<comment><USER2> If you don't even know someone in your social network well enough to know whether they'd be qualified for a particular job, then you probably shouldn't be referring them to your employer, since you have no way of assessing how good they are at what they do. Passing someone's resume along to your employer is an implicit endorsement of that person, and if they end up being a waste of the company's time, your own credibility will suffer. Not to mention that when you later refer a really good person, they may get ignored due your past history of recommending unqualified candidates, and you'll miss out on referral bonuses.

<comment><USER3> Thanks for meaningful insight, but I have to disagree. The concept itself is to lower the barrier of giving a reference so that employee can easily inform chosen friends whom may be interested. It is still so much better than not having resume - employer gets probably good lead. Moreover HR can ask referrer about that person and see if he have any more valuable informations</comment></comment>


Show HN: CrowdSound – Collaborative Playlists with Voting - <AUTHOR> https://itunes.apple.com/us/app/crowdsound/id1002999712

<comment><USER2> Very cool idea.

I'm fascinated by the digital-era implactions of activities like this -- listening to songs with your friends. What used to be a simple private act now possible involves questions like "does the Spotify account owner's license allow sharing in this context?" or "does sharing the music in this setting constitute a public performance?".

</comment><comment><USER3> Very cool indeed. I wonder what the business model is, if there is one?</comment>


Ask HN: What are some good examples of innovative software projects? - <AUTHOR>

I'm looking to find out examples of the most innovative software projects.
I understand that in hardware there is a lot of innovation.
But I'm trying to see what ideas exists in software world: can be a project, a language, a framework.
I'm looking to find things that brings a new perspective, a new concept, a new vision of the world, a new insight.
(Context: I will use these kind of examples in trying to inspire a generation of young software developers to generate ideas and implement them with resources they have available). <comment><USER2> My absolute favorite: [https://en.wikipedia.org/wiki/Chandler_%28software%29](https://en.wikipedia.org/wiki/Chandler_%28software%29)

Also read the book. Way more epic than Game of Thrones. ;)

<comment><AUTHOR> I read through Wikipedia and I see why this is a good software with a lot of work in it. I didn't understand yet the concepts of management proposed there and probably I will need some days to play with it. What is the innovation that you identify there?

</comment></comment><comment><USER3> [http://9front.org/](http://9front.org/) [http://golang.org/](http://golang.org/) [http://openbsd.org/](http://openbsd.org/)

<comment><AUTHOR> Yes, operating systems were also in my mind. Great examples about Plan 9 and BSD. I confess I didn't write any piece of code in Go, but read sometimes here a lot about it. So I'm curious what do you think are the most innovative things Go brings to programming languages?

<comment><USER3> Go attempts to bring the original Unix and Plan 9 innovative philosophy to the other systems, most importantly: simplicity, and doing things sanely from the start, not in a complicated fashion. You can find lots of material about Go on the internet, but one could list features like compact syntax, fast compilation, easy deploying (statically linked binaries), and easy networking and concurrency features (CSP). These are not necessarily "new" innovations but they are rarely utilized by other tools to same extent (Plan 9 being notable exception).

</comment></comment></comment><comment><USER4> [http://ortask.com/testless-case-studies-find-duplicate- tests...](http://ortask.com/testless-case-studies-find-duplicate-tests/)

</comment><comment><USER5> [http://maidsafe.net/roadmap#/roadmap](http://maidsafe.net/roadmap#/roadmap)

</comment><comment><USER6> Some research, open-source and commercial projects in Operating Systems security: [http://openxt.org/related/](http://openxt.org/related/)</comment>


The trouble with Javascript - <AUTHOR> http://www.moock.org/lectures/troublewithjs/

<comment><USER3> This seems rather un-self-aware. Yes, "class Food { etc. }" feels more intuitive to you than how it works in JS _because you learned on the classical inheritance pattern_. But classical inheritance is not _fundamentally_ easier to understand than prototypical inheritance. You've just used it for so long that you don't remember what it was like to see it as a newcomer.

If you want to be fair, this should be called "the problem with OO programming", and the summary of the problem is that it's complicated and requires that you learn a lot of counterintuitive concepts.

<comment><USER4> I've started programming in JavaScript before or at the same time I started programming in Java and still find that the author's argument is mostly valid. It's not a matter of habit, it's a matter of consequences and the amount of knowledge you need to have to make basic language features work correctly.

Prototypes are simply more complicated than classes. They change behavior of objects, whereas classes _define_ behavior of objects. The syntax doesn't help it either.

<comment><USER5> That's your opinion. My opinion is that prototypes are simpler than classes. The distinction between a class and an object can be very tricky, especially once you get dynamic or introspective because then you run into the situation where classes are also objects.

<comment><USER4> If it was simple, there would be no articles about "proper" ways to construct objects and arguments regarding whether using the "new" keyword is a a bad practice. It's absolutely ridiculous that such core language features need to be discussed and argued about so much.

<comment><USER3> They don't need to be discussed and argued about. If the irrelevant flamewars are to be the standard by which a language is judged, then the only language that will ever pass muster is the one that is never released.

</comment></comment></comment></comment></comment><comment><USER4> I would argue that the biggest issues with JavaScript are:

\- Most obvious solutions to simple problems are often wrong. (Examples: iterating over a "dictionary", getting a variadic function to work.)

\- Callbacks that create callbacks and so on (hard to understand the real structure of the program) and callbacks that are shoved into global variables (hard to debug).

\- Insane type conversion paired with poor error logging. (This has nothing to do with being dynamically typed, BTW. You can be dynamically strongly typed or at least have some safeguards.)

<comment><USER6> I'd add that it's too easy to pollute the global scope accidentally, because a simple anonymous block structure (e.g. braces) to scope variables is not allowed. Best workaround is to wrap most all code in an anonymous function that is then immediately executed (function() {<your code here}}).(), but that's ugly and easy to forget. I think Coffeescript does this _by default_ for all blocks of code, which IMO is one of the principal reasons for preferring it to original javascript.

<comment><USER7> > which IMO is one of the principal reasons for preferring it to original > javascript.

It's a nice feature, but saying it's one of the _principle_ reasons to prefer CS over JS is a stretch. Wrapping your entire file in an IIFE is a one-time development cost and a simple pattern to remember. Compare that to the syntactic sugar, safeguards, and added functionality that one will leverage constantly during development.

</comment></comment></comment><comment><USER8> As an ex-Actionscript, now-JS programmer a lot of this resonates with me.

After the move, I missed a lot of things - mostly the productivity stuff like type-safe renaming; intellisense; clickable function names. Also the presence of a real module system, and the fact that the compiler would catch my typos.

However, after comparing my two codebases (the original one in Actionscript and the new on in Javascript), I can't help but be amazed at all the damn boilerplate that's in my Actionscript. I ended up spending an enormous amount of time specifying interfaces and careful inheritance chains so that all of my type annotations would be compatible and safe. Did I need to do all that? Probably not, but the design of the language certainly encouraged me to do so. I can't help but wonder what I could have done with that time - <USER2> considering the fact that my JS codebase doesn't seem to have more bugs or worse stability.

Would I switch back if I could? I'm not sure.

I can't help but think that there's a real opportunity for a Coffeescript-like language with a module system, clean class syntax, and some Go-like features such as Go interfaces and type inference, plus manual type annotations when necessary.

<comment><USER9> "I can't help but think that there's a real opportunity for a Coffeescript- like language with a module system, clean class syntax, and some Go-like features such as Go interfaces and type inference, plus manual type annotations when necessary."

haxe meets a lot of these criteria and has been around for a while.

<comment><USER10> seconding this.

Also, a new version of the haxe compiler was just released that is geared towards supporting new js features and cleaner integration: <http://haxe.org/download>

</comment></comment></comment><comment><USER11> Usually rants on Javascript pound on the warts it acquired due to being rushed to production back in 1995. Warts like semicolon insertion, the lack of a module system, etc.

Instead of that, we get boring syntax arguments that seem to have come from yet another static vs dynamic programming language flame war, written by some someone that thinks the Java OO model is the only acceptable OO model. More then half that list also apply to Python or Ruby and that is just silly.

<comment><USER12> I wouldn't exactly say that the list is wrong, just because half of it also applies to Python or Ruby. All languages have some kind of issues, so I guess it's an okayish list of Javascript specific gotchas.

</comment></comment><comment><USER13> Random contextual side note:

Colin Moock has been contributing to the webdev world since the late 90s (<http://www.moock.org/webdesign/>) mostly focused on Actionscript. Back when people thought web development was a joke (and not flash), he did a ton of work teaching and writing about what he had learned and I probably wouldn't know what I know about web dev without folks like him.

That being said, I think the lecture was poorly titled given his conclusions...

<comment><USER14> I thought the same thing since I've followed Colin since starting Flash development. It turns out the title of this post is incomplete, on his lectures page it is actually "the trouble with javascript (and why it's worth it)" <http://www.moock.org/lectures/>

</comment></comment><comment><USER15> Here's why a "class" definition is a "function" in JavaScript:

Since JavaScript is prototypal and not class-based, the "new" operator simply creates a tabla rasa object. The argument to new is a function that runs on the new object with "this" in the scope set to the object.

Thus "new foo()" creates an blank object and runs foo on it. You can do this with any function!

If you don't try to force C++/Java semantics onto JS, it's much easier to understand.

</comment><comment><USER16> I find it a little worrying that "Must run every line of code to find all the errors" made the list. More worrying was the fact that the author thought having compiler-enforced type safety would relax that requirement. Giving the benefit of the doubt, maybe by find all errors, he meant "find all type errors except for anytime anyone does something dynamic or a cast".

I would hope we all recognize by now that even running all lines of code (100% test coverage) is insufficient to find all errors (especially semantic ones). In any language.

</comment><comment><USER17> "The trouble with JavaScript is that when I try to pretend it uses classical inheritance, nothing works the way I think it should."

</comment><comment><USER14> The title is incomplete, on his lectures page it is titled "the trouble with javascript (and why it's worth it)"

<http://www.moock.org/lectures/>

</comment><comment><USER18> Are there really no JavaScript-capable IDEs out there that support code completion, jump to definition, re-factoring, etc? I don't see anything in the language that would preclude such features.

<comment><USER19> Yes there is, and it works quite well: [http://www.jetbrains.com/editors/javascript_editor.jsp?ide=i...](http://www.jetbrains.com/editors/javascript_editor.jsp?ide=idea)

For sure it has some oddities with the completion as it can't be sure what the prototypes are, but then it just lists functions from different prototypes which match your prefix.

<comment><USER18> Thanks. Those specific complaints from the link seemed more like quality of implementation issues of typical ECMAScript editors vs Adobe's ActionScript IDE. I can live without type inference in a dynamic language, but Visual Studio and Qt Creator have spoiled me on the other features.

</comment></comment></comment><comment><USER20> "Would _YOU_ Let JavaScript Land Your Plane?"

No I wouldn't, but I'd let it run my web app. Dude it's javascript, it runs in a browser! What other language runs in all the four major browsers? None.

<comment><USER3> I actually would definitely let JavaScript land my plane, assuming it had undergone substantial code review, had exceptional test coverage, and was interfacing with a reliable and sane API (I would definitely _not_ let the DOM land my plane). In other words, under the same conditions as I would want for any other language.

</comment></comment><comment><USER21> _This just in: Javascript does not follow the One Way to do things. Developer outraged!_

</comment><comment><USER22> The trouble with JavaScript is the name is misleading - you're lead to believe it's a scripting form of Java. Instead it's more akin to Lisp in C clothing. Doug Crockford explains it best. <http://www.crockford.com/javascript/javascript.html>

</comment><comment><USER23> If all you want is classical inheritance, there are so many libraries that are available which mimic that.

<comment><USER3> I would say "or just use CoffeeScript", but you really should understand JavaScript better than that before using CoffeeScript.

<comment><USER24> Not should, _have to_. You can make the same types of mistakes in CoffeeScript that you can make in JavaScript. Try compiling this:

      class Animal
        constructor: -> @type = 'Zebra'

        feet: []

</comment></comment></comment><comment><USER25> Most of the author's 'trouble' would be solved by reading "Javascript: The Good Parts"

<comment><USER26> I came here to post exactly this. I don't know what's happening, maybe it has always happened, but these days I get more easily pissed when someone's trouble could be solved just by reading a book... People: blog posts are nice and all, but for god sake, just read a book. Especially when there is a good, almost universally agreed upon, such book.

I think it's unbelievable that people want to learn about a subject but can't be bothered to read a book about it. This leads to flawed learning at the foundational level, and then avoidable surprises when years (yes, years...) down the road people discover some "unexpected" behavior they should have learned about at the very beginning of the learning journey.

In ye good olden days, when people came to a forum with a stupid question that could be easily solved if the person asking would just bother to read the manual, they used to get a polite RTFM...

Maybe we should start saying RAFB when stuff like that is posted.

</comment></comment><comment><USER27> Let me guess.. you are a java senior developer, aren't you? You should learn python, or ruby. They will open your mind to a whole new level of abstraction.

<comment><USER28> Please. Python is my favourite language, and has hardly any of the silliness of js. In python classes are still classes, methods are still methods, constructors do look like methods but are clearly a special method. Calling something from the superclass looks slightly odd, but only slightly. People know better than to monkey with object internals unless they have a good reason, in a way that doesn't seem to happen in javascript - I suspect because many perfectly sensible things in javascript look like monkeying around with object internals (foo.prototype.x = ...). Python is dynamically typed, but it gets away with it because its types are strict; if you think a is an int but it's actually a string, you'll catch it when you try and do a + 5. And even given that, python has added (weak, optional, but still there and standardized) type annotations. Code completion works, I don't know how but it does (maybe this could be done with javascript too). Modules are standard and heavily used. The language has a standard and multiple compatible implementations.

Thought: if "prototypal inheritance" really is more powerful/useful/etc., why don't we see efforts to implement it in languages with traditional classes? I've seen dozens of attempts at implementing "traditional" inheritance in javascript, but none goingin the other direction.

<comment><USER29> Well, the reason you don't really see efforts to implement prototypal inheritance in classical languages is because it would be much more difficult than the converse. Prototypal inheritance is both simpler and more flexible than classical inheritance, so building the latter on the former is much easier.

Another thing: there is nothing fundamentally wrong with coercing types. The only time you have an issue with this is when you combine overloading with coercion. Particularly, JavaScript overloads + and uses it to coerce values, which is just broken. Either overloading on types or coercing types by itself is fine and neither is clearly superior; the problems stem from having _both_.

JavaScript also has a standard and multiple compatible implementations; all the cross-browser issues I know of have to do with the DOM rather than the language itself. On top of this, some of the JavaScript implementations are _really_ fast for a dynamic scripting language.

Also, let's not get into Python's many problems and weird semantics. It may not have the "silliness" of JavaScript, but it has plenty of silliness of its own. I say this as somebody who's been forced to use it both at work and in my courses: it's just as confusing as JavaScript was, just in different places.

</comment></comment></comment><comment><USER30> Don't get me wrong, JavaScript is horrible. But an argument whose major point is JS' OO is a joke is kind of weak. You would be better off thinking of it as a C-syntaxed functional programming language with mutable data structures.

Not that it's a more accurate description, but trying to use it as such will make you more productive and make you write better code.

</comment><comment> tyler-dodge Did he just complain that there are no compiler errors in a interpreted language?

<comment><USER31> He basically said 'it's a prototype-based language, therefore it is bad.'

...

</comment></comment><comment><USER32> [http://www.moock.org/lectures/troublewithjs/actionscript- cod...](http://www.moock.org/lectures/troublewithjs/actionscript- codehints-1.jpg)

Off topic, but what font is that?

</comment><comment><USER33> so? Javascript is never, ever going away.

It'd be real nice if ECMA made some changes to fix the ugly, but how long would that take to propogate? A decade?

</comment><comment><USER34> ... and your point is?</comment>