skysight-inc/HackerNews huggingface dataset:
I think your point is valid with respect to experienced, technologically-proficient attackers. But as Berners-Lee points out:

The attack is by colleauges, members of family, etc, not by hardened black hats.

As readily available as tools like John the Ripper and its various clones are, the average user (parents, schoolmates, stalkers) probably won't think or be able to operate such a tool. These are the kinds of attackers who will, when asked for a master password, either start guessing or just give up. Hence:

Well, in a lot of places with say teenager culture or
work groups, if you leave your computer open you know
people will read your facebook and may even send messages as you largely for fun.

It is a different damage level of security failure for someone to get hold of the password and be able to log in and stalk them at any time in the future.
That same principle really applies to just about all major software projects: using high-quality feedback loops as early as possible can be a huge win. Whether that's having (carefully selected) pre-alpha customers for your product or in Rust's case, co-development with a serious target application (i.e. Servo).
The problem with YAGNI as a development slogan is that it can be too broadly applied.

I think a better wording might be, "don't increase complexity writing code you may not need". The issue is usually not the presence of additional code. Rather, it's making design decisions based on requirements that may never in fact come to bear.
did you ever consider that removing people from harms way is a good thing? Even it means their job is lost? People can be retrained, reanimation is a bit much.

These are very hazardous work sites and these vehicles are bit unforgiving. The day we don't send people down in mines will be a good one, if it starts with the trucks up top then so be it.
As a newer HN user I was surprised that there are no comments on job postings. I've also noticed some interesting posts and think there could be some constructive conversation around them.

I can appreciate why there are no comments but also I think it would be interesting to allow direct feedback to job postings.

Anyone else ever thought this, too?
But you knew right then that you were going to implement the other two classes, and that you would need the code. It's not like you aimlessly added abstraction to cover your lack of design and grasp of the problem space--you had done some back of the envelope design and knew you needed it.

That's not premature at all.
Maybe it shouldn't be seen as a hard rule but as some heuristic in the back of your mind, to avoid over-abstraction, digression and never-shipped depression. A counter-balancing notion.

And most of the times people mean YAGNI for the first expression of need-vs-implementation. Surely they know there's a lot of chance that one will need more solid abstraction, but it's just to avoid digging too deep into the wrong hole. Somehow it's like http://en.wikipedia.org/wiki/Simulated_annealing . Avoid being stuck in a local maximum.
Thanks. This is why I posted this. Not everyone's office is full of kernel hackers. In real life, most security is grey.
What is really dishonest is not having an option to downvote a job ad.
9 In 10 New Drugs Are No More Effective Than The Old Ones
To be fair, he insists on his site that he was not lonely or depressed. It seems his motivation for suicide was that he found the idea of growing old and incapacitated to be the scariest thing he'd ever imagined, and he wanted to end his life before that happened, while he was still able to do so. He mentions he'd planned this out since he was young, but didn't put a date on it until a year or so before he committed suicide.
And truck designing ones. The moment you get rid of the driver you can go berserk with innovative designs.
Is it possible to use them in zero ? because ksr2's comments tells otherwise.
I don't get it - is the unit cost per driving system cheaper than the cost of one human driver? Surely in a huge operation like that, the costs of operating a giant multimillion dollar vehicle could also include the salary of a driver?
Plus, the generic behaviors of a Pet (say, life and death), are all logically separate from dog specific things. Even if the world only contains dogs, having a Pet class might lead to more organized code.
It doesn't really matter how you call it. There are more important things people need learn about.
Same here. It was a tweet about my typo from "python" to "pythong"[0]. Every few weeks I would get a random favourite from a plausible sounding name. They're all bots

[0] https://twitter.com/chewxy/status/333827059908497409
Reddit allows users to comment on ads.

99% of the time it doesn't go well, especially if they are being dishonest.
This brings back to my mind the popular blog post by Aaron swartz: Fix the machine, not the person : http://www.aaronsw.com/weblog/nummi

I personally think only few people can be fixed, those who are very intelligent and who know how to get over human nature and their cognitive biases.
The graph of gainful-employment vs. technological-efficiency is not linear. It first increase, then has a hump, and goes down from there.

Eventually you get two groups -

A few highly skilled and specialized people that design, maintain, and improve the automated systems.

A large amount of unskilled workers, who are nothing more than "replaceable units", that get told what to do by those systems.

And that does not even attempt to even show the amount of unemployable people that would be around from all the human jobs lost in the first place after the hump. Just think of the fast food industry, and how technologic improvements would "disrupt" it (by removing the work force). And then who do you sell the product to? The person who does not have a paycheck?
> seeing a piece of code that was specially written for a very narrow and specific use case, and needing to extend it to some scenario that the original author did not envision

There's pain in both options: making something specific that has to be made more general later, and making something overly general and never actually having a use for the additional complexity.

The former, though, is solving problems you have, and the latter is solving problems you often don't end up having. Given the choice, I would always prefer the former.
How groundbreaking is this? On that note, what is the state of the art for brain-computer interfaces, invasive or non-invasive, with which the user can actually input data into a computer?

As far as I understand the method described in the article, it could eventually be employed as an alternative to eye tracking for computer input, i.e., instead of determining what letter the user's eyes are looking at by using cameras pointed at their face and computer vision you would scan the user's visual cortex directly. One can immediately think of applications this would have even outside of the assistive technology market, e.g., for mobile input.
seems like this worked, being at the top of HN and all...
> The author's example is particularly poor.

I thought the author's example was reasonably good, but it doesn't capture the spirit of YAGNI as I see it.

Instead, the way I'd phrase it is: we're introducing pets to Minecraft. For now, this means a dog. Maybe we'll add chickens and cats later, but our first release of this feature will only be dogs. I could create a Pet class and a Dog class that inherits from that, but maybe we won't. Creating a class hierarchy is only going to slow me down for now, so I'll skip it for now and just create Dog.

Fast forward a couple months, and the feature is a huge success. But, instead of an interest in cats, the users are now clamoring for different breeds of dogs. Good thing I didn't waste time creating a class hierarchy rooted at Pet, because then I'd have to juggle Pet -> Dog -> {Shiba Inu, Golden Retriever, etc.} (although I'd personally implement dog breeds with new attributes on Dog, but you get the point).

Or, the feature is a flop, and is going to be cut. Good thing I didn't spend time implementing a class hierarchy because that would've been even more wasted development time. I'm glad I got the feature into market as quickly as possible to validate it.
By real concurrency he clearly meant CPU concurrency.
I think that's a decent format (assuming the startup is launched), but it doesn't encapsulate the spirit of some jobs. For example, I actually like posts like the following (right now the 2nd post on the board):

Help us build the mobile app farmers really want
https://news.ycombinator.com/item?id=6266489

It intrigues me a lot more than "FarmLogs (YC sXX) seeks iOS developer". If that was the title, I might think it was some stupid iphone game and ignore it.

But if you click on it, it's a really interesting startup that could help a lot of people not normally helped by technology.
Actually it is important to learn about, because it's possible to do parallelism without bringing in the issues of concurrency (non-determinism, synchronization) and thus write code with less potential for serious bugs.
Dear Prime Minister Cameron
> "YC companies have totally lost focus they are now just broadcasting."

This is unfair. There are a lot of YC companies and many do write clear, informative ads.
It's especially amusing considering that actual "merit" is usually the last thing I think of when I see people at the "tip top of success" like Ballmer. Very few of these people did much more to merit their success than anybody else in the industry they're in, in terms of actually doing quality work. Most of the "above and beyond" effort they put in is related either to simply being part of the relevant 'old boys club'/coming from wealth already or else engaging in the kind of backstabbing and negative competition that MSFT's stack ranking encourages.
well what if it's 20% of the National University of Singapore? That's not exactly a big name school in the Bay Area. (By now I have an idea which company this is)
Although I am one to also ask from time to time for links or citations I think that in this case this is clearly one persons opinion as opposed to someone saying "it is well known that dishonesty sells and that all large mega corporations get to where they are by.." [1]

As far as "dishonesty" in business that is determined many times by when the consensus actions of a particular industry is. Behavior in one industry in many cases means you have to play the same game or perish. Each industry works differently.

[1] Add: In which case a citation would be appropriate.
I was nodding along, but man was that example painful. I'm sure that it was in good effort...but it really didn't do justice to why YAGNI is bad.

I'll bite: it's really terrible for security purposes. Aside from the typical YAGNI feature examples, there's plenty for application maintenance and back-end development.

Let's say you have a database with several layers of privileges. You frequently have to perform actions that require higher privileges than that user has, and you're a lazy dev. So you try to automate this process by adding further code to your system design, expediating the entire process at the cost of some authentication.

Bam, huge red flag and a half. Yes, you can have this and defend it at the same time, but in most cases, it's silly to try. Adding code just adds another vector and a half.

That said, yes of course adding features you don't need will bloat the system. But that pet example kinda sucked, I'm sorry.
HN is, at least in theory, a place where being polite when giving feedback is the norm. Reddit, on the other hand, is a place where humour and rudeness is not only expected, but wanted by the majority.
I think I've seen a reddit ad upvoted once, maybe twice. The vast majority of them (even when they seem like the hivemind would like them) are downvoted. It's strange.
Your code shouldn't be designed to reflect what you believe is going to happen to the program eventually; it should be designed to fit the requirements as they are right now. If a Pet class makes sense later on, add it later on.
Comments are off on job postings because they tend to become a running critique of the company or product doing the posting.
This is one of the best presentations I've ever seen, especially considering the subject matter. Incredible.
I've worked on some big, mature code bases, and I've always appreciated it when other people believe in YAGNI. It tends to result in relatively simple code with just enough complications to support the features which actually exist.

In theory, it would be nice if the code included appropriate hooks and abstractions. But in practice, it's often quite hard to guess where those hooks should be, and which aspects of the code should be abstracted. And since the abstractions are based on hypothetical designs, they're very often useless.

Basically, I'd rather maintain over-simplistic code that implements a few features well than code that has been prematurely generalized to support half a dozen features which don't exist yet. All too often, the generalizations are wrong, or simply get in the way of other features I'm trying to add.

Unfortunately, YAGNI is one of those rules that requires common sense to apply well. It works best as a sanity check for an already-experienced programmer: "Really? Do I actually need a whole new set of abstract interfaces here? Or can it wait?" If a programmer is totally lacking in taste and judgement, YAGNI won't save them by itself.
According to wikipedia:

In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other.

But it doesn't really matter, what matters is whether people understand each other, not whether they're using the "correct" words.
Sure, sure, but A/B testing the feature is going to be hell of a lot easier when you can easily switch out dogs for cats for chickens for optimized dogs.

You don't want to get stuck in a local design minima. Adding a class hierarchy here would've been basically free (subclass overrides for two or three behaviors, tops).

Again, there are good examples out there of when YAGNI is important--this wasn't one of them.
When’s Om Malik Going To Stop Hating On Yahoo?
This sort of reminds me of Minimum Viable Product methodology (MVP) but I think YAGNI is at a later stage in the development cycle.
Make sure to click the "play" button in the header for the full experience.
Here's the other side:

https://news.ycombinator.com/item?id=6269281
God I love reddit. Nothing warms my heart as much as an angry anonymous mob full of inside jokes and puns attacking idiocy in advertising.
I think this is second or third such video of a heavenly body colliding with the sun that I have seen. I am a bit curious why the impact from one side of the sun (which is diametrically huge in comparison to the incoming projectile) pushed out a large flare or material on the other side of it?

Is sun just a ball of liquid+gases+plasma or there is a hard solid core in the middle of it? For if there was a solid core at all, or even a molten inelastic core, then perhaps the emission on the far side wouldn't have been this big. To me, the the ejecta on the other side is almost equal to the splash on the side the comet hit.

Any explanations?
Pretty much, it's just some small unimportant technical detail.
An open letter to David Cameron from Nordic editors
The salary of the driver is mostly inconsequential - in Western Australia, they have trouble getting people out there for any price. So autonomous trucks are good because they solve the risk and delay associated with finding an operator.

Autonomous trucks will get to the stage where they simply don't stop. Human operated trucks need breaks, and make mistakes. So it doesn't matter if they cost more - they also produce more.

Finally, autonomous trucks don't cause OH&S incidents nearly as easily. This is a huge issue, especially for a company like Rio Tinto. In Australia at least, OH&S issues can shut mines down. This alone would probably be worth any price premium in the million dollar order of magnitude.
It's not a single click. They have to go into Settings, find the passwords section, open that up, find the password they want, and click show password for that entry.

That's not "browsing passwords". That's clear, malicious, intent. It's like someone in your room looking at the bottom of your underwear drawer for secret items. Chrome is in no way popping passwords up in front of friendly unsuspecting visitors.
Donated Space Telescopes are Remnants of Failed NRO Program (2012)
Ah, I would love to work on such projects. What is a real barrier for me that most of these jobs require US citizenship or permanent residency, which I don't have the luck to show. I do understand that these are strict requirements because of the export control laws. Since you are in the industry you might know if there is any place where you can work on autonomous vehicles without being a US citizen. Maybe somewhere where they work on civilian applications? Or a comparable lab/company in europe?
I divide YAGNI into two cases: security and bloat.

Bloated features are what you just described - more often than not, it's unproductive to code in extra things you don't need on a deadline. You can better work elsewhere. And yet, I think you're right, a lot of developers who will eventually need/want what they're putting in later anyway.

On the other hand, YAGNI has significant security implications. I posted a example downthread about how a database could be compromised by adding in a back-end feature for lazy admins. In that case, YAGNI is really something you want to avoid.

A lean system is an easier system to plug up. But I also understand that's a bit outside the scope of strict features.
You're the one using the wrong words: actual experts on concurrency and parallelism disagree with you:

http://existentialtype.wordpress.com/2011/03/17/parallelism-...
http://blog.golang.org/concurrency-is-not-parallelism
http://ghcmutterings.wordpress.com/2009/10/06/parallelism-co...
Automated attacks will rapidly adapt. There's zero barrier without some OS-provided sandbox mechanism. For instance, something that verifies the signer of the executable before providing a key. (That doesn't exist on Windows, for example.)
"because they tend to become a running critique of the company or product doing the posting"

Why do they feel that is bad? And have they ever been on on HN job postings (if so how long ago)?
I think we are forgetting that the point of the law is to protect people. If a bunch of people do want to be lawless in the drugs and public urination sense, but go out of their way to do it in an isolated, out of the way place, then I support them 100%, and think the police and law should stay away. "Lawless" is not a dirty word in my mind when the laws are wrong.
I think that in this case this is
clearly one persons opinion

Agreed, but they should've phrased it as such as opposed to stating it as fact. I appreciate that your reply included "I think" :)
Please explain the exact algorithm that the browser stores encrypted passwords and needs a master password before showing, but can "remember for convenience".

Or do you mean that it'll prompt people for a master password for uncommonly used sites? Because that's just going to lead to people forgetting the master password and having to do a password reset.
Learning the difference between c. and p. won't help me write less buggy software. And I think there's no clear consensus what exactly is the difference.
I've worked at Microsoft, so maybe I do know what a slow-moving BigCo is like. Yet for all the cruft I did see, I never once recall thinking, "if only these people had YAGNI..." Usually the problem was just the opposite, that something was built that was overly specialized and not re-usable and somehow managed to spread its implementation details all over the place.

The factory-factory-factory example reminds me of a certain brand of OO spaghetti, very typical of people who are applying ideas from OOP but don't have a firm grasp of what problem those ideas were meant to solve. I see that problem as distinct from YAGNI, it's just a problem of bad design.

My own advice would be: it's fine to make some shortcuts in the interest of productivity, but please try to keep them isolated. The details of your shortcut shouldn't leak heavily into your design, and the next person to maintain it should be able to swap out pieces without fearing the rest of the thing will fall over.
In terms of physical constraints, Ming Thein says that a mirrorless camera is easier to take with you all the time. The Olympus EP1 with a pancake can be in shirt pocket, which means you can take a picture anytime, whereas a DSLR requires a camera bag, a solid back that requires strong will. So physical constraints definitively encourages photographers to take mirrorless cameras, which give the quality of regular SLRs in compact camera format.

In terms of the aesthetic differences of larger sensors, he doesn't negate that SLRs will disappear. If you want the maximum quality, and can put the time to prepare, than getting an SLR like Nikon D800E with a great lens makes a lot of sense, with a full-frame aesthetic. Expect though that most of the work produced could be from a smaller Olympus or Fujifilm camera.

Cheers,
Y Combinator is a business...
do you have any links to pictures taken with the 1020? Thanks
Oh, so this has beed tried before?
Once upon a time I had the notion that "founding armies" always had an edge over the rest. Alexander -> First army of unified greece. Early Rome. Napoleon -> first unified French army. Bismarck -> first unified German army. Union. Japan in 1905. Red army in russian civil war. US in WWII was still somewhat army of immigrants. Thanks to this article, I can put a name to this effect.
Wait for the new Olympus EM1 - it has full PDAF
In the bad old days, 1976 and on, we used this: http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th...

Unfortunately it was essentially samizdat until 1996. But it's an excellent work, and e.g. taught me pointers when the K&R chapter on pointers and arrays didn't work for me.
The example stated "when we add chickens and cats", not "if we decide to add chickens and cats". It was clear that the requirements at the time included 3 types of animals--if it wasn't clear, you should've written the spec better.

Look, I'm on your side about YAGNI and shipping products not code and whatever other stuff we probably both genuflect at. I'm actually dealing right now with a lot of fallout involving overengineering a project when it should just be kicked out the door and set to work.

That all said, too much shoddy engineering and cowboy-coding is done with YAGNI given as a hollow excuse. There is a lot of pushback on doing upfront design work, but even a cursory consideration of the problem domain and code structure will oftentimes yield better code that otherwise would've been ignored under the banner of "we aren't gonna need it".

EDIT:

Hell, I'll take it one step further: when developers do decide to be lazy and claim YAGNI, they often aren't lazy enough, and instead write hacks that are too large to just get something done. If you are going to half-ass something, by God, half-ass it all the way.
Oh? Then why don't they say anything in their posts that disagrees with my view on the subject? (Hint: You're replying to the first comment I made in this thread, so the idea that I used the words "concurrent" or "parallel" in any particular way, much less wrongly, is objectively incorrect.)
Ask HN: Google API billable limit increase?
Has anyone on here EVER manage to get this increased whether it be for the custom search API or another product.

We're hitting the 10k limit on the custom search API everyday and have filed a request to increase every other week for the last 2months. As of today, we're still yet to hear back from anyone at Google.