Show HN: Upboat, idea validation with a twist - <AUTHOR> http://www.upboat.us
Demo: http://www.upboat.us/idea/upboat Screenshot of logged-in view: http://i.imgur.com/vUZXfZc.png
Upboat is an idea validation platform, somewhere inbetween Kickstarter and LaunchRock. If the idea you pitch receives over 200* "upboat"s (consented would-be users) within one week, you get the whole emailing list of all those who upboat'd it. If not, you get nothing. This is helpful for those who have ideas for side-projects, but lack the strong-enough incentive to get to work and just hack something together. Should you put up an idea you came up with, and in a week it gets enough upboats, you have a 200-strong user incentive to get to work. If not, then not a big deal.
You can upboat an idea as an potential user of the service, a potential developer of the idea (github auth'd), and/or as a potential investor in the idea (angelList auth'd). No commitment--just the chance to chat. This hopefully provides a stronger social proof scheme than a landing-page-captured email count.
* In the future, I'd prefer this to be 500 instead of 200.
Backstory: I built this at the Angelhack Silicon Valley hackathon this past weekend in 24 hours of maddening, restless typing. Granted, I was also "in the zone" for most of it. In past Angelhacks, I've done silly things like single-handedly build and present 3 different hacks (drives the judges nuts), but this time I decided to go for one production-ready hack (we'll see if I'm right). Upboat came out of it, so please, if you can contain yourself, don't mind the sloppiest code you'd ever laid eyes on.
I'd love to get some feedback, but I'd love even more to get enough Upboats to keep working on it :) <comment><USER2> On the registration popup, it says 500 users required.

I had nearly this exact idea before. Actually that's where my username Avalaunch comes from - "launch your new idea with an avalanche of support". Thus far I haven't followed through with the idea because I don't think it provides enough value to the would be early adopters.

Two suggestions:

1\. Let the idea author dictate how many users are required instead of setting an arbitrary number. For some ideas (new dating site), 500 isn't nearly enough. For others 50 would be plenty.

2\. Set it up so that the idea author is encouraged to give something to the potential users for upboating an idea. Ie. "First 3 months of service are free for all upboaters".

Good luck! I'd be interested to hear how it turns out for you.

EDIT:

Suggestion 3. Add login by Facebook. I know most of HN hates it, but I hate filling out forms more.

EDIT 2:

The develop upboat is a really cool feature that I hadn't thought of. Maybe add a designer upboat too? Or ideally, let the idea author determine what kind of upboats he's looking for. Maybe I have a great developer but I really need a salesperson.

<comment><USER3> Interestingly I was working on this as well. It was called "should I Build it?" and the idea is if enough people vote YES (you decide how many people are enough), then you build it.

Two Additional Suggestions:

1\. After the potential user votes "yes" or "no" allow the idea author to collect feedback as to why they voted the way they did. (customer development built-in). This will provide some great insights into what's valuable to your prospects.

2\. Secondly it will be more useful to allow the idea author set this up on their own domain and be able to add their own styling to the page because most of the traffic the page will get will be from the idea author's network.

I don't see myself as a user, coming to your website to look for ideas to support with my email.

Finally how do you plan on monetizing this app? This is the chief reason I dropped the idea which is probably short-sighted but it'll be interesting to see how you go about it.

Good Luck.

<comment><AUTHOR> 1\. Good call. 2\. A widget is an awesome idea. Move aside, LaunchRock! 3\. You're the man. Thanks!

Monetizing? Apps aren't expensive, and if it provides value to a community I certainly wouldn't mind not-charging for it. It took me 24 hours to build, and hopefully not a year of labor to maintain. If I can break even, I'd be happy. Otherwise, selling contact info of idea authors who've collected unreal amounts of upboats to investors seems like it could do something, granted I gather the consent of all parties involved.

</comment></comment></comment><comment><USER4> I think your github oauth request is a bit broad:

        The app Upboat will be able to:

        * Read your public information.
        * Read your private email addresses.
        * Update your public and private repositories (Commits, Issues, etc).

I'd like to register myself as a dev, but I'm not going to agree to those terms. No offense, but you need to do a lot more to justify why you want write access to my github account.

<comment><AUTHOR> I just need enough permissions to know that you have > 0 repos, public or private. I didn't see anything between just-email and all-the-things in their oauth docs, but I might've missed something while rushing through. Do you know otherwise?

<comment><USER4> No, but even read only access to private repos is a problem. A lot of that code belongs to my employer and I can't in good conscience grant access to it even if I want to.

I'm not sure why having an empty account is something you care to filter on. If someone really wants to pretend to be a dev, forcing them to click "Create new repo" before they sign up isn't going to provide much of a barrier. You're already basically taking them at their word so I'd recommend just dropping the requirement.

<comment><AUTHOR> You, sir, are the voice of reason. I'm pushing an update now that removes those conditions.

</comment></comment></comment></comment><comment><USER5> My first reaction was that this is creative and interesting. Impressive that you did it in 24 hours.

The validation use case for Upboat makes sense... but it seems strictly weaker than, say, Kickstarter for validation. Emails mean much less than payments; you could get 1000 emails but then have a low conversion rate on that. If you did the same project on Kickstarter, you'd either fail to reach your goal or reach the goal and have validation that N people want it enough to pay for it. Upboat would be good for checking interest in FOSS projects or something, but then what is your plan to monetize it?

<comment><USER6> Could also extend it to include a charge for the first month's usage.

Once the requisite number of upboats is met, the funds can be transferred to the idea holder, less a clip of the ticket.

This would also improve confidence that the validation is genuinely representative of user willingness to spend money - if I get 1000 upboats for a new service, but I plan on charging $49 a month for it, I still have no idea if I've validated people willing to pay $49 for it. Pledging that money and then collecting it at goal reached (Kickstarter model) would help alleviate this, and I think make for much more compelling investor discussions.

</comment></comment><comment><USER7> It's awesome that you've actually taken action on this as an idea rather than just talked about it. (Like me)

I posted a similar idea, amidst several other ideas here that I welcome any and everyone to steal/modify and use for themselves. (Though I won't refuse equity)

[http://lesswrong.com/lw/e26/who_wants_to_start_an_important_...](http://lesswrong.com/lw/e26/who_wants_to_start_an_important_startup/78d2)

Message me here or at www.Facebook.com/AltonSun since we probably have some mutual friends if you're interested. (Directed towards everyone since I already know Michael as an awesome hacker that consistently cleans up well at top hackathons in the Bay Area.)

Your idea is better than mine for a couple reasons: 1\. It's hard to measure whether someone really fulfilled your wish 2\. Lower barrier to entry and simpler with just emails, you can reasonably charge the poster some nominal fee rather than the upboaters to keep noise to signal ratio low

</comment><comment><USER8> I'm just curious what the user's incentive for using upboat is?

Edit: I mean, I'm not a startup owner, but I visited the site and couldn't figure out why I would want to do this, rather than just wait until the product actually comes out.

<comment><AUTHOR> I'm not sure what angle you're asking this from--the originator of the idea, or someone who might want to use a service?

Regarding the former, that's answered in the OP, so you probably mean the latter.

A) Why do you browse HN? I will assume here that it is because you want to keep up with hacker news. Another possibility is that you want be stimulated/inspired by interesting ideas and premises for startups. While the traffic and postings on Upboat thus far haven't been overwhelming, I've enjoyed reading people's ideas and commenting to probe them deeper about them. It keeps me on my toes for ideas I might have in the future. It also gives me the chance to become an early adopter/user of a service I personally find impactful and needed. I get to be a part of that, if other Upboaters agree.

B) The social aspect to Upboat lets me see how people I follow are upboating. This eases the friction of finding potentially great ideas I would like to upboat for the reasons in A. Although the follower/followee social network thing is overplayed and contrived by now, I feel the social filtering it provides is a compelling reason to stay active and upboat ideas I find valuable and want my followers to take a look at.

<comment><USER2> I think what revx may be alluding to is the fact that you're currently selling more to the person with the idea instead of the idea backer. Your home page is a good example. It asks "Is your startup idea valid?". Contrast that to IndieGoGo's home page which says "The world's funding platform. Fund what matters to you." or Kickstarter's which encourages you to "Discover great projects" with the goal of "Bringing Creativity to Life".

You're clearly solving a problem for those seeking idea validation but are you also solving a problem for those willing to give validation? Both KS and IGG do a really good job of tapping into a very visceral desire to help others succeed and to be a part of something bigger than oneself. If you can do that with Upboat you'll have a winner.

<comment><AUTHOR> Have an HN upboat, sir. I think you hit on a point I wasn't even thinking nearly enough about. I naturally enjoy hearing out ideas and knowing my feedback is heard, but I overlooked the possibility of that being uncommon. Light incentives (specialty accounts for early adopters) might be in order per the kickstart model. Thanks!

<comment><USER9> While I totally agree that you'll need to incentivize the potential users to use your app, I think that right now you've subconsciously taken the right path. To attract the users you need sufficient number of interesting ideas to show to them. That's why targeting the entrepreneurs,developers and designers (as someone brilliantly suggested) is a way to go for now imho. After that you can focus on implementing changes aimed at acquiring "normal" users. And that can be a real challenge. The perks/benefits seem to be already proven solution. I also thought about turning the "upboats" into some kind of game of prediction - can the user guess which idea will take off? Something like here: [http://www.upboat.us/idea/c4861c9bf49ce663](http://www.upboat.us/idea/c4861c9bf49ce663) ;)

</comment></comment></comment></comment></comment><comment><USER10> Congrats on shipping! However:

You don't prove the validity of a startup idea by asking a community of startup enthusiasts whether they think it's valid (except if it's an idea targeted to startup enthusiasts).

It's the same as getting validation from your friends and family: next to worthless.

People who make up the Upboat community and the potential customers of your startup idea are very probably different. And they're going to have wildly different opinions on the validity.

What you should find out is whether your potential customers think it's valid.

<comment><AUTHOR> It's not a simple "yes, it's valid". It's a "yes, I like it, and if you make it, I'm going to be among your first users." And suddenly, it's built, and 200+ users auto-appear.

</comment></comment><comment><USER11> Clickable links: [http://www.upboat.us](http://www.upboat.us) Demo: [http://www.upboat.us/idea/upboat](http://www.upboat.us/idea/upboat) Screenshot of logged-in view: [http://i.imgur.com/vUZXfZc.png](http://i.imgur.com/vUZXfZc.png)

</comment><comment><USER11> Nice looking site. My biggest nit-pick with any site is that I don't want another account on another site. So either FB/Twitter/GitHub/Persona/Google sign-in would be fantastical.

</comment><comment><USER12> I just signed up for an account and posted an idea! As a developer, I think this is a great tool to get users before deciding to sink into a project that might never see the light of day

</comment><comment><USER13> Love it!

Suggestion: It is very rarely a good idea to open links in a new window/tab. Please remove target="_blank" from your 'Popular and New' links.

<comment><AUTHOR> You got it!

</comment></comment><comment><USER14> I had a similar idea a couple of months ago, but the issue I found with it is that a virtual "vote" for a product is borderline worthless. When an idea is funded on Kickstarter, people are putting real money on the project, something they do not want to part with unless they feel they are getting something of equal or greater value back.

Either way, all the best to you, and good luck.

</comment><comment><USER15> The design could use quite a bit of work, but other than that I think it's a pretty solid idea! :)

<comment><USER16> Agreed -- but for 24 hours, the design is pretty good too!

</comment></comment><comment><USER17> very interesting concept. The karma based version at [http://firespotting.com](http://firespotting.com) gets many good ideas. The validation and user base is a good value add.

<comment><USER18> I would love to be able to drill down and monitor both [http://firespotting.com](http://firespotting.com) and [http://upboat.us/](http://upboat.us/) via [https://lobste.rs/](https://lobste.rs/) style tagging.

<comment><USER19> seeking a lobste.rs invite.

<comment><USER18> Hey puneetsmail, just saw this. You still seeking?

<comment><USER19> Yes please. firstname.lastname@example.com

</comment></comment></comment></comment></comment><comment><USER20> Who's benefiting from not releasing contact information until a certain threshold is met?

<comment><AUTHOR> The users who are upboating. Do you want to be one of 5 supporters, and then get emailed to use a product with just the other 4? If it doesn't reach 200+, there's also somewhat more incentive for the author of the idea to use the emails for other purposes than the posted idea.

</comment></comment><comment><USER21> How ironic is it going to be if your app doesn't get 500 supporters on your own site?

<comment><AUTHOR> It probably won't at this rate, TBH. But as of now, the only way to find out is to launch.

</comment></comment><comment><USER22> Maybe have a requirement that at least a site/mockups be made?</comment>


Do you track time at your job? If so, how? If not, why not? - <AUTHOR> Previously at my job we didn't track task time, but that has changed. We don't bill hourly, but per project & we have a project management system. However, now we are required to track time per task, our internal morale has fallen through the floor. Is it a good idea to track time if we aren't billing hourly, or is there a method to track time without destroying internal morale? <comment><USER2> I've been tracking time for years. I estimate how long the task should take, then add time taken as I proceed. Very useful for future estimation. Definitely helps for project management and billing. I don't recommend doing it in 5 minute steps as that gets tiresome. But 15 minute blocks seem to work out well.

</comment><comment><USER3> per task? find another job. life's too short for that kind of b.s.</comment>


A Snappier, New Look Editor – CodeSandbox - <AUTHOR> https://codesandbox.io/post/new-look-editor <comment><USER2> This update is really a ton of tiny things that improve the editor experience, but mostly it's about laying the groundwork for what's to come. Still lots of work to do</comment>


A three-page paper that shook philosophy, with lessons for software engineers - <AUTHOR> http://jsomers.net/blog/gettiers <comment><USER4> > A philosopher might say that these aren't bona fide Gettier cases. True > gettiers are rare. But it's still a useful idea...

At least as presented, I see the idea being used to do more harm than good.

Take the first example, with the form not autofocusing. We're already not in a Gettier case, because the author didn't have JTB. The belief that he caused the bug obviously wasn't true. But it wasn't justified, either. The fact that he had rebased before committing means that he knew that there were more changes than just what he was working on between the last known state and the one in which he observed the defect. So all he had was a belief - <USER2> unjustified, untrue belief.

I realize this may sound like an unnecessarily pedantic and harsh criticism, but I think it's actually fairly important in practice. If you frame this as a Gettier problem, you're sort of implying that there's not much you can do to avoid these sorts of snafus, because philosophy. At which point you're on a track toward the ultimate conclusion the author was implying, that you just have to rely on instinct to steer clear of these situations. If you frame it as a failure to isolate the source of the bug before trying to fix it, then there's one simple thing you can do: take a moment to _find and understand_ the bug rather than just making assumptions and trying to debug by guess and check.

tl; dr: Never send philosophy when a forehead slap will do.

<comment><USER5> How is it not a JTB?

Belief: The pull request broke the search field auto focus.

Truth: The pull request _did_ break it. There was an additional reason beyond the pull request unknown to the author, but that's not important to the Truth portion here.

Justified: This is the only one you can really debate on, just as philosophers have for a long time. Was he justified in his belief that he broke autofocus? I think so based on the original JTB definition since there is clear evidence that the pull request directly led to the break rather than some other event.

I think that when claiming it's not a JTB you're choosing to focus on the underlying (hidden) issue(s) rather than what the author was focusing on, which is kind of the whole point of Gettier's original cases. For example Case I's whole point is that facts unknown to Smith invalidate his JTB. In this programming example, facts unknown to the author (that someone else introduced a bug in their framework update) invalidate his JTB as well.

<comment><USER4> His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place.

What I'm really trying to say is that the article isn't describing a situation that relates to Gettier's idea at all. Gettier was talking about situations where you can be right for the wrong reasons. The author was describing a situation where he was simply wrong.

<comment><USER6> > His real belief was not exactly that the PR broke it, it's that the root > cause of the break was isolated to his code changes. This is evident from > the debugging procedure he described. And that distinction is very > important, because that detail, and not some abstract piece of philosophy, > is also the real source of the challenges that motivated describing the > situation in a blog post in the first place.

Yes, but the exact same point can be made about the Gettier case. The problem is inappropriately specified beliefs. The problem with _that_ is that it's impossible ex-ante to know how to correctly specify your beliefs.

For instance, you could just say that the problem with the Gettier case is that the person _really_ just believed there was a "cow-like object" out there. Voila, problem solved! But the fact of the matter is that the person believes there is a cow - just like this person believes that their PR broke the app.

<comment><USER7> I think I agree with the parent. While this can be made into a Gettier case by messing with the scope of the JTB (pull request broke it vs change broke it) I don't think it really works as intended by the author, and it feels like a poor example in a field teeming with much more straight forwards instances.

I can't simplify the explicit examples I have in my head enough to be worth typing up, but the gist is that I can be correct about the end behavior of a of a piece of code, but can be completely wrong about the code path that it takes to get there. I have good reasons to believe it takes that code path. But I don't know about signal handler or interrupt perhaps, that leads to the same behavior, but does not actually use the code path I traced out.

This happens to me reasonably often while debugging.

</comment></comment></comment></comment></comment><comment><USER8> I think it helps to look at the mind as a probabilistic survival engine than some truth engine.

If there appears to be a cow in a random field the odds are extremely low that someone put a papier mache cow there. If there's something that has 50 % chance of being a snake you panic and run because that's a 50 % chance of dying.

In the case of the authors bug yes the change he introduced had a good probability of being the cause. However he could have increased the probability by going back over commits and confirming that his exact commit introduced the bug. Now the probability goes even higher. But it could still be machine specific a cosmic ray or whatever but the odds are over whelmingly low.

In practice causal reasoning also works in a probabilistic fashion.

I have a simple model saying that if a planes engine is on then it's flying. Its a single step probability and so it's not very accurate in the real world.

I do a bunch of experiments and say a plane is flying if the engine is on and air is going over it's wings faster than a certain speed.

Now we have two correlations connected by a causal model that works in many other cases. Hence the probability of it being correct rises.

But at the same time we should never mistake direct correlation for causality. But in daily life it's "good enough".

<comment><USER9> This is an excellent comment - I'm just disappointed you managed to say it all without the word "Bayesian". The base rate for paper mache cows in fields is very low - one is perfectly justified in assigning a decent probability that a field contains a cow, if one sees a cow-shaped object in it. If you are in a part of the world that has a lot of cows in fields, you will presumably assign an even higher probability. You might even say you're "sure" there's a cow in the field, and act as such for everyday purposes. But don't be fooled - you're not really sure. If someone offers to bet you ten dollars versus your life that there is a cow in the field, you'll likely not take the bet.

It seems that the philosophers were grasping towards a definition of "know" that encapsulated the idea of assigning 100% probability to something, after incorporating all the evidence. From a Bayesian standpoint, this is impossible. You can never be 100% certain of anything. To "know" something in the sense of "a justified, true belief" is impossible, because a belief is never both 100% and justified.

(Note that it is entirely possible to see the paper mache cow and conclude that it is likely only paper mache and that there is _not_ a real cow in the field. Is this belief "justified"?)

<comment><USER9> I've thought a bit more about it, and concluded that while the above is a neat _answer_ , it doesn't explain the question, and [thewarrior]'s remarks were nearer the mark on that. So here goes.

It's tempting to think of "knowledge" as some relationship between the mind and a single fact. But when we use the word "knowledge", what we _actually_ mean is "an accurate world model" \- a _set_ of beliefs. This is the disconnect that Gettier cases are designed to expose - they construct scenarios where someone's mental model is inaccurate or incomplete, yet by sheer luck produce a single, cherry-picked correct prediction. We are uncomfortable calling these correct predictions "knowledge" because as soon as you start probing the rest of the mental model, it falls apart. Sure, they think there's a cow in the field, and there really is one. Ask them any more questions about the scenario though ("what color is the cow?") and they'll give wrong answers.

From this perspective, "knowledge" as a "justified, true belief" is a perfectly coherent concept - the problem lies with the inadequacy of the word "justified" to describe the output of a complex decision procedure that incorporates many beliefs about the world, such that it could be expected to yield many other correct predictions in addition to the one in question, up to some arbitrary threshold.

A thought experiment - suppose you tell the observer that the cow they see is made of paper mache. They no longer believe there is a cow in the field. Intuitively, has their knowledge increased or decreased?

</comment></comment></comment><comment><USER10> This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are:

* expected output from a known input (intention)

* unexpected output from a known input (defect)

* expected output from an unknown input (serendipity)

* unexpected output from an unknown input (unintentional)

For example I maintain a parser and beautifier for many different languages and many different grammars of those languages. In some cases these languages are really multiple languages (or grammars) imposed upon each other and so the application code must recursively switch to different parsing schemes in the middle of the given input.

The more decisions you make in your application code the more complex it becomes and predicting complexity is hard. Since you cannot know of every combination of decisions necessary for every combination of input you do your best to impose super-isolation of tiny internal algorithms. This means you attempt to isolate decision criteria into separated atomic units and those separated atomic units must impose their decision criteria without regard for the various other atomic decision units. Provided well reasoned data structures this is less challenging than it sounds.

The goal in all of this is to eliminate _unintentional_ results (see forth bullet point above). It is okay to be wrong, as wrong is a subjective quality, provided each of the atomic decision units are each operating correctly. When that is not enough you add further logic to reduce the interference of the various decision units upon each other. In the case of various external factors imposing interference you must ensure your application is isolated and testable apart from those external factors so that when such defects arise you can eliminate as much known criteria as rapidly as possible.

You will never be sure your open-ended system works as intended 100% of the time, but with enough test samples you can build confidence against a variety of unknown combinations.

<comment><USER11> How is 2 & 3 from above different from 4?

An unknown input producing correct results is still a problem - the unknown input is the problem.

Therefore, i postitulate that anytime an unknown input is possible, the software is defective.

<comment><USER12> The entire world of AI relies on dealing with "unknown" input?

<comment><USER13> I would say yes.

There's a saying that when people figure out how to make a computer do something well, that it's no longer in the field of AI. I'd say there's some truth in this, in that for many problems we have solved well (e.g. playing chess), the intelligence is not that of the machine, but of the programmer.

I think that in order for a machine to genuinely be intelligent, it must be capable of original thought, and thus unknown input. Known doesn't necessarily mean specifically considered, but that it could be captured by a known definition. As an example, we can easily define all valid chess moves and checkmates, but we can't define the set of images that look like faces.

</comment></comment></comment></comment><comment><USER14> The propensity for mistaking belief for facts certainly take daily hits as a software developer. "How come this simple thing isn't working? I thought of everything didn't I?". After a while you are forced to realize that belief isn't the same as reality.

It seems insights like this don't easily translate into other domains though, like relationships, dearly held political views etc. We prefer to think of them as based on facts, when in all probability they are merely beliefs fraught with assumptions.

Some people might be good at being skeptics in all areas, but I sense most share my own ineptitude here, the reason probably being that any such (incorrect) beliefs don't immediately come back and bite us, as in programming.

<comment><USER15> The funny thing about development is what's say 90% of the time you are convinced everything is correct and should be working and it's immensely frustrating because it's not, so you know you are wrong but are unable to offer yourself a more convincing theory and just get stuck until something clicks. But then there's that 10% of the time where you're actually right. And you don't know which one it's going to be. So you have to calm yourself down like "I know I think Im right about this but clearly Im not" but at the same time you have to hold onto that conviction because you're right damnit. Haha.

<comment><USER16> As Raymond Smullyan proved, everyone is either inconsistent or conceited.

<comment><USER15> [http://www.mit.edu/people/dpolicar/writing/prose/text/episte...](http://www.mit.edu/people/dpolicar/writing/prose/text/epistemologicalNightmare.html)

Reading this made my day.

</comment></comment></comment></comment><comment><USER17> The "cow in the field" example reminds me of two heuristics I like: am I right for the wrong reason?; am I wrong for the right reason?

Being right for the wrong reason is dangerous: it's not easy to spot, and it perpetuates false sense of security leaving "black swan events" unanticipated. This might occur during debugging as the article points out, or e.g. during A/B testing of a product.

Bring wrong for the right reason is just plain frustrating.

<comment><USER11> > Bring wrong for the right reason is just plain frustrating.

what's an example of being wrong for the right reason? I can't think of any cases where this happens...

<comment><USER18> In the context of political forecasting, imagine that you are a defence chief who is faced with an unquantifiable external threat, as the US was by Russia during the Cold War. You can predict that this enemy is a very great threat, or you can say that it isn't much of a threat, but the outcomes are asymmetric. If you say that the threat is a grave one, and strengthen your defences accordingly, then if the enemy attacks, you were clearly right to take the threat seriously. If the enemy doesn't attack, you were still right, because you can say that the enemy only didn't attack because of the action you took. On the other hand, if you dismiss the threat as insignificant, and the enemy attacks, then at best your career comes to a sudden and unpleasant end. So therefore, it is always right to over-emphasise the threats, and if you turn out to be wrong, you were wrong for the right reason.[1]

[1] [https://wiseinvestment.co.uk/news/antiques-roadshow-tony- yar...](https://wiseinvestment.co.uk/news/antiques-roadshow-tony-yarrow- november-2014)

<comment><USER11> > always right to over-emphasise the threats, and if you turn out to be wrong, > you were wrong for the right reason.

if the audience is not receptive to the concept of opportunity cost, then yes. Unfortunately, a majority of people over-estimate the need for security and thus, allow themselves to be fooled into believing that this over-emphasis, no matter the cost, is justified.

Just look at the TSA!

</comment></comment></comment></comment><comment><USER19> >> He called them "gettiers" for short. So we used to talk about gettiers all the time, no doubt in part just because it felt clever to talk about them, but also because when you're a programmer, you run into things that feel like Gettier cases with unusual frequency.

Sometimes I think that is what philosophers are doing - feeling clever - perhaps as a defense against some negative inner problem (psychology is an outgrowth of philosophy after all). The whole cow story stinks of telling someone "you're right, but you're also WRONG! Your perception of reality is BROKEN!". To me knowledge is simply having a model of the world that can be used to make useful predictions and communicate (and some other things). Aside from that, it doesn't matter if your model is "grounded in reality" until it fails to work for you, at which time it can be helpful to realize your knowledge (model) needs adjustment.

One way to resolving the authors first software issue would be to check a diff between what he committed and the previous production revision - this would quickly uncover the changes he "didn't make". This is an old lesson for me - what I changed may not be limited to what I think I changed. It's a lesson in "trust but verify". There are any number of ways to view it, but in the end we only care about ways that lead to desired outcomes weather they're "right" or not.

On a related note, I've found that software is one of the _only_ places where there is a "ground truth" that can be examined and understood in every detail. It's completely deterministic (given a set of common assumptions). I've found the real world - and people in particular - to not be like that at all.

<comment><USER20> > Sometimes I think that is what philosophers are doing - feeling clever - > perhaps as a defense against some negative inner problem (psychology is an > outgrowth of philosophy after all).

All science is an outgrowth of philosophy.

It's very frustrating when people look the obviously trivial and sometimes silly examples that philosophers use to elucidate a problem, and take it to mean that they are interested in trivial and silly things. Being right for the wrong reasons is a common and difficult problem, and some if the solutions to it a really insightful and powerful ideas.

> Aside from that, it doesn't matter if your model is "grounded in reality" > until it fails to work for you, at which time it can be helpful to realize > your knowledge (model) needs adjustment.

It might matter a great deal if your model is not grounded in reality - <USER3> are situations where that can kill you. It also seems like one of the fundamental aims of science, to have theories fail less often.

</comment></comment><comment><USER12> There's a much closer analogy from software development to the cow story. The cow story is confusing because the cow that you see (A) is fake, but the real one (B) you don't know about. So your belief is not a justified true belief because although the real cow exists, the one your knowledge refers (A) to isn't the real one (B).

An intertemporal variant of this is race conditions. There have been lots of problems of the form "(1) check that /tmp/foo does not exist (2) overwrite /tmp/foo"; an attacker can drop a symlink in between those and overwrite /etc/password. The file that you checked for is not the same file as you wrote to, it just has the same _name_. This is an important distinction between name-based and handle-based systems.

<comment><USER21> If the real cow (B) was not present, your belief that there was a cow in the field would be justified but not true. Seeing a the fake cow (A) justifies your belief that there's a cow in the field. Adding a real cow (B) that you can't see doesn't remove the justification.

<comment><USER12> Good point, I've edited "justified" to the full phrase "justified true belief"

<comment><USER21> If the belief is both justified and true, how is it not a justified true belief?

</comment></comment></comment></comment><comment><USER22> > _I could have had a JTB that the code change had caused the emails to stop > delivering, but still we wouldn't want to say I "knew" this was the cause, > because it was actually the service outage that was directly responsible._

He is wrong and this is not a gettier in any way. "The code change had caused the emails to stop delivering" is not a JTB, because it is not true. Rather it was that the email server went down.

<comment><USER23> He simply wasn't speaking with precision. If you replace "code change" with "pull request" in his statement, it's JTB.

<comment><USER22> No you're talking about the first example. On the second example he says

> _But—gettier!—the email service that the code relied on had itself gone > down, at almost the exact same time that the change was released._

So the error was caused by the email service going down, which is completely independent of the code change/pull request.

</comment></comment></comment><comment><USER24> I don't see any of his examples as Gettier cases. He thought his code caused the autofocus problem; it didn't. He thought someone else's push had broken email, but instead the service happened to go down at the same time. A proper Gettier case would be when you write code that you believe to be correct and it does work, but not for the reasons you think it does. Often this eventually bites when some edge case arises.

I run into this fairly often playing chess. I calculate out some tactic, decide it works, and play the first move. But my opponent has a move I overlooked which refutes the line I was intending to play. Then I find a move that refutes his, and the tactic ends up working in the end anyway, just not for the reasons I thought it would.

<comment><USER25> Here's an example that comes to mind:

A programmer writing a function refers to a local variable, "status", but thinks they are referring to a global variable. The code works by chance because the variables happen to have the same (fixed) value.

The variable shadowing means that the programmer could quite plausibly be confused and believe that they were accessing the global variable ("justification"). "I know I checked the status variable, like I was supposed to".

</comment></comment><comment><USER26> > _A philosopher might say that these aren't bona fide Gettier cases. True > gettiers are rare._

I beg to differ. Besides the examples in programming the author gave, I can very easily think of examples in medicine, police work (e.g. regarding suspects), accounting, and so on...

<comment><USER27> Well, why not write them down for us?!

<comment><USER26> As if they're difficult to derive on one's own?

You believe X has cancer because he has the symptoms and you can see an offending black spot on their X-ray.

The lab results say the black spot was just a cyst but X indeed has cancer in the same organ.

<comment><USER28> That sounds to me like (1) not a clear example of a Gettier case and (2) something that would, in fact, be rare.

#1 because one of the reasons for your believing X has cancer is that "he has the symptoms", which (if I'm understanding your example correctly) _is_ in fact a consequence of the cancer he actually has; so, at least to some extent, your belief is causally connected to the true thing you believe in just the way it's not meant to be in a Gettier case.

#2 because (so far as I know) it's _not at all common_ to have both (a) cancer in an organ that doesn't show up in your X-ray (or MRI or whatever) and (b) a cyst in the same organ that looks just like cancer in the X-ray/MRI/whatever. I'm not a doctor, but my guess is that this is _very unusual indeed_.

So this isn't a very convincing example of how clear-cut Gettier cases aren't rare: it's neither a clear-cut Gettier case nor something that happens at all often.

<comment><USER26> In the general case it's "I believe X based on signs that would imply X correctly, and I happen to be correct that X holds, but I misread the signs I used to come to the conclusion".

I don't think this is rare -- including in the version of my example.

The only reason there's arguing that it's not a "clear cut case" is that I mentioned seeing "symptoms". Ignore the symptoms I mentioned, as they are a red herring, e.g. seeing the mark could cause the belief alone.

Other than that, it's a belief (1), that's justified (2), and true (3) -- while being accidentally justified.

Consider the case of a policeman that things someone is dangerous because they think they seen a gun on them. So they shoot first, and lo and behold, the suspect did have a gun on them -- but what the policeman seen was just a cellphone or something bulky under their jacket.

Or the spouse that thinks their spouse is having an affair because they see a hickey. Their spouse indeed has an affair (and even has a hickey on the other side of the neck), but what their spouse saw was just some small bruise caused by something else.

Or, to stick with the theme, figuring domestic abuse, and the victim suffers that indeed, but your guess is based on a bruise they had from an actual fall.

</comment></comment></comment></comment></comment><comment><USER29> I can imagine a future where what's true generally describes itself (like terraform on drugs for software :p) Imagine software that is fully self descriptive and would no longer require engineers to individually interpret what's happening because the software would tell us. The system would be a graph of every single component and all possible connections between them, and all variants of each component and state that it could be in. When we introduce a change we would be aware with perfect information about the affect to the states and the paths between them.

In the example the Mental Model was at a level too shallow, it should have only affected the paths between the autofocus and the user. But the bug necessitated a larger mental model (the author was considering too small subsection of the graph).

I'd hope in the future we could reach a state where the program could have detected that the frame refactor would have an affect on the autofocus and all other components instead of being an implementation detail.

</comment><comment><USER30> Although many folks have raised the "not Gettier" objection, I would propose that the premise of applying the test to _debugging_ is wrong. Debugging means that your assumptions were already faulty: otherwise the system would not have bugs.

That is, the act of programming means working on an unfinished thought, something that can reflect some beliefs but compromises on being an exactly true expression of them. And so the weight of philosophical reasoning should appear at design time. What occurs after that is a discovery phase in which you learn all the ways in which your reasoning was fallacious - both bugs and feature decisions.

</comment><comment><USER31> > (Yes, I should have caught the bug in testing, and in fact I did notice some > odd behavior. But making software is hard!)

How often have I noticed some "odd behavior" in testing, and later wasn't able to reproduce it? Some nagging feeling that I broke something remained, but since I've deployed a new version (that fixed something else), and I couldn't reproduce the "odd behavior", I tricked myself into ignoring it.

And then I deployed to production, and shit hit the fan.

Now I try to pay more attention to those small, nagging feelings of doubt, but it takes conscious effort.

</comment><comment><USER32> This reminds me of a recent event at WrestleKingdom 13, a Japanese professional wrestling event where, as you might imagine, pretty much everything is planned and choreographed ahead of time.

In the opening match, Kota Ibushi suffered a concussion. Some doctors came out, carried him out on a stretcher, and took him to the back. As it turns out, this was all planned. The doctors were fake, and this course of events was determined ahead of time. But coincidentally, Ibushi _actually_ suffered a real-life concussion in the match.

Wrestling always has an interesting relationship with reality.

</comment><comment><USER33> This is precisely why when dealing with bugs I advise juniors to avoid asking the question, "what changed?" Gettier cases are just one problem that you can face when asking that question.

Instead I usually tell them to do it the proper way: start from the bug, and work backwards to understand why that bug is happening. At that point the change that caused the bug becomes obvious, and most of the time we realize that we probably wouldn't have come to that conclusion by looking just at what changed.

<comment><USER34> This is one of two approaches to the problem of debugging a system. It's advantage is that assuming the programmer can focus on everything they have seen in the debugger for long enough, they can find where the issue arises.

It's disadvantage is that as systems get larger, it can get exponentially more time consuming. As programmers we sometimes learn tricks (read: assumptions) to cut down this time, but in the end, the complexity of the system beats all but the very best/most determined.

Consider tracing a bug in this manner through the entire code of something as complicated as an operating system. Most of the code you did not write yourself, and you have likely never seen before and no idea what it does. Each new frame the debugger reaches you have to spend time understanding what is happening before determining if this is where the problem occurs, and there are so many frames that it can become difficult to sort through them all.

</comment></comment><comment><USER35> This are called false positives and are a normal occurrence in the life of a software developer. That's why when testing the root-cause you should test for a false positive as well.

</comment><comment><USER36> I haven't read the original paper, so maybe the example is better, but it seems the cow example fails the justified condition. The knowledge is justified if it derives from the evidence, but once we know the evidence is faulty it can no longer be used for justification by definition. It seems by extension that any justified true belief can become unjustified by the addition of new information that invalidates the justification on which the alleged knowledge is based upon.

<comment><USER4> What you're saying is more or less exactly what the paper was getting at.

It's hard to say based on a short Internet comment, but it sounds like the spot where your disagreement comes from is that you're understanding the word "justified" in a slightly different way from how epistemologists were using it. For example, one of the responses to Gettier's paper was to suggest that maybe the definition of "justified" should be altered to include a provision that invalidating the justification would imply that the belief is false.

So, for example, under that modified definition, the visual evidence couldn't serve as a justification of the belief that there is a cow in the field, because it allows the possibility that it isn't a cow but there still is one in the field. On the other hand, it _would_ work for justifying a belief like, "I can see a cow from here." (Yeah, there's another cow in the field, but it's not the one you think you see.) But, still, that wasn't quite the definition that the mid-century epistemologists who made up Gettier's audience were using.

(ETA: Also, the original paper didn't involve cattle at all. Wikipedia has what looks like a good summary: [https://en.wikipedia.org/wiki/Gettier_problem#Gettier's_two_...](https://en.wikipedia.org/wiki/Gettier_problem#Gettier's_two_original_counterexamples))

<comment><USER36> Thanks, I think you're right about how I was understanding the word "justified". I like bringing up philosophical disagreements on HN since it often gets responses like yours :)

<comment><USER4> Yeah, sorry, though, I realized after I posted that I failed to properly acknowledge that you hit the nail on the head -- I picked that response to Gettier specifically because it matched your criticism.

</comment></comment></comment></comment><comment><USER37> Sounds like (from the cases presented) an over intellectualisation of "coincidences."

</comment><comment><USER38> Another really great work that's related to some of these concepts is "Naming and Necessity" by the philosopher Saul Kripke.

[https://en.wikipedia.org/wiki/Naming_and_Necessity](https://en.wikipedia.org/wiki/Naming_and_Necessity)

It investigates how we assign names to things and what those names mean and how we can reason about them.

</comment><comment><USER39> I know mathematical logic but I don't know much about conventional philosophy. The Gettier argument seems to indicate that a system of false propositions used to arrive at a conclusion could be called "justification" in normal epistemology - that seems a bit disturbing. Being "justified" in believing X means just having some reason, maybe utterly bogus but existing and convincing to you, for believing X (and then X becomes knowledge even if X happens to be true entirely different reasons). How could no one have commented previously if that was how the system was?

Edit: the main practical implication of the argument seems to be that one cannot assume that when you have argument for X and when you then you get empirical evidence for X, you cannot take that a proof your argument for X is true. It might be suggestive of the truth of the argument but the structure of the argument also has to be taken into account. But that's been a given scientific and statistical investigations for a long time.

</comment><comment><USER40> I initially thought this article might be about programming by coincidence [1] or maybe about user experience superstitions [2], but after reading it I wonder if this isn't just about the practice of debugging. Software is complex. When someone begins investigation into a bug, if the fix is not immediately found, it becomes a matter of running down a list of hypothetical causes. As one's experience deepens, both the "running down" and the curating of the "list" become more efficient. IMHO this article is merely about a developer who was unaware of certain hypothetical causes.

1: [https://pragprog.com/the-pragmatic- programmer/extracts/coinc...](https://pragprog.com/the-pragmatic- programmer/extracts/coincidence)

2: [https://www.nngroup.com/articles/quality-assurance- ux/](https://www.nngroup.com/articles/quality-assurance-ux/)

</comment><comment><USER41> I actually disagree with the Gettier thought experiment and don't believe it demonstrates anything interesting.

When you see the cow (but it's really a convincing model), then in your mind, there should be some probability assigned to a variety of outcomes. The main one would be a cow, another one might be that you're hallucinating, and so on down the list, and somewhere the outcome of cow-like model would be there.

From that point you can go in at least two directions, one would be something like a Turing test of the fake cow... beyond a certain point it's a matter of semantics as to whether it's a real cow or not, or you could say that your "justified true belief" had to apply to the total state of the field. If you believed there was both a cow model and a cow behind it, that woukd be justified, but the existence of the cow behind the model would not justify incorrect belief that the model was a real cow, in the sense of not admitting uncertainty over the things you see.

<comment><USER42> > From that point you can go in at least two directions, one would be > something like a Turing test of the fake cow... beyond a certain point it's > a matter of semantics as to whether it's a real cow or not, or you could say > that your "justified true belief" had to apply to the total state of the > field. If you believed there was both a cow model and a cow behind it, that > woukd be justified, but the existence of the cow behind the model would not > justify incorrect belief that the model was a real cow, in the sense of not > admitting uncertainty over the things you see.

You're replacing the model it was criticizing with a different model and then saying that it doesn't say anything interesting about your model, so it's not interesting. It's not an argument that knowledge isn't possible, it was an argument against the traditional definition of knowledge as it was almost universally understood at the time.

<comment><USER41> I'm saying the model it would like to criticize is not an interesting or worthwhile model to talk much about.

</comment></comment></comment><comment><USER43> It's a bit in the weeds, but I think the author has a wrong JTB. They author deployed multiple changes, and just incorrectly assumed that their PR was the one that introduced the bug. They author had incorrect knowledge about what was being deployed. If something in their deploy process indicated that in fact only their code was being deployed then perhaps it's a JTB? But otherwise I think it's just a bit off.

However, the gist of it is correct. We often update dependencies or deploy more than we think we do. We have an "us" focused view of our code, and keeping gettier cases in mind helps us break out of that.

Just recently I kept thinking that I didn't know how to write a jest test, when in fact I was using a version of Jest which didn't support a certain method. It's easy to think it's our fault, when in fact there can be deeper reasons.

</comment><comment><USER44> Interesting to compare this with a simpler term - "Red herring" as something that throws you off course.

</comment><comment><USER45> These cases seem to come up often (weekly?) in software development. I wonder how often they come up in other professions.

One common case is when you change or delete a comment, and suddenly something breaks. It couldn't have been the comment... but it was working fine before my edit... wasn't it?

<comment><USER46> And then as you look closer, you wonder how it _ever_ worked. Hang on, _did_ it ever work?

<comment><USER47> I lost quite a few hours trying to restore a feature after I made a commit, only to find out that it was broken for weeks already. Or worse, was not even implemented yet.

It's amazing how that just keeps on happening.

</comment></comment></comment><comment><USER48> I was surprised when I first learned that this was a novel philosophical concept, because I recall reading a Renaissance-age Italian story(maybe from the De Cameron?) that talks about this:

Basically, a man sees his wife walking in the town square with the hat of a friend of theirs, and this leads him to believe that she is cheating with that friend. It turns out that he just offered the hat to her in the market, to help her carry some eggs home, and she was going to return it. So, she goes and returns it, the husband follows her, and it turns out she actually is cheating on the husband with the friend, but the hat hat nothing to do with it.

</comment><comment><USER49> This hits close to me as a possible reason why I could never get good at solving geometry problems, solid geometry especially. Most problems would be trivial when one assumes specific preconditions, but my mind was always wandering around, looking at all potential sides of a problem and I could never solve anything. To quote the author from my particular pov:

        a problem has multiple potential causes, and you have every reason to believe in one of them, even though another is secretly responsible.

Reminds me that I need to pick up a book and re-learn the damn thing. It really saddens me that I suck at geometry.

<comment><USER50> I think you should try looking at geometry more like a creation initially then a problem. In this manner you can see assumptions as just building up more simple worlds with those constraints. I have found this view helps when teaching geometry as it empowers the mind.

</comment></comment><comment><USER51> I don't understand how anyone could have ever thought "justified true belief" was a good definition of knowledge, since the question of "what constitutes justified belief?" is muddier than the question "what constitutes knowledge?" in the first place. Further, even without considering such absurd situations as a real cow hiding behind a fake cow, if you see something that, based on its appearance, almost certainly is a cow, the near certainty doesn't change into absolute certainty just because what appears to be a cow is in fact a cow.

</comment><comment><USER52> As usual, science has a more practical take on this. Occam's Razor says that if you see a cow shape and hear a cow sound coming from that direction, the most likely explanation is that you're seeing a cow. It retains the possibility this isn't true; the belief can be falsified in several ways: by examining the cow more closely, by the real cow walking out from being the fake one, etc.

I think it follows that we never absolutely "know" something. We asymptotically approach knowledge. The scientific method is a way of approaching truth.

</comment><comment><USER53> I don't think the example of checking in someone else's bug is a very good one. If I checked in something that had code from other people I would see it very easily, and if I did not think there was any way my code should have affected the autocomplete then I would assume the code I checked in which was not mine broke the autocomplete.

Matching it to the example of the papier mache cow doesn't really work because the papier mache cow hides the real cow but it is very easy to see that your code was also checked in with other people's code.

</comment><comment><USER54> Somehow, the examples all sound more like a quality and/or testing issue. The workflow seems prone to people rebasing to a buggy state and at that point, in a non-trivial system, all bets are basically off. Basically I need to be able to have a "JTB" about a pull request having undergone enough review and testing before being merged on the master that it doesn't introduce such glaring regressions as cited in the examples. If that cannot be ensured, I'm setting myself up for one goose chase after the other...

</comment><comment><USER55> I learned this word, but I'm scared and wondered by it every time. I think it fits here. There is two worlds: believed and true. And when they merge it's called "peripeteia"

<comment><USER56> I read the Wikipedia's entry. It seems that it could be better explained as a "plot twist": when your confidence in an outcome is overturned, for better or worse.

</comment></comment><comment><USER57> It might be true that even though I have a JTB about something I might be wrong.

Nevertheless, I think It would be resonable to act upon a JTB as it it was true. For all effects it is true to the best of my knowledge. This does not mean I shun down new information that might make me to change my JTB.

And if having a JTB is not knowledge, what is? What can we know? We can always imagine a world where even our most firm JTB might be false. If a JTB is not a good case to use the word knowledge I don't know what is

</comment><comment><USER58> Always bemused and not a little confused that anyone (most notably, Americans) still spend so much time and energy on analytical philosophy [and its Quine-y assertions about semantics] so many decades after its sort of formal semantics collapsed as a useful way of analyzing natural language.

Linguistics (not to mention, comp lit or continental philosophy) departments have an order of magnitude more to say about meaning in natural language and have had for... decades and decades.

I just don't get it.

</comment><comment><USER59> I don't like this approach. If everyone were to approach a problem with this mentality it would conjure doubt in the entire process. Nothing would ever get done. Question: "how do we know if anything exists?" <\--(an extreme example). Answer: "well we don't but it doesn't help us with the realities of the problem at hand." I think this idea introduces confusion and does more harm than good, in my opinion.

</comment><comment><USER60> This reminds me of how some studies are proven to be true but the reason they are true are not the reasons the author of the study presents. Instead, the true-ness is either a coincidence or a correlation, not causation. These people go on to write books and entire industries are formed around these hypothetical truths and it takes years to undo the damage of the original study (e.g. marshmallow test, jam experiment)

</comment><comment><USER61> So just to be clear, a 'gettier' is when something you Believe and have Justification for turns out to be false?

      Actually True
      J B
      1 1 knowing
      1 0 denying
      0 1 lucky hunch
      0 0 sceptic, default position

      Actually False
      J B
      1 1 mis-justification: un/incorrectly-verified
      1 0 lucky denial of mis-justified
      0 1 superstition
      0 0 sceptic, default position

<comment><USER16> No, it's when you get the right answer for the wrong reason, like a math problem solution that has two mistakes that cancel out in the end result, but are still incorrect logic

</comment></comment><comment><USER62> Note most gettier cases are plays on our intuitions:

What feels like a pointer is actually a category. That is, it feels like it points to one, but it points to many. Like both examples given here: [https://en.wikipedia.org/wiki/Gettier_problem](https://en.wikipedia.org/wiki/Gettier_problem) .

<comment><USER16> For the C heads, you mean what feels like a pointer is actually an array? :-)

</comment></comment><comment><USER63> I had a philosophy lecture last year that included a lot of epistemology (Theory of Knowledge). We talked a fair bit about justified true beliefs, but Gettier only came up in a side note - the professor being more interested in skepticism and the responses thereto. Never would have dreamt of applying that lecture to programming, though.

</comment><comment><USER64> The article was great. I also find philosophy and software correlates occasionally. The response of the author to the gettier cases are expected behavior. In fact it is a blessing. 99% of the time there is a cow, we experienced that before and that's the reason of our confidence. We easily solve our problems with this approach.

</comment><comment><USER65> The first example is exactly the reason why I hate rebases and prefer merges and complicated history instead. It may be more complicated, but it doesn't swipe problems under the rug.

<comment><USER16> That's why in some quarters it's called git _debase_.

</comment></comment><comment><USER66> My own opinion is that knowledge is always relative to a perspective. It is only valid in a context.

Nothing is absolute.

Example:

1=1 is something i know is true cause i know the rules of mathematics. There is no absolute truth to that.

<comment><USER67> 10+3 = 13 when talking about coconuts, but 10+3 = 1 when talking about time[1]

[1] In America anyways.

</comment></comment><comment><USER68> As software abstractions often put up facades in front of similar abstractions, this is bound to happen to us software developers.

</comment><comment><USER69> Didn't Descartes cover this with "I think therefore I am."? Everything else is varying degrees of speculation.

</comment><comment><USER70> My reaction Gettier cases as a philosophy minor was that J is the only philosophically interesting part of JTB.

</comment><comment><USER71> "Justified true belief"? All our knowledge is subjective by definition. We don't even know whether we're living in a simulation.

Personally I doubt that we're living in a simulation. But the fact that we could be, demonstrates that we don't have objective knowledge. No cows needed in the field explain it

Philosophy might better be called "the history of flawed thinking"

<comment><USER13> > We don't even know whether we're living in a simulation.

I think it's actually worse than this. This scenario suggests that our minds are capable of infallible reasoning yet we may not be able to trust our observations. Really, I don't think we can even trust our own mind, and therefore JTB is undefinable.

<comment><USER72> This strikes me somewhat similar to saying that we should not use Newtonian mechanics, because we know better that at subatomic level Newton's laws do not apply.

But Newtonian mechanics are still extremely valuable, worth discovering and understanding, and anyone catching a baseball is employing them quite proactively. JTBs are the Newtonian mechanics of epistemology. You can pick them apart at a deeper level and show how they don't really exist, but they are still incredibly useful.

<comment><USER13> I'm not saying that we should entirely disregard epistemology. After all, belief is necessary to make decisions, and thus to thrive. Although I think people should be mindful that knowledge may not be possible in actuality, just as modern physicists are mindful of relativity and quantum mechanics.

</comment></comment></comment></comment><comment><USER73> So just more simply "red herring"

</comment><comment><USER74> Isn't this just a confounding factor?

</comment><comment><USER75> Is not this same as coincidence?

</comment><comment><USER76> To me this seems unhelpful. I'd say there is no "knowledge"; there's only belief. And if you defined knowledge as "justified true belief" then you couldn't apply the definition in practice in the real world because you don't know when something is true. But that's philosophy for you: fun (for some people) but not useful.

<comment><USER27> In an epistemology class once I said to the lecturer "I don't know anything." He said "Don't you know your name?"

<comment><USER77> Not good enough, point to that which knows. Where is it? Who knows it? If there is a knower to that, where is it.. Keep going with this investigation and realize there is no knower, only knowing.

Eastern philosophy has nailed this thousands of years ago and we westerners are up to this day totally in the dark. We actively treat the I as a concrete object that really exists as an entity. It does not hold any closer examination and evaporates entirely the closer it is questioned.

<comment><USER78> I know my name just like I make a cup of tea. It's not you who makes my cup of tea, right, so who is it? Well, me—the referent of my name, this person right here.

That's just part of how our language works. It doesn't seem to matter whether I am a "concrete object" or some swirly pattern of becoming or indeed even an illusion! The English word "I" does not refer to an eternal soul or "atman."

If you stare long enough at an ice cream you'll have the marvelous insight that in reality there is no concrete ice cream entity, not least because it melts. Yet people don't go around saying "wake up, there are no ice creams!" Why is that?</comment></comment></comment></comment>


The world's best office - <AUTHOR> http://blog.footballaddicts.com/the-worlds-best-office/ <comment><USER2> The design may prove to be not very accessible for anyone with a physical condition that limits their mobility.</comment>


ASML Buys Stake in Carl Zeiss Unit for $1.1B - <AUTHOR> https://www.bloomberg.com/news/articles/2016-11-03/asml-buys-stake-in-carl-zeiss-unit-for-1-1-billion-in-euv-step <comment><USER2> Background: This is all about EUVL, a technology for making chips with smaller features.

See:

[https://news.ycombinator.com/item?id=11241963](https://news.ycombinator.com/item?id=11241963)

[https://news.ycombinator.com/item?id=12841278](https://news.ycombinator.com/item?id=12841278)

<comment><USER3> I don't know if I could stand the tension of working in a company where quarterly shipments were single digit units of product is considered a banner year :-) Makes for a really odd revenue stream. Someone builds a new fab, woo- hoo!, then 2 years of nothing.

<comment><USER4> It gets better when you consider that Intel et al. depend on them.

<comment><USER5> I'm realizing how what I thought was just a refined consumer/prosumer company for photography, is involved in many different fields of deep science. And for a while now.

<comment><USER6> It's kinda of a side business (cine lenses, too), but "refined consumer / prosumer" would be Fuji o Leica. Not many lens-makers are more "pro oriented" than CZ, maybe Rodenstock and Schneider-Kreuznach.

<comment><USER7> I'm not sure about Leica, but Fujifilm is not in the "refined consumer / prosumer" category either. Neither is Canon, Nikon, or even Olympus for that matter. AFAIK they all make high performance optics that are used in manufacturing, lithography, or machine vision in some capacity or another.

<comment><USER6> Leica (well, same parent company, I think that the structure is a bit complex) also makes microscopy equipment, but I'm talking about their lens lineup intended for photography. Leica makes very good things that are not very practical or realistically priced. Fuji makes good prosumer cameras and lenses, but they don't have wide professional adoption for ecosystem / features considerations.

<comment><USER7> Again, I think you are wrong. Fujifilm makes extremely high quality professional lenses that are used on medium and large format cameras. Or at least did fairly recently. They've also announced a new medium format digital system with lenses to match. I have the Fuji "prosumer" X series system, and I can tell you that their lenses are very, very high quality - besting most of the Nikon and Canon offerings with metal construction and in some cases weather sealing.

<comment><USER6> They stopped making those a few years ago. Their current offerings (the fuji x system) are good for people that like nice cameras but don't need to make a living with them (like me - when I shoot digitally I use a Sony A7r, but I wouldn't have picked that for actual work and could also have gone Fuji, but at the time they had only the 16mp first gen x-trans sensor), most of the lenses are good, but they don't have the coverage of the expansive Nikon or Canon ecosystems, mirrorless tracking autofocus is still lagging behind pro dslr bodies (I don't even use autofocus, but again, I don't generally have to get paid), etc. In the end a 2012 D800e outperforms a brand new X-T2 in image quality in most scenarios, despite the Fuji having better lenses (and you can always natively mount superior Otus or Apo-Sonnar lenses on the Nikon).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This may seem like an odd question, but strategically, why acquire the stake (aside from dividends)?

As I understand, ASML already depends on Carl Zeiss. I would guess ASML will depend more heavily on them with EUVL over the next decade, but I honestly haven't done the research.

Is this going to give them more control over production? Does it somehow reduce their costs?</comment>


Autonomous Fatalities - <AUTHOR> https://medium.com/@tartavull/autonomous-fatalities-53b1fcbd76bf <comment><AUTHOR> I've been try to explain in simple words the state of the autonomous industry. Let me know if it makes sense to you.</comment>


Simulating flocking behaviour with boids [video] - <AUTHOR> https://www.youtube.com/watch?v=bqtqltqcQhw <comment><USER2> If you are interested in programming this type of thing (alife, fractals and whatnot) you might like NetLogo. [https://ccl.northwestern.edu/netlogo/](https://ccl.northwestern.edu/netlogo/)

There is a 2D and a 3D version of the language interface, and you can find a number of Boids demos in the samples for both of them.</comment>


Driven to Distraction - <AUTHOR> http://webnotes.net/?rX8m9P

<comment><AUTHOR> some may find this to be a bad thing for reasons that i have not yet imagined -- but i linked to a highlighted version.</comment>


Growing up with AI - <AUTHOR> https://medium.com/mit-media-lab/growing-up-with-ai-how-can-families-play-and-learn-with-their-new-smart-toys-and-companions-fe9abcc6e152 <comment><USER2> I am really jealous of what the more creative/motivated kids growing up today have access to.

When I was a teenager not long ago, I was mostly motivated by cheating in games which got me learning basic scripting for keyboard/mouse macros which then led me to increasingly complicated stuff for botting.

But there are so many more motivating factors for learning how to code today, and they have never been more accessible. For example if you want porn of your high school crush? You gotta train your own deepfake for that. You will start off as a script kiddie but when you grow up you can tell people you've been training neural networks since you were 12.

<comment><USER3> Jesus, I would have hoped they would achieve more noble pursuits instead of jumping straight into artificial child porn.

<comment><USER4> Kids are not into noble pursuits.. I learned html/css and webhosting stuff by making phishing sites of for my favorite video game.

<comment><USER3> When I was younger _I_ was into noble pursuits. I loved to study programming and would talk about ways I would want to help the world with my future skills.

That's all gone now... At some point I started to get darker and more cynical, and began to see technology not as a way to improve the world, but rather as a way to take what is mine. It started as a few disappointments here and there, then into short bouts of anger, then expanding into a constant simmering rage. Don't know if I'll ever recover.

What happened...

</comment></comment></comment></comment><comment><USER5> This is a great project but I can't help say it: I don't like Scratch (and similar block-based languages). They are limited, in some cases by design (e.g. opening files in Scratch) but usually by their very nature. I very much prefer the safety wheel way of learning to ride a bike: use the real thing with addons until you don't need them.

Maybe I'm wrong, any thoughts from people who worked with kids? I can give anecdotal evidence from my son (had no problems with Python or CHIP-8) but that's a sample size of 1.

<comment><USER6> I've worked with kids from elementary to high school age. One of the obstacles for getting nearly any kid into coding is conditioning their response to things like syntax errors and the other obtuse-looking things compilers and interpreters like to spit out.

For example, a kid can spend an hour adding a tree of dialogue to their text- based dungeon crawler, only to get a compilation error they've never seen before. They might have forgotten a curly brace somewhere and I'll help them find it, then they give it another go only to find out they forgot a semicolon or misspelled a variable name. That series of events can be pretty demoralizing, and it takes some coaching to get them through.

The above is obviously a teachable moment to test early and often, but the point is kids often lose motivation in the face of errors they don't yet know how to interpret. On the other hand, kids get really interested when they can see the fruits of their labor come to life, which can happen without a lot of friction in Scratch.

So to give students a taste for that success without the slog through syntax errors and stuff, things like Scratch are fantastic. Especially for younger kids where attention span and getting bored or disinterested come more easily. We quickly move on to real languages, though, and the concepts they picked up in Scratch are easily portable to Python or whatever else.

<comment><USER7> When I learned to program (I was ~13 years old) using Small Basic I had no issues whatsoever with the errors the interpreter gave me, even though they weren't even in my native language. It was pretty obvious to me that I had committed a mistake at some point of my code.

For kids younger than that, maybe it's better to learn scratch, but I wouldn't trade Small Basic, it's a great language to learn, the only bad thing is that it's made by Microsoft and only runs on Windows.

<comment><USER6> Yeah, in my experience teenagers (especially those that are highly self- motivated) can see stack traces and stuff as just another part of the puzzle. It's the younger and less motivated kids that tend to get frustrated.

Edit: I'll also point out this:

> It was pretty obvious to me that I had committed a mistake at some point of > my code.

How a student handles this is also often a sticking point. "Oh no, another error, I'm bad at this, maybe this isn't for me." Is an attitude that I've had to turn around. It goes a long way to convince a kid that it's actually the computer's fault because it isn't smart enough to understand what you're trying to tell it. So you have to be really specific in how you write to it. Then suddenly error messages are informative clues on the way to making your program work, rather than the computer scolding you for being a bad coder.

</comment></comment></comment></comment><comment><USER8> One of the things I love about voice interfaces the most is how they allow for us to remove abstraction between what we want technology to do for us and how we get it to do it.

The last major step we had for making technology more accessible and easy to use for more people was the touch screen which made it possible for anyone to understand what "click the button" or "drag the folder" means.

My kids speak with Google Home all the time. They get more and more creative with what they ask it for.

Furthermore, you can interact with it at naturally at a dinner table or in a meeting room without having to look down at a screen. It really just becomes a natural no-obstructive participant of the group of people which I think is going to be it's biggest

Whatever weirdness my generation feel around speaking to tech it will be totally normalized by the coming generations.

</comment><comment><USER9> Most of these articles have the same narrative, summarized as: We have seen how dangerous and important technology is with elections, now it's more important than ever we educate everyone about AI.

As if the two concepts follow or are related at all, it seems more like a extremely convenient way to pivot the conversation to this new area of hype in technology while not actually owning up to anything.

How about we talk about anti-trust law, privacy, and busting up Facebook and Google instead?

<comment><USER10> I want something to new to come up and shatter Facebook, Google etc. We need more internet companies, and right now Facebook & Google reek with a vile stench. They lack creativity and innovation. They are the IBM of the current generation.

<comment><USER11> As far as fundamental research goes, they are both currently doing a lot of the very best machine learning research.

What they are as companies is an entirely different matter, in which case I would not doubt your comparison.

Take, for example, the decreasing quality in user experience in map apps over the last few years. Mining our data is apparently much more valuable than doing a simple job better.

<comment><USER12> Apple maps got way better! Granted, coming from a difficult starting point...

<comment><USER11> It strikes me as not a coincidence that they are also the company in the big few which most highly values its users' privacy. Still not great, but it's something.

</comment></comment></comment></comment></comment><comment><USER13> One point that is not raised or discussed, which I think is important, is that these learning platforms are not "the real thing". They're just artificial environments with building blocks designed for making toy projects, but no engineer would ever use them to build something of significance.

This is not to take away from the work - I'm a big fan of Cynthia Breazal's group and the work her graduate students have done over the years. But it would be nice to see effort put into removing the artificial separations between user/programmer, or learner/professional. An apprentice carpenter uses real hammers and table saws, an apprentice baker uses real flour and sugar and ovens, so why are apprentice programmers using the plastic playset/ez bake oven equivalent of Tensorflow?

(and if the answer is just "because tensorflow is too hard for a 7 year old", then how can we get somewhere where there is something as powerful, if not more so, than Tensorflow, while also being accessible to 7 year olds?)

<comment><USER14> An apprentice carpenter often does not use 'real' power tools. Nail guns for example are significantly more expensive and dangerous than a hammer, but also more specialized.

<comment><USER15> Students routinely are given machines/equipment/tools that is massive overkill for the task they are being asked to do so that it can be assured that their effort is spent learning instead of fighting their way around the limitations of their tools/equipment.

<comment><USER14> An apprentice is not really just students in that they are paid reasonably well. That pay is based on the idea their going to get a job done reasonably efficiently while not breaking stuff or getting someone hurt.

Put another way, you generally don't give interns root access to production servers.

</comment></comment></comment></comment><comment><USER16> I would love a Young Lady's Illustrated Primer: a Propædeutic Enchiridion for my daughter.</comment>


Number of open source applications on government desktops doubled - <AUTHOR> http://www.osor.eu/news/mt-number-of-open-source-applications-on-government-desktops-doubled <comment><USER2> Increased by 100% would mean it has doubled. Increased by 47% is much less.

</comment><comment><USER3> A 47% increase is not 'doubled'. 100% increase = doubled.</comment>


Ask HN: Help, NY is shutting down our hacker house due to AirBnb Law? - <AUTHOR> New York is shutting down our hacker house in NY due to AirBnb Law, apparently, even though it's not  not at all a short-term stay situation (we all have leases, receive mail at the address, some of us have been here over a year).<p>An inspector came by on Wednesday and dropped off papers saying we all had to be out by Sunday. Does anybody know anything about this or what our options are? <comment><USER2> r/legaladvice or see a lawyer.</comment>


Android Wear, it's time for a new name - <AUTHOR> https://www.blog.google/products/wear-os/android-wear-its-time-new-name/ <comment><USER2> Please, just deliver something that isn't just kinda shit first and then I'll be happy to hear about how you want a more coherent branding experience.

<comment><USER3> +1 to this.

I used a Polar M600 for the last year, and the long anticipated AW 2.0 update pretty much ruined it. After the upgrade, Play Music lost the ability to shuffle on-device content. The worst thing was that the watch was divorced from the phone, and my "google managed" gsuite account wanted to install Android Device Policy manager, which then wanted me to enable a PIN (annoying) and encrypt the watch (impossible), so I lost access to Google authenticatior on the watch, which was pretty much the only advantage it had over a non- Androidwear smartwatch.

I just replaced it with a Garmin that also does BT music (which can shuffle!), and I"m loving week-long battery life vs the 1-day at most life. The notifications work just as well. I'm beginning to think that full-blown Android (or WatchOS) is just a bad idea for watches, and companies like Garmin and Fitbit have a much better platform.

<comment><USER4> Third party google authenticator applications worked (and continue to work) really well on the Pebble as well.

<comment><USER3> The problem is that (AFAIK) there can be only one authentictor per account. So to move it to my watch, I'd have to remove it from my phone. And that makes me ... nervous.. The nice thing about the android wear authenticator was that it could be both on the watch and the phone at the same time.

<comment><USER4> I haven't set up the official Google Authenticator app in a while, but what I have done in the past is to seed the watch with the same value as the phone app. It marginally increases the risk, as I now have two devices that could be stolen, but the convenience was worth it to me.

That may require using a third party app on the phone as well as the watch, though. I'm not sure if the official Google Authenticator app still makes this practical.

<comment><USER3> Ah! That's a great idea. I had not considered that..

</comment></comment></comment></comment></comment></comment><comment><USER5> There's no comma or other separator between "Wear OS" and "By Google", nor is the font size smaller for "By Google", so can we assume that the full name is in fact "Wear OS By Google"?

\- "Check out the new Wear OS By Google watch from Samsung!"

\- "The new ASUS Smartwatch powered by Wear OS By Google"

\- "Wear OS By Google vs watchOS: 10 ways they differ, you won't believe #9!"

It just rolls off the tongue.

<comment><USER6> > so can we assume that the full name is in fact "Wear OS By Google"?

Well, this is the same organization that brought you "Google Play Music All Access"...

<comment><USER7> YouTube Red Music by Google

WTF YA'LL

</comment></comment></comment><comment><USER8> Ars had an article[0] over the past few weeks about how Qaulcomm isn't creating new chips for Android Wear and therefore smart watches were on the decline / not improving.

Has anything changed? Are there non Apple competitors in the field?

[0]: [https://arstechnica.com/gadgets/2018/02/android-wear-is- gett...](https://arstechnica.com/gadgets/2018/02/android-wear-is-getting- killed-and-its-all-qualcomms-fault/)

<comment><USER9> How would ars know what Qualcomm is or isn't doing? Last I checked they were not in the habit of taking out billboards announcing their current in progress parts and product roadmap. Or did I miss a radical shift in their marketing strategy?

<comment><USER10> The article talks about how many years it's been since Qualcomm even announced a new product in that line. That's 2 years without a press release while Apple and Samsung _shipped_ multiple hardware generations in the same time, and Qualcomm's product was based on an old design & fab process which was behind Apple when it first shipped.

<comment><USER9> Well, I'll grant you that they are not predictable and not always on the ball, but honestly that argument is thin. Extrapolating from just one data point is not even "anecdata", it is just noise.

<comment><USER4> I understand your point, but I wouldn't exactly call it only one data point. There are quite a few indications from the that there is relatively little interest from existing Android Wear manufacturers for new hardware.

Maybe this rebranding is a sign that Google is putting more effort behind it now, though.

</comment></comment></comment></comment></comment><comment><USER11> Google has to be the absolute worst at putting together multiple brands + having a cohesive naming structure.

This happens across almost every single one of their verticals. It has to be with how they organized teams, right? I mean they have 3-4 different chat/talk programs on their own?

</comment><comment><USER10> This reminds me of the 90s tech bubble when companies would spend 6+ figures on a name and fumble the execution. If Android Wear had good products nobody would think there's anything wrong with the name.

<comment><USER12> 90's? Still doing that in the 2010's!

[https://techcrunch.com/2011/03/24/color-com-was-acquired- for...](https://techcrunch.com/2011/03/24/color-com-was-acquired- for-350000-the-domain-name-that-is/)

<comment><USER13> Oh my god, TechCrunch's site is annoying. Wtf the fuck is with the check mark and removal of contrast when you get to the bottom of the article? It's like "Oh for the last 3 paragraphs we're going to make it slightly harder to read this."

Man why can't companies just let us read text without trying to make some big stupid extra functionality?

<comment><USER14> For me once I scrolled to the bottom it just auto-navigated me to some other article. Scrolling up didn't take me back. UX Fail.

</comment></comment></comment></comment><comment><USER15> Unless this means that the next release of Android Wear won't be based on Android; it don't see the point of this rebranding.

To be honest, I thought that Android Wear was pretty much abandoned at this point.

<comment><AUTHOR> It would be weird, but who knows ?

I think the real reason is provided in the article. iPhone users. They think using an "Android Wear" causes confusion.

<comment><USER15> I don't see it happening either : Wear's biggest issue in on the hardware side, not the software one.

> They think using an "Android Wear" causes confusion.

I see .. well at can at least tip my hat to Google on this, they tend to have a pretty open ecosystem.

</comment></comment></comment><comment><USER16> They just uploaded a video as well.

"Introduction to Wear OS by Google Development"

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

</comment><comment><USER17> Everyone knows that Apple = iOS. Apple iPhone, Apple Watch, etc.

Not everyone knows that Google = Android because of all the other Android vendors. Google Pixel, but also Huwei Nexus 6P, Samsung Galaxy 9, etc.

Should have kept the old name.

<comment><USER18> I think the whole point is to get away from "Android." The average Apple (iOS) user will see "Android" and not bother to give it a try. They see "Wear OS" and they might try it. The audience is not just tech users.

<comment><USER17> The average Apple user is going to use the equivalent Apple product.

Wear OS by Google sounds like a big bag of nothing to anyone who ISN'T a tech user. At least using "Android" associates it with the platform.

</comment></comment></comment><comment><USER19> Google clearly has lost direction here, anytime they start changing names around it's never good for the products. Yet Fitbit and Apple seem to have the wearables thing down.

</comment><comment><USER20> I still can't get over the `.google` TLD.

</comment><comment><USER21> That seems like a terrible name...

</comment><comment><USER16> Being Google, I am betting that they reboot the complete userspace as they did with Brillo.

</comment><comment><USER22> its renamed to WearOs if anyone came straight to comment section.

<comment><USER23> "Wear OS by Google" actually

</comment></comment><comment><USER24> Do you think this sentence by Google was intentional?

"In 2017, one out of three new Android Wear watch owners also used an iPhone."

In that, they found the three people that bought an Android Wear watch in 2017, and one of them had an iPhone.

<comment><USER13> I think they mean that a third of the users but holy shit is that a confusing sentence. That's such a hilarious catch!

</comment></comment><comment><USER25> I get to see literally four lines of this article at a time, sandwiched between the largest fixed header and footer I have ever seen on a website.

One day somebody will figure out how to make those things overlap, and they won't have to write any content anymore.

<comment><USER26> No one ever stopped to realize that they were re-creating the browser toolbar hell.

<comment><USER13> And now, instead of us having to actively install them, they're just forcing them on us every time we go to a page! The EU and their stupid cookie warning laws don't help either. "Close this footer bar so you can see the next footer bar"

<comment><USER27> _> The EU and their stupid cookie warning _

Great in theory! Let people know what cookies are and the privacy implications.

 _Absolutely_ terrible in practice since any non-trivial site with user accounts will require cookies to use. It's as useful as the peanut warning on a package of peanuts (although at least that exists to save taxpayers money).

<comment><USER28> Actually, sites that use cookies purely for necessary parts of the site don't need a cookie warning. Eg an add to cart button.

<comment><USER27> There are a few categories of exceptions but again, I'd need to see an example of a non-trivial site that doesn't implement any kind of cookie that requires the warning _and also_ doesn't have the warning "just-in-case".

Any site large enough to have anyone with the title that includes "Marketing" on the payroll means they'll be using some form of analytics and will need the warning.</comment></comment></comment></comment></comment></comment>