There's an over-abundance of information. All that's left for HN is angry, emotional quibbling by those who lack the basic qualifications to evaluate the data and science, even if they were interested in actually doing so.
The comments I've read so far present interesting POV's backed up by data and observations. I don't see how that qualifies as "angry emotional quibbling".
I don't see the problem with discussing science either. Newton's law of gravitation has been around fot 322 years, and it has been shown to be just a very good approximation (like everything else in science). Also, it is still an open question (AFAIK) whether it holds at very small distances. Climate research is not physics. The number of variables and the complexity of the system is of such magnitude that I am pretty sure there will plenty of room for scientific discussion for years and years to come.
("Hacker News"? This particular little niche website is fast becoming Wall Street Blog West. People who came for the tech are leaving because of the increasing emphasis on how to make a few fast buck any old way.)
I agree. I found it depressing that your comment was down-voted to the negatives.
As a long-time San Francisco resident I found it irksome that Alex was so quick to bemoan the lack of culture to consume without showing any possible interest in creating any.
In my opinion, San Francisco is a beautiful place for creators.
Well it's particularly odd because he claims he received a lot of feedback from other SFers who all see the same issues as he does and are equally fed up.
I say it's odd because the startup culture is be all about opportunism.
Is accountability/sane governance that intractable of a problem that people would rather move than meet the demand?
Where did I claim otherwise? I only noted that his suggested approach -- which is clearly reflected by 37signals -- has led to me maintain a lower estimation of their decorum and the value of their positions.
The submission title is a direct quote from the article: The decline of the MBA will cut off the supply of bullshit at source
Second, this article has the facts wrong. MBAs from top schools aren't having trouble finding jobs, nor have those jobs started paying way less.
I don't have the statistics to support or refute this claim, but the article discussed a massive glut of graduating MBAs, not just the top of the class from "top schools". I'm not sure if you actually read the article, or simply penned a knee-jerk defensive response to the harsh wording.
Testing can verify that your software works within the space of behavior that you already know about. It can't make up for your failure to understand the problem fully.
Thinking about correctly testing software is generally one of the best ways to improve your understanding of the problem.
I quite often find bugs during unit testing simply because I'm forced to think about how the software will break, rather than thinking about how it will (or should) work.
I think of it as being quite similar to waiting overnight to proof-read your own paper. You need to be in the context of the reader, not the writer, or your brain will skim over most mistakes.
Sure, writing tests can find design bugs. But that's not really the question at hand here. The specifics are that we have a clear and obvious requirement ("torpedo should self-destruct if it turns a full 360 degrees") that turns about to be missing an important point ("EXCEPT IF IT IS ON THE BOAT").
No amount of testing the former will lead you to realize the latter. Sure, you might happen to come to the realization while writing the test, but you might do so over breakfast too.
I'm not saying "don't do testing". I'm trying to point out that it has limits. The fact that you've written tests and they pass doesn't get you off the hook for design bugs.
I think his point is that the test itself isn't the useful bit. The useful part is that thinking about what to test can uncover bugs.
This is what FMEA (Failure Modes Effects Analysis) does: you assume failures of every part of the system, rank their likelihood and the end effect and see how your design handles it. A good FMEA assumes everything will fail and analyzes the impact. Unfortunately, comprehensive FMEA is expensive and time consuming so it's usually only done for critical subsystems.
No amount of testing the former will lead you to realize the latter. Sure, you might happen to come to the realization while writing the test, but you might do so over breakfast too.
You're a bit more likely to do it during a time you've set aside to fully consider potential failure scenarios.
I guess I can't argue with that, as it's essentially unfalsifiable. But it's worth pointing out that writing a unit test, which is the subject that started this discussion, is definitely not a time when you're "fully considering potential failure scenarios". Unit tests are narrow and focused, and aimed at verifying features.
What you're talking about is something I'd call white box QA. Which is valuable, though it's essentially just an extension of design, and has the same limits.
My broad point still stands: you can't "process" your way out of this with extra testing. Some bugs are just inherent, and stem from the fact that we're human.
Unit tests are narrow and focused, and aimed at verifying features. What you're talking about is something I'd call white box QA. Which is valuable, though it's essentially just an extension of design, and has the same limits.
It seems like most negative arguments regarding "unit tests" start by defining them as a small subset of what can be usefully tested, and then arguing against the value of testing such an incomplete subset.
I don't see the point of drawing such an arbitrary line. I leverage "unit" tests to automatically test units of code as completely as possible (not just 'verify features'), and I expect the same of tests that others write.
They have a restriction on taking pictures of things you shouldn't (which includes most of the campus), but they don't have restrictions on cameras.
In addition to there being no written rule against it, I've openly and regularly hauled digital video and still cameras across campus without ever hearing any complaint from the omnipresent security guards.
How do you think people work on iPhoto/iMovie/FCP? Check out cameras from a locked facility?
Even with the government: you don't have to obey laws. You can go live in jail. There's always an alternative option. Freedom is about having fair options.
I hope not. Between Protobuf and Thrift, I don't see the point of adopting a less efficient, even more niche NIH serialization format and RPC protocol.
Might be different if there were already numerous libraries that supported it but honestly if the extent of it is support in four languages (plus a few more that support the serializer) it's probably not worth wasting the effort unless it differentiates itself substantially from the existing solutions.
Both protobuf and Thrift are designed exclusively around simple static type-checking with type-erasure. Neither support heterogeneous collections, much less discriminated unions or GADTs.
There are plenty of untaken vertices in the serialization-format hypercube.
Heterogeneous collections, discriminated unions, and GADTs can be implemented easily in either thrift or protobuf by leveraging inclusion of custom type-tagged messages/data.
However, while the encodings are absolutely sufficient to represent these data structures -- if you so choose -- my experience dictates that keeping serialized messages typed and as simple as possible is advantageous from the perspective of long-term maintenance and interoperability.
