Types Are Anti-Modular - <AUTHOR> http://gbracha.blogspot.com/2011/06/types-are-anti-modular.html <comment><USER2> From the Haskell reddit discussion:

> It's a simple truth, indeed a tautology, that if you want the compiler to > check the consistency of interactions between modules, then the compiler > must know the information that it is checking. That's all that's being said > here. It really shouldn't surprise anyone. If you dispose of typing, then > someone still needs to know that relevant information in order to write > correct code; but it is the programmer, rather than the compiler.

or, with more wit,

> Types are anti-modularity in the same sense stop signs are anti- > transportation.

[http://www.reddit.com/r/haskell/comments/hs39c/gilad_bracha_...](http://www.reddit.com/r/haskell/comments/hs39c/gilad_bracha_types_are_antimodular/)

<comment><AUTHOR> The blog post isn't about correctness - it's about modularity. Lispers and Smalltalkers are used to programming with very small compilation units - individual methods and individual functions. Being able to fix running programs w/o going through the whole compile cycle is a demonstrable productivity gain.

Types and modularity are at odds. The antagonism is readily apparent in languages that support dynamic _and_ static typing - Qi. It's RCEPL (Read- Check-Eval-Print-Loop) has serious restrictions in comparison to its standard REPL.

<comment><USER2> > Being able to fix running programs w/o going through the whole compile cycle > is a demonstrable productivity gain.

Indeed! Removing many sources of runtime failures at compile time is also a demonstrable productivity gain. So good thing that static typing is no barrier to dynamic extension or modification -- however, you must defer type checking of splice points between components until later stages. (This was my PhD thesis).

<comment><AUTHOR> The act of verifying types defeats modularity.

I think static typing is grand, but Gilad has a valid point.

<comment><USER3> This is a serious "citation needed" assertion. What language doesn't verify types? Python does. Lisp does. ("TypeError: cannot concatenate 'str' and 'int' objects" or "wrong-type-argument: stringp 42")

I think the problem that people run into with types is when storing values for future use. Imagine that you have a data structure that looks like:

       data Foo = Foo String

And then later on in your application, you have a function like:

       frobnicate :: IsString a => a -> a

Then, you write a program that looks like:

       program :: String -> String
       program = frobnicate . preprocess . Foo

This is all well and good as long as you only want your program to operate on Strings. But if you want to change the type of your string data (perhaps to a more efficient "ByteString", or something like that), then you are kind of out of luck. You pigeonholed yourself into using String when you defined Foo as "Foo String", and now you have a lot of work to do to feed that ByteString to the function that actually cares about the type, "frobnicate", which can already handle ByteStrings.

The problem here is not type checking, but rather that you built your program in terms of an abstraction that was not generic enough, namely the "Foo" type. If you were just using Python, then your program would have been:

       class Foo:
          def __init__(self, string):
              self.string = string;

       def frobnicate(whatever):
           return whatever

In this case, there would be no trouble using whatever type you wanted as the "string", because you decide what type is OK at "frobnicate" time, instead of at compile time.

The downside is that with your too-specific Haskell program, you know it's too specific before you run it (because the compiler whines at you), but with the Python program, you may only find out when your pager starts making a loud noise at 3 AM, because Python has no idea what you're trying to do.

(Personally, having worked on a huge Python app that does no type checking anywhere, I have to say I hate that technique. I prefer what I do in Perl, which is to type check on object creation, but use type classes instead of concrete types. You can still "late bind", but you also get errors when you're making a mistake rather than deferring a decision. You can do the same thing in Haskell, too, but with even better guarantees that you won't be waking up in the middle of the night to unfuck your code.)

<comment><AUTHOR> I already said I'm not talking about correctness only modularity. Early/eager verification breaks modularity.

<comment><USER3> I would say, "bad program design breaks modularity", not early typechecking. If your types are defined so that they are as broad as possible (i.e., "what you really want"), then you will never even notice there is a type system, until you try something impossible.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> Um... NO. This argument applies equally to functions and constants and is equally wrong.

 _Types_ are _not_ anti-modular: the culprit is module systems that don't allow type parameterization. Systems such as Java solve this problem for functions and constants by allowing code to be parameterized over interfaces. Bam, you can compile code using said functions and constants separately from their implementation.

The solution for types is exactly the same: move types into interfaces. Guess what, Objective Caml and Coq do this via module functors and it's glorious. If my airline scheduler module needs to compile separately from my graph module, well I can write:

module Scheduler(Graph: sig type graph val traverse: graph -> (string -> unit) -> unit end) = struct ...blabla... end

and I can compile that code without ever writing a snippet of the graph module -- not even defining the ADT!

TLDR: this problem has been solved 30 years ago by people who actually use typed languages.

<comment><USER5> Thanks for pointing this out. I was about to believe the post was correct, but it seems it isn't. However, just to be sure I understand you correctly:

Is the module functor compiled only once, or once for every parameter type? I'm asking because if it's compiled only once, the generated code might be significantly less optimized. This might not play a role for complex parameter types, but could miss lots of good optimization opportunities for simple types such as int or char. How is this solved in those languages?

Also, is it just OCaml and Coq, or is this possible with other strongly typed languages (such as Haskell) as well?

<comment><USER6> Haskell's module system isn't very advanced. In fact, it about as simple as it could get. This is pretty well known known and there are proposals floating around to add more advanced features. But there generally isn't much need and, as you mention, adding things like module type parameters prevents many cross- module optimizations (which GHC does quite aggressively).

In practice, it doesn't seem to cause much of an issue, but this may just be down to how Haskell tends to be used.

<comment><USER4> Indeed, typeclasses in languages such as Haskell and Mercury can be (ab)used for many of the same uses as functors. I've used both and there are merits to each, but I still can't put my finger on when one is better than the other.

</comment></comment></comment></comment><comment> alok-g Copy-pasting a comment on the original article here, since I have the same comment/question:

Brian said...

Dynamic typing doesn't restore the modularity- it simply delays checking for violations. Say module X depends upon module Y having function foo- this is a statement which is independent of static vr.s dynamic checking. This means that that modularity is lost- you can't have a module Y which doesn't have a function foo. If module Y doesn't have a function foo, the program is going to fail, the only questions are when and how.

What I don't get is why detecting the error early is a disadvantage. It's well known that the earlier a bug is detected, the cheaper it is to fix. And yet, all the arguments in favor of dynamic typing are about delaying the detection of bugs- implicitly increasing their cost.

6/05/2011 6:49 AM

<comment><USER7> The article's just claiming that the modules of dynamic languages can be compiled independently; not that it will be correct.

Just my thoughts: There's a bigger question here about types, though. I think the argument is that the ceremony of types gets in the way more than it helps, and it requires up-front design. Many people like dynamic languages for their flexibility; and when you get bugs, you have to fix them anyway. There's an assumption in typed languages that we can design our types well enough upfront to help solve the problem.

It's interesting how types create a dependency on the interface (i.e. if you use a type, you depend on it). One of the ideas of Abstract Data Types was to reduce dependency on the internal implementation details; but you're still dependent on the external interface. If you change the interface, it creates problems (e.g. unit testing claims to give you confidence to refactor, but if you change interfaces, you also have to change the tests...). _EDIT_ added "claims to"

This seems intrinsic to modularity, and I can't really see any solution to this; except for ways to make it easier to cope with interface change. Some insights may come from webapp API's, where the dependency is more explicit (you have to send and receive serialized messages).

<comment> alok-g Maybe you got me closer to the answer, and you certainly seem to have more experience on this subject than I do. I am still missing some part of the picture, so let me ask:

Types: You think about the problem up-front to the best you can. Most likely you later change the interface. The compiler now breaks the code and forces you to fix it.

Dynamic: You are flexible, which means you can start your work without having to think up-front (Q1: How is this good?). Later when you change the interface (which may exist only in your mind, but it does as far as the modules are to interact with each other in some way at all), the code still breaks but the compiler won't tell you.

In either case, as you said "you have to fix them anyway". So Q2: How is compiler not being able to complain about broken code (and possibly unit tests finding it) helping?

One comment here cited an example where one can get away without introducing errors while still changing the type ("f(g(x)"). But that is readily achieved with statically typed languages like C++ as well.

<comment><USER7> Q1, you're assuming you _can_ design upfront; that is, that you understand the problem, you have enough information to solve the problem, the world won't change and so on.

Q2, the ceremony of types itself has a cost. You have to think about it, type it - and you may need to change it. When types ripple through layers of calls, the changes do too.

Note: I don't know the answer. I notice that dynamic languages _seem_ to be becoming more popular (are they? or are they just more publicized?) In a rapidly changing world, it's more important to adapt now than perfect. There's a general trend, that because computers get faster but humans don't, more and more of the work will be transfered to the computer. Dynamic languages do this in the sense that they are less efficient than static languages - on the _assumption_ that speed is the main benefit of static languages. Certainly, the coder has less work to do. Another benefit is that it makes coding accessible to less skilled people (and more skilled people who have less time to devote to a particular task).

There are trade-offs. The first thing is to note what the trade-offs are. The second thing is to note what groups of people use programming languages and for what tasks. The third thing is to ask how those people value those trade- offs, for those specific tasks. e.g. Perhaps sometimes, a crappy, hard-to- maintain, only partially correct solution _now_ is better than a high-quality, clear, correct solution _too late_?

</comment></comment></comment></comment><comment><USER8> This article confuses the reader with a weird implicit definition of modularity. The miscommunication is rooted here:

> Separate compilation allows you to compile parts of a program separately > from other parts. I would say it was a necessary, but not sufficient, > requirement for modularity.

The author goes on to assert that a _requirement_ for modularity is that modules that depend on each other should be able to be compiled independently, without even a specification to glue them together. This just doesn't make sense. This might be a debatable point, but it has nothing to do with modularity.

</comment><comment><USER9> Lack of types gives the _illusion_ of more modularity.

As was mentioned -- there are still dependencies. The only difference is that, without types, checking whether the parts fit together is deferred until later -- but it will still be done. (All parts of software have to be connected, and all have to be consistent.)

And therefore you could argue that types are _pro_ modular: because they allow you to write separate pieces without needing the whole to test if it is OK -- which you cannot do without types.

</comment><comment><USER10> Existential types? The author alludes to this, and then proceeds in ignorance of what he'd just said for the rest of the post.

In Java, all you have for these is interfaces, so it's no wonder people think that types are problematic.

Types aren't the problem. Crappy types are the problem. Not making the types lightweight enough that people can dish them out at their pleasure, that's the problem. When the math don't work well enough, make better maths.

<comment><AUTHOR> Except you can't unpack existential types, right? [http://stackoverflow.com/questions/2300275/how-to-unpack- a-h...](http://stackoverflow.com/questions/2300275/how-to-unpack-a-haskell- existential-type)

<comment><USER2> Unpack in this sense means "unbox", and you can specialize before you hide the type.

</comment></comment></comment><comment><USER11> I disagreed strongly with this post and was about to post a rebuttal, but then I realized there actually is a situation where untyped languages enjoy a concrete, practical advantage because of the lack of compilation dependencies. That situation is when you are writing a module (something that would be a compilation unit in a typed language) that calls missing or nonexistent library interfaces, and you want to test parts of the module that do _not_ depend on the missing APIs. In a typed language, you can't do it. You would have to satisfy the dependencies first so your code would compile, or you would have to copy snippets of your code out of the compilation unit into a REPL or another file so they could be compiled separately. In an untyped language, you can experiment with parts of the module and even start writing tests without having to make sure all of the module's dependencies are satisfied.

Aside from that one advantage, though, it's the same with types or without them. For a module as a whole, the compilation dependencies that exist in a typed language are the same as the runtime dependencies that exist in an untyped language. Whether you're using a typed or untyped language, you can write whatever code you want, but you can't do anything with it until you satisfy its dependencies. With that one exception, of course: in an untyped language, you can run code that _doesn't_ depend on the missing APIs but happens to be in the same module as code that _does_ depend on them.

Overall, I don't think that amounts to much, especially compared to a typed language like Scala where you can copy snippets into a REPL. Or even better, Ensime is an Emacs mode that is supposed to let you work with Scala the way Slime lets you work with Common Lisp. (I haven't tried it myself yet, but it exists, and people are using it for real work.)

<comment><USER12> Yeah I really hated this post. Starts off with a flame-baiting title. Then resorts to very qualified statements to support it. After reading it I'm wondering if it matters at all and I'm feeling dumb all throughout the discussion. :-(

Update: Aarghh, it's just aggravating to read an academic stirring up the pot over some point of theoretical purity. And I love theory too. ;-)

<comment><USER11> It's the worst kind of theory: a theoretical point presented as a practical insight without any explanation of what the practical ramifications actually are.

</comment></comment></comment><comment><USER13> If g returns an x and f takes an x, I can do f(g()) without knowing anything else about type x. Even type inference will choose an x that makes g compatible with f, or complain if there isn't any. So the system is still modular at the source level, which is important because it keeps the project comprehensible. What you don't have is binary-level modularity, but that's just an efficiency hack that dates back to when computers were almost too slow to run compilers. Now it should only matter to people who obfuscate by refusing to ship source (or source-equivalent intermediate files, which at least one Ada and one C++ implementation used to handle separate compilation of polymorphic code) and living with the lack of whole-program optimization.

</comment><comment><USER14> Why not structural typing?</comment>


Netflix personal trainer - <AUTHOR> http://makeit.netflix.com/projects/personal-trainer <comment><USER2> neat! happily surprised to see netflix creating a nice little tinker project like this. More companies should do this.

Also, a nice landing page with the video on the left. They were even kind enough to leave the default scroll behavior! A great introductory doc.

But creating this doesn't change the fact that a lot of netflix content is subpar, nor does it make me less likely to cancel my membership. Which is fine - but don't make this a regular thing, either.</comment>


Craig Wright's proof isn't valid because he uses bash background instead of && - <AUTHOR> https://imgur.com/ZUXBkTt <comment><AUTHOR> The use of & instead of && here means that openssl start running at the same time as the base64 decode command. This means that openssl could start reading from an old version of the signature file before base64 starts writing to the new one.

<comment><USER2> The shell '>' redirect will truncate the file first of all, for example:

      echo "foo" > message.txt ; ( sleep 3 ; echo "bar" ) > message.txt & echo "message: '$( cat message.txt )'"

will print "message ''", not "message 'foo'".

Interestingly, that means that the 'openssl' command might have been working with an empty signature.

Of course, he might have just aliased 'openssl' as 'echo "Verified OK"' ...</comment></comment>


Ask HN: Head First Books? - <AUTHOR>

Hi, im a selftaught programmer. I know how to program VHDL and other hardware programs.
But now i wanna do software programs and they recomend those books. But I cant find those books in my country (I live in Mexico, Tijuana to be exactly) I can go across the border but i dont know where could i buy those books)would buy the ebooks but i just got my lap stolen. any tip or advice where i could get them or any other books you would recommend would really apreciate it <comment><USER2> Hey I'm an editor for Head First, glad you're interested in our books. You can buy direct from O'Reilly and we'll ship to Mexico: <http://search.oreilly.com/?q=head+first>.

Sorry to hear about your laptop. :(

</comment><comment><USER3> Any large chain bookstore such as Barnes and Noble or Borders will probably have several _Head First_ titles in stock.

</comment><comment><USER4> If you look at the right places online, you can find such books.

</comment><comment><USER5> Surely amazon.com ships to Mexico?</comment>


The Leanest Startup in Silicon Valley - <AUTHOR> http://www.inc.com/magazine/201207/leigh-buchanan/the-leanest-startup-kurt-varner-dailytoaster.html <comment><USER2> Repeat after me...You do not have to suffer to build a business. So many stories like this are sensationalized in the media and it convinces so many young entrepreneurs that it's a right of passage to struggle while building a business. It's not true. Yes, other entrepreneurs had determination and some sacrifice...but they most likely didn't suffer so dramatically, nor make their loved ones suffer along with them. Don't fall for the trap. Be smart enough to build a business without the struggle.

Capitalism says that in order to improve your life you must first improve the lives of others. The more lives you improve, the better your life will become. If you eliminate your own self interest of a good life, you have forgotten the biggest reason you are building a product in the first place. You aren't respecting your life, your wife, your business or your customers by doing this.

Stop struggling and build something valuable that people will pay you for. Living out of a van down by the river may get you a few news articles and motivational speaking gigs, but your struggle is not related to your success. I've been there...I've done it. It is irrelevant and unnecessary.

<comment><USER3> Amen. Kindly dead the romanticism of starving and being pushed to the brink...realize the first, last, and only thing that matters is providing a solution for a human want. Period.

</comment></comment><comment><USER4> > "People who aren't successful yet," says Varner, "can do anything they > want."

This is the most important bit of the entire article. While not profound at first glance, this actually is very insightful.

When you don't have anything yet, what really holds you back? Are you going to lose your job? If you don't have one, no biggie. When you live in a car, are you going to get much more in the (pardon the term) gutter? Not really.

Going for it is a great thing.

<comment><USER5> Unless you get in a car accident :-/

</comment></comment><comment><USER6> Why not slap a layer of buzzwords, while keeping your original concept underneath?

Latest fad is turning everything social. Ugg... But, it might get the attention of fad-followers:

DailyToaster: Social wakeup calls. Friends take turn to call you up. They win "points" by getting you to your destination on time. Leader-boards, badges, etc...

Did I say friends? Why not strangers. Plenty of loudmouths. Might as well put them to use. The calls are routed through the DailyToaster call system to prevent spam and protect phone privacy.

Why stop at meetings? Apply this to weight loss, book reading, etc.

</comment><comment><USER7> Oh god. I admire his pluck. But the headline is killing me. Lean != cheap.

Toyota is a major source of the Lean philosophy, and as the world's largest car manufacturer, they spend plenty of money. They just continually seek to deliver more customer value per dollar spent.

</comment><comment><USER8> Direct link to DailyToaster - <http://dailytoaster.com>

More info on my blog - <http://kurtvarner.com>

<comment><USER9> Brilliant. By living in a car, you will have very few distractions, though I wonder how do you get electricity and an internet connection?

<comment><USER8> I wrote about the logistics of everything here (although a few things have changed since this post) <http://kurtvarner.com/post/19347794553/man-car- startup>

<comment><USER10> Sell the Civic get a Toyota Previa - my buddy whose been living in his car for years owns 3! Some people enjoy living in their car, especially if your work requires travel or you like being able to move someplace new easily or just don't want to stress over things like paying rent. That's great Palo Alto wont give you a ticket. I think Walmart parking lots are all safe as well. I always thought an app telling you safe places to sleep in your car or camp for free or even good dumpsters to dive would be a handy thing to have - get in touch if you want to work on it, I doubt its the right audience to get rich off of though :-)

</comment></comment></comment></comment><comment><USER11> Man, I love this guy. I'm not convinced that the idea is big enough to get him where he wants to go, but the moxie, the hustle, the spirit... you can't help but root for somebody like this.

I'm shocked he didn't get into YCombinator, to be honest. Pg always talks about how it's about "the team, not the idea," and if anybody has the moxie to get in as a solo founder, I'd have thought it would be Kurt.

Anyway, Kurt, keep banging away and keep believing! I believe big things will happen for you if you stay dedicated.

<comment><USER12> > you can't help but root for somebody like this.

I can. Dude left his wife three hundred miles away so he can live out of a car to work on his idiotic startup. "Moxie"? I'm sure that's something his second wife will be able to appreciate. In the meantime, I agree with "Herbert": he's a tool, and this moronic stunt is transparent and far from endearing.

<comment><USER11> I'm not a huge Teddy Roosevelt fan, but I think his words fit this discussion quite well:

 _It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat._

<comment><USER12> Those words are appropriate for Elon Musk, not a bum writing a social alarm clock out of his car.

</comment></comment></comment></comment><comment><USER13> Met Kurt at a few meetups and based on his pitch I have to disagree with the "too niche" criticisms mentioned in the article. The number of people, including myself, who have trouble getting up in the morning is a huge market. I'm not sure if his current idea is the right solution, but if he can make me productive during the 30-45 minutes that I spend hitting the snooze button every morning that'd be worth paying for.

My only criticism is that I feel he's ignoring the root of the problem, which is not getting enough sleep. Most people don't have trouble getting up after a nice, long 10 hours of sleep. It's getting up after 4 hours of sleep that's tough. And if Daily Toaster served its function of waking me up quickly after 4 hours of sleep I'd inevitably pay for it later that day/week anyways.

<comment><USER7> Amen. I used to try to control when I woke up by setting an alarm clock. Now I control it by having a regular schedule, getting plenty of sleep and making sure there's bright light, hopefully natural, at the time I want to wake.

It reminds me of when I was a young sysadmin, leaping from emergency to emergency, alarm to alarm. That was fun, but eventually I realized that the maximally lazy approach was to rig things so that alarms were never necessary.

</comment></comment><comment><USER14> Sounds like this guy took War of Art a little seriously.

[http://www.amazon.com/The-War-Art-Winning- Creative/dp/159071...](http://www.amazon.com/The-War-Art-Winning- Creative/dp/1590710037)

As a younger person in college I always felt that being confident enough to move to Silicon Valley and try to get attention you'd have to be able to code a compiler in an interview for a language you've never seen on a machine you were unfamiliar with. Or if you were the artist type you'd produce work universally lauded for both it's execution and creativity. I guess you have to start somewhere, why not here? Oh yeah, 10,000 hours rule that's right. :)

</comment><comment><USER15> I met Kurt for the first time about 4 months ago and have been sharing beers with him since. Definitely a guy with vision, the right kind of work ethic and attitude. Also a very talented Product Designer.

</comment><comment><USER16> Good for him and all, but it's still a questionable product idea. He might be better off spending his 3 months figuring out a product people actually want and then moving up north.

</comment><comment><USER17> Many of us go through incredible hard times and have to make difficult lifestyle decisions, if you can get media attention while at it - more power to you!

</comment><comment><USER18> This guy needs to start a rent-your-car-for-the-night-as-a-bed , an AirBnB for your car. Or a startup that sells kits allowing you to turn any car into a place to live while camping or travelling cross country. Or a startup that sells life-saving kits allowing you to live out of your car for up to x days in case of an emergency.

<comment><USER19> I have seen people renting their cars overnight on airbnb :)

</comment></comment><comment><USER20> I like his drive, but where are his 10,000 hours? I'd at least think you'd be an expert at something before starting a business with zero cash.</comment>


Show HN: Loyalti (loyalty rewards program for mobile phones) - <AUTHOR> http://www.loyaltiapp.com/platform/

<comment><AUTHOR> We've been working on Loyalti for a few months now, and are now actively looking for franchises and stores to partner up with. We'd love to hear feedback on our product and any advice on signing on potential franchises.

</comment><comment><USER2> How are you integrating with all the different POS systems. I'd imagine that is quite a hurdle?

<comment><USER2> Hello?

<comment><USER3> Hey, sorry didn't think this thread made it anywhere. We do POS integration only with chains/franchises, and work with their POS company. The integration itself is very minimally invasive, and you can read about it here: <http://www.loyaltiapp.com/platform/developers/></comment></comment></comment>


Neutrino experiment reveals inconsistency in how matter and antimatter behave - <AUTHOR> https://www.quantamagazine.org/neutrinos-suggest-solution-to-mystery-of-universes-existence-20171212/ <comment><USER2> 1999 article talking a little about historical results and projections for CP violation [http://cerncourier.com/cws/article/cern/28092](http://cerncourier.com/cws/article/cern/28092)

</comment><comment><USER3> Oof, p value misinterpretation:

> That result got the community excited — although most physicists were quick > to point out that with such a small sample size, there was still a 10 > percent chance that the difference was merely a random fluctuation. (By > comparison, the 2012 Higgs boson discovery had less than a 1-in-1 million > probability that the signal was due to chance.)

<comment><USER4> Yep. When reading the actual papers from the LHC, LIGO, etc groups the p-value/significance aspect seems nearly irrelevant though.

My impression is usually they have some set of possible theories that predict the exact result observed, then go on to do more experiments to distinguish between the predictions of those.

Really they should just drop the significance testing because it adds nothing and they don't seem any better at interpreting those tests than other fields. If I am wrong about all this and that aspect actually is crucial, then physics is in trouble...

<comment><USER5> In HEP, it's more that the bar is so damned high, and your n equals something in the billions or trillions, _and_ oversight from the community is extreme. The confidence required for example, to make people feel generally positive about the discovery of the Higgs boson, was in the realm of billions to one. Generally there is a model, and dats needs to fit that model to what would be an insane degree of confidence in most other fields.

There is a bit more to it than just pure sigma values; it is also a matter of how closely the data fits the model overall, a lack of competing hypotheses to explain said data, and to what degree other evidence exists to support the model. Of course, if the theory being confirmed is complementary to existing physics, that also helps a lot. Having said that, 3 sigma is about when people started to get excited about the Higgs, and 5 sigma was confirmation.

<comment><USER4> The problem is that the sigma calculation is only about rejecting the null model (ie, the model of "background noise"). That number is calculated without including info about any theory/evidence regarding the Higgs boson.

So, all of the confidence and confirmation _regarding the Higg 's boson_ better actually be coming from "how closely the data fits the model overall, a lack of competing hypotheses to explain said data, and to what degree other evidence exists to support the model".

As an example, I'd imagine detecting the Higgs boson at 1 eV energy levels is theoretically predicted to be even less likely than billions/trillions to one odds, therefore detector noise would be a more likely explanation for such results, despite the low p-value.

<comment><USER6> >That number is calculated without including info about any theory/evidence regarding the Higg's [sic] boson.

That's not true. You can see plots in the 2011 and 2012 papers that give these calculations as a function of mass. It's basically impossible to make a mass- independent calculation. (Not withstanding the fact that there's no Higgsless theory to do calculations for the background).

>As an example, I'd imagine detecting the Higg's [sic] boson at 1 eV energy levels is theoretically predicted to be even less likely than billions/trillions to one odds, therefore detector noise would be a more likely explanation for such results, despite the low p-value.

You're right, the p-value is much lower. Previous experiments have long since excluded such a low Higgs mass. Also, if the Higgs mass were so low, we probably wouldn't exist.

<comment><USER4> 1) Typos fixed.

2) "That's not true. You can see plots in the 2011 and 2012 papers that give these calculations as a function of mass."

\- Can you explain what you mean via figure 1 in this paper: [https://arxiv.org/abs/1207.7235](https://arxiv.org/abs/1207.7235) ?

\- I don't see the relevance of calculating p-values as a function of mass to my comment

3) "Not withstanding the fact that there's no Higgsless theory to do calculations for the background"

\- Then what model did they use to calculate the p-values? (I do not know the details but am fairly certain it is one where there is no Higgs boson at any given mass)

4) "Also, if the Higgs mass were so low, we probably wouldn't exist."

\- Ok, but I've also read headlines like "CERN proves the universe shouldn't exist", clearly this is just because their model of the universe is wrong. I'm sure in a pinch people could come up with some kind of balancing out of whatever problems would arise from such a small Higgs mass. The point was that _assuming the current theory is correct_ , the Higgs would be a much worse explanation than detector noise.

<comment><USER6> RE 2: What I mean is that "N-sigma" and local p-value are being used interchangeably, which you can see from this plot. There's no "number ... calculated without including info about any theory/evidence regarding the Higgs boson".

RE 3: The model used to calculate the background are unphysical in the sense that they set the Higgs production cross section to zero without changing anything else. There's no physical Higgsless theory.

RE 4: I was agreeing with you and adding some facts.

<comment><USER4> >'What I mean is that "N-sigma" and local p-value are being used interchangeably, which you can see from this plot. There's no "number ... calculated without including info about any theory/evidence regarding the Higgs boson".'

Sorry, I still don't see what information is being used that requires theory/evidence regarding the Higgs boson. Whether or not anyone knows about the Higgs boson they could be plotting p-value by mass for these experiments.

>"The model used to calculate the background are unphysical in the sense that they set the Higgs production cross section to zero without changing anything else. There's no physical Higgsless theory."

So they actually change their model to be surely false, then go on to prove the known false model they just created... is false. This is pointless.

<comment><USER7> > they could be plotting ... by mass

he was saying, the mass calculation depends on the theory about the higgs? they can't just put it on a scale :)

<comment><USER4> You may be right on that point. For some reason I was thinking they just summed up the velocities, etc from whatever hits the detector. Perhaps somewhere they assume something about the Higgs boson though.

This makes the significance testing they do even more ridiculous though. At first I thought the model of background noise was simply not providing much info about the topic of interest: the existence and mass of the Higgs.

According to what I have learned here, it is much worse. Not only are they testing a purposefully rendered false model (and taking rejection of that known-false model as evidence for the Higgs), but they are also assuming the Higgs exists (and has whatever properties you all are referring to) as part of this process. As a result, the Higgs exists either way (whether background model is rejected or not) according to this process.

Doing this test sounds pretty meaningless to me.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> How can they know they detect their neutrinos not the neutrinos travelling through space and passing earth as if it wasn't there?

Sine we are living in matter dominated region of space it would stand to reason that most stellar neutrinos that pass through us are matter neutrinos.

<comment><USER9> They can infer the momentum of a detected neutrino from the detector data, which lets them statistically distinguish neutrinos coming from the beam they control (controlled direction and energy) from background noise (e.g. neutrinos from the sun).

<comment><USER8> What about neutrinos from outside of the solar system?

<comment><USER9> I don't know what biases there are in the distribution of such neutrinos, but the basic idea still holds, which is that they have a specific source of neutrinos they're looking out for and neutrinos of other origins will only look like they're from that source very seldom. They can infer the origin of the neutrinos based on the direction from which they entered the detector and how energetic they are.

<comment><USER10> The Super-Kamiokande detector is useful for neutrino detections generally, and they calibrate it from time to time using various devices, and have been for decades (!).

[https://arxiv.org/abs/hep-ex/9807027v1](https://arxiv.org/abs/hep- ex/9807027v1) [1998]

The T2K experiment is in a way essentially another calibration system. It of course has its own overview page at [http://t2k-experiment.org/t2k/](http://t2k-experiment.org/t2k/)

</comment></comment></comment></comment></comment><comment><USER11> "Experts believe that neutrinos and anti-neutrinos have super heavy counterparts" \- is this one about supersymmetry?

Then, "some experts" not "[all] experts" since supersymmetry is not universally accepted with its lack of evidence.

<comment><USER5> Definitely. ADMX for example, is searching for axions, under the assumption that WIMPs or sterile-heavy neutrinos are he wrong bet. Having said that, SUSY is still very popular, albeit unsupported by evidence. Critically for proponents of supersymmetric theories, they have also not been ruled out, and nothing else has been ruled definitely in.

</comment></comment><comment><USER12> Maybe to lower down expectations we should have two names: Universe existence and Universe formation.

Universe formation is how the universe "formed".

Universe existence is how the universe come to exist out of nothing.

The article and neutrino experiment talk about the former. The latter is more interesting, though.

<comment><USER5> The latter feels like a classic case of questions for which the answer is unhelpfully, 42. That is to say, do we even know what the question is? We have no real reason to believe that the universe came from nothing, or that nothing exists in a way that isn't purely Conceptual. Certainly all of our explorations into the nature of nature indicate complete absence of nothingness, which may go someway to explaining the popularity of theories which don't require it. Cyclic universes, cyclic ekpyrotic universes, multiverses and more all essentially attempt to reframe the question on nature's terms, not ours.

So it's interesting to think about, but there are reasons to believe that humans will always lack the tools to find the answers. Imo that makes it feel like questions about the existence of god, or an afterlife. They are important and have massive bearing on our existence, but I doubt in our ability to answer them, or even to ask the right questions in the first place. In that sense, they're less interesting than questions we can actually formulate and hope to answer, like the "hows" rather than the "whys" of existence.

<comment><USER12> Nothing is a concept; therefore it should exist, no? The only possible exception I can think of is if concepts are actually physical the way physical reality is.

<comment><USER13> In classic physic, nothing is a concept true, in quantum physic with the foam of virtual particles coming from the void (see casimir effect) 'nothing' is a much nebulous concept!

</comment></comment></comment></comment><comment><USER8> How do they produce exactly same number and energy distribution of muon neutrinos and antineutrinos?

</comment><comment><USER14> What a terrible headline.

<comment><USER15> Why? It sums up perfectly the article. The existence of the Universe IS a mystery. And the article is about neutrinos.

<comment><USER14> There are mysteries in the universe that may be solved through a discovery about neutrinos. But the mystery of the _very existence_ of the universe itself cannot be solved by appealing to the existence of some other contingent object within the universe.

<comment><USER15> Let's go one step at time. Matter and antimatter should be created in equal way and they annihilate once they bump into each other. This very fact should raise an eyebrow that no matter should exists, but clearly does. If we solve this mystery then we can go further another step.

<comment><USER16> If they would simply be annihilated after being created, why be created at all?

I feel like somehow, we are way off in our understanding of the universe and how it works. There are so many unanswered questions, such as:

1) If the big bang created space and time as we know it, what was there before that?

2) Why did the big bang suddenly occur 14 billion or so years ago? Why not a couple billion years before or after that?

I know that the steady state theory of the universe has fallen out of favor, but I wonder if some appeal could be made to some kind of fundamental force that has always existed and always will, which behaves with fluid dynamics, and the "islands" of matter that we experience are actually some kind of fluctuations in that fluid.

<comment><USER7> 1) The canonical answer is: there was no before, the singularity happened at delta_t=0. It is a mathematical construct resulting from extrapolating a physical model backwards in time which somehow converges. I'm not sure its not just convention. The big bang didn't create space time. It _is_ space-time indeed and we know nothing (absolutely nothing, I believe!) about an object that has no spacial or temporal extend. All they are interested in is a few seconds after.

And the other big point is that our concept of time might be flawed. Maybe in relativistic terms, from our point of view it was a few seconds, but it actually took an eternity and you could keep observing closer and closer to the origin (in the diagrammatic sense) but never reach it, so who even cares, still? So, in a way more easily grasped by humans, it would be more apt to say, there is no _after_ , because we will possibly never get _behind_ it in our way forward. Does that seem sensible to you?

2) Because that's when the size of the universe in the calculation reaches plank scale? I'd like some correction because I have read before that plank scale is not actually a hard physical boundary, but I believe we just don't have the tools to say anything about that time with any certainty. And don't be mistaken, there are loads of competing theories and all have warts, paradoxes and open questions. Such is life, ironically, which I still think is a comfortable closure.

</comment></comment></comment></comment></comment></comment><comment><USER8> Can nothing influence rate of oscilations of neutrinos?

I have trouble accepting CP symmetry violations.

<comment><USER17> > I have trouble accepting CP symmetry violations.

Universe does seem to exist, though, doesn't it?

How would you explain that without CP symmetry violation?

<comment><USER8> > How would you explain that without CP symmetry violation?

My preferred explanation is that areas dominated by matter and anti-matter got pushed away far apart by the energy of annihilation between them, universe is much larger than observable universe and our galaxy, neighbouring galaxies, possibly even whole observable universe belongs to region that was dominated by matter that is now separated from anti-matter dominated ones with sufficiently large and empty void.

I don't exactly buy the idea that all of the matter was at the beginning in one geometrical point, and exactly uniform. Background radiation is not exactly uniform so imho not all places in space had exactly the same amounts of matter and anti-matter either.

<comment><USER18> The geometrical point you refer to is a projection, not an empirical fact. PBS has an excellent YouTube series called _Space Time_ , which describes the Big Bang cosmology in some detail, in several episodes. I'm not exactly sure which ones, but I could track them down if you like. However, I might recommend the entire series; you might be able to refine your speculation somewhat.

</comment></comment></comment></comment><comment><USER19> My impression as a layman is that quantamagazine.org is leaking a lot of ... ambitious ... physics headlines into HN; I've kind of stopped clicking on them after the first few.

Physicists in the audience, is that an accurate assessment or should I go back to excitedly clicking through when I see them?

<comment><USER20> I work for a physics journal and when we make articles for the public to describe findings we have the opposite problem when it comes to authors. Scientists especially in theory are reluctant to ascribe much at all to their research other than the phenomenon shown. In research this is a good thing, but when we want to show the public what these very theoretical or specialist discoveries mean to our total understanding of physics it is not as helpful. Just getting anyone to speculate what a finding means is hard.

In this case, this is something that might explain a CP violation that can explain why we exist in a universe of matter. To a physicist, explaining it is a CP violation is grandiose enough. But in reality the title is not at all misleading as CP parity is one of the biggest unsolved problems in physics, and yes it is a mystery as to why we have a universe of matter that exists. So while it may seem ambitious to a person in the field, it is indeed truthful and exciting research.

<comment><USER21> Quite simply, when the specialist tell you that it is not news worthy, then it is probably not news worthy. Otherwise we get all these new particle discovered clickbait, where the journalists just neglect to mention that the "particle" in question is a compound state that was well studied in the 60ies or that the particle in question is just an oscillation mode of a crystal. (I am not joking, both are examples that were well upvoted on HN.)

And that is just the ideal case, where journalists report on experiments. In theory most articles are just as interesting as someone created a branch on a github project, that is the very first step towards something that may develop into something interesting, or it may not.

So yeah, "just getting anyone to speculate what a finding means is hard," because everybody knows that science journalists try to feed the public bullshit. Seriously, every single climate change denier I ever discussed with has given me page after page of links to popular science reporting where the entire problem was, that the journalist found someone who was willing to speculate and these speculations turned out to be wrong.</comment></comment></comment>


Ask HN: Why isn't logic intuitive to some of us? - <AUTHOR> I struggled at logic and proofs. I struggled at Discrete Mathetmatics and Theory of Computation.<p>I felt so stupid in those classes, and was demotivated and never put forth any effort. Why isn't this stuff naturally intuitive to some of us? Is the only way to get better at it is to just grind it out and wait till it clicks? Why can't I just see it and get it? Is it because I must learn the language like how one learns the english language? <comment><USER2> It's math. Some put less effort and some put more. But all put effort in it.</comment>


Girls' Life vs. Boys' Life? Magazine Cover Sparks Uproar - <AUTHOR> http://www.mprnews.org/story/2016/09/23/books-girls-life-vs-boys-life-magazine-comparison <comment><USER2> The problem is that with all of the bullshit aside, they need to sell the magazine to some dwindling population still buying them.

The "heartwarming", positive cover is indeed heartwarming and a good message, but is also pretty lame, and unlikely to sell magazines.

I also question whether this is typical shallow/ignorant internet outrage. When I was a kid, Boy'a Life was a Boy Scouts magazine, and had annual themes that appeared every year at the same time. If you looked at the May/June cover, the annual Boy Scout Jamboree issue wouldn't be as "internet offensive".

</comment><comment><USER3> IIRC, Boy's Life magazine is run by a boy scout organization while Girl's Life is run by a corporation chasing for the most eyeballs possible.

<comment><USER4> It's mentioned in the article. Boy's Life actually has a noble mission behind it, whereas Girl's Life is for-profit trash (essentially). The parallelism between the names of the two is an unfortunate coincidence. Near as I can tell the Girl Scouts don't have a magazine, but if they did, it would be a better comparison against Boy's Life. Maybe they should publish one?

<comment><USER5> As an aside, The Girl Scouts is a really fantastic organisation. In particular compared to The Boy Scouts in the US (which is much more religiously affiliated and discriminates against gay people; The Girl Scouts by contrast are trans-inclusive).

<comment><USER6> I was never in the Scouts myself, but surely one archaic, discriminatory policy doesn't negate all of the good the organization does, right?

</comment></comment></comment></comment><comment><USER7> Maybe it's just my lack of need for external influence, but why is this a big deal? I think women can and should be whatever they want to be. A trashy magazine shouldn't change that.

Should A Girl's Life change the tone of their stories? That's up to the market. As long as their demographic enjoys what they print (which translates to $$$), they'll continue to run it. Should people be outraged by it? If they choose to be, yes. But at the end of the day a consumer is a consumer, and if they want trash they'll get it.

<comment><USER8> I can not provide links right now, but reading up on "stereotype threat" will probably explain why this still matters.

I a few words: the same person performing the same task will perform lower if they are aware of a stereotype that says that their group performs worse at the given task. It is reproduced for white and black, male and female, etc.

<comment><USER9> But why would that mean anything to the publisher? They want to sell the magazine and if soul crushing mind rotting stereotypes sell copies at the checkout line then why would the publisher want to be the moral agents of change?

<comment><USER8> Fair point. My personal answer, that I do not try to push on others, is that we all should try to be agents of change. To be fair to the publisher they made it clear that they have quality content next to the cheap content.

</comment></comment></comment></comment><comment><USER10> There are plenty of men's magazines that will offer you a "denim checklist."

</comment><comment><USER11> This is indeed a humorous juxtaposition, but they wouldn't make crap like that if our society didn't gobble it up.

</comment><comment><AUTHOR> Why was this flagged?

<comment><USER8> Some of the flagged comment in the discussion were very sexist. The rest of the flagged comments were people a bit aggressively calling them out. I guess all the up and down voting triggered a flame war detector.

Which is really sad, I really hoped we can all agree that your sex does not determine whether you are a good engineer.</comment></comment>


Top 7 indicators of consumer internet success (Startup Review) - <AUTHOR> http://www.startup-review.com/blog/top-7-indicators-of-consumer-internet-success.php <comment><AUTHOR> ad "7\. Story that lends itself to mainstream PR": Dabble Db used Smalltalk as initial marketing vehicle, so maybe "Story that lends itself to fringe (with fanatical users) PR" could also be a valid strategy...</comment>


A Short Introduction to the Art of Programming (1971) [pdf] - <AUTHOR> https://www.cs.utexas.edu/users/EWD/ewd03xx/EWD316.PDF <comment><USER2> Quite an insightful thought for 1971:

"With the advent of what is called "large scale integration" (being a term from the computer field, its acronym LSI is better known!) it seems to become technically feasible to build machines more like "clouds of arithmetic units" with information processing activities going on simultaneously all over the place, for shorter periods of time even independently of each other. Programming for such machines will pose completely different trade-off problems: one will be willing to invest in potentially useful computing activity before its actual usefulness has been established, all for the sake of speeding up the whole computation. But although I know such machines may be coming, I shall not touch these problems for the following reasons. First, as far as general purpose applications are concerned, I have my doubts about the effectiveness with which such forms of parallelism can ever be exploited. Second —and that is the most important consideration— parallel programming is an order of magnitude more difficult than sequential programming."

Also, the first mention of "cloud", although with a different meaning.

<comment><USER3> That's right, this is more a description of how speculative execution works within modern processors (a quite familiar topic lately thanks to Meltdown, Spectre & co.).

<comment><USER4> Except the author was assuming manual scheduling where today speculative execution is mostly done transparently in hardware (barring failed general purpose VLIW attempts).

<comment><USER5> There's no assumption of manual scheduling in that text.

</comment></comment></comment></comment><comment><USER6> It's really eye opening to read something like, knowing it was written in 1971:

 _> It is not unusual —although a mistake— to consider the programmer's task to be the production of programs. (One finds terms such as "software manufacturing", proposals to measure programmer productivity by the number of lines of code produced per month etc., although I have never seen the suggestion to measure composer productivity by the number of notes, monthly scribbled on his score!)._

47 years later, a lot of people still measure programming productivity by LOCs. Hell, even major freelance marketplaces try to track your every billed second by taking screenshots of your desktop or webcam "just to make sure you're working".

<comment><USER7> A big part of the problem IMO is the software development community has gravitated toward rate compensation instead of product compensation. A composer is commissioned to deliver a product and is compensated for said product, not for the time he/she worked to create the product.

This was real eye opening for me when I did contract/consultant work, even as a 1099. I can understand the enterprise, butts in the seat model of developers being on retainer but for contracting houses I don't get it.

If developers don't want to be bound by these metrics they need to get better at forcing the client into contracts for deliverables with clearly defined acceptance criteria. Also, it seems to me that the best way to get proficient and creating and updating these contracts is by having to work twice as long to deliver a work product as was initially estimated.

<comment><USER8> I'm not very optimistic that we'll ever be able to reach that utopian state, though. After all, the only person in the fixed-bid equation with any incentive to nail down requirements up front is the developer - it's in the best interest of the buyer to be as vague as possible so that they can defer actually making any decisions until they've had a chance to see the finished product, when the consequences of the decisions are most obvious. Then they can turn around and say, "the requirements clearly state that..." or in other words, you're going to be working for free. Once you get up into even five- figure bids (never minds something that might take a year to deliver), the people writing the checks are happy to put more effort into deliberately obscuring the requirements gathering process than actually gathering requirements, just to keep their options open, and they have a legal department that you don't.

<comment><USER7> I hear what your saying but there's a whole host of other fields that seem to pull it off. Other than the fact that software is not bound by physical constraints, I really don't see the major differences.

I think we're just fighting the "always done this way" mindset.

<comment><USER6> A lot of developer contract work doesn't fit into a fixed bid model.

What if someone hires you as an ongoing general problem solver?

I've had many contracts like this for 4-5 months where they just threw problems at me and expected me to think of a solution and then implement it.

This could be anything from little scripts to make development better, ops / deployment improvements, better docs, being a 2nd set of eyes for pair programming, etc..

Something like that isn't really possible to plan out, so paying by the hour makes sense.

On the other hand, I do fixed bid pricing on a lot of things when it makes sense. I sometimes even do a hybrid approach where it starts as a fixed bid and ongoing maintenance becomes hourly.

<comment><USER9> Something I'm forced up against frequently at a company that provides fixed bids for projects and refuses to bill anything hourly: How do you determine a fixed bid for fixing or modifying an existing product you're unfamiliar with?

If a client comes in and says "one out of every 50 times you load a page in this web app, it renders a blank page, how much is it going to cost to fix?" what do you say?

Every hour you spend investigating or familiarizing yourself with the problem is basically just spec work with all the risk that entails. In many cases when you're "fixing" something, the project could be entirely spec work as you spend 8-16 hours determining that the problem is simply a misconfigured setting that will take 5 minutes to flip.

Clients very rarely (in my experience, never) specify problems to a degree sufficient to create a concrete scope of work, and they're not going to pay you hourly to do so.

If I take my car to a mechanic and say "it makes a funny rattle sound, how much will that cost to fix?" he's not going to give me a fixed bid.

<comment><USER6> The more unfamiliar it is, the more inclined I would be to use hourly billing. In your blank page example I would bill by the hour.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> For those who prefer a plain text version, start reading from [1]

[1] [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD316.html)

<comment><USER11> I'm quite surprised that the original PDF wasn't handwritten anyway, as Dijkstra really seemed keen on that (and back in the olden days, I remember some kind of PostScript module that faked this)

<comment><USER12> I think you're thinking of the "Dijkstra" TrueType font (available from zillions of places. I remember there being different versions, so it probably is worthwhile to download a few and pick the largest (or, better, to inspect them for their glyphs))

<comment><USER11> I definitely remember it being in PostScript (back in the days when that was much more prevalent in Linux and I actually used jwz' scripts to print CD cases).

It might be this [http://ftp.math.utah.edu/u/ma/hohn/linux/misc/quickscript/di...](http://ftp.math.utah.edu/u/ma/hohn/linux/misc/quickscript/dijkstra.qs)

If so, that appears to be a regular vector font, too, no random deviations or letter variants to make it appear more handwritten.

</comment></comment></comment></comment><comment><USER13> > _The market is already so heavily overloaded with introductory texts on > computers and computer programming that one must have rather specific > reasons to justify the investment of one 's time and energy in the writing > of yet another "Short Introduction to the Art of Programming"._

In 1971? I seriously doubt that...

> _[people] who identify the programmer 's competence with a thorough > knowledge of the idiosyncrasies of one or more of the baroque tools into > which modern programming languages and systems have degenerated_

This, however, is as valid as ever...

<comment><USER14> In 1971 there was already 15 years of FORTAN books, and 10 years of ALGOL and COBOL books

<comment><USER13> All 100 of them?

Today we have more books than all those FORTRAN and ALGOL and COBOL books combined just for a single language, like Python or Ruby.

<comment><USER4> Landin's "next 700 programming languages" seminal paper was done in 1965 you know. If anything, there was probably more variety in the 70s computing scene (books, languages, and so on) than there is today.

</comment></comment></comment></comment><comment><USER15> Not directly related, but here's a short documentary on his life and career (Dutch spoken, English subtitles): [https://m.youtube.com/watch?v=RCCigccBzIU](https://m.youtube.com/watch?v=RCCigccBzIU)

</comment><comment><USER16> Still a good read (from 1971 then with .pdf Adobe Acrobat optimized). The Towers of Hanoi simulation section brings back memories of an old Wang 2200 Basic machine (64K as I remember) buried in storage at my old prep school which we managed to bring back to life (more or less) . Decided to write a Towers of Hanoi game using its available box graphics, which could be animated but which quickly taught the maxim: write forward then erase behind (otherwise the imagery appears jumpey). The results were similar to the 'Towers of Hanoi' app now on ROKU 4. But how to add an animated 'solve' function? Raw strings (for 2: top small 1 -> 2, top small 1 -> 3, top small 2 -> 3) ate up too much memory beyond 7 (2^n - 1 = 127) so system analysis suggested: give the smallest box a life of it's own and if total number of discs to be moved is even, script the smallest to follow a path 1 -> 2, 2 -> 3, 3 -> 1, 1 -> 2 etc. for first then every other move. If total number of discs odd, script it a path 1 -> 3, 3 -> 2, 2 -> 1, 1 -> 3 etc for first then for every other move (until you're done). Each next alternate move is any valid move (top smallest on any other column move to any other column with no disks or with column with top disk larger than that one). Seem to recall Martin Gardner had a similar solution in an old Scientific American 'Mathematical Games' article.

</comment><comment><USER17> "The sole reason one likes to write is insufficient..."

Interesting that they did not seem to want to attract people who just enjoy programming..

<comment><USER18> That's in the context of writing the text, not of writing programs. So I'm not quite sure what your point is.

</comment></comment><comment><USER19> this is a smart dude, he invented one of the most popular algorithms of finding a shortest path in a graph.

<comment><USER20> ...to say the very least! From [1],

> His fundamental contributions cover diverse areas of computing science, > including compiler construction, operating systems, distributed systems, > sequential and concurrent programming, programming paradigm and methodology, > programming language research, program design, program development, program > verification, software engineering principles, graph algorithms, and > philosophical foundations of computer programming and computer science. Many > of his papers are the source of new research areas. Several concepts and > problems that are now standard in computer science were first identified by > Dijkstra or bear names coined by him.

[1] [https://en.wikipedia.org/wiki/Edsger_W._Dijkstra](https://en.wikipedia.org/wiki/Edsger_W._Dijkstra)

<comment><USER21> Did someone say semaphores?

[https://en.wikipedia.org/wiki/Semaphore_(programming)](https://en.wikipedia.org/wiki/Semaphore_\(programming\))

<comment><USER22> Semaphores are great for creating simple read-write locks.

</comment></comment></comment></comment><comment><USER23> the name should be Edsger</comment>


A Chinese-built replica of the Titanic will set sail from Dubai in 2022 - <AUTHOR> https://www.fastcompany.com/90255590/a-replica-of-the-titanic-will-set-sail-from-dubai-in-2022 <comment> java-man Do they use a Chinese-built replica of binoculars?

</comment><comment><USER2> Will steerage accommodations be available?</comment>


Covid-19: What do we know about "long Covid"? - <AUTHOR> https://www.bmj.com/content/370/bmj.m2815 <comment><USER2> We really need two things:

1\. Better systems for preventing transmission of disease generally as our cultural default.

2\. Better models for helping people genuinely recover, something modern medicine doesn't actually address for most diseases.

We have physical therapy for certain injuries. We don't really seem to have something similar for infections. We think just treating the infection per se is all we need to do. We generally do not school people on how to resolve the issues left behind from antibiotic use, chemotherapy, etc.

<comment><AUTHOR> 1: Masks! that seems to work.

2: Physiotherapy? Yoga?

3: there are articles about rehabilitation centers for ex-covid patients, in europe + UK at least.

<comment><USER2> 1\. Are you suggesting masks as a cultural norm for all eternity? I hope not.

I'm talking about sustainable permanent changes. I like contactless takeout, like Little Caesar's pizza portal as one example.

2\. Neither of those are for infections per se.

3\. Thanks. I will look for such, but it probably sucks if the past 55 years of my life is anything to judge by.

<comment><USER3> > 1\. Are you suggesting masks as a cultural norm for all eternity? I hope > not.

Well in some Asian cultures it was already normalized to wear a mask when you have any kind of symptoms of anything contagious. I was hoping that convention would move west even before this pandemic happened -- so I hope it stays with us.

<comment><USER2> I think we are already far too accepting of the idea that it's just normal to be germy and ill. I wish that expectation would change. I don't think it has to be that way.

<comment><AUTHOR> There is a war between your immune system and your environment, with constant escalation. Every time people meet they exchange germs. Most often it's something your immune system has already seen, but sometimes you're tired or it's something that's mutated or that's brand new.

Unless we live in a literal bubble with filtered air, we're going to be germy.

The safest way to not be germy is likely to live in a sunny dry place away from people but then it's usually hot and maybe amazon doesn't deliver.

<comment><USER4> True eradication of most germs is probably impossible, given how hard it was for smallpox and how hard it currently is for polio. But I don't think there's any inherent reason why all remotely serious diseases couldn't be driven to the level of tuberculosis - something that exists, endemic in every country, but at such a low level that most people have no real expectation they might catch it.

<comment><USER5> We can treat tuberculosis with antibiotics. Do you think we can just do the same thing with e.g. malaria? The only diseases we've eliminated have been from vaccines, and the diseases we control tend to be from either relatively easy behavioural changes or medicine.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> "nearly nine in 10 patients (87%) discharged from a Rome hospital after recovering from covid-19 were still experiencing at least one symptom 60 days after onset. "

I don't understand how this illness is not taken more seriously in the west given how little we know about it and what little we know tell us it's not a recover / die kind of illness and more like a bell curve with recover / suffer forever / die and suffer forever seems to be the fat part of it.,

<comment><USER6> Wouldn't you expect long-term side effects from hospitalization that likely involved a ventilator and sedation? Not an expert here. Maybe someone else can chime in?

<comment><USER7> This is presumably only one aspect of "long Covid", but a study [0] that was making the rounds a couple weeks ago found this (quoted from the accompanying editorial)[1]:

> _"In 100 recovering patients included in the study, 67% of whom recovered at > home, evaluated a mean of 71 days after confirmed COVID-19 diagnosis, 78% > had demonstrable cardiac involvement via cardiac magnetic resonance imaging, > 76% had detectable high-sensitivity troponin, and 60% had evidence of active > myocardial inflammation by abnormal native T1 and T2."_

> _"...if this high rate of risk is confirmed, the pathologic basis for > progressive left ventricular dysfunction is validated, and especially if > longitudinal assessment reveals new-onset heart failure in the recovery > phase of COVID-19, then the crisis of COVID-19 will not abate but will > instead shift to a new de novo incidence of heart failure and other chronic > cardiovascular complications._ "

In other words, even mild cases of Covid-19 are very frequently resulting in heart inflammation and other forms of cardiac injury.

[0]: [https://jamanetwork.com/journals/jamacardiology/fullarticle/...](https://jamanetwork.com/journals/jamacardiology/fullarticle/2768916)

[1]: [https://jamanetwork.com/journals/jamacardiology/fullarticle/...](https://jamanetwork.com/journals/jamacardiology/fullarticle/2768915)

[2]: (another editorial, easier read) [https://www.statnews.com/2020/07/27/covid19-concerns- about-l...](https://www.statnews.com/2020/07/27/covid19-concerns-about- lasting-heart-damage/)

</comment></comment></comment><comment><USER8> If you're interested in or even doubting the long term effects, follow one of the larger (91k+ and growing) survivor groups [0]. It is anecdotal, but the stories are very real and quite intense. Even odd things that you don't hear about in the news, like excessive burping [1] and of course, the heart breaking children tag [2].

You don't want this thing if you can help it.

[0] [https://www.facebook.com/groups/COVID19survivorcorps/](https://www.facebook.com/groups/COVID19survivorcorps/)

[1] [https://www.facebook.com/groups/COVID19survivorcorps/search/...](https://www.facebook.com/groups/COVID19survivorcorps/search/?query=burping&epa=SEARCH_BOX)

[2] [https://www.facebook.com/groups/669615740453955/post_tags/?p...](https://www.facebook.com/groups/669615740453955/post_tags/?post_tag_id=704593920289470)

<comment><USER9> Groups like that are always populated by people with the worst of the worst outcomes. There's no indication of how likely these problems actually are.

<comment><USER10> On the other hand, those with conditions like fibromyalgia and chronic fatigue syndrome were relegated to groups like that and it's only been as of late that they've been taken more seriously. We're unfortunately seeing the same thing happen to a lot of legitimate pain patients, as they're easier to dismiss than those with obvious presentations of symptoms.

</comment></comment></comment><comment><USER11> The reports of pulmonary, neurological, and cardiac damage are pretty troubling.

Ed Yong's Atlantic article about long-haulers is excellent: [https://www.theatlantic.com/health/archive/2020/06/covid-19-...](https://www.theatlantic.com/health/archive/2020/06/covid-19-coronavirus- longterm-symptoms-months/612679/)

Eric Topol's twitter is an excellent source for Covid science coverage: [https://twitter.com/EricTopol](https://twitter.com/EricTopol)

</comment><comment><USER12> More and more it's clear to me that the appropriate historical analog to Covid19 is not the spanish flu. It's polio.

<comment><USER13> Notably, there is still no curative treatment for polio. If you do contract it, it's still a roll of the dice whether you recover fully or develop paralysis.

<comment><USER12> and a ~10% CFR, whoof.

<comment><USER4> Although a direct comparison is hard, because most polio cases are believed to be asymptomatic but broad screening is less common.

<comment><USER12> well, the first part of that's shared, anyway.

</comment></comment></comment></comment></comment><comment><USER14> I know of at least one "long hauler." The descriptions they give are horrific.

</comment><comment><USER15> Welcome to the newest "pre-existing condition" in American health care.</comment>


Google brings nonbinary emoji to Android Q - <AUTHOR> https://www.cnet.com/news/google-brings-nonbinary-emoji-to-android-q/ <comment><USER2> I like the classic yellow blob design. It's undeniably neutral regardless of race, age or gender. Everyone used it until, well, one day someone told us that we should triggered by it.

When you start diversifying, _it never ends_ because you cannot include everyone and someone always, _always_ feel left out. At least Facebook emoji is still the yellow blob though. :)

I think this, in some way, a common cycle for things. When thing start to get uniform, we tends to break it apart, and when things began to spin out of control, we try to unify it again.

and the cycle continues...

</comment><comment><USER3> The problem for me is that we've gone and complicated the heck out of Unicode and...chat has largely moved on from Unicode.

Now, I am way more likely to text a Bitmoji or "sticker" or whatever, none of which have any dependence on Emoji.

<comment><USER4> >chat has largely moved on from Unicode.

I don't understand this; how so? And on to what encoding has "chat" moved?

<comment><USER5> I believe the poster was referring to the trend of casual messaging—not specifically chat—taking on more of a memic composition in the form of images, GIFs, and the like.

</comment></comment></comment><comment><USER6> How about we just keep using the original bald yellow smiley faces? No race, no gender, just emoticons.

<comment><USER7> Yes please

or lets just have it all and stop worrying so much (so lets have these ungendered ones, sure, but lets also have a real gun emoji)</comment></comment>


Dear Microsoft [from Slack] - <AUTHOR> https://slackhq.com/dear-microsoft-8d20965d2849 <comment><USER2> Previous discussion [1].

        Dear Microsoft (slackhq.com)
        87 points by davidhariri 11 hours ago

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

</comment><comment><USER3> I use slack every day and have no problems with it. This letter has so much wrong

> First, and most importantly, it's not the features that matter.

Yes, yes it very much is. Do you think people would use Slack if it was bare bones?

> The revolution that has led to millions of people flocking to Slack has > been, and continues to be, driven by something much deeper.

I have no idea what this "revolution" is. What exactly is the deeper meaning?

> Second, an open platform is essential

Says the team making a closed source app with an api. Nothing Microsoft can't do.

> We're glad you're going to be helping us define this new product category

Group chat isn't new.

</comment><comment><USER4> I'm not a user of Slack (solo dev) so I guess I'm not the target audience for this. But I am I wrong in feeling that this comes off as completely lame?

To me it reads as weirdly premature desperation conveyed in a condescending tone.

<comment><USER5> Yeah, it's really weirdly passive-aggressive and lame. Condescending is a good way to describe it.

I use Slack in a small 5-person company and generally dislike it. The desktop app is horrible. Why does a chat app need 400MB of RAM anyway? It also doesn't let me customize the font—or really much of anything—not a dealbreaker, but a bit annoying. So basically I use Slack in a browser, which is at least usable. Entirely and easily replaceable though.

<comment><USER6> Isn't the desktop app just a chrome browser plugin? With its own starting point?

<comment><USER7> It's an Electron app.

</comment></comment></comment></comment><comment><USER8> That was a lot of words just to publicly display that they're scared. Who approved this PR disaster?

</comment><comment><USER9> This is one of the more bizarre press releases I've read in a while.

<comment><USER10> I'm reminded of when Apple welcomed IBM to the PC a business.

[http://blog.vdcresearch.com/.a/6a0115714871cc970c01a3fd332bd...](http://blog.vdcresearch.com/.a/6a0115714871cc970c01a3fd332bda970b-pi)

</comment></comment><comment><USER11> Translation: we just collectively shit ourselves.

</comment><comment><USER12> That genuinely left me scratching my head. What a weird passive aggressive press release.

</comment><comment><USER13> I'm not entirely sure what the point of the release is, it also feels sort of passive aggressive to me

</comment><comment><USER14> Slack = Dropbox. They don't own the stack. Their chat app is worthless to all the real companies, i.e., non-SV funny money (which btw is 99.9% of the world's purchasing power), who are living in msft or google products and don't want to click into some incompatible app they won't be able to rally others around because it's not recommended by IT.

</comment><comment><USER15> i think it's funny their final point was "slack is here to stay".. as if their explosive growth over the last year - which involved many companies switching out their existing chat service for slack - could not be repeated next year to another destination.

</comment><comment><USER16> I had no idea Microsoft released a chat client until I read this article.

Microsoft should send Slack some flowers and a thank you card for the free marketing.

</comment><comment><USER17> I'll admit that i don't use slack...but it would have come across as more respectable if they hadn't injected a tad bit too much passive aggressiveness. I mean if this was written in the late 90's/early 2000s, perhaps I might have agreed with them. But have they seen what microsoft is up to? I mean, microsoft is working with linux...working. with. freakin. linux! Microsoft. with. linux! ;-)

</comment><comment><USER18> This note sounds like the kind of passive-aggressive stuff I write and subsequently discard to feel better about some dispute with a coworker.

There's such an air of condescension here, all from a team that didn't even design its own flagship product ([http://metalab.co/projects/slack/](http://metalab.co/projects/slack/)).

I feel bearish on slack.

</comment><comment><USER19> I came to know about Microsoft teams only by this post. I see better value proposition with whole office 365 offering.

</comment><comment><USER14> I would short Slack. Shark jumping moment.

</comment><comment><USER20> Just yammering about upcoming competition :-)

</comment><comment><USER21> What the heck?

</comment><comment><USER22> Weird "marketing".

</comment><comment><USER23> Epic fail

</comment><comment><USER24> haughty</comment>


Show HN: Launch of a minimalistic VPS provider with CoreOS and Atomic images - <AUTHOR> https://datamantle.com/ <comment><USER2> You can use the promo code LAUNCH for $5 of credit. Server locations look like they're currently limited to Canada.</comment>


Sony Sped Up a Factory with These Tiny, $35 Computers - <AUTHOR> https://www.forbes.com/sites/parmyolson/2019/03/10/how-sony-sped-up-a-factory-with-these-tiny-35-computers/#350aea7e7d20 <comment><USER2> "Each tiny computer is equipped with extra sensors to monitor things like temperature, vibration, proximity and energy usage."

You would think those high-end sony factory machines would have these sensors in them already. If true, manufacturing in 2019 is still not cutting edge as I expected. But you know, Forbes is also known for its clickbait titles and terrible writing with 90% junk for SEO keyword stuffing.

</comment><comment><USER3> beaglebone started this whole SBC movement, it is still a great board, better than RPi in my opinion, but the marketing is not as good so it's much less known</comment>


What ideas have you implemented that have failed, and why? - <AUTHOR> In the "What ideas do you regret not implementing?" thread, Maurycy suggested turning it around and asking "What ideas have you implemented that have failed anyways?"  After all, most of us are more worried about the risk that we'll work our asses off building something cool and then find nobody likes it rather than the risk that we'll never get started at all.
I agree with maurycy that this is a far more interesting question, so I took the liberty of submitting this as a discussion topic.  Please be more specific than "Because there was no market for it" - that's obvious, why wasn't there a market for it (or turning it around, why'd you implement it if there was no market), and how does it differ from projects you've done that have succeeded. <comment><USER4> Before Viaweb we had a startup to put art galleries online. But galleries didn't (and mostly still don't) want to have their inventories online. Galleries want you to come in in person so they can impress you with their fancy space and make a big production out of bringing stuff out of their mysterious back room.

Since we were too poor then to have bought any art from galleries, we didn't realize this was how they worked. Lesson: don't build things for users so unlike you that you don't understand what they want.

<comment><USER5> Don't tell me that meeting chicks was not a side goal of this endeavor!

<comment><USER4> Believe it or not, it wasn't. It was the business part that was new, not the art part. I'd just come from art school.

<comment><USER6> I always wondered what made you want to go to art school.

</comment></comment></comment></comment><comment><USER7> My previous (failed) startup had the following plan: Identify (university- level) lectures given all across the world, for many different areas of study, that doesn't change much over the years. Example: statistics.

Now build a live computer-based lecture with a software architecture to live- test what you know with questions, including skipping ahead once you 'grok' something, and working your way through more examples if you are struggling. Get this right with a sizable budget. Don't just get academic experience on board, but also didactic experience.

The amount of value created is staggering; lectures are very boring and relatively ineffective, professors generally want to do research instead of lecturing anyway, and they cost a bundle. Every year, how many professors around the world are lecturing statistics? Thousands, easily.

The reason it failed: Video stuff is very expensive, and universities move at glacial speeds. We just couldn't get the universities to commit actual money to the project in time - and we all despised bureaucracy.

I'd like to return to this idea when there I have more money and more experience some day.

</comment><comment><USER8> I've been trying different things on the Internet since about 1995. Back then I was trying to create online storage, which turned out to host more adult files then anything else. Finally gave that one up due to bandwidth costs.

After that I tried my hand at web-based email which extended into a calendar, time and billing and eventually forums that I hosted and other people could use their own domain name with. Turned into a semi-successful business, but the management of the system ended up eating up too much of my time and it wasn't making enough to let me quit my day job.

I wrote an anti-spam service that was efficient and quite good at filtering spam, but the resource required to take it to the next level were not around and I couldn't generate interest in the product. This came down to a not enough hardware to get the full working prototype finished problem.

Some of the largest problem I had were the 800 pound gorillas that seemed to appear just before my product was ready and I wasn't agile enough at the time to compete.

I don't regret implementing any of the project I did, even the map server that I've tried to create about 6 times. For me half the fun is the creation and until recently I haven't been dedicated to creating a large business out of it.

Plus the experience and the amazing tools that have come out of the whole journey are worth more then the the time I spent on all of this.

Another big lesson I've learned it that I can't do the whole thing alone. Just like you need the right tool for the right job, the right person for each job is important as well.

</comment><comment><USER9> 1 The first was a mobile game distribution network. Developers upload their games and tag them. Publishers get a widget they embed on their site and displays games relevant to their website content. If their audience like a game, then they simply input their phone number in the widget and hit SEND to my phone. It didn't work because I kept changing my direction and I wanted to wait until everything was perfect to launch. Big mistake. Several months of development out the window.

2 An location based SMS coupons. User registers for offers they are interested in and add zip code. Advertisers choose a radius to distribute their ad and send it to all users within the perimeter. Too easy to copy and SMS business is costly. Still got some interest from some VIP in the mobile field. The real reason was I got bored with it.

3\. A RSS to SMS/IM content distribution. It failed because i just kept changing direction. On top of that the idea was not unique at all.

PS> Now i am working on something truly unique. Well at least it hasn't worked so far although a few carriers and handset manufacturers have tried it.If I do not get a call from PG after launching this one, then I will be xtremly surprised.

</comment><comment><USER6> I have started and abandoned RSS aggregator projects 4 times in the last 4 years. The first was in C++ and MFC, then Python, another Python, then Scala.

Certain things about feed aggregation that you might think would be cool wind up not really working out well in my opinion. It's not until you try to aggregate together thousands of blogs that you realize that the best blogs are very much cults of personality, and can't be easy clustered together like mainstream media as in Google News.

You'd also be amazed at how poorly implemented simple markup specifications like RSS 2.0 can be. I forget what law it is that says the easier it is to implement something, the worse the prevailing implementations are because of barriers to entry, but I think it's very much true.

Thirdly, I'm very throughly convinced that the browser is the best environment for consuming hypertext, not special desktop applications. Therefore apps like NetNewsWire get it wrong in my view.

These aren't instances of business failure, just reasons I abandoned things and opinions I came to have by writing code and seeing what happened.

</comment><comment><USER10> I had better hopes for Apache Rivet. But it has had lots of upsides just the same, and I've learned a tremendous amount from watching Tcl itself gurgle down the drain, even if it still pisses me off.

</comment><comment><USER11> From one perspective, juwo my product, has failed. No investors, No cofounders, No Users (apart from me). Yet - I plan to reimplement and hopefully, turn things around.

juwo is not a failure until I give up.

I won't give up while my convictions about it remain.

</comment><comment><AUTHOR> In this post, I'm defining success as "The number of people who find it useful is roughly equal or greater than the number of people who I thought would use it." I'm explicitly not defining it as financial success - most of the projects I've worked on have been hobby or volunteer efforts, and the commercial ones tend to flame out for implementation difficulties.

By this definition, I count 5 and a half successes (auto-uploader and new DB system for FictionAlley, Scrutiny and roomdraw ticker at Amherst, "Write yourself a Scheme in 48 hours", and a Netbeans plugin for my current employer is the half), 3 and a half failures (inAsphere, RejectedByYC/Bootstrapacitor and the current incarnation of Diffle), and 7 projects that failed because I or my employer failed to finish implementing them (a MUD, a Gnutella API, SchoolBrain, SecureTunnel, a Scheme-like programming language, collaborative editing, a Ruby plugin for Netbeans, and a Haskell-like programming language). The interesting part is the failures that were implemented fully, so I'm going to skip the successes and the bad implementations.

inAsphere.com was a teen-content dot-com run exclusively by teenagers, founded in 2000. Had the normal forums, link directories, articles, and polls. We launched it after a month and a half, folded in cross-x.com and its userbase (an earlier site founded by one of the founders), then found that rather than _gaining_ new members, we were _losing_ the existing cross-x.com userbase. The investors pulled out after 3 months and the project was canceled.

IMHO, it failed because: A.) we were pompous, elitist, and corporate - <USER2> market statement was "A teen content site for _intelligent_ teens", thus implying that anyone who didn't like use was stupid. B.) we really weren't all that smart. C.) we had very little to differentiate us from every other dot- com in 2000 D.) we talked down to users - while they had felt like they were part of a community in cross-x, it just felt like they were part of a corporate machine with inAsphere.

RejectedByYC/Bootstrapacitor was a side-project my startup did after YC rejections came out. You can see the initial announcement threads at <http://news.ycombinator.com/item?id=16234> and <http://news.ycombinator.com/item?id=18233>, though the site itself is down now. Aside from some of the obvious comments in the threads, I'd put its failure down to: A.) unclear positioning - because of the name and manner of announcement, many people thought it was intended to compete with YC, while it was really intended to serve as an additional resource for those of us who couldn't get into YC/TechCrunch/other programs. B.) Chicken-and-egg problem - the site gains much of its value by having a community of dedicated & driven entrepreneurs, but no dedicated & driven entrepreneur will sign up unless others already have. C.) Poor understanding of requirements - honestly, I don't think it actually "fit" its intended purpose all that well. As an entrepreneur now, I wouldn't use it myself, which is a pretty damning indictment. Ironically, my sister just told me today that she thought that idea has more potential than what I'm currently working on, so perhaps there really is something there, and we just weren't willing to spend enough time on it.

I'm reluctant to include Diffle ( <http://www.diffle.com/> ) as one of the failures, because it was never meant to succeed! The site as it exists now is basically a bunch of functionality that we need for our real idea to avoid losing out for lack of silly stuff (much like how Google Video lost out to YouTube for a bunch of stupid and easily-correctable reasons). I could knock off that functionality fairly easily while still employed at my day job, so I figured I might as well put it up on the off chance that people like it. After all, having _something_ up is better than having _nothing_ up, and we have a completely different name and domain name ready in case we tarnish our brand. It also gives us a bit of a psychological boost, knowing we have a site that we can just plug our real engine into.

In retrospect, I don't think I would do it this way if I had to do it all over again. If your real idea is any good, you'll have plenty of users begging for you to add the features that you omitted. And you can find out much quicker if your real idea is any good, and switch to a different one if necessary. Plus, feedback on something that's _not_ your real product is basically useless, because you draw a completely different audience. Friends and family that you show it to assume you're doing something different than you actually are, and they make all sorts of erroneous assumptions based on that.

Finally, I'm including the Netbeans plugin I wrote for work. This actually does get used - my boss loves it, and gave me a nice bonus for it. However, it's not being _sold_ , which is what I thought would happen with it. The reason is kinda instructive:

When I started at my employer, I thought the company did something different than what it _actually_ does. Like many bootstrapped startups, there's a split between the founder's vision of what the company should be, and the products/services that actually bring in the money to execute on the founder's vision. I had built a product based on the founder's vision, but I thought that the founder's vision _was_ bringing the profits in, and so was a little disappointed when nobody except my boss uses my software.

Also, I think I should mention an observation about the 5 successes: in _every single case_ , I was a member of the community that would eventually be using the software, and I basically just built something I would use myself. I was an author at FictionAlley before I was a programmer for FictionAlley. I was a student at Amherst before I wrote its course-evaluation system. I was interested in learning Haskell before writing a tutorial for it, and in fact basically wrote the tutorial as a way of teaching myself Haskell.

<comment><USER12> _"... I was a member of the community that would eventually be using the software, and I basically just built something I would use myself ..."_

Do you think this is a variation of _"make what users want"_?

Initially being in a community gives you insight into what they want. But you don't always have to be part of a community to do this. You could just as easily extend this to _"making tools for yourself"_ solving those annoying problems. In the process develop something that others _might_ find useful.

 _"... "Operacy" and the skills of doing. The notion that it is enough to "know" is both absurd and dangerous. Research has shown that youngsters who pursued hobbies did much better in life - because they has some experience of operacy ..."_ ~ <http://www.edwdebono.com/debono/msg02r.htm>

Insight comes also from _operacy_ or doing. Rather than just knowing, watching, reading. You gain more from doing.

<comment><AUTHOR> "Do you think this is a variation of "make what users want"?"

Absolutely. "Make something users want" is really the fundamental principle of just about all of business. Everything else is just details.

It's surprisingly difficult to know what users want, though, unless you're one of them. It's usually the most mundane details that lead to success - <USER3> like YouTube and Reddit enabling comments, or FaceBook keeping your information private outside of the college, or FictionAlley hosting Cassandra Claire's fanfics. A lot of consultants will tell you "Do market research! Make sure people want what you're building", but the fact is, most people are unable to verbalize what they want. They know it when they see it, and they might be able to tell you if you sit next to them and walk through how they use it, but a bunch of questions over the phone isn't going to get any useful feedback.

<comment><USER13> I think all three of the above examples (Facebook, Reddit, Facebook) are examples of first mover advantage, not any specific technical feature.

<comment><AUTHOR> None of the examples above were actually first-movers, though. YouTube was beaten to market by Google Video and a whole bunch of Web 1.0 video-sharing sites that nobody's ever heard of. Reddit was beaten by Digg, del.icio.us, and various others. FaceBook was beaten by Friendster, MySpace, Orkut, and lots of other social-networking sites. FictionAlley was beaten to market by Fanfiction.net and lots of boutique archives.

</comment></comment></comment></comment></comment><comment><USER14> How would you know why a startup failed? The main reason may simply be that you are not living in a good place for startups.</comment>


Take photos where your subjects aren't looking directly into the lens - <AUTHOR> http://www.eugenewei.com/blog/2015/9/23/my-favorite-photography-tip <comment><AUTHOR> I always thought these things were obvious (although I had never found so beautiful words to say them), but it appears they are not.</comment>


You Can't PDF Your Way to Good Software - <AUTHOR> http://www.codingthewheel.com/archives/You-Cant-PDF-Your-Way-to-Good-Software-Development

<comment><USER2> I'll now annoy and patronize you all by again agreeing with the spirit of this post while disagreeing with the particulars.

Security documentation is different from normal documentation in that it serves dual purposes, and "comprehensible documentation" is the lesser of the two. The more important objective of a security standard is to provite citable line-item rules that can be audited against, and the reason you do that is so that you can make reviews, tests, and audits objective.

You can argue with the specifics of those rules, but even something as obvious as "keep windows synchronized with data" could merit a line item if it's something that bad devs consistantly fuck up, and could be inclined to argue with ("that's not a security problem and nobody has ever complained about it!") in a review.</comment>