Apache Wave - <AUTHOR> http://incubator.apache.org/wave/about.html <comment><USER2> The crucial tactical error the Wave project made was not integrating with existing systems like email and chat. This forced people to either jump fully onboard with Wave or ignore it. Predictably, when faced with an ultimatum like that, everyone just kept using email (and IRC and wikis). If the Wave team had instead spent a fraction of their development efforts on seamless integration with email, IRC, and other relevant protocols, even at the cost of some simplification of Wave itself, the project might very well have been a success and more advanced features could have been added later once adoption picked up.

<comment><USER3> I think the invite only beta hurt it more. I got in from a random redditor, but no one else I knew was in it, so I played with it for 5 minutes and then forgot about it.

<comment><USER4> Spot on. When GMail was still in Beta, and you didn't know anybody else on it, at least you could still send and receive email with the rest of the world.

<comment><USER5> also gmail gave you 5 or more invites so you could invite your friends. Wave should have done the same. It would have allowed small social networks of people to play with it together.

<comment><USER6> As I recall, I had several invites when I got in. The problem was that those invites went into a queue, they were a lie. With gmail (at least when I got to it), my invites were sent out immediately and the recipient could start using gmail _that day_. With Wave, my invites were queued and when Google felt it was time they'd send it out. This could be days or, in at least one case for me, weeks later. By the time I got enough people in to give it a shot, only myself and the most recent were interested in trying it.

<comment><USER7> Well, even though many if not most of my friends ended up with an invite (and we made active use of Wave), that didn't make it a success: the client was just too slow and laggy. It basically only worked in chrome, and poorly there. Large threads were simply unusable.

I don't think the closed beta-ness of wave really hurt it. If wave had actually worked _well_ , then maybe there'd have been a point where it was worth opening up to many users - but wave never got there, so it's a moot point.

</comment></comment></comment></comment></comment></comment><comment><USER8> The current Apache Wave code base is a vast complex tangle (GWT wasn't the right decision, I doubt web sockets was either), and there's virtually no life on the developer list.

To be in any way seriously useful, this should be reimplemented as from scratch with a strict separation of UI and wave server back end, with a _massively_ simplified deployment process. (Go would be a good choice imho).

The ideas behind wave are interesting, but the technical debt that Google dumped out when they abandoned wave is so massive, I consider the current wave code base a completely lost cause.

Seriously; interested developers drop into the mailing list form time to time; look at the code base, then run screaming. The reports barely even get done.

<comment><USER9> I agree with this. I wanted to add OT to one of my projects and checked it out. Couldn't get the head or tail of the code. So opted for ShareJS instead.

</comment></comment><comment><USER10> In terms of a modern day 'Wave' I don't understand why I had to find out about Slack [https://slack.com/](https://slack.com/) from a Quartz article: [http://qz.com/192948/slack-the-best-way-to-organize-your- bus...](http://qz.com/192948/slack-the-best-way-to-organize-your-business- communications-is-not-to-organize-them-at-all/)

<comment><USER11> Is Slack comparable to HipChat? Seems like it has more robust document sharing.

<comment><USER12> Slack is a better HipChat. msg formatting, code snippets, google hangout support, etc.

</comment></comment></comment><comment><USER13> Any particular reason why this was posted today? It seems to have been incubating at Apache since 2010. Is there a roadmap?

[http://incubator.apache.org/projects/wave.html](http://incubator.apache.org/projects/wave.html)

<comment><USER14> You are correct that we have been incubating since 2010 - the community around it has changed quite a lot since then though...

There is no roadmap, as we do not (yet) have a large enough consistent amount of developer power to benefit from one. Most of the patches we receive are fixes/improvements that benefit the submitter (e.g. full text search, monogodb backend, etc.)

<comment><USER13> Spelling out where you'd like to take the project will help attract developers. Without some sort of direction the project looks aimless.

<comment><USER14> I agree, prior discussions on the mailing list have been unable to resolve this though. There are two directions in which to progress: 1) Convert the project to be primarily about the federation protocol (which was the original direction of FedOne), with the existing client being a 'demonstration' implementation of the protocol. This sets our market to be other developers. 2) Be client specific, extend the existing client, add mobile support etc. Setting our market to be users directly. 'The next communications platform'.

(2) is what we have been mostly doing for the last couple of years, but our Java6+GWT+Ant+Subversion (only recently switched to git) stack was failing to attract new developers. There were several calls to rewrite the entire thing in (say) javascript.

<comment> rkuykendall-com Rewriting the client sounds like an awful task, but it might be necessary. I think I liked wave, but really have no interest in trying to get that online. If it was a stack I knew ( Rails ) or a stack I knew would be nice to use ( Flask, Node ) I might be interested in getting a copy online and maybe contributing.

Just for curiosity's sake, let's say I wanted to write a REALLY bare-bones Wave client. Like, maybe just doing text-only waves, maybe not even real time. How hard would that be?

<comment><USER15> There is a console client for Wave: [http://www.waveprotocol.org/code/console- client](http://www.waveprotocol.org/code/console-client)

<comment><USER16> I think thats not supported anymore, remember seeing something about it being legacy code flagged for removal (if it hasnt already been)

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Back in 2009/10, we ran our startup primarily on Wave for several months. Several of us found it very useful; I thought it was a promising combination of email, Google Docs, and chat. On the other hand, the usability was horrible and it was ridiculously buggy; several people hated it with a passion.

I can see why Google gave up on it but it's disappointing that they haven't incorporated these ideas into other products. And it doesn't seem like Apache Wave ever gained enough momentum to move forward.

What other projects are looking at similar chat/email/collaborative editing hybrids?

<comment><USER18> I think Google did incorporate a lot of this functionality into Docs - multiple users editing the same doc at once is pretty close to the functionality I wanted from Wave, and I've used it multiple times to great effect.

<comment><USER17> Agreed that the collaborative editing from Docs is great, but I believe Docs already had that functionality before Wave.

The kinds of things I was thinking of is that there aren't any "subsections" in docs (comparable to Wave's replies); and Docs still isn't a "container" in the way that Wave was -- you can't embed a poll, for example.

</comment></comment></comment><comment> vertex-four My opinion of where Wave went wrong is that it was completely non-extensible past a couple of fairly limited extension points. You couldn't build brand new real-time applications on top of Wave.

What they should've done was simply expose their real-time technology stack, then let people create documents backed by whatever (sandboxed) Javascript they want. When you open a wave, the Wave client would download the relevant Javascript, then use _that_ to generate the user interface for the document, while managing the complexities of operational transforms and federation itself.

<comment><USER19> I thought the server was open source running a documented protocol? I never got to close to it other than playing with the client. I recall considering installing the server - May be misremembering though....

<comment><USER6> There were two protocols. One used internally by the Google Wave server, and a federation protocol based on XMPP.

Extending waves could be done with gadgets and bots. Bots were essentially XMPP clients that could observe the wave and submit changes to it [1]. Gadgets had other utilities, like introducing features to a wave document. I can't remember any particularly interesting ones, but some simple ones would be dice rollers and polls.

[1] I played with a clojure REPL bot at one point, neat concept and I liked the idea for a collaborative way to teach someone how to program or pair program. I toyed for a time with exposing a common lisp REPL (I didn't get far) to create a collaborative worksheet-style interface. Since the underlying technology was language agnostic I thought it would have been neat as a way to integrate a number of different interactive languages.

</comment></comment></comment><comment><USER20> I used Wave quite a lot, it was great to arranging meet ups of groups of people as you could all have an active conversation and use the "Poll" widget to say if you where coming or not.

I also used it for other things, but organising groups of people was the main use. Once it was discontinued I tried to run the open source version, but it was never really that stable and in the end we swapped back to emails.

It's a great shame to see this dead

<comment><USER21> Yes, it was really great for organizing groups of people. My campus ACM chapter used it instead of email when we were setting up a new computer lab, and it was one of the best experiences I've had with a piece of collaboration software.

It's main problem for us was that large waves tended to get slow on our 2007-era entry level laptops, and nobody really wanted to maintain the wave by deleting unimportant chit-chat. Some sort of decay mechanism to hide old, irrelevant blips would have been nice.

</comment></comment><comment><USER22> I used Wave on a number of projects as well as some of the biggerish discussion "waves" back when it was still with Google.

For the projects, it was _awesome_. This was a long time ago, so I don't remember all the excruciating details, but it made coordination and collaboration on big documents pretty trivial. We also had some group messaging and file-storage accounts that went virtually unused because of Wave.

Our use-case was in writing large-ish documents (a few hundred pages each) as a committee. And it was pretty trivial to just create a wave for each section of each document, then use top level comments in the Wave for each subsection, and capture everybody's brainstorming for each section. It was like a living collaborative outline that eventually filled itself in and turned into a section. We used links off of the discussions into Google docs for collaborative editing of the documents and when we felt everything was good, somebody would simply go in and copy-paste all the text into master good doc for final cleanup.

Having worked on similar projects in the past, coordinating this kind of activity with email and word docs (or even google docs) is a huge PIA. When we decided to move it to Wave for a small trial (to figure out the workflow) it was pretty trivial and sort of worked naturally. There was a minimum of document syncing issues, or confusion about who said what in which meeting or email. The entire past history of discussion, with threading and everything was open for review. It was _amazing_ despite many of the obvious issues with the Wave client.

The big discussion "groups" on the other hand were mess. It was impossible to find where new comments in old threads were posted, and once the conversations got big enough, the UI slowed to an unusable mess. Wave didn't last long enough for anybody to figure out how to deal with this.

Outside of those two use-cases I really didn't use Wave for much else. I suspect I would have found other uses as time went on if it had survived (and especially if it had flowered and federated).

I've thought long and hard about why Wave failed and it really does come down to 2 things:

\- lack of focus

\- poor user experience that never seemed to get any better

Wave tried really hard to be all things to everybody, with some really neat tech demos to show use cases (arranging a group meeting by embedding a poll and a map etc.). I think it was kind of like the C++ of communication mediums. It's sort of everything, but you can only realistically use some subset of the functionality in practice and the parts you don't use just end up seeming useless and weird.

On the user side, carving out just the functionality for your use-case was also hard. And the slow as syrup client really was a huge turn-off. Weird, non-standard scroll bars everywhere (which never got fixed and never worked like anybody expected), nobody liked real-time global echo as they typed (brought about by a confusion of how IM actually worked in practice), and way too many half-baked widgets and bots and things.

I think Wave should have simply focused on a few simple use-cases, nailed and refined those, then grown all the other awesome ideas organically so the user- community could start to slot those into their workflows.

Wave might have worked better if it was launched simply as a threaded messageboard with real-time replies showing up in a post. Users would have also needed 1 more layer of organizational abstraction, a "Wave container" to carve out different groups of Waves. In my use-case above we really needed to have a container for each document, with each Wave for each major section. But in the most general case, a "pg" type person could have created a "Hacker News" container, and each submission and comment history would have been the individual Waves.

When Wave launched, everything was a wave and there was no way to organize them, so people ended up using top-level comments in the waves as the "topic submissions" and the Waves went on for thousands of comments across dozens of topics before they started to break. It just wasn't a good organizational metaphor, but the system and the client didn't offer a good alternative.

Then the client was clunky and slow, nothing else on the web felt as slow even with such little graphical sparkle. It was basically a side-by-side email client by look, yet acted like it was folding proteins or mining bitcoin in some worker thread.

<comment><USER23> > The big discussion "groups" on the other hand were mess. It was impossible > to find where new comments in old threads were posted

Funny, this is the exact same problem I see with google+.

We're using hangouts to do some cross-continent roleplaying sessions, and g+ is a natural fit for having a discussion group/notes -- unfortunately it has horrible mail notifications (you get a notification, but not the _content_ of new comments) -- and is pretty buggy (with posts randomly disappearing when you're accessing g+ across devices).

Having a few parallels discussions is almost hopeless -- and this is just within one "community". I couldn't imagine using it for anything involving more than a handful of people.

<comment><USER24> For dedicated roleplaying, I really like Roll20. It's specifically designed for that, and I've used it for several different groups, both from the DM side and the player side.

<comment><USER23> Roll20 looks interesting, not sure how well it would work for our mix of "play-by-mail" and video sessions.

I'll have a look (and at Trello too) -- but I lean towards something I can self-host if I am to make the effort of dragging the rest of the group away from g+/hangouts in the first place.

<comment><USER25> Maybe the open source remote learning tool [http://bigbluebutton.org](http://bigbluebutton.org) would be helpful

</comment></comment></comment></comment></comment><comment><USER26> I created one of widgets that launched with Wave to use VOIP services to make a conference call from inside the gadget.

Part of me wished it stayed because I had a single letter user id.

Anyways, meeting minutes were something that it did well in my observation. Liveblogging was also interesting with it especially if you had maybe 2-3 editors and everyone else was view-only. Live tweeting events is rather feeble compared to what could have been done with Wave.

<comment><USER27> Who knows, maybe you would have ended up like @n ;)

</comment></comment><comment><USER28> I wish every day for this to finally become usable and deployable. A bit of GitHub integration and I have tons of places I'd get Wave going again.

<comment><USER29> Check out co-meeting, kune, Novell Vibe, and Rizzoma. There are lots of alternatives that are very useful.

<comment><USER16> none of which federate with eachother :(

<comment><USER29> you use 'federate' as if it's a killer feature, but how many products out in the marketplace that you use actually do that?

</comment></comment></comment></comment><comment><USER30> I don't understand this submission. There's no news here, it's an "about" page from 2010. What am I missing?

</comment><comment><USER31> I remember when Google Wave was hyped up to the point where people were begging others for a beta invite. When I first got access, it seemed pretty interesting but oddly enough, nothing really motivated me to use it again.

<comment><USER32> That whole "begging for an invite" thing was, in my world, the reason we couldn't use Wave. When you have a project with 10 people, and 3 of them can't get on Wave... it's game over. Back to email/IM/whatever.

I never understood why, beta or not, anyone would release a collaboration tool without the ability to invite collaborators.

<comment><USER33> They did fix that fairly soon by giving each person around 10 invites, but I guess you had given up at that point.

<comment><USER6> I mentioned this elsewhere, but invites were queued. You had 10 invites and you could send them all out the first day you got into Wave. But it might have been days or weeks later before their received their invitation. Mine came 2 weeks after a friend invited me. My sister's arrived a week or so after I invited her. This killed the momentum, it took too long to build up the social network which this system depended upon.

</comment></comment></comment></comment><comment><USER34> > Allthough Googles own server was never released as Open Source itself, they > did release "FedOne" as a reference implementation of it. It was open > source, and allowed people to both run and federate their own wave servers > together. It did not connect to Googles main "wave.google.com" server, but > did connect to a special "sandbox" server allowing testing of the protocol, > server and clients.

What idiot greenlighted that feature? :P

"Yeah let's make a distributed social network but don't let them connect to the one EVERYONE IS ALREADY ON"

</comment><comment><USER35> I remember back in the day people would kill for a Google Wave invite. It felt like all the cool kids were using it and if you weren't on it, you meant zero. When you actually got on it after reading all the praising reviews and begging for invites on googlewaveinvites.org or whatever shady site you stumbled upon, it was a massive anti climax. Sure, it looked really good but it felt so... I don't know... void?

I think we all just wanted to be part of the "Google Wave croud" and the hype was more of a focus than the actual product. Thinking about it, I don't even remember what Wave _actually_ was or why Google dismissed it.

</comment><comment><USER36> > Wave a real-time communication and collaboration tool.

Serious question: Am I a bad person for closing the tab as soon as I noticed that the first sentence is missing a verb?

Programming is all about details, and I guess I see it as a strong signal if a project can't get details right on their landing page.

On the other hand, maybe this unfairly biases me against projects maintained by non-native English speakers. And even among native speakers, perhaps I shouldn't be biased against people who choose to spend their time on pursuits other than writing perfect English.

<comment><USER37> You're not a bad person. Actually, I like that you question your decision, though that's probably confirmation bias because I use the exact opposite of your heuristic.

As I view it, any project has finite resources. You can spend them on your presentation or you can spend them on the product. Every hour that you're spending fixing typos on the website is an hour that you're not patching bugs in the code. Thus, when I encounter a beautiful, well written, well designed site, I mentally note that they've taken a lot of resources away from the product and caution myself accordingly.

Obviously my heuristic has a significant flaw - it assume that all projects have equal resources. A project with less resources can have lousy presentation and lousy code while a project with abundant resources can be exemplary in both categories. That's why I don't use it as my ONLY method of advising decisions.

However, your method also has a fatal flaw. Imagine that you're right and that the source base is an incoherent mess. It's pretty cheap to hire a couple of grad students to clean up the text on the page. They haven't done a damn thing to fix the mess in the code, but your heuristic now gives them an all clear.

<comment><USER36> > Obviously my heuristic has a significant flaw - it assume that > all > projects have equal resources.

Indeed. Perhaps my heuristic works for open-source projects because, if a project is "important" enough, some nutcase like me will come along and either complain about or fix their webpage. If the first sentence of their webpage has an obvious typo, that's a signal that maybe there aren't enough people who care about the project.

<comment><USER38> Have you also complained on their issue tracker?

</comment></comment></comment></comment><comment><USER39> Strangely, every one of the links in the downloads page has 404'd for me. I was quite disappointed to see Wave die, since I think it was both incredibly forward looking on Google's part and, all things considered, immensely useful. I wish it could have become the email replacement it wanted to be. It suffered greatly, though, from higher latency, intermittent bugs, and lack of (very) widespread adoption.

<comment><USER40> Disclaimer: I work for Google, though did not at the announcement, nor cancellation, and my views are my own, etc. etc.

I managed to get into the beta, and was so excited about the prospect. I think one of the most serious problems at the time was scaling... A conversation with more than about 5 participants was just plain unusable due to how slow it was to update and display.

It has been five years, however, and computers have gotten _much_ faster. I tried the test server, and while it has some display issues (flashing boxes during updates, etc.), it is _very_ fast, and quite comfortable to use.

I think the only problem at this point is a social one... I can really only imagine two scenarios where this takes off. 1) The non-federation case gets incredibly compelling (e.g. if for internal company collaborated editing) and eventually there's so much use, people start setting up federation. 2) Niche (meaning targeted, not meaning inconsequential) federated use becomes common (e.g. if open source communities were to switch to this en masse in place of listserv), and people get so accustomed to using it that outside organizations start picking it up.

I'd love to see that happen, but at this point, I'm not holding my breath.

<comment><USER41> I would not be surprised to find out that many open source communities would love to switch to a better list software than Mailman. It would need to work well for the main list use case of course - so that switching would cost nothing and people could connect to the waves in their own time.

</comment></comment></comment><comment><USER42> I liked Google Wave, and really liked being able to write software robots on AppEngine that joined waves like humans, and could read and write to waves. Potentially a nice platform to develop for, until Google Wave was cancelled.

I have run Apache Waves a few times, easy to set up and the simplified UI is very nice.

What I am missing from Apache Wave is a platform for writing software robots. Does anyone know of any useful options for this?

</comment><comment><USER43> I always wondered why Wave was not intergrested with Usenet as could of brought usenet into the modern World interface/interaction wise. Beyond that it reminded me of many Web 2.0 Nortel project, great technicaly but pushing the resource boundaries of the time. Hence had its sluggish moments, as in on a fat pipe was great, but consumer pipes was meh.

Still, it moves on.

<comment><USER6> Google has Google Groups which interfaces with usenet. Also, the nature of "waves" doesn't fit with threaded communication model of usenet. It can be made to work, but you'd need many waves/wavelets to accomplish that, and going back and editing previous stuffs would create a confusing set of messages on Usenet. Would you post those to usenet? Post it by replying with a diff? It'd require a very different model. Far easier to integrate standard web forums with usenet (which I, personally, think would be awesome) than what Wave had. It was really designed around a collaborative document model. Would've been awesome if the invite system hadn't been so clunky, and the year delay between announcement and when my friends finally got access just killed any momentum at the time (for me).

<comment><USER23> > Google has Google Groups which interfaces with usenet.

Yeah, for a typical Google idea of interfacing -- you can't get Google groups as usenet, but you can get usenet as Google groups (the web front-end).

<comment><USER6> True. I guess my point was:

1) They have an interface to usenet so an interface via Wave wasn't (strictly speaking) necessary.

2) Such an interface could have been added later via gadgets and bots, rather than one singular hardcoded method.

</comment></comment></comment></comment><comment><USER44> At Mindcamp in 2009 we had a session to try to figure out how/why to use Wave. We tried to use Wave to facilitate said conversation. In my opinion, it was a wash.

Wave had amazing technology and perhaps a "before it's time" communication model, but it needed a better narrative or training step.

</comment><comment><USER45> Wouldn't you prefer this for a forum instead of phpBB?

<comment><USER46> Not sure it really solves forum's problems.

Have you seen/tried Discourse[1]? They _do_ try to solve them.

[1]: [http://www.discourse.org](http://www.discourse.org)

<comment><USER45> thanks</comment></comment></comment>


Celebrating 10 Years of Firefox - <AUTHOR> https://blog.mozilla.org/blog/2014/11/10/celebrating-10-years-of-firefox-2/ <comment><USER2> My love for Chrome ended and I switched back to Firefox about 3 months ago. The switch went well and I'm happy with my choice. Reasons:

1\. First version of Chrome for the desktop supported extensions, because it was competing with a popular Firefox, and now on Android they don't give a shit about enabling users to customize the behavior of their browser, which pisses me off.

So I switched to Firefox on my Android because it allows me to use these plugins ... AdBlock Plus, HTTPS Everywhere + LastPass. Plus it has a handy Reader Mode, that's like Readability built into my Firefox. And I find the UI nicer on my 7-inch tablet. This naturally led to a decision to switch to Firefox on the desktop too, because Sync.

2\. In Firefox on my desktop I like having Tab Groups + the Awesome Bar (which does a good job of doing full text searches in my history, much better than what other browsers are capable of) + a really cool tweak to the Australis theme called "The Fox, Only Better" which is awesome and will make it much harder for me to switch browsers again.

I also love it when Mozilla develops something, then everybody benefits, like Asm.js or PDF.js. Try using Chromium instead of Chrome, it's not the same experience.

3\. I've been all hooked into Google's stuff, I even pay for a Google Apps account and everything, but I noticed that Google hasn't been aligned with my interests.

For example they killed Google Reader to promote Google+, they showed no interest in fixing Gmail's broken IMAP support, they showed no interest in fixing Google Calendar's broken CalDAV support, they discontinued the Exchange support from Gmail, they discontinued the XMPP support from Google Hangouts, they announced no interest in providing alternatives that I know of, certain features in their online products only work in Chrome. It seems to me that Google is only interested in standards as long as they are the underdog.

I also moved to Dropbox as my cloud storage, because Google Drive still does not have a Linux client. I mean, Google out of all companies should think that Linux support also means headless servers (like home servers or other appliances), so providing Linux support should be obvious. But no, 2 years later, the OS X client is still shitty and still no Linux support. I have to trust my data to a third-party if I want that, or suffer one of the shitty open-source alternatives and risk my data.

So there you have it - Firefox is a great browser and it also tries to make me happy. And yes, I would also like the one-process per tab model, but they are actively working on it.

Happy Birthday Firefox.

<comment><USER3> Your memory of desktop Chrome doesn't match mine. Chrome added extensions more than a year after launch. [http://chrome.blogspot.com/2009/12/google-chrome- for-holiday...](http://chrome.blogspot.com/2009/12/google-chrome-for-holidays- mac-linux.html?m=1)

Its extension model remains superior to Firefox's, and I hope Mozilla fixes this. I shouldn't need Python and an SDK installed to develop a JavaScript browser extension. [https://developer.mozilla.org/en-US/Add- ons/SDK/Tutorials/In...](https://developer.mozilla.org/en-US/Add- ons/SDK/Tutorials/Installation)

<comment><USER4> > I shouldn't need Python and an SDK installed to develop a JavaScript browser > extension.

You don't. The only things you need are a text editor and a zip utility (and I'm not sure about the last; it's certainly not needed if you're not distributing the extension). You only need the SDK if you want to use the Add- on SDK.

<comment><USER3> Then it's a problem with the documentation ([https://blog.mozilla.org/addons/2014/06/05/how-to-develop- fi...](https://blog.mozilla.org/addons/2014/06/05/how-to-develop-firefox- extension/)), which is a little easier to fix.

</comment></comment></comment></comment><comment><USER5> It seems the standards-based browser du jour is moving back in Mozilla's favor lately. I can say, for the first time in ages, that FF is very fast, very stable and very secure. Chrome, on the other hand, has been less stable, less fast and less secure.

<comment><USER3> I have the same feeling on everything except security, but electrolysis should help with that. [http://m.slashdot.org/story/199459](http://m.slashdot.org/story/199459)

<comment><USER2> Firefox needs a better security model for add-ons. The thing that bothers me in Firefox is the Private Mode (Incognito in Chrome), as it doesn't disable add-ons. And I use private mode quite often.

Mozilla has been relying on a more strict review process for whatever gets published on addons.mozilla.org (when compared to Google), with Firefox users experiencing less instances of add-ons turning to mallware/spyware, but I'd like both this review process and a better security model for these add-ons.

<comment><USER6> You could set up a separate profile for that¹. You can also use the Profilist² extension in your main profile for easy switching and creation.

1: [https://support.mozilla.org/kb/profile-manager-create-and- re...](https://support.mozilla.org/kb/profile-manager-create-and-remove- firefox-profiles)

2: [https://addons.mozilla.org/firefox/addon/profilist/](https://addons.mozilla.org/firefox/addon/profilist/)

<comment><USER2> Hey, thanks for the tip on Profilist. Neat stuff, wonder why it isn't included by default.

<comment><USER7> Profile manager UI is still around and used to be easier to get to (there's a command-line option for it now), but it was too easy to accidentally remove profiles and also confusing for people who got into it accidentally.

Profilist is relatively new and doesn't allow profile deletion, but to me still seems like the kind of feature that's great as an add-on but not used by so many people and confusing to less power-users.

</comment></comment></comment></comment></comment></comment><comment><USER8> This anniversary makes me feel like I should do something nice for Firefox. Then I realised that I've been working on their DVCS of choice, Mercurial. Well, Firefox, you've served me very well over the years. I hope I can make Mercurial better for you in return. Thanks!

<comment><USER9> I know git gets all the love and attention, but I think Mercurial is great. Thank you for your contributions.

</comment></comment><comment><USER10> I was a Mozilla Suite user 12 years ago. Then became a passionate Firefox user and supporter of the Open Web. Happy Birthday Firefox! Looking forward to 10 more years!

</comment><comment><USER11> Did anyone else donate to appear in the New York Times ad?

[https://blog.mozilla.org/press/2004/12/mozilla-foundation- pl...](https://blog.mozilla.org/press/2004/12/mozilla-foundation-places-two- page-advocacy-ad-in-the-new-york-times/)

<comment><USER12> I still have my copy of the German FAZ ad. [http://upload.wikimedia.org/wikipedia/de/7/7c/Firefox_faz_an...](http://upload.wikimedia.org/wikipedia/de/7/7c/Firefox_faz_anzeige.pdf)

</comment></comment><comment><USER13> I've been a Firefox user since it launched. It's still my browser of choice on my personal Windows laptop and on all of my Android devices--I admire Mozilla's willingness to not let the OS vendor hold a monopoly on the browser software, now as much as they did a decade ago with Microsoft.

Then again, my primary music player on my laptop is still Winamp, so make of that what you will.

<comment><USER14> Switch to Foobar so you can be whole.

</comment></comment><comment><USER15> I can't believe it's so old! I still remember using the first version of Firefox. Wrote a small story about my first encounter with it here: [http://nagarjun.co/post/102328175145/firefox-is-10-years- old](http://nagarjun.co/post/102328175145/firefox-is-10-years-old).

</comment><comment><USER16> Congrats. Although I no longer use it as my everyday browser, it made a big difference for me in the early days of OS X.

</comment><comment><USER17> I just got back from visiting a friend the Mozilla office. Thanks for creating an amazing web browser that opened a new dawn away from the shackles we were once stuck with.

Also, thanks for the cake today:)

</comment><comment><USER18> DuckDuckGo is not a pre-installed search engine in at-least Nightly.

<comment><USER19> It just rolled out in the stable 33.1 release today. It will hit the other channels (Beta, Aurora/Developer, Nightly) shortly.

<comment><USER20> I get that this isn't a code change and so this probably isn't _critical_ , but, still, isn't that exactly backwards?

<comment><USER21> Yup. To time the release with the tenth anniversary, it had to go around some of the normal release engineering and localization processes.

</comment></comment></comment></comment><comment><USER22> FF is awesome, if i wasn't an android guy, I'd be using it exclusively. But chrome <-> android Just Works™

<comment><USER10> In my opinion, Firefox for android is vastly superior to chrome.

<comment><USER23> I really love it, the only think that bothers me is the annoying UA sniffing so many sites do that only check for Chrome/Webkit to display mobile.

<comment><USER24> you can fake your UA with an addon on mobile. Works for me most of the time.

<comment><USER23> I use that addon as well but I don't think that I should need to. It'd be better if sites used feature detection rather than UA sniffing.

<comment><USER25> You can help fix that! Report websites at [https://webcompat.com/](https://webcompat.com/)

</comment></comment></comment></comment></comment></comment><comment><USER26> "10 years ago we built Firefox ----to-give-you-a-choice--- because we realized how horribly we had botched Netscape Navigator." _fixed_

<comment><USER26> Why was this comment downvoted? This is exactly why Phoenix — I mean Firebird — I mean Firefox — was started, because the Netscape Suite was a fiasco, but the underlying Gecko rendering engine was worth salvaging. [http://en.wikipedia.org/wiki/Firefox#History](http://en.wikipedia.org/wiki/Firefox#History)</comment></comment>


Circus 0.5 released - <AUTHOR> http://blog.ziade.org/2012/07/06/circus-05-released/ <comment><USER2> I'm always a little surprised that release update articles like these don't open with a one sentence description of what the library/package does for those of us who have never come across it before.

edit: here's a great example of someone doing it right: <http://docs.celeryproject.org/en/latest/whatsnew-3.0.html>

<comment><USER3> I kinda did it for all previous releases, like the box on the right here: <http://blog.ziade.org/2012/06/12/circus-04-released>

Will do it for 0.6 thx for the feedback

</comment></comment><comment><USER4> Is the process file-descriptor exchange protocol the same as einhorn ( <https://stripe.com/blog/meet-einhorn> ) ?

</comment><comment><USER5> (Slightly) OT: The "Y U NO STOP COOL FEATURES?" image is a total turnoff to me. It devalues the product.

<comment><USER3> Ah well, I found it funny - Humor is always risky I guess :)

The documentation at <http://circus.io> otho does not have such things</comment></comment>


Nissan says self driving cars are impossible today - <AUTHOR> https://www.wired.com/2017/01/nissans-self-driving-teleoperation/ <comment><USER2> I say this whenever this topic comes up: we have public transport today, it's safer and cheaper than having a car, it allows you to make use of your commute time (read, study, eat a sandwich, have a coffee), it's better for the environment (electric doesn't come from nowhere), and it's faster and even more so if more people use it. Your city maybe lacks it, but then the solution is not to say "meh, public transport is crap" and go buy a car. But this is the answer I always get in this community of people who make a living finding solutions to problems.

On the road, an actor's actions do not merely affect itself, but all the others on that road. If you slow down at a point, that can cause the driver arriving at that point five, ten minutes after to stop. On the road, everything creates a butterfly effect. And just like you can't run around naked or listen to very loud music in residential areas, you can't just get on the road with your new toy which if fails, does not only put your life at danger, but also many others'.

<comment><USER3> That is if you live in a place with sane, safe, readily available public transportation which doesn't increase your commute time by 2-3 times.

It's not hard to find places where a 40min commute in a car turns into 2-3 hours using public transport.

Public transport is also not as reliable in places with extreme weather especially cold.

Have fun waiting for a bus in an open bus stop at -10c...

<comment><USER2> Where I'm it goes down to about -5C in wintertime (-4C ATM). I'm actually fine with it.

Certainly in rural areas and in wider peripheral suburban areas public transport is less useful. But in actual cities (London, Paris, Istanbul, etc.) with a high density of people and their residences, public transport is the way to go. I don't know much about American cities, but if we got a comprehensive and functional system of metros, buses and boats here in Istanbul, where some of you would classify as a part of the third world, I guess you are capable of doing it in the US too.

<comment><USER4> Sadly, anything that requires taxpayer funding toward the common good is a political non-starter in the US (socialism!). The best hope we have in the US for decent bus network is probably Uber/Lyft:

[https://www.bloomberg.com/news/articles/2016-08-15/uber- and-...](https://www.bloomberg.com/news/articles/2016-08-15/uber-and-lyft- want-to-replace-public-buses)

</comment></comment></comment></comment><comment><USER5> Short version is that the road is full of things at the 99th percentile that won't be programmable so the car will either fail, bail, or simply stop.

I don't disagree with that sentiment but there were all sorts of things that "PCs" couldn't do that real computers could and they were still commercially successful (and eventually caught up to "real" computers for the most part). I could imagine that someone could come up with signage which self driving cars would understand and act on. Basically put up a QR code that links to the government approved way self driving cars should navigate the hazard, and of course a programming language that could communicate that to the car.

Of course you would not want just anyone to set up overrides or you would have pranksters sending cars off into corn fields or worse.

The part that Nissan appeared to miss is that if you can make them work in 99.9% of the cases, then you can hack around that last .1% and the cars will still be a net win in terms of better road behavior.

<comment><USER6> > Short version is that the road is full of things at the 99th percentile that > won't be programmable so the car will either fail, bail, or simply stop.

Autonomous cars aren't programmed, they're trained, like humans. So I don't think this reasoning applies. If they behave poorly in some circumstances, they'll just create new training simulations covering those cases with better outcomes and push an update out. The cars will learn better and faster than humans.

<comment><USER7> One thing that humans have going for them is that they have an understanding of what is going on around them, including in the minds of other people. I don't think this is fatal to your argument, but it is something to consider.

I am in the apparently unusual position of believing that autonomy is both feasible and desirable, while thinking that the capabilities of current implementations are being oversold.

<comment><USER6> > One thing that humans have going for them is that they have an understanding > of what is going on around them, including in the minds of other people.

I hear this argument often, but I see no evidence for it. It just sounds like yet another flawed attempt to make humans more special than they really are.

I guess we'll see over the next 5 years as autonomous vehicles become deployed.

<comment><USER8> Well, I at least have empathy. Maybe we could say "some humans have an understanding..."? Nobody was claiming 'only humans' \- Chimpanzees clearly have empathy.

<comment><USER6> I'm not sure empathy is relevant understanding another _driver 's_ mind. This thread is still about driving right?

<comment><USER8> Understanding the state of mind of another is the definition of empathy. "Did that guy see me? Is he waiting for me to go?" is exactly the kind of question that requires empathy to answer.

<comment><USER6> I won't dispute your use of empathy because that will start a whole other debate. Instead, I'll simply demonstrate that understanding another driver's mind has nothing to do with the scenario you presented.

The rules of the road define who has the right of way. Of course, sometimes other drivers don't see you, but you literally have _no way of knowing whether or not they do_. The only thing you can do is begin your attempt cautiously in accordance with road rules and abort at the first sign of potential collision.

Notice how this decision process is completely algorithmic. Proper understanding of another driver's mind is a red herring. You use the almost- collision to infer what the other driver knows, not the other way around like you seem to think.

<comment><USER7> From your replies to me, I was beginning to think I was being trolled, but I see you probably simply have not experienced the full unpleasantness of urban driving, in which people violate both the rules of the road and common sense for motives, not just through a lack of awareness. From my experience and informal discussions, I am very confident that people weigh the presumed motives and purpose of other drivers in their predictions of future outcomes - in fact, when I am in urban traffic and not alone, discussions of other drivers' motivations and likely behavior do come up.

Now, I do not doubt that if all (or most) vehicles were autonomous, things could work as you describe (though traffic might flow more smoothly or efficiently if vehicles could signal 'intent'), but that is not how it works at the moment, and the transition is probably the hardest part of introducing autonomous vehicles.

<comment><USER6> > in fact, when I am in urban traffic and not alone, discussions of other > drivers' motivations and likely behavior do come up.

Sure, after they do something seemingly stupid that you don't understand. Inference follows observation, not the other way around, and autonomous vehicles are observing all the time with reaction times much faster than a human's. Even if an autonomous vehicle weren't able to understand high-level goals, it understands and detects vectors much better than humans do, which is all that's really needed to create and adapt a plan that avoids collisions.

> I am very confident that people weigh the presumed motives and purpose of > other drivers in their predictions of future outcomes

And I'm very confident that even if this were true, it's largely irrelevant to being a good driver.

<comment><USER7> It is a bit self-serving of you to include the unnecessary dependent clause "that you don't understand", but as you are just stating your personal opinion, it is ultimately inconsequential.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> The only way autonomous cars will work is when they are driven on pre- certified roads. And the cars continuously report back what they see to update the certification. Combined with traffic monitoring cameras that can keep a road section's certification updated.

So just like most cars are to be driven on paved roads, reliable autonomous cars will need to be driven on roads with good visibility of lane markings. And road construction or road hazard cones will need to be electronic, so they can give the car computer unambiguous instructions (such as "shut down until driver manual control is confirmed").

</comment><comment><USER10> Nissan also released a car that's controllable over the internet with nothing more than the VIN[0]. I wouldn't necessarily trust what they say in terms of technology advancements.

[0] [http://www.bbc.com/news/technology-35642749](http://www.bbc.com/news/technology-35642749)

<comment><USER11> that kind of reinforces the point...

</comment></comment><comment><USER12> So the computer won't know what to do and you're going to dump it on someone in a cubicle a thousand miles away? Here, make a decision in at most a second and a half or you crash? That's going to work ;<).

If the computer is confused I want to be the one to make the decision. I am perfectly happy having a system right now that works 95% of the time in good weather.

I think it will be at least 2025 before it can handle a Michigan winter, maybe longer. Still want a limited system ASAP.

<comment><USER13> Most drivers can't handle a Michigan winter. I just drove from Lansing to Grand Rapids in this weather we had today, and there were four cars off the road in the span of a dozen miles. Front-wheel drive cars on straight roads, too. They didn't just spin out, those drivers had to seriously mis-handle their vehicle to wind up in the ditch.

That being said, the "self driving" part of my car (cruise control) turns itself off when the wheels slip already, so I agree that I could handle a car that drove itself in good weather but punted back to me in the snow. Vision- imparing snowfall is actually a more rare event than people might think. Normally the roads are quickly cleared.

<comment><USER14> _Most drivers can 't handle a Michigan winter. I just drove from Lansing to Grand Rapids in this weather we had today, and there were four cars off the road in the span of a dozen miles._

A lot of drivers have problems driving in winter conditions. But most? Over 50%? That's a pretty strong claim.

<comment><USER15> Most drivers are in India, southern China, the equatorial belt, etc. I don't think they have much experience with Michigan winters.

<comment><USER14> I believe it's understood that the drivers under discussion are Michigan drivers, are they not? If not, I'm not sure how interesting the statement is. Drivers in India, southern China, or the equatorial belt won't have need of a car that can handle Michigan winters, either.

<comment><USER15> I don't think that was clear from context at all, no. However unlike a human driver, people will expect a car to continue working and working safely in non typical thriving conditions.

<comment><USER14> It's not clear to me that this is true. Here on HN I'm surprised how often members can't imagine how a problem might be solved using a computer or other technology. Or people in general being surprised that technology can be applied to everyday problems. I bring this up as examples of people having limited expectations of technology, not that they're right or wrong in their assumptions.

That's not to say sometimes people have unreasonable assumptions as well. That's why I say it's not clear to me.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I think self-driving cars have incredible potential, but the media hype is just too strong around this technology. People are used to startups going from 0 to unicorn in 5+ years, because they are often based on simple technologies and business models centered around exponential growth. AirBnB, Uber, twitch, and many more are all technology companies that obviously had many challenges, but they did not depend on a technological breakthrough in order to get where they are today.

There is a gap between Level 2 and Level 4 (arguably Level 5 with the new standards, but I'm going to assume Level 4 means what most people would call a true self-driving car) autonomy which is dangerous, because it lulls humans into a false sense of safety. And then when the car can no longer drive itself, the user is expected to take over with a delayed reaction time and little to no context in what could be a very dangerous situation. It is a deadly valley. There are numerous studies on this topic from the aviation industry, and drivers don't have nearly as much training as pilots.

I think real self-driving cars are awesome, and the first time I sat in one years ago when I worked on it as a PhD student was truly an incredible experience. But the hype around the technology is too much, and when investors push for a product in a few years when it's not ready at best companies will fail and at worst people will die. Misinforming the public on this is a very serious problem which nobody seems to care about, even after at least 1 death which is still under investigation.

I am all for working on this technology and seeing incremental improvements over the years. But I am frustrated with the media's portrayal of how it's just around the corner (I am frustrated with the media in general), and I believe the overpromise of the technology is largely responsible for the death of the Tesla owner in Florida last year (and there are other accidents that are reported in China which get much less coverage).

People will say self-driving cars save lives and are safer. In theory, yes - but the problem is we aren't there yet. There just isn't enough data to make that claim. When Tesla said it was safer, they ignored the fact that all of their driving was on highways (which are statistically safer) and that their owners are more affluent and older (at least I assume the average Tesla owner is 25+). The data isn't available when you break down these demographics, but I suspect if it were that 1 death would actually make autopilot deadlier than manual driving. It's a moot point though - anybody trying to extrapolate meaningful conclusions from a single data point is making a ridiculous claim.

<comment><USER17> You are underestimating how game changing even "incomplete" self driving features will be.

Autobraking for accidents only, is a "self driving" feature that you can buy right NOW on most 2017 cars.

Auto braking alone could save 10s of thousands of lives every year, and it is absolutely production ready.

<comment><USER16> Autobraking is a great technology that has been around for a few years (BMW was selling it in 2013), but nobody touted it as a self-driving feature. My point isn't that working on this technology is bad, my point is people expect it to do more than it can.

<comment><USER17> That doesn't mean it isn't a self driving feature.... Automated accident prevention sounds awfully related to self driving.

The technology has been around, but it isn't deployed to the majority of cars yet.

What I am saying is that self driving technology doesn't have to be perfect for it to change the world.

It doesn't matter if we are a ways away from getting to the "nobody owns a car, and everyone just uses self driving Ubers" future. Because the current, shit accident prevention technology can ALREADY change the world, even if it is "just" by cutting accidents in half and saving "only" 40,000 lives every year.

<comment><USER16> I agree, and that's great! But when a company sells a feature called Autopilot, and it's marketed as a car that drives itself, I have an issue when someone dies and the company spins bad statistics to defend its practice.

Incremental improvements that save lives and make driving better are fantastic. Overselling a feature that can kill people is not.

</comment></comment></comment></comment></comment><comment><USER18> There's a human backup in the car itself. I don't see why you'd need remote control until we're ready to let cars drive without passengers which is a lot further away than cars driving with people in the car. What kind of car would not have some sort of a manual override anyway? That'd be incredibly stupid to the point of gross negligence.

Also, the posted title is clickbait bullshit and not the actual title of the article.

<comment><USER19> Google is actively promoting a self-driving technology that doesn't need a human to take over, ever. Their commercial for this technology features a blind man being driven by a car around Austin, TX. As well, the prototype at the Computer History Museum is a model that does not feature a steering wheel at all.

The thesis of the article is that the promises made by these companies -- and the promises are being made -- are not quite feasible in the short term.

So what kind of car would not have some sort of manual override? The car that all these companies are promising!

</comment></comment><comment><USER20> I think the self driving stories on HN have consistently underestimated human drivers and overestimated the tech and hand waved away the myriad challenges.

There is something deeply unpleasant about underestimating people and underestimating the problem is generally not a great way to solve it.

In the real world hundreds of millions of drivers have been driving on extremely varied roads and traffic conditions all over the world for decades. Given the sheer scale and volume of drivers, conditions and cars involved it appears self driving proponents are massively overplaying the safety card and worse with little to no data for the other side.

Any ai vehicle that requires new kinds of roads or contraints is a completely different ball game and cannot be compared to human drivers. Trains are far safer and in many cases faster than cars. Yet the train story in the US has remained dire for decades making ai safety proponents look self serving.

Technology does not exist in a vaccum, it is to benefit us and things like cars are tecnological as much as social and political. A car gives you basic transportation but also the freedom to go wherever you want. Having ai cars, constraints for them and control that could limit mobility and freedom then become more than techology issues in which the voice of society becomes far more important than the people creating the technology.

</comment><comment><USER21> Sort of reminiscent of Balmer and his frowning upon the iPhone

</comment><comment><USER22> as a transitory measure in the beginning there will be zones marked as self- driving areas and others where this will be deactivated.

</comment><comment><USER23> The world is, literally, losing it's mind.

</comment><comment><USER24> I wish people would just give up on this self-driving car business for now.

We don't even want autonomous robots in our house, pitter pattering about like toddlers, at 3 miles an hour. We don't even trust our smart TV sets.

So let's make 2 ton versions, and throw them into a frying pan with people? Yeah, great idea. I bet they'll act _just like_ TCP packets. Good job.

Why not segregated roadways? If we're so desperate to automate trucking and shipping, how about big, thick K-rails, and dedicated roadway?

We all know that early adopters suffer the growing pains of buggy first versions. No reason for all of society to share this burden when It hasn't even been put to a vote.

Keep these things the hell away from ordinary people, and their kids for at least another 50 years.

<comment><USER13> Plenty of people have robots pitter pattering in their house like toddlers. They're called Roombas, and they're the highest selling vacuum cleaner on the market right now. And the reason "we" don't trust smart TVs is because they spy on us without telling us. And the "we" in this situation is a tiny, tiny subset of the population. A lot of people don't know and don't care, they just like Netflix and how it's built into their TVs.

No one voted on if they wanted cars in the first place. I'm not sure if you're aware of how incredibly dangerous cars are, but I can tell you without looking up the numbers that if we were to vote on it today with an unbiased viewpoint, there's no way anyone would be allowed to drive a car.

I'm sorry, but I feel like you're going to be in the minority on this one. You seem really scared. I'm not trying to change your mind, but I would like for you to take a look at traffic fatality statistics and and think hard about whether or not it's worthwhile pursuit to try to bring that number down.

<comment><USER25> > They're called Roombas, and they're the highest selling vacuum cleaner on > the market right now

A correction: they're the top-selling _robotic_ vacuum cleaners. Traditional 'dumb' cleaners still outsell them by magnitudes.

<comment><USER13> Hmm, I can't seem to find my source to back that up so I'll have to concede that point. I remember reading something on HN a few months ago that the Roomba was the single best-selling vacuum cleaner of 2016, in the same vein that the MacBook is the best selling laptop even though all PC makers combined out-sell MacBooks.

But since I can't back up that claim, I'll give it to you.

</comment></comment></comment></comment><comment><USER26> I don't care about self-driving cars until car company CEOs have their kids riding in them. Until then, I am not interested in taking the risk of testing their engineering.

<comment><USER27> You point is sound that companies who produce faulty driverless cars take the upside of them after they socialize the losses from them.

Point 229 in Hammurabi's code: [229] If a builder build a house for some one, and does not construct it properly, and the house which he built fall in and kill its owner, then that builder shall be put to death.

or to put it in your words. CEOs (or their kids) must drive around in driverless cars before patrons pay for them.

</comment></comment><comment><USER28> Somehow, "I told you so" just doesn't quite say it - I Robot</comment>


Apple Co-Founder Wants to Be Australian Citizen - <AUTHOR> http://finance.yahoo.com/news/apple-co-founder-become-australian-160413129.html

<comment><USER2> Discussion: <http://news.ycombinator.com/item?id=4568709></comment>


Ask HN: Would you use js.fo? - <AUTHOR> Hey guys I've been very busy lately with js.fo, you can type in to your browser to see what it is.
For instance,

   <script src="http://browser.js.fo" />
 Will allow you to embed a fully standalone web browser in your HTML.
The other items I am working on still but would love to hear suggestions and feedback. <comment><USER2> nslookup says

 __server can 't find browser.js.fo: NXDOMAIN

<comment><AUTHOR> Yeah its not up yet but curious to here your use cases, right now im sending api keys one ppl at a time. Thanks

Its literally a vnc. Fully customizable, programmable, browsable. The idea is to release impactful javascript libraries on js.fo that will aid in web data acquisition, and other machine learning based solutions.

Id be curious to hear suggestions, lately ive been possessed by machine learning that i began neglecting sleep and food to quench this giant knowledge void that lingered for years...

Ive finally seen the light and i can say ML and AI is the shit! I mean its so fun to learn and watch. I actually watch neural network topics on youtube to relax.....even linear algebra i used to fear i enjoy....its amazing to be a part of this movement but more importantly the magic we can accomplish!

[http://js.fo](http://js.fo)

<comment><USER3> I'm sure you are aware of [http://js.org](http://js.org) and [http://dns.js.org](http://dns.js.org) It is a similar idea but not identical.

<comment><AUTHOR> yeah, basically I wanted to release some stuff I've been working on using similar format.</comment></comment></comment></comment>


Would you like to play a game? - <AUTHOR> http://getnekko.com

<comment><AUTHOR> <http://tqft.net/wiki/Maneki_Neko> may provide a bit of a hint as to what we're doing, but don't take it too literally :)

</comment><comment><USER2> Intrigued and a little scared.

</comment><comment><USER3> Huh -- now I'm curious.</comment>


Should I Comment My Code? The Case Against Code Comments - <AUTHOR> https://www.crondose.com/2016/10/should-i-comment-my-code/ <comment><USER3> I'm a junior/trainee developer and I was advised that comments should explain why something is happening, not what is happening. The what should be self explanatory by reading the code, but knowing why something is being done is useful when you, or someone else, has to look at it again in the future.

<comment><USER4> I learned to code in a way that the variable and function names also would tell you the why. And otherwise the git log is your friend.

Tl:dr; i only do comments to excuse really stupid code.

<comment><USER5> No one wants to look through a lengthy git log to find the reason something was done to a particular block of code!

<comment><USER4> I assume every damn editor out there has a plugin that makes this a complete non issue. I spend most of my time in a terminal anyway and know my way around it, i prefer it by far to comments, also because of the metadata like dates and authors which rarely is found in comments.

<comment><USER6> Half of the time, when I look at the git blame for a certain line, I get: 'whitespace-only change'

</comment></comment></comment></comment></comment><comment><USER5> Not mentioned in this article is the effect that dynamic typing vs. static typing has on how you comment. It is common practice in Clojure, for example, to heavily document every function, because it is a dynamic language and there are no other obvious ways to indicate the types of arguments or the function's return value (though that is gradually changing in the language, but not entirely). This practice is so encouraged and standard in Clojure that all functions can be defined with language-standard documentation strings that become a part of the function definition, which can then be looked up at the REPL.

Some statically typed languages don't suffer from this particular problem of making types clear, so you will see comments less, and reserved more for cases where logic is hard to parse conceptually. But some static languages have a similar problem due to type inference, which causes commenting in the same fashion as a dynamic language.

I am of the school of thought that except for making types clear, the best way to comment your code is to make the code as clear as possible so that it is obvious without extra explanation. Often, you can refactor a clumsy or confusing piece of code in a way to make its intent clear.

But sometimes you cannot, and that's where comments come in.

<comment><AUTHOR> That's a great point, that can make a difference for when comments are applicable.

</comment></comment><comment><USER7> IMO there are two legitimate places for comments:

\- Public facing APIs where you're very specifically clear about how something works, to be consumed by people who don't intend on or need to read your code

\- Explaining away seemingly weird code, odd choices, things new developers might think are mistakes but aren't, choices that may not on the surface appear to be important for performance, or solving edge cases etc.

<comment><USER8> Everything is a public facing API. The private function you wrote is public to the person who is fixing a bug / adding a feature to the code (which might still be you, a year from now).

<comment><USER7> Right, but the person fixing the bug or adding the feature is going to be reading the codebase. I don't want to have to read a libraries codebase just because I want to use it's public funcitons.

<comment><USER8> Certainly. I just mean, documenting private code is almost as import as public APIs.

</comment></comment></comment></comment><comment><USER9> I find the argument not very strong. While stating that comments will become outdated, the author also states that he uses comments for code organization. There's nothing inherent about code organization comments that would somehow make them less likely to become outdated or not used at all (header styles wouldn't be prevented from going under some other comment heading by default, to take the example the author stated).

I write comments for a few different reasons, the most important being to document my thought process at the time of coding and to note other approaches that failed or why it's done in a specific way. This helps the coding process itself.

Focusing on the what and why makes it easy to skim through code that someone else (including one's past self from several months ago) wrote. While good naming could help to some extent, there is no substitute to longer comments to capture thoughts and assumptions that could be revisited in the future to learn from as well as identify opportunities for improvement.

</comment><comment><USER10> The best place for documenting code, ranked from best to worst:

* the code itself - I.e. function names, class names, parameter names

* test and assertion names

* comments in code

* comments in tests

* version control repository commits

* some external documentation repo like Confluence or MediaWiki

Comments are good when they describe why, not how or what. For example, good comments might be "Had to do it this way to support v2 of the API".

I hate going to documentation for an API and seeing "setFoo() - sets the foo value".

<comment><USER11> Big +1. One clever trick: put the URL of the design doc inside the code as a comment.

</comment></comment><comment><USER12> If you change code, then you should change any comments about that code.

Comments that don't match the code should be flagged in code review.

<comment><USER13> Related quote:

Code never lies, comments sometimes do. \- Ron Jeffries (says clojure- emacs/cider)

<comment><USER11> ROFL. I get the sentiment... but respectfully disagree: code lies all the time.

To make a few... \- misleading function/variable names \- improperly captured errors/exceptions \- improperly structured locking/concurrency \- code that's overly complex or naively simplistic eg naively insecure.

<comment><USER14> This is a great point, code is often very messy, and often misleading the way it's written, and often has bugs.

But, fwiw my reaction to your first line is that to announce your disagreement is to not get the sentiment of the quote. What he meant was that code is executed and comments are not. When he said "code never lies" he meant that if your code is buggy, then the bugs will be experienced by users. So your point is actually orthogonal to the point being made, and doesn't either refute or support the quote.

</comment></comment></comment></comment><comment><USER15> Once I had to work with a well written but undocumented NodeJS application (in ES5, dynamically typed). I didn't know what to expect from any function, neither the structure of the data. Suppose you have a function that returns an Employee, but you do not know how the Employee is defined, so you need to look on the database schema to know the basic structure -- but when you use it you see that there is data that wasn't in the initial definition! The Employee is mutable and some data was added in some place along the app. Good look finding the actual expected output! This is easily fixed by adding some comments about the expected data returned by the function.

Please, just document your code and update if any code comment if needed. It's cheap and easy.

<comment><USER16> Yikes. That's one of the things I like least about dynamic languages. Being able to add properties onto an object after it is initially defined willynilly is a disaster for trying to understand what is going on.

</comment></comment><comment><USER8> Comment your code.

Top level comments explain the purpose behind a function or type. It can explain nuances that can't be discovered from the name (does this function append a newline at the end? Does it ignore empty values? What happens if this value is null? etc).

Aside from trivially bad comments (i.e. "add 1 to n"), comments are almost always helpful to get into the head of the person that wrote the code (even if that person was you, a few weeks ago). Comments are great at explaining why. Why this code exists at all, why it's doing things the way it is, why the hell we're removing the last character of this string, etc.

Sure, you should write clear code... but there is no way that a function name can convey all the details of the function... otherwise the name would be as long as the comment you put above it:

IndentJsonWithTheGivenIndentStringAndReturnWithoutTrailingWhitespace

If your comments are getting out of step with the code - you need better code reviewers. Code review should be a part of any professional development organization. If you're just hacking on a side project on your own... then yes, it means you have to review your own code. This is a skill, it takes practice, but one of the things you should always be looking for is "do the comments match the code?"

I would be very VERY skeptical of any experienced developer that said they don't comment their code.

</comment><comment><USER17> >> Comments, by their nature, are static.

Says who? Comments, like unit tests, and READMEs, need just as much attention as raw app code. As others have said here, explaining what the code is doing isn't the end goal of comments, because you can read the code for that.

I tend to use comments mainly for handoff purposes. One of my peers needs to know what I was thinking, goals, anomalies, etc., rather than how to parse syntax, which they can do already. Here's a random example:

        /*
         *  checkReady() starts the winston logger, which is set to catch unhandled exceptions. We don't want
         *  to do that until both the web and SMTP listeners have started, so that they can throw errors and
         *  exit the app. This is important because running on well-known ports without cap_net_bind_service
         *  shouldn't fail silently.
         */
        function checkReady() {
            if (++serverCount == 2) startLogger();
        }

...And whether or not I've made a bad decision here regarding startup logic is moot. :)

</comment><comment><USER18> I don't remember a real life situation when I was unhappy because the code had so many comments. Several times I've been unhappy because the developer obviously had spend a lot of time thinking something, but did not leave any clues about his thought process in form of comments. Especially if the code is dense, it is not always easy to grasp the meaning.

Sometimes the lack of comments leaves you to wonder if you are looking at a bug or a deliberate design decision. When working on projects that have history, one sad thing is that usually everything else gets lost over time except code and comments. Design docs, issue trackers, emails, commit logs - all gone when companies change, code is moved around etc.

My general instruction would be that if you are thinking if you should write a comment, then write it. Writing a comment takes no time at all and it is easy to remove later. Coming up with the same insight that would be captured by one line comment may take hours when somebody else is looking the code 12 months later.

<comment><AUTHOR> Yes, the problem that I've found is that I've taken over legacy applications (several times), where the previous developer wrote comments/instructions for how to work with a method. And I wasted countless hours trying to follow their instructions, just for it to turn out that they had changed the method and never updated the comments. So the time wasting component can work both ways in my experience.

If that were an isolated incident I would blame it on the individual developer, however it's been a constant trend in the apps I've taken over through the years.

</comment></comment><comment><USER19> I think the author missed the opportunity to show how choosing better identifiers for his example would have eliminated the need for comments immediately. Also notice how his comments were actually bad from the beginning: it said the method returns something even though it doesn't.

Example:

      def printPlayerLineup(playerPositionByNames)
        batOrder = 1
        playerPositionByNames.each do |name, position|
          puts "#[name} bats #{batOrder} and plays #{position}"
      	batOrder += 1
        end
      end

There are also a few tips to give about how to pick good names. For example if you expect an array of player names the argument should be called `playerNames`, not `players`. Another example is function names should always start with a verb.

Also, if you end up writing comments just to specify types, consider using a statically typed language instead.

<comment><USER8> What am I allowed to pass into this function? a hash? a list? To me, player position by names sounds like a hash of name:position. Your code assumes the input is in bat order, but doesn't say that anywhere (and how does that work with a hash?). This is why you need comments.

</comment></comment><comment><USER20> At a minimum, unless it is a trivial piece of code (like a few lines), you should comment about the purpose of a function and usage.

Here is an example of how the _old school_ numerical analysts documented purpose and usage of their code (the short variable names are a historical artifact) [http://www.netlib.org/lapack/explore- html/d0/db8/group__real...](http://www.netlib.org/lapack/explore- html/d0/db8/group__real_g_esolve_ga3b05fb3999b3d7351cb3101a1fd28e78.html#ga3b05fb3999b3d7351cb3101a1fd28e78) For the more curious, this is a Fortran subroutine that solves a linear system of equations.

</comment><comment><USER21> One of the best ideas I saw here on HN was someone saying that they will mentor their employees to add comments to their code exactly under one condition: you add a comment above it explaining why the comment below needs to exist.

That's a pretty interesting way to enforce some discipline in the commenting process, basically by adding some necessary friction into it (while also keeping it generally simple).

Curious if there are people who have tried this approach or a similar system, and how it worked out?

<comment><USER22> Ugh. Why the comment hate on HN?

Reading code, it's pretty astoundingly rare that I look at code without comments and think, man, this code is so self-explanatory! Conversly some of the best code I've ever read has comments that clearly explain what is expected, why the code works this way, and what other parts of the system use it.

<comment><USER23> Maybe it has to do with the language? If you read code in an easy language like Java, it's usually self-explanatory.

</comment></comment></comment><comment><USER24> One more justified case for commenting is in my opinion when you have to work around some bug or specific behavior of 3rd party library by doing unusual construct.

If you comment that part, it will be much easier to read the code and avoid changing such construct. I know it should be covered by tests anyway, but it will save some time for your coworkers.

</comment><comment><USER25> Names are exactly as easy to not change at comments are.

</comment><comment><USER26> I really like the way Robert 'UncleBob' Martin put it: "Every comment you write is a failure to express yourself well in code."

<comment><USER8> How are you going to express these in code:

"We have to trim the last character because this third party library we're calling has a bug that doesn't handle null terminators"?

Or "we have to continue to support the old-style url for backwards compatibility reasons"

or "we're dropping down to assembly here because it's 100x as fast as the naive solution"

or even "This function ensures the returned string ends in a line return."

<comment><USER26> First three are "why comments" so they are good. The fourth is not a comment. It should be clear from the code what it does.

<comment><USER8> You shouldn't need to look at the implementation of a function to know it's basic functionality.

<comment><USER26> So name your function "ensure_line_return"!

</comment></comment></comment></comment></comment><comment><USER27> I've felt that business requirements tend to be the sort of thing that benefit from code comments. Because too often you don't have time to create the whole machination that is required to fulfil some arbitrary business rule.

</comment><comment><USER28> I see lot of people using the argument "code should be self-explanatory so you don't need comments". But even if the code is clear and self-explanatory, isnt it still faster for people to read plain english?

<comment><USER29> Ideally, the code should read as close to plain English as possible. There's still a trade-off between specifying it in one place and synchronizing two pieces of text so that they basically say the same thing.

</comment></comment><comment><USER30> The point is not whether to comment or not - it is just to do whatever it takes to make what is happening on every level more understandable whenever there's the slightest doubt that it might appear unclear to anyone else (including the future you). It doesn't matter if it requires rewriting the function, adding a link to more in-depth documentation or populating the code with ASCII art of wild flowers - just make sure that the next person that has to understand the code won't curse you...

</comment><comment><USER31> The point made in the article is based on an example that violates good Separation of Concerns. Also focusing on _why_ induces developers to justify themselves the reasons to write the code and assume any reader knows all the assumptions of the environment. This trend will strongly disencourage code exploration and keeps newcomers in the outer side of the wall. A good alternative would be to have a combination of 1. good separation of concerns 2. good method/function name and 3 comment with focus on _what_. If you do this consistently your app would be really friendly to newcomers and even to your future self because when taking a look to it 2 years later, your code will tell you the name of an action followed by a human description of what it does _without forcing_ you to read the rest of the code and reverse engineer it to answer what it should be a simple question. Also you scan code through the app faster if you need to read less to understand what's all about. Most people don't see this because they are too immersed in the set of assumptions that a given project has, but time proves they would be rather focusing on _what_. There is a secondary benefit on doing this, it will slowly make you write better method and argument names, so it will me more often than not that your code will need comments at all.

</comment><comment><USER32> It would be really cool if whether the method takes an array or a hash table could somehow be part of _the code itself_ , and if the function is updated but not the callsite an error is shown?

Alternative title: "Should I use a type system?"

Sarcasm aside: comment anything non-obvious, and make the non-obvious things as few as possible. It's always better to have two lines of overly obvious code, than to have one line of opaque code plus one line of comment.

</comment><comment><USER33> I think of comments similarly to footnotes and embedded notes in prose writing. If there's something I can explain in the normal flow of writing, I do so.

If I have to refer to some research, a bibliographical reference, some outside documentation about data formats, or some special business rule which impacts the case I make a note. They are for asides, deeper context, and outside references.

Don't use footnotes to explain the paragraph. Use them to explain the context in which the paragraph is to be understood. Likewise, use code comments to explain the context for the code.

Many of my comments are an example record for some legacy data format. I don't write a comment for every line of the parsing routine. I give the example record and the code. Many are also notes about an RFC or standard, down to the paragraph, and where my implementation ignores some obscurity in that or which way I interpret some ambiguity in it. Why that standard was chosen rather than a competing standard, though, is often more suitable for the developer doc / README rather than in the comments themselves.

</comment><comment><USER34> This may sound tedious and strange, but I've learned to comment nearly every line I write. I think the cognitive load while skimming is much lower, but MUCH more importantly, the process of writing them is a very valuable perspective shift. It forces me to look at a block of code more holistically, and as a result I tend to catch most of my bugs while writing comments.

</comment><comment><USER35> How to create readable code that explains itself should have more focus. It's not just about naming classes, methods and variables, but also about structuring your code. It's quite possible to create a method with the perfect name that is over nine thousand lines long and difficult to understand.

This can be very subjective, but code complexity metrics can help identify problem areas. I find that areas with high complexity often benefit from refactoring into smaller pieces making it more readable and self explanatory.

If you can't structure your code to explain itself, perhaps commenting isn't such a bad idea, at least it would be a record of your thoughts at the time, until someone else comes a long and hopefully cleans it up.

<comment><USER36> Just to echo what has already been brought up here, sometimes it's not the _what_ that is important, but the _why_. Reading the code is unlikely to explain the why for quite a few complex things.

</comment></comment><comment><USER37> While I understand that comments can make it more difficult to understand code, I have frequently seen this advice taken too far. What is clear to the writer may not be clear to readers so they may avoid commenting complex code they have been working in for awhile.

</comment><comment><USER38> This article completely omits mention of 'why' comments, and only talks about 'what' comments.

I can just about accept that in a sufficiently descriptive language that what the code is doing can possibly be made clear (in practice for things like embedded C, this isn't actually true). But no code, however well named, can ever tell you WHY it is doing what it is doing. Those code comments are invaluable.

They can range from the trivial explanation of a corner case bug as the rationale for an otherwise pointless looking bit of error checking, to discussing a system requirement when explaining the implementation choice for a whole module.

</comment><comment><USER39> Beginners tend to write long comments explaining what the code does, then as they progress the comments get shorter (because they can read the code more quickly) and eventually come the realisation that

// gets bear count

function getNumber() ...

is not as good as just

function getBearCount() ...

Places where comments are still useful, IMHO:

\- complex or clever code; e.g. when I use shift for division by 2, that tends to confuse some coders, or regular expressions in javascript (for some reason JS devs seem scared by regexp)

\- strange requirements or bugs or other reason to do something in a weird way

\- other places why it may not be clear what I am trying to achieve

<comment><USER40> >\- complex or clever code; e.g. when I use shift for division by 2, that tends to confuse some coders, or regular expressions in javascript (for some reason JS devs seem scared by regexp)

I've found I've never had to use a Regex in Javascript yet. Also I don't think anyone enjoys reading Regex. Writing it is a lot easier. :)

Reading `/2` or ` * 2` is more intuitive than `<< 1` or `>>> 1`. Although I learned a new code obfuscation technique! ;) [0]

Testing 2^39 and bit shifting is negligibly faster. At lower values (2^4) it is equivalent. For any multiplication/division by a higher power of 2 (2^2, 2^3, 2^4) they become equivalent in speed.

        549755813888 * 2 x 1,526,678,336 ops/sec ±0.67% (97 runs sampled)
        549755813888 << 1 x 1,562,645,566 ops/sec ±0.26% (99 runs sampled)

        549755813888 * 16 x 1,552,125,291 ops/sec ±0.33% (100 runs sampled)
        549755813888 << 4 x 1,530,867,164 ops/sec ±0.35% (98 runs sampled)

This seems like a case of "being too clever" by trying to optimize something that the compiler can optimize itself.

<comment><USER39> There was a time when it made sense, but now I agree it's rather pointless

</comment></comment></comment><comment><USER41> 1\. Comments should be subject for tests (for example: [https://docs.python.org/2/library/doctest.html](https://docs.python.org/2/library/doctest.html))

2\. They should describe the purpose of the code in general not the quirks in the code

3\. The exception rule is when the code can't be self-explanatory. Hacks are undesirable, but in real life you have implement them sometimes anyway - <USER2> comments are necessary

4\. Docstrings in everything are wrong, the code itself is a documentation.

</comment><comment><USER42> I've always used comments on adverse behavior, or to remind myself/whoever reads it later about something I got stuck on.

If you take the time to refactor a function it takes no time at all to edit the block comment above the code.

Lately I've been caring less about how long the name of a function may be, and I've found it much more helpful when looking back at code I've previously written.

</comment><comment><USER43> How not to comment:

Put in a bug tracker number, description, and your name, and end up with a comment much larger than the code actual change. Also comment the end of the change.

DO NOT REMOVE! Almost all web analytics tracking tags have these. Do not remove? I do that all the time. Those messages are probably there for brain dead people, but it doesn't stop them either.

</comment><comment><USER44> This reminds my of my own pet-peeve when it comes to good practices being abused:

DRY: DRY in the sense where "I have three nested ifs, but to avoid I have to compare against this variable three times so my code now is simpler. RIGHT?"

</comment><comment><USER45> What is really annoying is that there are many Github repos without a useful README.

</comment><comment><USER46> A good rule of thumb is that code shows "what" it does, comments explain "why" (when it's not obvious).

</comment><comment><USER47> I don't see any of the functions returning any lists. They do produce some output, though.

</comment><comment><USER48> It's curious that the answer to "people don't have the discipline to update comments" is "develop the discipline to code in a way that avoids comments".

</comment><comment><USER49> This is _horrible_ advice from a lazy coder. I tried it for a couple of years and now I have to go back and figure out my old code. Sure it's doable because it's good code, but it's an absolute waste of time that could have been avoided with comments. Let's say it takes me 5 minutes to figure out 10 lines of well-written code after some time has passed without comments or 5 seconds with comments. Which one is better, especially when you have to figure out hundreds of lines of code?

</comment><comment><USER23> Generally you should only comment if your manager really wants you to, otherwise just write clear code and don't comment.</comment>


Ask HN: Are you limited in what language you can write in at FAANG? - <AUTHOR> Hello I was having a discussion with a friend and found that one of my assumptions about how FAANG companies tend to operate may actually not be true.
Hoping someone from Facebook or another could comment.
Each tech company has it's preferred languages - but I'm wondering how strict those guidelines are and how far they extend. If you wanted for example to write a microservice or script in Ruby at Facebook would you be allowed to? Or are the guidelines more strict for what languages you're allowed to use?
Thanks in advance for taking the time to read / respond. <comment><USER2> Google at least is pretty strict about it for server-side software. You're going to be writing in C++, Java, Python, or Go (IIRC even Node.js is forbidden, though they may've relaxed that since I left). For client-side software you use whatever the native language is for the platform - that's Java (and apparently now Kotlin) for Android, Objective-C for iOS/Mac (I'd heard there was an effort to get Swift approved, but it was well after my time), and C# for Windows. Google has a fair number of proprietary languages I won't go into too - the big public one is Sawzall, but that's now deprecated in favor of Go. Some special projects can get special dispensation to use other languages (eg. there was a team that used Haskell while I was there, and a lot of the data scientists use R for prototyping their models), and you can generally use whatever you want for throwaway prototypes that run only on your machine, but you won't get any support from Google tooling if you use something that isn't one of the official languages.

IIUC most Apple teams write code for one of their hardware platforms, so they use the native languages supported by it - Objective C and Swift, with a fair amount of system-level C and C++ code too.

Amazon I've heard is more open; teams can use whatever they want, because everything is exposed through a big SOA anyway.

No idea about Facebook. They hired a bunch of ex-Googlers, so I'm guessing they largely copied the Google model but with different starting languages (eg. they started with PHP then evolved it through HipHop and Hack). Thrift supports a lot more languages than gRPC though, so that may indicate they allow more languages internally.

</comment><comment><USER3> > If you wanted for example to write a microservice or script in Ruby

Not FAANG per se, but at Uber, you wouldn't be allowed to use Ruby for a new microservice. The only exception to language blacklists is if you're fixing issues in a fork of a 3rd party tool that is already written in an non- official language (e.g. homebrew or phabricator). Official languages get support from platform/infra teams (in terms of libraries, greenkeeping, etc) and are setup for things like security guideline compliance.

Our official stacks are Java (backend), Go (backend), Swift (ios), Java (android) and JS/Node (web).

Of course, there will always be unofficial languages, such as the odd library written in C++ or the odd project written w/ react native or legacy code written in python, but those are minorities, in terms of number of projects.

<comment><USER4> Without getting into a language debate per se - what does Uber have against Python?

(If indeed, as it sounds, there's an across-the-board ban against it).

<comment><USER3> The decision was from before my time, so I'm not sure what the specifics are. As I understand, the main motivations to move away from Python were that Java/Go provided better performance (e.g. memory usage) and reliability (read: static typing)

<comment><USER4> Fair enough - I just like to understand where people are coming from on this issue.

<comment><USER3> On a side note, my brother works at Duolingo and wrote an article detailing a very similar migration (from Python to Scala) here: [http://making.duolingo.com/rewriting-duolingos-engine-in- sca...](http://making.duolingo.com/rewriting-duolingos-engine-in-scala) and lists very similar reasons for the switch.

</comment></comment></comment></comment></comment><comment><USER4> You're qenerally quite limited in the languages / protocols you can use at _any_ decent shop.

It's not about oppressive top-down control or anything like that. It's a matter of choice. And the better shops tend to make these kinds of choices... very carefully.

If you agree with their choices - then maybe they're great places for you. If you don't - to the extent that you wouldn't want to work there - that's also fine (and they'd probably respect that).

But those "anything goes" shops where you can write a microservice in whatever language you fancy? Those are the places you definitely want to stay away from.

</comment><comment><USER5> I would think it's highly dependant your team/product and not a global company wide policy. If it can run in a container and is 12-factor there should be no problems deploying and orchestrating it

</comment><comment><USER6> In Fred Brook's book, The Mythical Man Month, there is a chapter on "Adding People to a Late Project Makes it Later". The reason given is the new people have to be brought up to speed (trained) on the project by people already working on a project. This is magnified if the project uses a different programming language, libraries, OS, database than other projects. Multiple programming languages: just say no.</comment>