Security Lessons Learned From The Diaspora Launch - <AUTHOR> http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-the-diaspora-launch/

<comment><USER4> There are a lot of lessons to be learned from Diaspora, beyond the (brilliant) points made about security.

1\. When media hype provides you with $200k, you're still best served by bringing people's expectations down to earth. There was no way they were going to be able to build anything approaching a Facebook killer in 3 months, and it would have been best if they would have made that clear in the beginning.

2\. There are a number of projects like Diaspora that have been working for years towards the same exact goal. The only way Diaspora could have succeeded where those have failed (or not-yet-succeeded), is if they had properly articulated where they would go right where others had gone wrong. If you can't do that, you probably don't have the perspective necessary to take on such a huge project.

3\. We all need to be less susceptible to the story of the "boy wonders" taking on the establishment. Between Diaspora and Haystack+, these should be sobering lessons about the dangers of hype and a good human-interest story when the result we need is stable, well-written code.

\+ <http://blog.jgc.org/2010/09/myth-of-boy-wizard.html>

4\. Open source isn't magic. Rails isn't magic. Having a good idea and a whole lot of heart isn't magic. It's true that the software world isn't exactly a meritocracy, but at the same time, we need to recognize that you have to be able to build something generally usable, and if you can't, there's nothing that will save you except for harder work and learned lessons. Some bugs will be fixed by the interest in Diaspora, but there are big architecture questions here that need to be resolved, and coordinating that democratically through the internet in a sea of strangers is a logistical nightmare. And while rails does provide a lot of functionality out-of-the-box, a project of this size isn't held up by how long it takes to write the photo-uploading code, it's held up by the big-picture stuff that rails can't really help you with. In the end, programming is programming. You need specs, mockups, user stories, documentation, all kinds of unsexy stuff.

I think we'll probably see Diaspora stabilize into something usable at some point. But I'm very doubtful that will be anytime soon, and I'm especially doubtful that it will be before the other projects (Elgg, Appleseed, OneSocialWeb, StatusNet, etc) mature into the facebook killer people want to see.

Building the kind of open source social networking software necessary to take on Facebook at it's own game is such a massive, complex undertaking, and it's such undiscovered territory, that there really is a big disadvantage to being the new kid on the block.

<comment><USER5> > Open source isn't magic.

Isn't it though? I think _popular_ open source projects have magic. These guys put out a demo with lousy unsecured code and rookie mistakes and within a week the worst offenders were identified and repaired.

I'm not saying they are great developers, but certainly OSS _is_ some sort of powerful magic.

<comment><USER4> Open source is good at getting the small bugs, the syntax errors, the security holes with clear and direct fixes, etc.

Open source is not good for making use of the "Many eyeballs" for architectural decisions. It's where the wisdom of crowds provides little benefit. This is why most open source projects are not a haphazard bazaar of stone soup contributors, like most people think, but are actually small dedicated teams of talented software developers, who are usually paid.

I think our conception of what OSS can achieve, _simply_ by being OSS, is somewhat inflated.

(Don't get me wrong, though, OSS is fantastic, and I think it's, by design, much better than close source)

</comment></comment></comment><comment><USER6> _"For example, if you were logged in to a Diaspora seed and knew the ID of any photo on the server, changing the URL of any destroy action from the ID of a photo you own to an ID of any other photo would let you delete that second photo."_

When I was working as a pen tester I would completely scold developers for letting this happen - telling them that with everything we know today about security and good programming practices there is no way you should allow that to happen. Off by-one bugs, timing attacks etc. are more excusable, but this, this is just amateur hour.

That was 11 years ago.

<comment><USER7> > That was 11 years ago.

The problem is, these kids are from _college_. They don't teach you stuff like "writing a secure web application" in college, or even try to.

(Not that this is unreasonable, though perhaps I'm suggesting that there should be different career paths for CS majors and people who intend to be professional programmers. (I say as a CS-educated professional programmer))

<comment><USER4> I've always thought it would make more sense for CS degrees to be for computer _scientists_ (ie, people who want to do more high-level theoretical work), and that software development was more of a trade school, where you learned the languages, and were soon thrown into real-world style projects and apprenticeships.

Imagine if your nurse came out of college having never stepped foot into a hospital, having only read about how to take vitals and such, but never having done it on a live human being.

<comment><USER8> I agree with the sentiment, but it's important to note that excellent programming requires some pretty high level theoretical understanding of Computer Science (i.e. Algorithms). There's a slow way to do everything and a fast way to do some things; programmers need to understand the theory behind this. In addition, if you're trying to teach someone how to write secure code, they're going to need at least some understanding of crypto. Crypto has theoretical aspects to it as well. Basically when you keep all the parts of theory that are useful to programming, there isn't much extra stuff left. It turns out the things you could remove only amount to about one theory course in your standard competitive Computer Science curriculum.

The real reason why we have an issue producing quality programmers is more fundamental; we just don't have enough people who are good at teaching it. It's not because we "waste" time on one or two courses on some theoretical aspects.

Another thing to consider is allowing Computer Science majors to opt out of general education requirements in favor of more programming classes. Allowing this would free up a semester or more for most undergraduates (as opposed to the one course saved from cutting theory). Even with just average teaching, a semester can make a big difference.

<comment><USER9> That's why professional programmers should get a B.S. in CS and then an M.S. in software engineering (or a few years of internship experience such as that required for licensed architects). Unfortunately, this is one of those things you can't say because it increases the opportunity cost of a programming career.

<comment><USER10> Or a professional programmer could just get a job and learn software engineering that way.

<comment><USER11> ...by getting scolded by more senior programmers for playing amateur hour and allowing authenticated, unauthorized actions?

<comment><USER12> The theory is that they know your entry-level and do some mentoring, code review, etc. to teach you about those sorts of things. That sort of depends on you getting a job with a good company, though.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I can probably go all night on this, but a couple things from a quick read of this (very good) post:

First, mass assignment.

The answer to mass-assignment bugs is "attr_accessible". Accessible attributes can be set via update/build/new; nothing else can. Every Rails AR model should have an "attr_accessible" line in it.

I've met smart dev teams working under the misconception that attr_accessible means "these are the attributes that can be changed based on user requests", and so virtually everything is made accessible. No! If something's not attr_accessible, you just set it manually (user.foo = params[:user][:foo]). It's not painful and the extra line expresses something important ("this is a sensitive attribute"). Attributes are inaccessible until they prove themselves mass-assignment-worthy.

Second, the string interpolation in the regex.

Real quick: don't ever let users interpolate arbitrary strings into regular expressions. Regular expression libraries are terribly complicated and not very well tested. To illustrate (but not fully explain) the danger here, run this line of code:

         ruby -e "'=XX</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=' =~
         /X(.+)+X/"

There are worse things that can happen to you with regex injection than a trivial DoS, but that should be enough motivation.

Oh, one more thing: I appreciate Patrick's take on systems failures breaking Rails apps before underlying crypto flaws will, but even if they had protected their keys, their crypto wouldn't have worked. Don't build things that require crypto. You aren't going to get it right.

<comment><USER14> _Every Rails AR model should have an "attr_accessible" line in it._

I'd do you one better: use an initializer to monkeypatch ActiveRecord::Base and fire "attr_accessible nil", which will cause mass assignment to fail on any object you create from a class which doesn't make the assignment explicit.

<comment><USER13> That's clever. Want a job? =)

<comment><USER15> Is that offer good for anyone? <http://news.ycombinator.com/item?id=1031126>

<comment><USER13> Of course. Drop me a line. I'd love to talk to you. We love talking to HN people.

</comment></comment></comment></comment></comment><comment><USER16> Lesson learned: Never let the outside world see your First Big Project Ever.

This is what Fred Brooks would have called the First System. Everybody builds this thing at the beginning of their career, and it's always this embarrassing. Mine, in 1996, took this a step further and actually prepared SQL statements in javascript before submitting them to the server to run. Yours probably did something equally bad. It's the rule of the First System. It's where we learn all the lessons we need so that we can do things right the Third time (I'll spare the Second System description for the time being...)

The key though is to make sure that nobody ever sees that code. Hopefully it will be locked away in some intranet vacation-time-planning app that nobody will ever dig into. That way you can look back at it in shame, but few others will ever know about it.

So here we have a team of people who have clearly never built anything at all, trying to learn on the job while being scrutinized by the entire world and actually submitting their code for public review.

God help them.

<comment><USER17> Quite the contrary. Provided they have the right attitude, the programmers at Dispora just learned more on their first project than they ever would have if they hadn't shown it to anyone. That's one of the primary benefits of participating in open source software.

<comment><USER16> I think the point is that this is the stuff that you _always_ learn in the course of building your First Big Thing. By opening it up to public ridicule rather than to a polite code review by an understanding senior dev, they don't really get any extra learning out of the deal. Just extra humiliation.

</comment></comment></comment><comment><USER18> I'll admit, when people came down hard on them vis a vis security, I figured it was just a bit sloppy as a preview release.

I was wrong.. these aren't really security "holes" as that's not strong enough a word. I think the best way to put it is they accidentally created the first social network wiki.

<comment><USER19> When you put it that way, suddenly I'm intrigued by the concept.

<comment><USER20> Obviously real people will object when you manipulate their friend lists and their photo galleries. But there's real possibilities in a wikified social network for fictional characters.

<comment><USER21> Permissions-based, perhaps? I often feel facebook is a little wiki-ish when I find myself tagged in a new album of photos a friend uploads.

</comment></comment></comment></comment><comment><USER22> It's not that the pre-alpha Diaspora has insecurities that bothers me, it's the whole execution.

What I really would like to see is a documented protocol - based on XMPP or some other established, well-tested protocol would be good, but if not then at least something.

Once you have that protocol - which tells you how Diaspora "seeds" communicate securely - you can let others build their own implementation, using Rails, PHP, Python, doesn't matter. Sure, release a reference implementation in Rails, but the protocol is the most important thing.

Unfortunately what we have is just another Facebook clone done in Rails, which is disappointing.

<comment><USER23> It looks like a classic case of poorly managed expectations - <USER3> technologists would prefer an approach like the one you outline (and this was what I was expecting), however given their visibility they had to deliver a working application that people could download and install and have it do _something_.

While meeting both of those objectives in those timescales might be possible it would be a truly remarkable achievement. Not surprisingly it didn't happen and they released something that pleased nobody - all we can hope for is that they learn some lessons and move onto better things.

</comment></comment><comment><USER6> _"NoSQL Doesn't Mean No SQL Injection"_

I lol'd. Mind if I use that?

MongoDB is harder to secure and filter because you have all of Javascript to worry about, rather than just SQL (and where most servers can escape arguments themselves through prepared statements etc.).

SQL databases are also well understood (for eg. in MS-SQL I can stop the remainder of the statement from executing with '--'). MongoDB with its JS engine is still a big unknown.

<comment><USER24> Similarly:

 _"...secret squirrel double-plus alpha unrelease..."_

Mind if I use that? It would be a terrific title for an animal fighting game I've been itching to make.

<comment><USER25> It's a snowclone of a line from _Animal House_.

<comment><USER26> ...which also references 1984 and a Hanna Barbera cartoon. Of course it's less funny now that I've analyzed it, but still a good joke.

</comment></comment></comment></comment><comment><USER27> One more bug in the first code snippet is their use of find_by_id means that @album could be nil, causing an error when they attempt to edit it. Most people would use @album.find and then catch the error/show a 404.

I realize these guys are in college, but they really should have (a) brought people's expectations in line with their abilities and (b) reached out to experienced developers to help them out. Intridea probably would have given them a few developer hours per week to help code, advise them, and so on. Just a little input and guidance would have saved them a lot of grief.

<comment><USER28> Totally, their lives would be so much better now if they had just asked 2-3 experienced Rails developers to review their work before releasing it like this. Actually, the fact that they didn't think to do that kind of illustrates a problem.

<comment><USER29> They shared a space with Pivotal Labs. Either they were lazy and didn't think to ask about stuff that matters - ui is nice[1], but securing your app is more important - or the Pivotal Labs guys dropped the ball big time.

I'm inclined to think it was neither and they just didn't think anyone would notice. It happens.

[1] <http://www.joindiaspora.com/2010/07/01/one-month-in.html>

</comment></comment></comment><comment><USER30> The biggest problem I think, and I speak from experience, is that some of the best rails tutorials leave out a lot of important security issues entirely. Some of them might do a trivial paragraph on password encryption, but most of them leave out any mention of these kind of basic security flaws.

Even if the writers didn't explicitly write chapters dedicated to security, obviously even that wouldn't be enough, they should at least note which code is entirely unsafe in production, and where you can learn more about it.

Every rails book is _filled_ with this sort of code that people learn, and then use.

<comment><USER16> Obligitory reference:

[http://expatsoftware.com/articles/2007/03/examplecode- produc...](http://expatsoftware.com/articles/2007/03/examplecode- productioncode.html)

(exampleCode != productionCode)

</comment></comment><comment><USER31> This is a great post and shows how awesome of a community we have. The Diaspora guys are a bit behind when it comes to solid programming, but Patrick (among others) reviewed the code, noted flaws, reported and advised them on how to fix them, then wrote a great post explaining what was wrong to help others avoid the same mistakes. Stuff like this is both educational and helps the programming community move forward. Thanks to Patrick.

</comment><comment><USER32> Thanks for the web-app security pointers in the post: the RoR security guide[1] and the OWASP Top 10[2]. These should be required reading for anyone making a public web application.

[1] <http://guides.rubyonrails.org/security.html> (Well-written, like the other guides. Totally worth reading fully).

[2] <http://www.owasp.org/index.php/Top_10_2010-Main> (Open Web Application Security Project's top application security risks for 2010)

</comment><comment><USER33> Not to be totally nitpicky but if they're using any recent version of Rails (I haven't looked at the source yet), the DESTROY action doesn't respond to GET by default. That doesn't change the fact that they don't scope deletes to the logged-in user's assets.

<comment><USER13> POST vs. GET is a little bit of a red herring anyways, since either method works for CSRF. (I'm adding to your comment, not amending it).

<comment><USER33> I'm certainly not qualified to argue with you on anything security related (nor would I want to). I'm simply clarifying Rails default handling of destructive actions which is probably semi-offtopic.

</comment></comment></comment><comment><USER34> Would appreciate if more articles like this are posted on HN, useful and practical!

<comment><USER35> Yeah - I usually come on here to find the technical sorts of articles that I learn from and have been seeing less and less of these lately.

<comment><USER36> It's true. And as a result, I'm seeing more and more threads like this one. :)

</comment></comment></comment><comment><USER37> I knew Diaspora had problems when I got an email from the guy who hosts Openspora telling me that [two] other people had the same username.

</comment><comment><USER38> I like that the phrase "Lil Bobby Tables" to reference dropping the database via SQL injection has entered the hacker vernacular.

What would be a nice one-page security guide would be a 'lil bobby tables' guide to databases - SQL injection for any database - (SQL or NoSQL) - <USER3> goal being to help developers prevent these attacks.

<comment><USER39> It exists: <http://bobby-tables.com/>

</comment></comment><comment><USER40> Did anyone really believe that a bunch of guys were going to write a secure privacy-based facebook-killer application in three or four months?

That's a challenging proposition even for experienced teams.

Though we all know that they warned us that the software was still full of bugs and treated as experimental.

Patrick says that doesn't matter, that they haven't got the foundation right and anything built on top of it will likely fall.

Maybe they can still iterate and fix those things. Maybe they will scrap large sections of the code and re-write it properly. I suggest they keep trying and learn something from all of this. Us older geeks can be pretty harsh sometimes. We often expect new-comers to not make the same mistakes we did once. That's how we learn though, so don't take it the wrong way.

Next time just don't promise more than you can deliver.

</comment><comment><USER41> Wow, those are some pretty amateur mistakes. Just taking whatever data you got from the user with no checks? Really? And that's not something you fix later. That should stick out like a sore thumb the moment you write it, making you check that user == logged_in_user before you even move on. Wow.

</comment><comment><USER42> I appreciate the two links with how to handling security issues in web application.

As many have pointed out, they do not teach this stuff in University and acquiring such knowledge you tend to have to be very proactive about your development if you do not have industry experience.

So thanks a lot for sending these nuggets our way.

You stated that the team is manifestly out of their depth in terms of web security, how do you suggest that they proceed given their month deadline? Can they pay a security expert to resolve these issue or no one wants to come within a mile of this?

<comment><USER14> So one of the painful lessons I picked up in industry is this: an impossible deadline plus a great desire to change is still an impossible deadline. Scheduling is not my bag, and I'm _far_ less well acquainted with Diaspora than you are, but if I was four man months from release at the day job with the state of the project where I think it is I would be sending out emails saying "We will _not_ hit this. It is impossible. We need to cut scope or push back release." to my superiors.

I don't know if you can get a security expert to fix this for you. You can certainly wave a big enough check around to get somebody to look over your code, but that won't magically improve code you haven't written yet. Also, it is highly likely that Diaspora is architecturally insecure -- that, beyond the "Oops, didn't check the input" code-level whoopsies that your federation strategy as written (and apparently as not documented outside of the sourcecode) just cannot be made to work right.

<comment><USER42> Thanks for the reply. I agree with the impossible deadline bit. Can you give an example of what you would consider a architecturally insecure web application?

<comment><USER14> Pretend someone described email over HTTP as a hit new webapp. Email over HTTP is architecturally insecure. Architecturally, there is no way to tell that people are who they say they are. Architecturally, the message is readable by every server between the endpoints. There is no notion of trust baked into email, so you're going to pour gazillions down the drain to retrofit anti-spam mechanics over the insecure architecture.

In terms of micro-architecture, take a look at Wordpress. I love Wordpress, don't get me wrong, but it almost can't be made secured due to some design decisions that can't be reversed, such as "Wordpress templates contain executable code with direct unfiltered access to the database."

</comment></comment></comment></comment><comment><USER43> I had my doubts about Diaspora, but now I know for sure: it will be a complete fiasco. Those are horrendous errors that show that those guys have completely no idea about web programming - and I can't see them learning it quickly (certainly not before planned release date of the final version). Sad thing.

<comment><USER28> Indeed, the level of errors shown in this demonstrates that they would probably need about 2-3 years of experience to be decent at doing work like this. I think the best thing they could have done is hired 3 skilled developers to work for 6 months at $5k a month.

<comment><USER22> Which begs the question - where did the money go ?

What they've released looks like your average weekend github side-project. I suspect a large % of Hacker News members have projects like this (though hopefully with better security ;-)). So what did they spend the money on ?

<comment><USER28> For their sake, I hope they still have most of it!

</comment></comment></comment></comment><comment><USER44> What idiots those Diaspora guys are! All that excellent security consulting, for free! They don't know the first thing about software development! It makes me so mad, I'm going to write up a carefully researched and detailed account of other errors they've made! Then they'll see how clueless they are - again! Ha, what _amateurs_!

<comment><USER44> _EDIT here because too late to edit my above comment_ I just want to clarify, to distance myself from the recent genius/tragedy submission: I'm mocking the people who criticize the Diaspora guys for not being perfect. I'm _pro_ release early, release often and _anti_ perfectionism. IMHO, Patrick is doing exactly the right thing - helping to build something better. But my post could be interpreted as mocking Patrick - that's not what I meant, and I apologize for the ambiguity.

On reflection, I shouldn't have expressed this through mockery at all, but through helping. :(

</comment></comment><comment><USER45> Excellent article. I can see why under the kind of time pressure they have been under there would be issues like these.

Interesting I was thinking in comparison to PHP where a beginner would much more likely be individually assigning each input into a SQL statement. Sure there are all kind of possibilities that can go wrong there to but mass assignment looks like it makes it so easy for someone to shoot themselves in the foot.

</comment><comment><USER46> I've always wondered about this (not being a code-monkey-ninja-wizard, myself)...

If you open source something, unless it's perfectly written, wouldn't the hacking potential be... near 100%? If everyone can see how you do _everything_ it seems like even a minor slip up will potentially surrender your site.

Could someone explain this (I'm probably missing a piece of the puzzle I can't place)?

<comment><USER14> Having source code makes both attacks and defenses easier. It isn't automatic that a bug present in source code will be caught, either by attackers or defenders -- "a million eyes make all bugs shallow" is basically horsepuckey. The bugs in the PNG processing routines, for example, took something like a decade for someone to find and exploit. All Java implementations of OpenID are OSS. All are vulnerable to timing attacks, at least as of a month or so ago. I implemented one of them and passed my implementation past our resident God King of Engineers and he didn't see that fault, either.

Now, if you're a highly anticipated project and you're making errors covered in every Security 101 article which happen to be very visible, then OSSing your code makes it highly likely that people will see those, for good and ill. What scares me for Diaspora's future isn't those errors -- it is the part of the iceberg below the waterline. I mean, if you're steaming at full speed towards a gigantic "I'M GONNA RIP UP YOUR BOAT!" sign, there is probably something underwater and I doubt any qualified security guy (I am _so_ not one) will donate you a few tens of thousands of dollars to tell you how screwed you are right now.

</comment></comment><comment><USER47> It is funny, I have looked at the code and am not a big ruby/rails person, but see obvious flaws and security holes. However, a lot of the discussion around these have been either in the "it is amateurish" bucket or the "are they expecting help from the OSS community? that is leveraging eyeballs, that may not come".

Now, while it hasn't been their primary intension (most likely), to have the OSS community (and others curious about the code) provide fixes and feed back, they sure have gotten a lot of input and advice. I also suspect they have learned quite a lot through the feedback - positive, constructive, and inflammatory. You really can't ask much more -- aside from some direct help.

While I have no plan to run my own Diaspora node, I do look forward to seeing how the code and project evolve.

</comment><comment><USER48> After reading the article, also read this comment: [http://www.kalzumeus.com/2010/09/22/security-lessons- learned...](http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from- the-diaspora-launch/#comment-5672)

The comment negates some of the statements made in the post

<comment><USER16> No, that comment just helps to explain how trivial these things would have been to work around. That's the whole point of the article, that these guys missed all the most obvious things that you need to do to secure your application.

There are no deep, tricky issues explained because absolutely zero effort was needed to find a half dozen breathtakingly bad practices floating at the surface.

So yes, of course it's trivially fixable. The problem is that it wasn't trivially fixed and they thought they were ready to release it.

<comment><USER48> Please read the whole comment I linked to. I was talking about things like the OP saying that browsers could delete things by prefetching (GET requests) or that update_attributes does a double assignment which are simply not true

<comment><USER14> I don't understand what the comment means by double assignment, but I guarantee that update_attributes will indeed let me overwrite owner_id in the manner specified. Would you like me to demonstrate this with code against a specific git revision? It isn't hard.

<comment><USER48> No, I'm happy to believe you. It just seems that assumptions like the "the code doesn't check to see if the destroy action is called by an HTTP POST or not." are incorrect and still in the post. There also isn't a proper answer to that comment so far.

</comment></comment></comment></comment></comment><comment><USER49> Well, I for one am glad that I learned from articles like this. It's a hell of a lot easier to read discussion from "real programmers" and learn from them. Now that I'm in college stuff like this is second nature.

</comment><comment><USER50> OK, you've made headlines. Now, where are your patches? ^_^

</comment><comment><USER51> I don't think this is that big of a deal. Pretty much every developer I know has learned about security through this exact process. Either a senior developer or user exposes the flaw and smart, but new, developers quickly realize the didn't understand the attack angles. Without concrete experience it's pretty hard to appreciate how exactly these attacks work. But after a few exploits you start getting paranoid, understand the basic problems, and are always thinking and reading about how your code might be missing something. These guys seem reasonably smart so I expect after a few months of exposure, they'll be fine.

<comment><USER28> Why would the community of experienced developers who are supposedly expected to be interested in working on this project, find it rewarding to sit around and wait for them to work through their training wheels? This whole situation really is absurd.

<comment><USER51> It doesn't seem absurd to me that a few college friends want to hack together a project to fix a problem they see. I think it's great, regardless of whether they succeed. Nobody is forcing you to join them.

<comment><USER28> Nothing at all is absurd about what they're doing - what is surreal is all the media attention and the expectations it has created in the average person regarding this. I don't think it's in the benefit of these four guys, actually. They're lucky in some ways and really unfortunate from other perspectives. I don't even know how I'd feel if I was in their shoes right now.

The idea that 'these guys are going to get all this money, and work for three months, and then surely deliver this top notch 'facebook killer' that we all want to use!' is a bit absurd, that's all, given that there are plenty of other projects working in this area, and there would be no reason at all to think that this one would be superior, the best, or even suitable. If it wasn't for the nytimes, etc. this would be just another project on github. The media has taken a normal situation and screwed it up majorly, and it doesn't appear to me that it's going to turn out that great for anyone involved.</comment></comment></comment></comment>


Even senior engineers can't afford to live near their offices in San Francisco - <AUTHOR> http://qz.com/516486/even-senior-engineers-cant-afford-to-live-near-their-offices-in-san-francisco <comment><USER2> Thanks for sharing. We are considering to move to the Bay Area and we heard a lot about this problem, this confirms it.</comment>


3/19/13 - Kirtsaeng v. John Wiley & Sons, Inc. [pdf] - <AUTHOR> http://www.supremecourt.gov/opinions/12pdf/11-697_d1o2.pdf

<comment><AUTHOR> The dissents are of particular interest.</comment>


Proto: The Language of Space/Time - <AUTHOR> http://proto.bbn.com/commons/

<comment><USER2> This is really interesting. I use to write embedded software for sensor networks, and it was really a pain to write stuff for it, and it was hard to reason about any emergent behaviors. I haven't looked into the exact semantics of Proto, but if it allows a higher level of abstraction, I think it'd be useful for a variety of systems.</comment>


Gender Gap in Computer Science Is Forecast to Last a Century - <AUTHOR> https://www.nytimes.com/2019/06/21/technology/gender-gap-tech-computer-science.html <comment><USER2> The web link no longer is effective for me, for NYTimes articles. Neither is any other thing I used to do, like visiting in FireFix focus.

Every day there seems to be several NYTimes articles on the front page of HN.

Am I missing how to access them, or does everyone somehow have a subscription, or is this astroturfing, or are lots of people upvoting something without reading it?

<comment><USER3> I suspect that a number of people (myself included) have a subscription. But using the "web" link to perform a search can often bypass paywalls.

</comment></comment><comment><USER4> I wonder if people will continue to try to get rid of the gender gap in computer science, if at some point it has been around and been stable for 100 years.</comment>


College Students: Where are you interning this summer? - <AUTHOR>

I'm still deciding between multiple offers, but I was wondering where other HNers are going to be interning this summer. <comment><USER2> Chubb and Son Insurance Group. It would be my second year there, and I found it to be at a slower pace than I was expecting. I guess the insurance industry isn't at a fast pace compared to a software engineer industry.

</comment><comment><USER3> SpaceX in LA. Looking like simulation software for simulating rockets, which is ok, but I'm excited about the environment.</comment>


Richard Stallman speaker visit guidelines - <AUTHOR> https://secure.mysociety.org/admin/lists/pipermail/developers-public/2011-October/007647.html?

<comment><USER2> I was really put-off when I saw video of him throwing a temper tantrum on the podium, smashing the microphone into the table and generally making a fool of himself.

I like what he's done for Free Software and GNU is an important part of computing (even if their kernel is awful). His personal choices about how he does his computing, i.e. wgetting each page and reading it with less or another pager are a little strange but I figure it's good to have someone on the fringe like that.

I'd never seen video or heard audio of RMS before and always assumed him to be a sort of Gandalf-type figure, wise and soft-spoken.

In reality he appears to be a fucking child. It was really disappointing.

That impression I got was reinforced when I read these guidelines; he seems really full of himself. I really got the primadonna vibe when I read some of the "guidelines". He requires they set aside an additional 45 minutes for photos after a 75 minute speech? Cringe.

Maybe it's just a cultural thing, but holy ego, Batman.

<comment><USER3> So, a couple points.

He uses wget to get pages because he's on the road almost constantly. His life is in his email, and he tries to respond to all of it, but gets a TON, and responds pretty quickly. He does this partly because he's using his own email client and his own editor, both of which he's been using for 35 years or so. In Emacs he has a ton of abbrevs for various common responses.

Because he travels all the time, he has a lot of experience of what works and what doesn't work, and is trying to make things as smooth as possible.

45 minutes of photos after a speech isn't his ego, its him asking the organizers to make sure they have plenty of time after the event for all the people who'll want him to sign a book or their laptop, or talk to him about free software.

I went to Brazil with him on a trip and I'm pretty sure there were photos and signing and things for a few hours after. We had to have a dedicated photographer to cope with the sheer number of people.

This is a guy who travels so much, someone bought him a parrot as a gift because they thought he'd like it, and it forced him to ask people to not buy animals as gifts. That's the scale of what he's dealing with.

</comment></comment><comment><USER4> RMS's guidelines are very very old news. His temper tantrum is now _two_ years past. Exactly how is this relevant to Hacker News?

</comment><comment><USER5> Him again. Look I appreciate his zeal and previous ventures, but why he has any relevance at all is beyond me. He's a pregnant prima donna who has lost touch with reality. I'd rather listen to the temple os guy talk to be honest.

</comment><comment><USER6> >Please do not ever mail me a file larger than 100k without asking me first.

Quote from an email that is 50k of pure text.</comment>


Is JavaScript getting worse? - <AUTHOR> https://buzzdecafe.github.io/code/2015/01/08/is-javascript-getting-worse/

<comment><USER3> > This means that typeof can now throw

        >>> def f():
        ...     type(x)
        ...     x = 10
        ...
        >>> f()
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
          File "<stdin>", line 2, in f
        UnboundLocalError: local variable 'x' referenced before assignment

        irb(main):010:0> def f()
        irb(main):011:1>     x.class
        irb(main):012:1>     x = 10
        irb(main):013:1> end
        => nil
        irb(main):014:0> f()
        NameError: undefined local variable or method `x' for main:Object
        	from (irb):11:in `f'
        	from (irb):14:in `evaluate'
        	from org/jruby/RubyKernel.java:1101:in `eval'
        	from org/jruby/RubyKernel.java:1501:in `loop'
        	from org/jruby/RubyKernel.java:1264:in `catch'
        	from org/jruby/RubyKernel.java:1264:in `catch'
        	from C:/jruby-1.7.12/bin/jirb_swing:53:in `(root)'

        public class Test {
        	public void f() {
        		boolean isInt = x instanceof Integer;
        		Integer x = 10;
        	}
        }
        >javac Test.java
        Test.java:3: error: cannot find symbol
                        boolean isInt = x instanceof Integer;
                                        ^
          symbol:   variable x
          location: class Test
        1 error

Oh no, it's now in line with just about every other lexically scoped language.

<comment><USER4> Except, now you have one that you expect and the other you don't. This doesn't make the language anything but more inconsistent. I prefer consistency inside a language far more than familiarity between languages.

<comment><USER3> Remember, it's not the function that's throwing the exception, it's the runtime. In order to make it not throw an exception, we'd have to special case typeof to make the runtime behave differently just for it. /That/ is inconsistent.

<comment><USER5> This throws an error:

        typeof x; // throws an error
        let x = 1;

This doesn't:

        typeof x; // returns "undefined"
        var x = 1;

While using variables before declaring them is bad practice, I think it's fair to argue that this behaviour is inconsistent.

<comment><USER3>
        let x = 0;
        function typeof_wrapper(y) { return typeof y; }

        (function() {
            typeof_wrapper(x); // throws an error
            let x = 1;
        })();

        (function() {
            typeof_wrapper(x); // returns "undefined"
            var x = 1;
        })();

Again, typeof isn't throwing the error, the runtime is, because a variable declared with "let" is being referenced before the declaration. It's not inconsistent, it's one of the main points of "let".

You're essentially arguing that a feature added because the old behaviour was undesirable is inconsistent because it's not exhibiting the old undesirable behaviour.

</comment></comment></comment></comment></comment><comment><USER6> Whoop-dee-freakin'-doo???

Sure there's a zillion frameworks and patterns for shoehorning OO into JavaScript. But the point is, ES6, is standardising it. That means libraries going forward will assume this is the way it's done and build on top of it. It gives them more expressive power and better inter-op.

Also, default params are long overdue but I'm not sure that makes them "so what". I'd rather avoid mangling the arguments array in some awkward if statements.

Bottom line, there's a lot of things about JS that aren't great, but it's what all the browsers actually run so we're kind of stuck with it and any improvements are welcome.

(Even if you use something like ClojureScript or CoffeeScript, JS is still the target language and the runtime. Improvements and standardisation matter.)

<comment><USER7> I think he means OO adds unnecessary complexity, hence the "bad bet".

<comment><USER8> ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that people _are doing that already_.

<comment><USER9> Just because a tool is in a box doesn't mean its useful. Considering the relative cleanliness, refactorability of code coming from the functional world (see Haskell and the like), it is debatable whether OOP is a "good" style to develop at all!

If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles.

<comment><USER10> Just because it's possible to write a program without a tool, doesn't mean it's more productive. Functional programming doesn't even directly oppose OOP, it opposes imperative. It is absolute basics of CS that there is data and logic and many problems are easy to reason about as logic modifying data (state). OOP is a tool that allows to encapsulate some data and logic that go together. Functional programming doesn't allow you much more than that. Just because you may (or may not) end up decomposing a program into the smallest units of logic, doesn't mean you've done something useful, or clean.

<comment><USER11> Without backing a horse exactly:

* FP as I understand it doesn't much oppose imperative or even most of OO. It opposes non-composability using discipline from pure/total languages.

* Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that (ADTs, existential types, modules, what-have-you do it fine if not far better). The remaining 90% may be a waste or actively harmful.

* FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely. This may end up being some kind of full-scale OO, I'm eager to try to find places where it does, but so far it hasn't ever.

As a meta note, "my kind of FP" is the Haskell type of purity and other such nonsense.

<comment><USER10> >FP as I understand it doesn't much oppose imperative or even most of OO

I think this is definitely true, if you take 'oppose' as 'incompatible'. If we look the design concept and plot them, there will be axes, and I think this is what we'll see.

>* Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that

That's also true, but it's not an argument against the seed of usefulness of the 10%. We have kitchen sinks because people pick and choose features at will.

>* FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely.

Same here, and everyone should practice this when they look at any function, or object method, trying to make it as atomic as possible.

> This may end up being some kind of full-scale OO

I don't think it's any more useful shoehorning a program into "everything objects" more than "everything is functions".

My point was to say that the core goal of OOP is a great one, it simply codifies something that people have done in C when they put structs and procedures in the same header file. Let's not throw the baby out with the bath water.

<comment><USER11> My point is merely that the benefits of are gained using essentially nothing more than real ADTs and yet are almost always bundled with harmful other things in practice. FP can include these core ideas nicely, much like how monads include imperative ideas nicely, by focusing on what composes well.

<comment><USER10> As long as I'm not using C++ I don't feel harmed by any OOP features I don't have to use. I don't feel being restricted. I'm curious, what are these commonly harmful things you're talking about?

On the other hand, most FP languages I tried feel very restrictive. The only language that is inclusive of all good ideas, seems to be F#.

<comment><USER11> I'm not a big fan of languages allowing mutability anywhere. You can use it, sure, but advertise in big bold letters as to where. This plays out repeatedly for any side effect.

There are some OO systems with effect types I suppose. Those would be interesting.

There are also OO systems that don't have mutability. But I think that it you remove mutation, all that class nonsense, and are careful with subtyping (since it breaks things badly often) then you basically have (badly typed) ML modules with open recursion.

The open recursion (a.k.a. late binding) bit is probably the most interesting thing but you can play with it in Typed LC just fine. It's just another form of recursion.

<comment><USER12> > There are some OO systems with effect types I suppose. Those would be > interesting.

Nim has something IIRC, but I didn't look into it yet.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > _Classes. Whoop-dee-freakin'-doo._

There are dozens of ways to do classes/inheritance. Standardizing this means better tooling, documentation, and interoperability.

> _Default parameters. By itself, this is another "so what" feature._

It's extremely useful in conjunction with named parameters. Named parameters are so much better than "option" objects.

If it's right in the function's signature, you can see right away how this thing is supposed to be used. Since it's declarative, it can be also picked up by your editor, too.

> _let considered harmful_

No, it's not. It makes variable declaration work like everywhere else. Function scope is the super weird anomaly.

</comment><comment><USER14> > let considered harmful

Did people actually use the side-effect var-hoisting intentionally within their code?

Pretty much any JS style-guide worth its salt suggests manually moving var declarations to the top of scope since it's nice to know ahead-of-time which indicators of state you should be keeping an eye on.

The idea of inspecting a variable that is later-on defined with let seems baffling to me. I can't think of any reason why you would want to do this.

<comment><USER15> I tend to declare vars with their context. Especially in functions that are (unfortunately) longer than usual, having all vars at the top makes for a mess.

But I don't think the `let` syntax is going to be a problem for people who write plain JavaScript. It's more likely to it might become a problem for languages that compile to JavaScript. (For example, soak operators in CoffeeScript.)

</comment></comment><comment><USER16> > let considered harmful: The problem with let is that it is not "hoisted" to > the top of its block, as var is with its containing function.

Interesting point, but I disagree. I think that the lack of hoisting is one of the _benefits_ of `let`. It works in a different way, which is more in line with other languages. Sometimes, you don't want a bunch of variables at the top of your function. Many functions do not need to be executed in the way that hoisting makes easier.

By the way, quoting Betteridge's law of headlines at the beginning of your article whose headline is a question does not mean you get a free pass of using such a headline ;)

</comment><comment><USER17> This is one of the few posts about javascript that I've encountered that sees hoisting as a good thing. I like `let`.

<comment><USER18> Have you read the linked article about typeof? Normally, it's safe to do typeof possiblyUndeclaredVariable, but if later in the function you do let possiblyUndeclaredVariable it starts the scope defined as "uninitialized", which causes typeof to throw.

<comment><USER19> Well that's perfectly normal in a properly scoped language.

<comment><USER20> What you have to keep in mind is that JavaScript is not "a properly scoped language". Pretending that it is will cause you to miss key aspects of how the tool works. This helps no one, including you. Please, for as crappy as the language might feel, approach the language on its own terms.

<comment><USER19> Function scopes and variable hoisting was not the best parts of JS anyway. _let_ brings lexical scope into the game, which I think is a great progress. And you cannot expect a variable to be defined outside of its _lexical_ scope. That's not any different that trying to access a variable outside of a function that is defined in.

If people were abusing variable hoisting in some way, they can continue to do so, by not using `let`.

<comment><USER21> If I'm following the blog post correctly, let does have effects outside of its lexical scope: it effectively makes the variable _even more undefined than a totally non-existent variable_. That is, the following code will not throw anything:

        // x has not been defined or initialized anywhere
        console.log(typeof x)

However, if you add a let statement after it like so:

        // x has not been defined or initialized here
        console.log(typeof x)
        let x = "foo";

typeof will fail with an exception, because the let statement changes x from an undefined variable to a new state that isn't even undefined anymore.

<comment><USER3> It's not having an effect outside of its lexical scope. You introduce the let into the same lexical scope as the console.log.

It will also throw an exception every single time. So unless you're adding a variable, and then never testing the code path that hits the new line, you're probably going to catch it pretty early.

<comment><USER22> Well, but doesn't let itself create a new implicit scope, from the point of the let statement to the end of the scope the statement is in? It seems to me that here let is indeed acting on things outside of lets own implicit lexical scope.

<comment><USER3> They are in the same lexical scope.

Inside a lexical scope, all matching variable names refer to the same variable. Because they are in the same lexical scope, all instances of the variable name "x" refer to the same variable.

Separate (but related) to this is the concept of where it is valid to dereference variables (this is where my knowledge breaks down - is there an accepted term for this?). Javascript says that for variables declared with "var", it is always valid to dereference them, but it might dereference to "undefined". For variables declared with "let", it is only valid to dereference variables in the lexical scope. In addition to this, it defines a "temporal dead zone", which covers the span between the start of the lexical scope and the "let" declaration. This isn't a novel thing - other languages do it, though they may use different terminology.

It's this "temporal dead zone" that you seem to be referring to when you say it's creating a new implicit scope.

It's still impossible for a let declaration to affect anything outside of its lexical scope. If it's shadowing a variable name in a parent scope, what it can do is stop variable names earlier in the scope from referring to the parent scope and make it refer to the variable in inner scope. This may seem like a problem, but most other languages will do the same thing (C++, Java, C#, Python, Ruby etc.) and I've never seen it be much of an issue.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> ES6 is fantastic and usable today using the excellent 6to5 [0]. I disagree with all of the author's points, I think these are great features.

[0] [https://github.com/6to5/6to5](https://github.com/6to5/6to5)

</comment><comment><USER23> Whats his problem with classes?

I find them a whole lot easier to reason about than prototype based inheritance. (But then I have more experience with class based languages).

<comment> vim-guru Classes adds complexity and reduces composability. With OO you end up with a soup of inheritence and patterns. Functions are way easier to compose and reason about.

<comment><USER24> > _Classes adds complexity and reduces composability._

I could easily argue the opposite. Classes reduce complexity, and increase composability. Classes allow you to group methods in a cohesive manner into a single entity. For example, a class named Queue, List, or Vector would imply to the programmer what it does without them reading any code at all.

> _With OO you end up with a soup of inheritence and patterns._

Just because programmers don't make clean code, doesn't mean the whole idea is somehow lesser then just using functions. Having a hodge-podge of 2000 line functions in one massive file is just as evil as "dirty" OOP code. At least classes encourage you to group your functions in some hopefully sane manner.

> _Functions are way easier to compose and reason about._

Functions are easy to compose and reason about, however, that does not mean that classes and OOP are not as easy. Each have their own clear costs/benefits. OOP, and procedural programming, should both be in a programmers toolbox.f

<comment><USER25> (article author here) I very much agree with this point of view. The most important concern is a developer who thinks and writes clearly, irrespective of style or programming paradigm.

That said, I find FP easier to reason about and comprehend, but that is just _one man 's opinion_. I also find it more _fun_.

The "bad bet" I was referring to was that you can make JS impersonate Java. That strikes me as a losing proposition. Sugaring up prototype inheritance to look like class-based inheritance just muddies the water.

</comment></comment></comment></comment><comment><USER26> I like `let`. It means you have to be implicit and actually be aware of what you're doing.

<comment><USER3> That part of the article isn't particularly clear. The intended behavior of let is great. The unintended behavior - that it can cause typeof to fail - <USER2> bad.

<comment><USER27> It seems to me typeof in the described case should return undefined.

<comment><USER3> typeof is never being invoked, so it can't return anything.

The rules of let are that any reference to the variable before the let declaration (the "temporal dead zone"), it's a reference error. So the reference error is being thrown before typeof is invoked.

</comment></comment></comment></comment><comment><USER28> JavaScript is definitely getting better. The only question is whether they are changing too much too fast. There'll be a lot of headscratchers when running into unfamiliar ES6 code.

</comment><comment><USER29> So classes in ES6 are something I have very mixed feelings about, on one hand all that is being added is syntactic sugar for what is already being done, I'd like to repeat that ES6 classes add NOTHING that isn't already being done and all it really does is pave the cowpath that is being used in places like node

Currently:

        JSONParseStream.prototype = Object.create(Transform.prototype);
        function JSONParseStream(options) {

        Transform.call(this, options);
            ...
        }

        JSONParseStream.prototype = Object.create(Transform.prototype);

        Object.defineProperty(JSONParseStream.prototype, 'constructor', {
            value: JSONParseStream,
            enumerable: false,
            writable: true,
            configurable: true
        }

        JSONParseStream.prototype._transform = function(chunk, encoding, cb) {
            ...
        }

With ES6:

        class JSONParseStream extends Transform {
            constructor(options) {
                super(options);
                ...
            },
            _transform(chunk, encoding, cb) {
                ...
            }
        }

That being said, the fact that previously you could not simply use the word class meant that despite efforts of people unused to the language (let me tell you how many half assed class libraries i've seen in code written by people who mainly code in python or java but have some web code as well), unnecessary inheritance tends to be avoided. The lack of a class keyword tends to get javascript writers to avoid inheritance for things best served by mix-ins or object literals, or whatever. I predict that adding the class keyword, while saving me some time will also cause an uptick to unnecessarily convoluted inheritance patterns as new users find they can implement all of their design patterns verbatim without thinking if they really need the ajax method, the json parser, and the url builder to all be in objects that inherit from each other.

</comment><comment><USER30> I'm sorry, but I really see no point in this article.

Do you realize that if the optional arguments were not included in Function#length, you'd just be saying "They are not reflected in the function's length property. C'mon, man" instead ?

Also, I don't understand Whoop-dee-freakin'-doo.

<comment><USER18> "They are not reflected in the function's length property" is exactly what the article _does_ say.

      Whoop-dee-freakin'-doo

[http://en.wiktionary.org/wiki/whoop-de- doo](http://en.wiktionary.org/wiki/whoop-de-doo) [http://en.wikipedia.org/wiki/Tmesis](http://en.wikipedia.org/wiki/Tmesis)

<comment><USER30> My bad, I misread. However, my point is still the same: there was two equally valid choices. Should the other path had been prefered, the author would now be complaining about it too. I don't find it very constructive.

As for Whoop-dee-freakin'-doo, no, it don't think it means anything in the context. That's not an argument, and the following sentence isn't either. Maybe I don't understand because english isn't my native language, tho.

<comment><USER31> From my understanding, the author was complaining about the way default arguments mess up implementations of currying. If default arguments were included in the .length, then all existing currying implementations would carry on working with no modifications, they would just ignore the default values and require that we pass in values explicitly.

Let's say we have these functions:

        function getElem(arr, index=0) { return arr[index]; }
        var curried = curry(getElem);

In a hypothetical world where default arguments _are_ included in the length, we would have to supply them explicitly. That's no big deal though, it's just a potential inconvenience:

        // Hypothetical, "better" semantics
        var arr = ["a", "b", "c"];
        console.log(curried(arr));     // partially-applied function, *not* "a"
        console.log(curried(arr, 0));  // "a"
        console.log(curried(arr, 1));  // "b"

The ES6 semantics is worse because we _cannot_ provide a non-default argument to a curried function:

        // Actual, "worse" semantics
        console.log(curried(arr));     // "a"
        console.log(curried(arr, 0));  // Error: attempts to run `"a"(0)`, but "a" is not a function
        console.log(curried(arr, 1));  // Error: attempts to run `"a"(1)`, but "a" is not a function

The reason this is particularly unfortunate is that one major use-case of currying is _to provide default arguments_! In other words, by adding default arguments to the language in this way, ES6 is breaking an _existing_ mechanism for default arguments!

I would argue that currying is actually more general than default arguments, so if it's a choice between one or the other, they should have added currying to the language instead of default arguments.

They're not quite comparable, but you can think of currying as supplying default arguments "dynamically" (at the call site), whereas regular default arguments are supplied "statically" (at the definition site). For example:

        // Give "y" a default value for everyone
        var defaultMultiply = function (x, y=2) { return x * y; };

        console.log(defaultMultiply(5, 7));  // 35
        console.log(defaultMultiply(5));     // 10

        // Don't commit to any defaults yet
        var curryMultiply = curry(function(x, y) { return x * y; });

        console.log(curryMultiply(5, 7));  // 35

        // Give "x" a default value, to act like defaultMultiply
        var double = curryMultiply(2);

        console.log(double(5));  // 10

        // Give "x" a different default, which we can't do with defaultMultiply
        var triple = curryMultiply(3);
        console.log(triple(5));  // 15

I've implemented and used currying in JS, PHP and Python, and I found JS the most pleasant, specifically because it didn't have default values.

<comment><USER32> Very well said. I work on the Ramda ([http://ramdajs.com/](http://ramdajs.com/)) FP JS library with the OP. Ramda is heavily invested in currying, and I don't yet have a clue how we'll deal with default parameters. At first guess, we'll simply have to explain that we can't curry such functions. Such a shame!

</comment></comment></comment></comment></comment><comment><USER33> I don't understand the benefit of fat arrow. I actually think it decreases the readability. What does lexical "this" binding mean?

<comment><USER34> Fat arrow notation massively increases readibility by reducing the boilerplate verbosity of function definitions. Lexical "this" binding means that the "this" of the enclosing scope is reused; Arrow-defined functions do not get their own "this" when they are called.

<comment><USER33> Thanks but massively? function() {} vs () => {}?

<comment><USER35> Also removes return statement for 1 liners. Reduces clutter of anon functions, especially when you're chaining a bunch together

e.g.

ES5

        users.map(function(user) {
          return user.name
        }).filter(function(name) {
          return name.length < 30
        }).sort(function(a, b) {
          return a.length - b.length
        })

vs

ES6

        users
        .map(user => user.name)
        .filter(name => name.length < 30)
        .sort((a, b) => a.length - b.length)

Contrived, but typical example.

</comment></comment></comment></comment><comment><USER36> Why didn't they call "spread" by the same name it's called virtually everywhere else, "flatten"?

<comment><USER23> I hate this. Why can languages try and standardize on things to at least some extent.

else if (JavaScript) elsif (Perl) elif (Python)

There is no good reason that these are different.

<comment><USER32> Yes, and those damned Italians still refuse to switch to English too!

</comment></comment></comment><comment><USER37> Eh, a lot of the additions are improvements, a few are not, a very small few introduce some annoying features. It's an improvement, maybe not perfect, but still a big improvement. Disclaimer: I like JavaScript.

</comment><comment><USER38> _Best of all, proper tail calls_

When are proper tail calls expected to show up? Looks pretty bleak.

[http://kangax.github.io/compat-table/es6/](http://kangax.github.io/compat- table/es6/)

</comment><comment><USER39> I'm more interested by how many people still seem to be using typeof instead of toString. What are you doing for array checking since typeof array === "object", !!x[0]?

<comment><USER40> There is also Array.isArray()

</comment></comment><comment><USER41> Betteridge's law[1] strikes again.

[1] [http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines](http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

<comment><USER42> That just gave you up as someone who didn't follow the link.

<comment><USER30> To be fair, the article itself ends with "No"

> So is Javascript getting worse? Well … no.</comment></comment></comment>


Facebook Co-founder drops US status - <AUTHOR> http://m.smh.com.au/technology/technology-news/facebook-man-drops-us-status-20120512-1yjfh.html

<comment><USER2> Substantial earlier discussions here:

<http://news.ycombinator.com/item?id=3960000>

and here:

<http://news.ycombinator.com/item?id=3960028>

Much of it is overlapping and/or duplicated, but with simultaneous submissions and no cross-referencing, that's bound to happen.</comment>


Accumulo - A Secure BigTable Courtesy of NSA - <AUTHOR> http://www.informationweek.com/government/enterprise-applications/accumulo-nsas-big-data-platform-faces-en/240008916

<comment><USER2> > "Accumulo's cell-level security makes it possible to set access control for > individual pieces of data using 'visibility tags.'"

Are these so-called "visibility tags" really crypto-capabilities?

<comment><USER3> It sounds more like labeled security. (SENoSQL?)

</comment></comment><comment><USER4> I'm curious to see how things will play out between the likes of Accumulo and HBase.

<comment><USER5> Yes, it will be interesting. HBase has a larger community and user base, which will surely help in its adoption. Accumulo & HBase have very similar architectures and purposes, so much that the NSA caught a little heat from the Senate ([http://www.wired.com/wiredenterprise/2012/07/nsa-accumulo- go...](http://www.wired.com/wiredenterprise/2012/07/nsa-accumulo-google- bigtable/)). If you absolutely need cell level security than you might want to go with Accumulo, otherwise, use HBase.

</comment></comment><comment><USER6> Does it come close to the advertised performance efficiency of BigTable? HBase is a resource hog, often blamed on the unoptimized Java of the Hadoop stack.</comment>


Smart Phone is a Smarter Wallet?  - <AUTHOR> http://www.time.com/time/magazine/article/0,9171,2048325,00.html

<comment><USER2> "For instance, what's to stop a sophisticated thief with a concealed payment terminal from digitally pickpocketing you [with NFC]?"

Using a barcode instead, with a face of the customer downloaded from a server onto the cash register, as in <http://www.facecash.com>.

<comment><AUTHOR> That is a concept that I have been toying with. However, all interactions with payment processing servers would have to be done via your smart phone's internet connection; which isn't a terrible thing despite possible slow connections.</comment></comment>


Machsend - P2P file sharing in the browser - <AUTHOR> http://leadthinking.com/89-machsend-p2p-in-the-browser

<comment><USER2> Yahoo! BroserPlus does not work in GNU/Linux.

It supports:

Windows XP & Vista

        * Internet Explorer 6 & 7 & 8
        * Safari 3.x & 4.x
        * Google Chrome
        * Mozilla Firefox 2 & 3

Mac OSX intel 10.4.11 or newer

        * Safari 3.x & 4.x
        * Mozilla Firefox 2 & 3

<comment><AUTHOR> Yes, it's a shame. Best thing to do is ask Yahoo to support it.

</comment></comment><comment><USER3> Reminds me of <http://www.streamfile.com/>

Discussed on HN here <http://news.ycombinator.com/item?id=252019>

</comment><comment><USER4> any idea how NAT traversal is done?

<comment><AUTHOR> There's a paper explaining here: <http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf>

I think that might make a good blog post.

<comment><USER4> I was asking how they are doing it from browser. But it appears that we need to install a local client :(

<comment><AUTHOR> You need to install BrowserPlus - but that's an in-browser installation (without a restart) and is fairly seamless.

During the beta you also need to download/install a BP plugin. This is only because Yahoo haven't signed the plugin - and will install automatically when they have.</comment></comment></comment></comment>


Legible and efficient SQL, with CTEs - <AUTHOR> http://www.iron.io/blog/2015/09/legible-efficient-sql-with-ctes.html

<comment><USER2> Legible? Absolutely. But it's important to keep in mind that CTE's are optimization fences. Optimizations like predicate pushdown are not currently available. More complicated queries may benefit from being rewritten with subqueries.</comment>


Ask HN: When reading the description, do you understand what my game is about? - <AUTHOR> https://itunes.apple.com/app/id889709720

<comment><USER2> Just read the descrition:

\- "Reach the target numbers with as few moves as possible" is this a platformer, where I must travel to the numbers or, being numbers, I have to do a series of operations to get to the target?

\- "the bubbles pile up to the top of the screen" There are bubbles? What do they do? do they hinder me in any way (besides making me lose)? "...reach the top" Am I going to be climbing?

From the text alone, I have no idea of the game. You failed to establish context - what I will be doing and how - and only talked about the goal (and that was vague), and the losing condition.

Now lets look at the pictures:

Ok, now I see the bubbles, the top, and the main idea of the game. You have a "tower" of numbers that is growing, and you will be berforming arithmetic operations with them to reach the target.

I didn't get exacly the steps to work with the numbers. I suspect is: 1- touch a number (8), 2- Touch an operation (-), 3- touch another number (5). You get 8-5=3, so I imagine you get a "3" bubble. I also assume you can only use two adjacent numbers (or where would the new bubble appear?).

If you get the target you get points. You can also swipe a number to remove it from the tower, with a penalty.

In conclusion, it could be better. I am assuming a lot from the pictures, so they should be clearer. Show the steps I have to take to works with the numbers. The textual description says nothing about the game. Describe the game in brief sentences: "You tower of numbers is growing without end! Do mathematical operations with them to prevent it from growing too much. Everytime you get the target number, you get points." Or something like it.

<comment><AUTHOR> Very useful feedback, thanks! Indeed context is important, and I did not realise this.

</comment></comment><comment><USER3> Looks interesting, but I don't have an iPhone so can't give you a full review. From the description though I think I understand, what confused me a little more (I haven't had my coffee yet so it may just be me :) ) is the screenshots. The first shot shows an 8 about 4 or 5 numbers down and an 8 at the top. The one further down is green but in the next shot the one further up is green. The next shot shows a 3 (I understand how you got there) but then the next shot shows the 5. It seems like they are out of order in the screenshots. The swipe more to earn more points is unclear to me as well.

This may be an iPhone thing, but why even have the swipe? Why not just do the math and as the math is done correctly the bubbles disappear.

I like the concept though and it seems like it would be a really good game for learning/practicing math skills while also keeping your brain fresh.

<comment><AUTHOR> Thanks a lot for your detailed feedback!

You are actually right about the swipe thing, and someone posted the exact same comment in his review on the appstore. So this kind of validates that I did something wrong there.

On the first part of your comment: I'm not sure I understand, but essentially when you tap a number it turns green, and then you just tap +,- or * to do an operation.</comment></comment>


Ask HN: Better alternative to Linode? - <AUTHOR>

According to Linode "lightning storm in the area caused a power outage and redundant UPS systems failed". My server is still down and I am seriously considering switching to another hosting company. Any suggestions? <comment><USER2> amazon ec2</comment>


Email is the new Fax - <AUTHOR> http://abhijitdhakne.blogspot.com/2013/12/email-is-new-fax.html

<comment><USER2> You are completely right.

Email is slow, too formal, and misused over the last 2 decades.

I want to get your feedback on Hop (I have no association with them) [http://gethop.com/](http://gethop.com/) . Its basically turning emails into instant messages.

I think its a great idea on paper because it creates a transition point for your senders/recipients not to give up email - and on your end, you have a different UI and UX.

Then after thinking about it as well as re-watching their demo video, email is no longer associated with "entertainment" or "connection" \- like you mention. We have LinkedIn, Facebook, Skype, Facetime, WhatsApp, (if younger, Snapchat, Instagram.. ) etc... So for Hop to do it for the average user, I think it just doesn't work.

There can be a play here for Enterprise though - where organization communication need to be more fluent, and efficient - thus leading to the short burst of replies (skip the 'Hi John' and skip the 'Best, Tim'), automatic threading based on discussion/wall-like layout, integration of directory + Sharepoint / Dropbox onto the fold, etc...)</comment>


"I Want to Know What Code Is Running Inside My Body" - <AUTHOR> https://backchannel.com/i-want-to-know-what-code-is-running-inside-my-body-ff9a159da34b#.gait3xuzi <comment><USER2> I saw a talk about medical device security (or lack thereof) at the Eleventh Hope a few weekends ago. Very scary. They started off with a story about patients in a hospital who became horribly addicted to morphine because they were able to hack the machine from resources found online ([http://www.massdevice.com/hospital-patient-hacks-his-own- mor...](http://www.massdevice.com/hospital-patient-hacks-his-own-morphine- pump-massdevicecom-call/)). Go on Shodan and search for medical devices and terminology (e.g. "radiology") and you'll see the state of things. Sensitive machinery exposed on the open internet. A lot of medical devices have hardcoded passwords that are used for remote operations by technicians.

Open sourcing this code would do a lot to mitigate these issues.

<comment><USER3> The sad part is that the companies will use this security by obscurity argument against open sourcing.

<comment><USER4> contrary to popular opinion....

Obscurity _is_ good practice as _one_ layer of a layered defence system.

See "Defence in Depth" [https://en.wikipedia.org/wiki/Defense_in_depth_(computing)](https://en.wikipedia.org/wiki/Defense_in_depth_\(computing\))

"Defense in depth is originally a military strategy that seeks to delay rather than prevent the advance of an attacker by yielding space to buy time".

We have to acknowledge that no system is perfect, there will always be holes, therefore a good approach is to layer up the imperfect systems which delays the attacker.

Obscurity is one of those layers, a system will always be more secure if you have to find it first.

<comment><USER5> True, but history has demonstrated countless times that closed source code doesn't provide near enough obscurity to deter hackers, and automated fuzzing tools make it even easier.

<comment><USER6> It also demonstrates that obscurity can significantly reduce the number of attack attempts that are made against you. See e.g. why people move SSH to non-standard ports - raising the entry bar for the attackers has some value.

</comment></comment></comment></comment></comment><comment><USER4> You most certainly _don 't_ want people to be able to modify safety critical code within a pacemaker.

What most developers don't realise is the level of engineering strictness that goes into anything safety-related. The rules and regulations related to anything that affects the human body is in a different league than what most developers are familiar with.

What _is_ a problem here, is that the design (not the code) apparently did not take into account any messaging security, relying on obscurity as its _only_ defence.

If the code was open-sourced, don't expect to find lots of buffer overflow attack vectors, or simple things like that. Its the design of the system as a whole at fault, and that is already open.

Medical devices such as these are _not_ black boxes to the people that certify them, everything is open to them, source included. Having worked in that sort of area, I trust the systems that are in place.

<comment><USER7> Industrial control systems are also safety critical systems that have to adhere to very similar regulations as medical systems. Yet, when you ask hackers in that field you'll quickly learn that they have terrible code and abysmal security. Rules and regulations do very little to improve code quality and security, imho. Most things in these regulations are either best practices that any software engineer does (write tests, for example, or do code reviews), or just checkboxes for the QA to check.

I'd argue that over time safety critical systems have worse code than normal software because refactoring is almost impossibly expensive due to all the paperwork that each software change ensues.

<comment><USER4> industrial control != safety critical.

"industrial control" covers both certified and non-certified code, you will have to be more specific than that for the purposes of this conversation.

Quite often, cases such as the pacemaker are flaws in _system design_ , not _code_. (e.g. no secure messaging, probably due to the lack of awareness when it was designed).

That is not to say that safety-critical code is perfect... just that it has a _lot_ more rigour and inspection involved than run-of-the-mill website code.

True, the expense and overhead does indeed affect the level of change that is acceptable to a business, but given that change is allowed, the quality of that change is what we're discussing here and all I'm saying is that there is a _lot_ more rigour involved than most developers here are aware of.

<comment><USER8> > That is not to say that safety-critical code is perfect... just that it has > a lot more rigour and inspection involved than run-of-the-mill website code.

I had assumed that as well until all of the horror stories around Toyota's firmware came to light.

[https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...](https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_recalls)

<comment><USER4> Unfortunately, we are human...

Yes, the toyota case is a well publicised case. Consider though, the number of safety critical systems that are out there performing perfectly everyday. Of course, that is not proof of much, but the fact that you can name the Toyota case (and probably the Therac 25 case) means that the process generally works.

</comment></comment></comment></comment></comment><comment><USER9> We hear a lot about how digital obsolescence is a growing problem, and almost all of it refers to not being able to access your old family photos and movies, or maybe old documents and spreadsheets. But what happens when your pacemaker is obsolete, the source code is long lost, and no-one knows how to update it?

Is this problem being addressed in any real way? 50 years in the future some of today's devices may still be operating in peoples' bodies, and it seems hard to believe that anyone would still have the knowledge and/or tools to upgrade them. And surely it's quite a big deal to open someone up to replace the hardware every 5 years?

<comment><USER10> The pacemaker or ICD generator is replaced when the battery is exhausted, typically 8–10 years. The procedure is not a big deal, it is commonly outpatient and done under local. Outside of some durable orthopedic implants, few implants will survive in the body for 50 years: it is a very hostile environment.

<comment><USER11> >it is a very hostile environment.

I've never thought of it this way, and you are right from both a technological and biological perspective.

Biologically we are wonderful containers of nutrients, but we have an army only the very sneaky or militant can overcome. Once that army stands down we are rapidly colonized - which is why we must be so careful with food/meat storage.

<comment><USER12> You just made me realize why bacteria and other things want to kill us so badly... we are precisely that, really extremely-high concentration stores of nutrients.

</comment></comment></comment></comment><comment><USER13> Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even the FDA is not allowed to.

<comment><USER14> With or without a warrant...?

EDIT: Not sure what's up w/ the downvotes. There are well-established ways for regulatory agencies (whether FDA, FCC, etc) to obtain firmware for devices -- and it almost always involves a warrant under extraneous circumstances -vs- proactively receiving proprietary code.

<comment><USER15> What if they had to subpoena a tomato grown in a field next to the toxic waste dump? What if they opted not to examine that tomato because they didn't have the resources to issue, process, and support, the lengthy bureaucratic process involved in such things?

<comment><USER14> Who owns the tomato? Who owns the land that the tomato is grown on? You can't just willy nilly confiscate other's property...

<comment><USER15> But the government can and should have the right to inspect a tomato (not necessarily a specific tomato) if all the tomatoes in that field are slated to go direct to consumers, right?

Similarly, what about testing for drug quality? You could even extrapolate it out to the SEC's right to examine a private financial transaction in order to determine legality. Or the IRS's right to inspect one's taxes to determine compliance.

Point is (IMO) there is a need put on government by society to bypass some of our "Inalienable" rights. In most cases this societal decision is necessary and makes sense, and I'm arguing that code inspection of life-critical systems is a reasonable example of such a case.

</comment></comment></comment></comment></comment><comment><USER16> Another really good talk about the topic, "freedon in my heart" by Karen Sandler:

[https://www.youtube.com/watch?v=5XDTQLa3NjE](https://www.youtube.com/watch?v=5XDTQLa3NjE)

It's mentioned in the article.

<comment><USER17> I can't recommend this talk enough. If you have the time, it is one the best keynotes I've ever been privileged enough to watch.

Ever since then, I've been very interested in all the paperwork sent to my grand father about his pacemaker + defib implant. Recently they mentioned to him that they will send out a remote monitoring device and Karens talk immediately jumped to mind.

Initially the documentation talked about how the remote monitoring device needed to be held close to the heart for a few seconds in order to download the relevant data. This gave me a modicum of hope that at the very least it was some sort of NFC type communication. This would at least make it harder to physically exploit.

However, they continued to say that if you want it to monitor you every night, just put it within three metres of your bed while you sleep. I had a search online and there does not seem to be a lot of people particularly interested in this area, although repos such as [https://github.com/openaps/decocare](https://github.com/openaps/decocare) give me hope in the ability of the community to reverse the relevant protocols and investigate these devices.

</comment></comment><comment><USER18> Obligatory talk on that topic from the 32C3:

"Unpatchable - Living with a vulnerable implanted device"

[https://media.ccc.de/v/32c3-7273-unpatchable](https://media.ccc.de/v/32c3-7273-unpatchable)

</comment><comment><USER4> _Please people.... before you comment on this thread, please inform yourself on what safety critical software is really like._

There is a lot of uninformed discussion in here currently.

[https://en.wikipedia.org/wiki/Life- critical_system](https://en.wikipedia.org/wiki/Life-critical_system)

</comment><comment><USER19> Sure this is about pacemakers, but cant we say something similar about the rest of our body?

<comment><USER20> Unfortunately, it's a black box made from nature that we have to reverse engineer.

<comment><USER21> It's also self-modifying code that bootstraps its own compiler.

<comment><USER22> Yea it's got some cool genetic algorithms.

<comment><USER23> One could frame the entire computing industry as a distributed genetic algorithm, executed by the _real_ computers in order to understand themselves and the environment around them. One could further posit that we don't really have a good handle on the right fitness function yet.

(I realize this sounds like a low-effort joke, but think about it for a second.)

<comment><USER6> Well, computing today seems like primordial soup flowing through the pipes set up by Moloch[0] - we keep doing random shit, somewhat directed by economic incentives.

[0] - [http://slatestarcodex.com/2014/07/30/meditations-on- moloch/](http://slatestarcodex.com/2014/07/30/meditations-on-moloch/)

</comment></comment></comment></comment></comment></comment><comment><USER24> I agree, I want to contribute to FOSS medical devices.

</comment><comment><USER25> By extension should every device I own require me to have access to the source code and output data?

Not a rhetorical question.

<comment><USER16> Y'know, back in the early 2000's and the days of Slashdot, it was quite common to find people who advocated for free software everywhere.

Now we find people who like yourself have to specify that the radical position that all software should be free is something worthy of serious consideration. That they're not joking or trying to be deliberately provocative.

What happened to us? Why did we go from boasting about installing Linux on a dead badger and talking about how all software will some day be free to being afraid to seriously consider the proposition?

<comment><USER26> Because Linux was supposed to become a great thing, but instead it remained a paradise for geeks to do what they think is best. Software built to make money, on the other hand, was built to improve things like ease of use, aesthetics, and buyer's happiness, because that's what buyers were looking for. The open-source people never really cared about the dumb people and lay folks, the ignoramuses that didn't care to learn how to compose commands and figure out regular expressions. And that Linux was supposed to be the shining example of open-source software, one that so many people installed and tried, only to find out it blows and is effectively unusable for their needs.

<comment><USER27> I was under the impression that Mac OS, iOS, Android and recently Windows all run "Linux" under the hood nowadays. Not to mention the presence of Linux in the cloud, which is essential for the functioning of most websites, apps and mobile devices. Am I wrong?

Basically, it's easier to tell where there is no Linux than the opposite. That surely doesn't sound like such a failure. It's as if all the other OSes and systems are front-ends for Linux subsystems.

<comment><USER28> Only Android actually uses Linux. macOS/iOS are proprietary Apple things with bits of mach and FreeBSD. The Windows thing you are probably thinking of is that Microsoft reimplemented various Linux APIs, so software built for Linux can run under Windows without Linux being involved.

</comment></comment></comment></comment></comment><comment><USER29> How about when I'm flying an airplane; I'm also putting my life in the hands of people that wrote the code that controls it and I have to trust that the plane won't shut itself down mid-flight because of faulty code. Should a similar argument be made here?

<comment><USER30> Perhaps you are being sarcastic, but I shall attempt to answer the question earnestly anyway.

I've been reading up on aviation regs due to a recent interest in getting a pilot's license. By my understanding, airplanes certified by the FAA as airworthy undergo some fairly heavy testing to exactly determine and prove what their capabilities and limits are. Given that getting your prototype wrong can cause the plane to crash and kill your test pilot, there's incentive to get this stuff right. Furthermore, once a plane is type certified, it can't be modified from that configuration without further testing to prove the modified configuration. Thus you'd better be damned certain that your engine control computers are correct, lest the FAA revoke the plane's airworthiness certificate, making that model unsellable, nevermind the lawsuits of the survivors of deceased passengers or insurance companies recouping their losses.

Additionally, from what I've seen, most general aviation airplanes are stuck in the 60s as far as engine tech goes, in part because of the strict FAA regs. We're talking air-cooled engines with carburettors here, no engine computer to speak of, or if you're running a fancy modern engine, mechanical fuel injection. Unless you're flying a brand new Cirrus SR22 or Diamond DA20, there's no code _to_ inspect. Even if there was, it'd be in the avionics. You don't need a nav beaon, radio, or transponder to land an airplane safely -- though they can make it much easier, and the FAA is going to want to know what happened once you're back on the ground.

As far is large passenger jets? I'd say as a passenger, no, you don't have access to the code. It's not your airplane; it belongs to the carrier.

Personally, if I were to own a plane and fly it, I very much would want access to any and all code that makes the plane go. Though if I'm going to be hacking on said code, I suppose that's what the FAA's Experimental category is for.

<comment><USER31> > Furthermore, once a plane is type certified, it can't be modified from that > configuration without further testing to prove the modified configuration.

Would this work similarly with autonomous cars? For example, what if google wants to change one line of code in their car?

</comment></comment></comment><comment><USER32> Can the mods change the link to [https://backchannel.com/our-medical-data- must-become-free-f6...](https://backchannel.com/our-medical-data-must-become- free-f6d533db6bed#.o436sohwc), since this is the full version of the story?

</comment><comment><USER33> Sounds like they could do with a law similar to the freedom of information ones for software of this type. Without that device manufacturers are not going to want to publish as competitors could copy it and some people may sue over perceived errors.

</comment><comment><USER34> I am imagining that young folks have Library Anxiety, and old folks have "Google Anxiety".

Ask any question and you will find an answer. Any question you have, no matter how banal or left-field. What is the weather? Is my grandson a lesbian? How do I eat pizza in Italy?

Where is the biography section? How do I understand the Dewey Decimal System? What is in the Special Collections, and what are the hours -- and do I need an appointment? The computers are down... is there a way I can search for books offline without randomly roaming the stacks?

</comment><comment><USER26> I want to inspect the blueprints of every building I walk into and know the sourcing and composition of all the structural components as well. For my life depends on these things to be true and properly constructed.

<comment><USER35> I'd like to read commments here without total strawmen derailing the conversation to nonsense. Do you have anything constructive to add?

<comment><USER26> Do you?

</comment></comment></comment><comment><USER36> Very soon we would have FBI and NSA requiring these pacemakers to have a kill switch to kill whoever they don't like.

<comment><USER37> They don't need to. Private industry has shown time and again that the device will remain insecure until consumers care (that is, indefinitely).

<comment><USER36> Those are two different things. Private industry's safety assurance will grow up steadily as the demand from consumers goes up. Currently we are just thankful to be alive.

For example if someone invents an artificial device that helps me get rid of diabetes I would be super happy. It is only a generation later we would demand that device meet certain quality floor. That is the case with all innovations.

Government however can put a very hard nail into the head of an innovation.

</comment></comment></comment><comment><USER38> Philosophy -

She doesn't know the code that's running on machines inside her body.

I don't even know the code that's running my heart.

And yet, I trust it.

<comment><USER39> The latter has undergone far more testing than the former.

<comment><USER40> The bug fix turnaround makes waterfall look downright lean, though.

</comment></comment></comment><comment><USER41> > "You're pulling data from my cardiac device that I paid for, implanted > inside my body, the most intimate piece of technology anyone can have, and > yet I'm devoid of access to the device? That moved me to my core," he says. > "That's just not right."

I'm sure she must have signed a user license agreement of some kind upon buying the device. So she shouldn't have to complain.

</comment><comment><USER42> Reasons to NOT open up the code: 1> Loss of competitive advantage 2> Open source is not necessarily any safer (heartbleed bug ... ) 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects. Who owns the liability in that case?

<comment><USER43> Even if we assume that these arguments are sound (which they aren't), they do not appear to provide a proper justification for _letting a human being die_.

Put another way: If you had to explain Marie Moe's death to one of her relatives, which of your three points would make the relative understand your position?

<comment><USER44> These are sound arguments. Medical devices have to be certified in all applicable jurisdictions and companies want to protect their competitive advantage. This is no different from, say, new drugs, which are similarly proprietary and the maker retains exclusivity for several years. Further, medications too are risky black-boxes towards end-users.

<comment><USER43> They are not sound in the context of human welfare.

We do not allow food companies to hide the ingredients of their products, because we know that companies (in the interest of profit) will fail to inform consumers about the dangers of eating unhealthily. Similarly, we do not allow meat producers to leave their meat ungraded because it endangers their "competitive advantage" \- we understand (empirically) that doing so leads to food contamination and otherwise preventable disease.

Your choice of proprietary medicine as a counterexample is an interesting one. The pharmaceutical industry in the United States has a _long_ history of "protecting its competitive advantage" at the cost of individual welfare - consider how frequently "reformulations" of the same base chemical are patented to continue milking a lucrative product that could improve the lives of thousands if genericized.

Perhaps even more pointedly, consider the fact that we deem it acceptable (and _necessary_ ) that the FDA step in and regulate the release of new drugs. Is there a valuable distinction to be drawn between the sort of regulation and evaluation that the FDA does and the sort that would be possible if programmers could openly evaluate medical devices?</comment></comment></comment></comment>


Pomodone App - <AUTHOR> http://pomodoneapp.com/

<comment><AUTHOR> Pomodoro timer for your favourite productivity tool.

Pomodone is the easiest way to track your workflow using Pomodoro technique, on top of your current task management service: Todoist, Trello, Wunderlist, Asana, JIRA, Pivotal Tracker, Basecamp.</comment>


Web based tool to generate sequence diagrams (uml) - <AUTHOR> http://www.websequencediagrams.com/

<comment><USER2> I wish I had known about this during my OOP course. This looks slightly more intuitive than the quick sequence diagram editor (sdedit) <http://sdedit.sourceforge.net/> . The thing about sdedit, however, is you can see your diagram as you code it, which I always thought was pretty sweet

</comment><comment><USER3> Try the NAPKIN style diagrams. I came across them in a technical article and found them eye-catching and fantastic. This is a neat and useful piece of software. The text format let's you crank out a meaningful diagram very quickly.

</comment><comment><USER4> "The SD/MSC Generator is an easy alternative to using mouse-centric tools..."

Hmmm..use the keyboard instead of the mouse? At one time, you would have been laughed out of the room. Nice to see that some apps understand what geeks have known all along: sometimes the command line just makes more sense.</comment>


Ask HN: Better Regex Support for JavaScript? - <AUTHOR>

My understanding is that regex in JavaScript is fairly crippled. http://www.regular-expressions.info/javascript.html lists a number of missing features. The most salient of these seem to be:

  # Lookbehind is not supported at all. Lookahead is fully supported.
  # No atomic grouping or possessive quantifiers

 One way to fix this would be to write a regex engine in JS. Does anyone know of any such projects? Alternatively, does anyone know of any other ways of supporting fully-featured regex in JS?
(Making a request out to a web service written in a language with better regex support is the default option, but I'm hoping to find something with less external dependencies.)
Thanks! <comment><USER2> Someone who offers three solutions to mimic lookbehind's in Javascript:

[http://blog.stevenlevithan.com/archives/mimic-lookbehind- jav...](http://blog.stevenlevithan.com/archives/mimic-lookbehind- javascript/comment-page-1)

Also, there seems to also be a lot of support for leveraging PHP's regex functionality on the server-side to accomplish this.</comment>


Ask HN: Is There a Shopify Equivalent for Services/Marketplace? - <AUTHOR> <comment><USER2> You mean something like - FreelancerCV.com?

Custom Domain-based Service marketplace -

[https://codecanyon.freelancercv.com](https://codecanyon.freelancercv.com)

[https://freelancer.freelancercv.com](https://freelancer.freelancercv.com)

[https://golang.freelancercv.com](https://golang.freelancercv.com)

and so on...

<comment><AUTHOR> More so a model where if I say own a business, want a pool of independent contractors I've vetted to view jobs, and give them an opportunity to pick up and perform a job. Example is something like Handy.com but more niche for a solo business.</comment></comment>