Move over T9, here comes Swype - <AUTHOR> http://news.cnet.com/8301-17938_105-10037202-1.html?tag=mncol;posts

<comment><USER2> The first thing that came to mind when I saw this preso was "What algorithm are they using to find the words?" The problem looks something like: Given a string of characters, find all possible words that start and end like the string of characters and use any number of characters in between.

The best I can come up (after not so much thinking about it) with is using Bloom Filters. Precompute the bit vector for every word in your dictionary, then after they swype, compute a vector for the string of characters and run it up against all the words in your dictionary that start and end with the same letters. Still kind of an expensive linear search, albeit fast (since it's just boolean AND).

<comment><USER3> You also get a hint from direction changes. As far as I can tell, direction changes almost always indicate that the current letter is in the word, though not every letter gets a direction change.

</comment></comment><comment><USER4> They just need to work on getting consumers educated more than T9 did. It's amazing how many times I have explained and demo'd T9 to people--vast numbers of people just don't get it and use multi-tap instead. After a couple of minutes T9 is way faster, but there is usually no tutorial and people get frustrated when it's not doing what they think it should (multitap).

<comment><USER5> as a foreigner, I hate T9. The first thing I do when I start using a new phone is to turn it off. It just doesn't work with short names, foreign words (or my name), or common sms slang.

I hope this is better.

<comment><USER4> Multi-language support is tough, but some implementations are better than others (there are lots of different versions of T9, you're just stuck with whatever your phone has). The latest version of T9 has support for using multiple languages at once, but most phone makers don't advertise what version of T9 they ship.

</comment></comment></comment><comment><USER6> the iphone app "writingPad" uses this input method

</comment><comment><USER7> qwerty evenly spreads commonly used keys between both sides so that you can type fast with two hands; seems like exactly what you wouldn't want with this tech.

<comment><USER8> Actually that's not true. Qwerty is a very bad layout for keyboards. The guy who invented it was named Qwerty. It was originally designed for typewriters and to be difficult to use to force the typist to slow down to reduce mistakes. Many alternate layouts have been proposed over the years but Qwerty became the defacto standard because it was so widely used by businesses with typewriters. That's what people learned and we've been stuck with it ever sense.

<comment><USER9> Wikipedia partially disagrees: <http://en.wikipedia.org/wiki/Qwerty>

It slows you down to prevent jams. The guy's name was Sholes.

<comment><USER10> Actually, it's not supposed to slow you down. It's supposed to make sure you're normally hitting keys that are far apart, which means the hammers won't interfere with each other. QWERTY is a pretty good layout because of it. The next letter you try to type is rarely in the domain of the finger that just pressed down, meaning you can line up a number of keys to be pushed at once.

In the Design of Everyday Things, Donald Norman talks about keyboard design a lot. QWERTY is really good, so switching to layouts that are only slightly better (dvorak) end up not being worth the time and effort.

</comment></comment></comment></comment><comment><USER11> I saw the demo live and it looked great with a stylus... so-so with touch and worse on a phone. Still has work to do.

</comment><comment><USER12> Definitely innovative, though I wonder if not lifting fingers from the screen helps all that much.

</comment><comment><USER8> I watched this live at Techcrunch50 and I had mixed reactions. First, it is a rather technically interesting way to do text input. Watching how the experienced developer was playing with it, I could sense how it could feel like writing cursive English letters as whole words.

For the average user though, I just don't see how it catches on. People are fairly split over whether they prefer phones with traditional button keyboards or if they love the touchscreen interface from the iPhone. I love the iPhone because I hated stencils. I get more screen real estate. Its easier for me to do typing on the iPhone than any other smart phone I ever used.

It honestly looked like the demonstrator was scribbling on the screen. I had to look twice a couple of times to make sure it was a live demo and not fake.

<comment><USER13> this catches on, i say within 5 yrs this tech is on virtually all touchscreen devices. people adapt. thats just how it goes. before txt mssgs came out , how many ppl typed mssgs on the key pad of a phone?

</comment></comment><comment><USER14> Not a fan at all. I understand how the creator might have put pressure on himself to develop a new relevant solution, but this is nothing short of counterintuitive. Why would you develop a text input method that forces the user to use one finger?

<comment><USER15> Because the input device is so small that there is no room to use multiple fingers effectively? Because that is the way people use mobile touch screen devices? (Hold the device with one hand, poke/type with the other)

<comment><USER14> How many new touchscreen-only devices are coming out with screens so small that this solution is feasible?

<comment><USER16> A lot since the iPhone shows how well it works.

How many people use more than one finger on the screen and how often?

<comment><USER17> Yes. And who says this is the last and final version?</comment></comment></comment></comment></comment>


How Movity (YC W10) built a noise dataset of the Tenderloin - <AUTHOR> http://blog.movity.com/post/702213904/the-visualization-of-noise

<comment><USER2> It looks like the answer is "it's pretty damn noisy everywhere we measured."

</comment><comment><USER3> Is it legal to say "This device is being tracked by the SFPD" if it's not?

<comment><USER4> I would guess it is unlawful, but not illegal. Meaning that the median bad consequence for doing it is that the authorities tell you to stop doing it and then you have to stop doing it.

</comment></comment><comment><USER5> Noise is definitely an interesting factor, but the truth is, most renters simply want the most bang for the buck and therefore, price is still the most important metric used in apartment hunting.

<comment><USER6> If you have kids this information is invaluable. My daughter is a light sleeper and I can tell you that I've had more than one unfun night dealing with noise in our neighborhood in Boston.

<comment><USER7> I used to live in a noisy apartment -- due to the fact that my cat loved to knock things over at night, causing loud noises.

The solution was earplugs.

</comment></comment></comment><comment><USER8> Interesting stuff but I'm wondering why you guys chose to do this in the Tenderloin?

In terms of the premise of 'not wanting to move somewhere noisy', noise is the least of your worries if you are moving to the Tenderloin. And most people living there don't hav a choice.

I would have thought more context could be put on this data if it was about an area people chose to live in (but is noisy/industrial, like SoMa).

</comment><comment><USER9> fascinating study. Questions: 1\. how can you drive the price down per corner? (make it affordable for large scale measurement). 2\. don't most people already have a general idea of how noisy a place is when they visit? 3\. will realtors pay for this data?

</comment><comment><USER10> I wonder if these guys considered that some homes have better sound insulation than others? While the outside may be noisy, the inside may be quiet. A noisy house in a less noisy area may be noisier than a quiet house in a loud area.

</comment><comment><USER11> Shouldn't this be better executed with JS on this iPad days?</comment>


Yahoo to early Reddit: You are a rounding error - <AUTHOR> http://vergestartups.com/haters-gonna-hate-by-alexis-ohanian-uberfacts/ Ohanian talks of his early days in Reddit where he is invited by Yahoo to join other startups. During a talk with a Yahoo employee, he is told Reddit's traffic is equal to a rounding error and that he doesn't belong. <comment><USER2> Haters gonna hate. What every starup founder needs to keep reminding themselves, especially in the beginning.

</comment><comment><USER3> Interesting if the current crew at Yahoo would treat them the same. It seems like they're more friendly to emerging players.</comment>


Monsanto leaks suggest it tried to 'kill' cancer research about weed killer - <AUTHOR> https://www.baumhedlundlaw.com/toxic-tort-law/monsanto-roundup-lawsuit/monsanto-secret-documents/ <comment><USER4> Isn't this right out of the Big Tobacco playbook when they "scientists" in lab coats producing studies that smoking was healthy?

 _The Tobacco Industry: The Pioneer of Fake News_

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5402187/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5402187/)

<comment><USER5> Is there a scientific consensus (or at least majority) as to the carcinogenic effect of the Roundup product?

<comment><USER6> There isn't. Glyphosate is well studied, and all evidence exonerate it. The constituent chemicals of Roundup _may_ interact with each other to render the cocktail toxic. But that's not equivalent to carcinogenicity. And it's not well studied as yet.

<comment><USER7> >Glyphosate is well studied,

No. That is false.

[https://ehjournal.biomedcentral.com/articles/10.1186/s12940-...](https://ehjournal.biomedcentral.com/articles/10.1186/s12940-016-0117-0)

The studies on glyphosate are plenty, but most are inadequate.

<comment><USER5> This led me to a WHO FAQ, which I was hoping would answer all my questions. [http://www.who.int/foodsafety/faq/en/](http://www.who.int/foodsafety/faq/en/)

The only answer I have so far is that we need to fund our research institutes better to get more studies faster. I do appreciate though that glyphosate has replaced many less safe herbicides.

I think even going off of the WHO FAQ, the comparison of the situation to one the tobacco industry faced is not the correct one.

</comment></comment></comment></comment></comment><comment><USER8> It is a real shame not to be able to trust "science" anymore. We'll have to come up with a new word for what we used to call science because I don't think corporations and media set on manipulating public opinion and laws will give it back.

<comment><USER7> It's not like it was hard to figure out what was going on.

On one hand you have scientists publishing letters of concern regarding glyphosate arguing for more studies to be done because of hints of carcinogenic properties.

On the other hand you have a full blown shill campaign on Reddit and other website, being all like, "there is absolutely nothing to worry about, why do you hate science!". And lobbyists bullying the EFSA into publishing a statement in support of glyphosate so that it could be relicense for further use within Europe.

You can trust science. You just have to be aware of the conflicts of interests. Monsanto hasn't bought every single scientist out there.

<comment><USER9> The funniest/saddest part of this is that even the people that catch on to the probable poison that is glyphosate and the shill campaign behind it will still angrily defend the safety and efficacy of IG Farben vaccines while happily eating Monsanto GM Frankencorn grown with glyphosate.

Depopulation is necessary and luckily it's also fairly easy.

</comment></comment></comment><comment><USER10> It's weed killer. Literally poison. Can we just curb our faith in science just a little bit and use some common sense. It's incredibly likely that ingesting poison is bad for you. Let's leave open the possibility that it isn't, but I personally require that people prove it's safe rather than continuing to ingest it until proven otherwise.

It's honestly just baffling to me that people find it surprising that consistent, low doses of poison may cause cancer.

<comment><USER11> Just because something is poisonous to the biology of plants, in doses typically used as a weed killer, doesn't make it toxic to humans.

That's not to say this doesn't cause cancer. Whether or not it does is irrelevant to the point that plant biology is not human biology — hell, other _mammals '_ biology isn't human biology (see: cats and chocolate, grapes, macadamia nuts, and onions) — and making inferences based upon this hypothesis is not particularly likely to result in correct assessments.

Further, "the dose makes the poison". Alcohol is a poison. _Oxygen_ is a poison in high enough doses. Is weed killer a poison? In some arbitrarily high dose, certainly. In some arbitrarily small dose, no. In the dose you're likely to encounter on the surface of produce? Possibly, perhaps even probably. But again, making inferences based on the fact that it kills weeds is faulty thinking. By that logic, one would be forgiven for avoiding onions at all cost; after all, they're cat poison.

<comment><USER12> If my cat is poisoned I would definitely avoid what it ate until there's overwhelming evidence that it's not harmful for me.

</comment></comment></comment><comment><USER13> I don't know what Monsanto did or didn't do and don't have any particular rooting interest for Monsanto, but I think it's worth noting that the published science for the carcinogenicity of glyphosate (the "weed killer" we're talking about here) is extremely flimsy.

Most publicity about "cancer" and "Monsanto" is traceable back to an IARC report that the World Health Organization (IARC's parent) essentially retracted. The report itself concerned dozens of different pesticides and herbicides and mentioned glyphosate only in passing. The studies it referred to equivocated about any link between glyphosate and human cancer.

(I'm going from memory here and someone will probably correct me on this, which will be great!)

It would be surprising if glyphosate turned out to be toxic, because it straightforwardly targets a metabolic pathway that plants have and the entire kingdom of Animalia lacks.

California recently added glyphosate to its list of chemicals that it's required to alert consumers about. But of course, that list is long and includes substances that virtually nobody controls their own exposure to, such as acrylamide --- a known human carcinogen --- which is universally present in cooked foods.

Finally, and this is obvious, but we're reading articles on a plaintiff lawyer's website. That's fine, but you're clearly not going to get the whole story from them. For instance, the lawyers are happy to leave you with a headline about Monsanto trying to "retract a cancer study". But they're of course going to leave out the fact that the study in question was the Séralini study, of "Séralini affair" fame; you can look this up in Wikipedia to see what I'm referring to.

<comment><USER14> While glyphosate is only questionable, Round Up itself, which includes a variety of surfactants, seems to have a more pronounced effect - <USER2> cytotoxic and mutagenic.

Many of the later documents in this dump center around formulated Round-Up's unexplained toxicity when compared to the survey of glyphosate studies in the literature, and a variety of understudied surfactants in the formulation.

Ex (ignoring sensationalized document titles):

[http://baumhedlundlaw.com/pdf/monsanto- documents/37-Monsanto...](http://baumhedlundlaw.com/pdf/monsanto- documents/37-Monsanto-Executive-Admits-Studies-Demonstrate-Formulated-Roundup- Does-the-Damage.pdf)

[http://baumhedlundlaw.com/pdf/monsanto-documents/38-Email- Sh...](http://baumhedlundlaw.com/pdf/monsanto-documents/38-Email-Shows-Former- Monsanto-Expert-Confirmed-Biological-Plausibility-of-Glyphosate-as- Carcinogen.pdf)

[http://baumhedlundlaw.com/pdf/monsanto- documents/42-Internal...](http://baumhedlundlaw.com/pdf/monsanto- documents/42-Internal-Email-Shows-Monsanto-Aware-of-Surfactant-Toxic- Effects.pdf)

<comment><USER15> There's a video where a Monsanto lobbyist spouts circular talking-points about how glyphosate was safe to drink, offered either Round Up or glyphosate and refused to drink it.

[https://youtu.be/QWM_PgnoAtA?t=25s](https://youtu.be/QWM_PgnoAtA?t=25s)

It's irrelevant if _glyphosate alone_ is cancerous or not, because 99.9999% of deployment is via sprays like Round Up. The _combined product_ , in both animal and human models, need thorough mutagenic research. It's just news shows don't want to give Monsanto free advertising or face libel laws, so they conflate the generic compound with the product.

<comment><USER16> I think you'll find if someone who thinks you are evil offers you a glass of liquid of unknown providence you to would decline it as well.

<comment><USER17> This presents an interesting conundrum. Monsanto doesn't trust anyone who proposes a Monsanto employee drink a cup of Roundup because ostensibly they're afraid the cup is something other than Roundup. People who want to propose this "prove it" don't trust Monsanto to supply the cup of Roundup because they're afraid Monsanto will just give some colored, scented water that only looks like Roundup.

The actual Roundup product toxicity is from the inactive ingredients used as a carrier for the glyphosate [1]. Supposedly pure glyphosate itself is low toxicity. If (and this is a big if) the LD50 for humans follows mice models [2], at the highest amount of glyphosate required of 10,000 mg/kg, then the average human at 70 kg would require 700,000 mg of glyphosate to incur a 50% chance of a lethal dose. That is 0.7 kg solid form glyphosate, well over what we might find in a cup that is roughly diluted to the concentration levels one finds in the least concentrated form of Roundup. The lower end of the animal models is rabbits, acute dermal LD50, at 2,000 mg/kg, five times lower, 0.14 kg solid form glyphosate for that average human.

If there are 540 grams glyphosate per liter of Roundup R/T 540 Liquid Herbicide (the term of art is "540 grams acid equivalent per litre", please, some chemistry hacker out there correct my quantities, I'm sure I'm getting this wrong), then a US customary cup of this kind of Roundup contains 127.76 g glyphosate. I chose this kind of Roundup because it looks like the least concentrated. The rabbit LD50 toxicity translated to a 70 kg human is 140 grams. The mouse LD50 toxicity translated to a 70 kg human is 700 grams. That cup is uncomfortably close to those levels for me, if my numbers are close to the ballpark; I sure as hell wouldn't drink that cup if my numbers are correct. I welcome corrections.

[1] [http://www.roundup.ca/_uploads/documents/RT540_label_Mar2014...](http://www.roundup.ca/_uploads/documents/RT540_label_Mar2014.pdf)

[2] [https://en.wikipedia.org/wiki/Glyphosate#Humans](https://en.wikipedia.org/wiki/Glyphosate#Humans)

</comment></comment></comment></comment></comment><comment><USER18> Y'all should take this with a grain of salt. Monsanto is hated as a company; the media just loves to vilify them. I've been suspicious of any anti-Monsanto news since looking into their lawsuit[1] against a farmer who grew illegally obtained patented seeds. The media and commenters made a big deal about predatory behavior but they it was clearly the farmer being an asshole. Anti- science/GMO nuts just latch on to anything without a care where the evidence points.

[1] Monsanto Canada Inc v Schmeiser

</comment><comment><USER19> Given the number of ghost written publications shouldn't there be a slew of retractions?

It's unethical, and generally a violation of journal rules to publish another's work listed with yourself as an author.

Then there's a journal editor that they pay, who they worked with to get a paper retracted, surely that should result in a re-review of everything involved there as well?

Has anyone done the work to determine which papers are involved and start the retraction notification process?

</comment><comment><USER20> News-flash, company people have known was evil for ages, actually is still evil.

</comment><comment><USER21> Here is a study of 12 diseases correlated with glyphosate, it is not official as in a published journal, but given that even pubmed states there are not enough toxicity studies, that most safety papers are not independently funded, and scientists who dare to say the contrary are shut down, I rather be more cautious than sorry: [https://people.csail.mit.edu/seneff/glyphosate/NancySwanson....](https://people.csail.mit.edu/seneff/glyphosate/NancySwanson.pdf)

</comment><comment><USER22> I see there is a few posts repeating the common interpretation that glyphosate is not dangerous because it only targets metabolic pathway only animals has, so for the sake of discussion here is another viewpoint: [https://www.youtube.com/watch?v=kVolljHmqEs](https://www.youtube.com/watch?v=kVolljHmqEs) (disregard the clickbait title), summary: Glyphosate is not bad for your body, but it does kill everything in your stomach, and that is not so awesome.

</comment><comment><USER23> It's interesting how the discussion of Monsanto shifted. The discussion was about how Monsanto changed the seed/weed business from a buy model to a subscription/license model for farmers - which is a disruptive fundamental change. Now the discussion is mainly ab Glyphosate.

</comment><comment><USER23> Walking by a Bayer - Monsanto owner pending regulatory approval - <USER3> every morning, with people streaming in and I'm reminded most people will work for anyone who pays them.

</comment><comment><USER24> Michael Clayton anyone?

<comment><USER25> Yep, except he wouldve been taken care of by team B and even if he hadn't, the prosecuting DA would've been gotten to and dropped the case under prosecutorial discretion. The movie had to have a semi happy ending for the plots sake. Real life is much nastier.

</comment></comment><comment><USER26> Shouldn't this be illegal in some form? It is morally reprehensible to use "money as free speech" to suppress scientific truth.

</comment><comment><USER27> yawn, oh no they wouldn't do that would they? _sips coffee_

</comment><comment><USER28> Colour me surprised.

</comment><comment><USER29> Of course they did. Anyone on the internet about a year - 2 years ago remembers every time you mentioned monsanto they would send shills in to defend them and call you a tin-foil hat conspiracy theorist.

<comment><USER30> It's been really frustrating trying to have any nuanced stance on GMOs with proponents doing the "durr all modern crops are genetically modified by human selection" and such. Like no shit, it is still possible to acknowledge that and believe that there are legitimate concerns about intellectual property, or with modifying a crop to be resistant to a carcinogenic poison farmers are going to dump all over it.

A lot of the pro-GMO people seem to argue in really bad faith if they're not paid shills.

<comment><USER31> Exactly this. Every thread on GM quickly polarizes into useless for and against sides, when we need to be selective about it.

And I've never bought the characterization of breeding/selection as a form of GM. Breeding is selection of a pathetically tiny set of modifications, but GM is on a whole other level. With GM we can write arbitrary binary strings of code into any organism. That's simply not comparable with breeding -- the space of realizable phenotypes is orders of magnitude larger with GM.

<comment><USER32> I agree that the polarization is useless. However what you said about selective breeding vs GM is just wrong. Selective breeding introduces numerous mutations, including ones often not even related to the desired traits. In contrast human directed genetic modification often changes a single gene, the state of the art in research universities for specific modifications is only in the tens of genes. You can only say they are not comparable in the sense that selective breeding introduces far more changes than GM and also in the sense that with GM we know what changed where in selective breeding we do not necessarily know how the change was produced or what the extent of it was.

Also I understand that this is a computer centered site but thinking of DNA as binary is a often used but terrible analogy. Living organisms were designed through complete randomness, try refactoring that. If you wanted to turn teosinte into corn without any random mutations and selection I think that would be far beyond our abilities for 100 years at least.

<comment><USER33> > In contrast human directed genetic modification often changes a single gene

Even CRISPR-CAS9 is not perfect and introduces a lot of unwanted genetic changes when used. Further the big advantage of GM compared with selective breeding is that you can inject Transgenes. This makes them totally incomparable.

<comment><USER31> give it a chance - it's early days, and there are many other techniques and more in the works

</comment></comment></comment></comment></comment></comment><comment><USER34> Who actually likes Monstanto? I imagine a vast majority of the American people would support an outright shutdown of their business.

<comment><USER35> Luckily we still have the rule of law, so the majority can't simply shut down a company they dislike based on an internet misinformation campaign.

<comment><USER36> Campaign implies organization. Who do you suppose is working to shut down Monsanto?

<comment><USER35> A mob can be stupid and dangerous without a sinister corporate backing.

Who is funding the anti-vaccine campaign? Nobody. It's stupid online bloggers and dishonest researchers egging each other on with fake news.

<comment><USER36> it's not a campaign then.

</comment></comment></comment></comment></comment><comment><USER37> Uh... My grandpa used to use Roundup in order to kill weeds in his cultivation land.

<comment><USER38> Great. Whats your point?</comment></comment>


Amazon and Google settle feud, bring YouTube back to Fire TV devices - <AUTHOR> https://arstechnica.com/gadgets/2019/04/amazon-and-google-settle-feud-bring-youtube-back-to-fire-tv-devices/ <comment><USER2> I think the bigger news here is amazon prime adding chromecast support. It's a feature I'm looking forward to having, and have wanted for a while.

YouTube on fire tv devices hasn't really been a problem (for me at least). They removed the native app but the web version seems very feature-complete to me, and works almost exactly as I assume the native app did. Its not really any more difficult to get to either.

</comment><comment><USER3> I really hope this is a sign of a generally more grown-up attitude at some of the media/tech companies.

All this dick-swinging just inconveniences users and pisses people off.

I'm hoping that Amazon and Now TV (Sky) eventually pull their heads out of their arses and release an app for the FireTV.

</comment><comment><USER4> There is also [https://smartyoutubetv.github.io/](https://smartyoutubetv.github.io/) which is a clone of the youtube app. It has been working fine on my FireTV since the feud started. Plus it blocks ads.

</comment><comment><USER5> Great. I hate being forced to use it through a web browser on the FireTV devices I own.

Love the Chromecast support coming as well.

</comment><comment><USER6> Any reason why AppleTV YouTube navigation using my iPhone Remote app is virtually unusable? Did Google do that on purpose?</comment>


Twister: Anonymous, private BtC/DHT/Torrent P2P microblogging - <AUTHOR> http://twister.net.co/ <comment><USER2> Doesn't that make this service website independent? It is like twitter without the downtime, or twitter with multiple twitter networks all being able to collaborate with one another, or twitter without legal BS.

And those are beautiful ramifications. Flaws anyone?

<comment><USER3> It's also twitter without "delete" and twitter without private accounts, from what I can see skimming the whitepaper.

</comment></comment><comment><USER4> Read the whitepaper and it sounds pretty amazing. The one downside is the spam messages, which they say are important to the security of the network, and that clients cannot hide them, but don't explain a method to prevent clients from hiding them. If they really are essential to the security of the network then there needs to be more than shaming, right?

</comment><comment><USER5> "send text posts limited to 140 characters"

That's just weird. Like putting horses reins on an early automobile, or putting a hopper in the front of the car to pour oats into.

"Bitcoin, in the sense of the digital currency, is not used at all"

I had to LOL at this. BTC is popular enough to try to piggyback completely unrelated things using the term as a lure. I've lived thru the "turbo" era, the "e-" and "i-" era and now we're entering the BTC era, where we can soon expect shampoos and hamburgers to be "BTC shampoo" and "BTC hamburgers" as a marketing gimmick.

<comment><USER4> The project is a fork of bitcoin, uses bitcoin blockchains, but because it doesn't use bitcoin currency they shouldn't mention the lineage?

<comment><USER5> Yes, at least not as a marketing scheme.

So this is a competitor of coinbase? Oh you mean its a miner. Oh no wait OK its like paypal but for BTC.

So... they copied some general source code concepts? Thats it? What a scam. Thats not real bitcoin support at all.

Its like saying a new game is internet compatible, in that if you install it on an internet connected computer its not incompatible with the OS. I actually saw this kind of thing during the early years of mass adoption of the internet. And now we'll see it in BTC.

<comment><USER4> You misunderstand, this project is literally a fork of the bitcoin repo. They didn't just "copy general source code concepts". It's right there on their about page.

<comment><USER5> "the implementation of the neat idea of block chain is on the basis of twister."

MS Excel uses do...while loops, my latest project uses do...while loops, therefore my project is based on Excel. I was reading it as algorithm use not literally forking the codebase as appears to be the case. Not everything using Quicksort is a kissing cousin of everything else using Quicksort, for example.

Its still cheesy as a marketing scheme. This thing's bitcoin, that means its a currency, right, or a funds storage system, or a psuedobank, or .. oh its a microblog service. LAME.

From a tech perspective I think its cool as an unusual use of the algorithm and technology.

<comment><USER6> Bitcoins block chain implementation and idea is innovative and revolutionary. Your do... while example is not. Also, the blockchain is sort of the most important bit of bitcoin. I struggle to see how you're missing this...

</comment></comment></comment></comment></comment></comment><comment><USER7> The incentive to 'mine' in this scheme is the possibility of winning the ability to send a sponsored message to all users. These sponsored messages could easily be filtered by users, making them worthless. Even if users collectively agree not to filter the sponsored messages, the average cost of winning the proof-of-work race must be less than the average value of the sponsored messages, which is unlikely.

</comment><comment><USER8> > _No IP recording

The IP address you use to access twister is not recorded on any server. Your online presence is not announced._

Can you really make that claim with a distributed protocol? Your IP address is visible to whoever you send data to, they could easily keep logs (heck my router does by default).

<comment><USER9> Your peers cannot know if the data originated from you or you're simply relaying traffic. Thus, your IP address cannot be associated with tweets.

<comment><USER10> Untrue. An (for example) ISP could very easily determine if you were an originator simply by if someone relayed it to you.

Similarly, a Sybil attack can probabilistically figure out the originator, simply be seeing which peer first relayed the communication.

<comment><USER8> This is about what I was thinking. Tor avoids some of the ISP-problems by re- encrypting at every step (so you can't correlate input and output, except by time/size, which is hard on a busy node).

After poking through the FAQ the claim softens quite a bit, into that "normal" users can't detect such things. This I'll grant is true. And they even mention that, if hiding from adversaries who can observe _lots_ of traffic, you should probably use Tor.

That said, the FAQ does say:

> _However if one entity is capable of recording the entire internet traffic, > he will probably be able to at least statistically sort out where you are > connecting from (your IP address)._

which I think I'll still disagree with, unless this is provided by DHT (I don't know DHT, sadly. I'll remedy this some day). Unless you run through Tor, it seems(?) like all messages are essentially plaintext across the internet, so they _would_ know _exactly_ where a message originated, if you're within their view.

</comment></comment></comment></comment><comment><USER11> You can accomplish the same with Bitmessage broadcast addresses, and it solves the spam issue with proof of work.

[https://bitmessage.org/](https://bitmessage.org/)

<comment><USER12> I don't know much about Bitmessage, but aren't messages dropped after two days? So a new follower / visitor would only see two days' worth of my microblog?

<comment><USER13> Yes. I would disregard comparisons with BitMessage. I don't think they really target the same market. BitMessage wants to be more of a _private_ snooping- free e-mail system. Twister wants to be more of a _public_ decentralized social network (resistant to censorship).

There may be some technical overlap and functionality overlap, but I think they are more different than similar. It's like saying Gmail is the same as Twitter, since you can also broadcast messages with Gmail, and you can also send private messages with Twitter. But the two really aren't the same.

</comment></comment></comment><comment><USER14> This isn't the right problem to be fixing: The right problem is a distributed data store.

</comment><comment><USER15> Nice, how secure is it though?

<comment><USER2> From an anonymity perspective, it is just as secure as current bitcoin protocols. Public anonymity at the sacrifice of privacy. In which case, if your 'twister' info is out there, you can theoretically be identified.

<comment><USER16> In other words, the security is poorly defined and based on the honest parties devoting at least as much energy to defending the system as the attacker devotes to attacking it.

What I want to know is this: What does Bitcoin have to do with this? You can have peer to peer, anonymous, encrypted messaging without any of the nonsense that Bitcoin entails.

<comment><USER17> Basically, if you have anonymous, P2P, encrypted messaging you need to solve the problem of maintaining a public ledger of user names to public keys. There are several approaches to this, but one of the most compelling right now is using the exact same mechanism that bitcoin uses to prevent double spending. Twister has absolutely nothing to do with bitcoin, they are only similar in that double-spending a bitcoin is analogous to identity theft in Twister.

<comment><USER16> "the problem of maintaining a public ledger of user names to public keys"

What is the point of that ledger? Public keys identify users on their own.

<comment><USER17> Yes they do but 1) most people are more comfortable dealing with usernames compared to public keys, and 2) distributing the public keys themselves can be tricky if you don't already have a trusted connection set up (just look at past abuses of Certificate Authorities for examples of this).

<comment><USER16> I do not see how distributing keys is "tricky" in this context. If you do not know who you are communicating with, then a man in the middle attack works if the attack occurs during your first attempt to communicate (think SSH); this would seem to be true regardless of the existence of a ledger, since you need to figure out which username you want to communicate with. If you do know who you are communicating with, you can distribute keys offline (e.g. "contact me with $key") or establish keys via some existing communication channel (OTR, PGP, whatever), just as you would have to distribute your username offline or via another channel given the ledger.

So sure, I can grant people are more comfortable dealing with usernames than with public keys, but that sounds more like a UI problem than a technology problem. People are certainly capable of dealing with Tor hidden service addresses, and I suspect that is because they are already using a UI they know well (their web browser).

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I need at least one more /buzzword in the title before I use it.

</comment><comment><USER19> are there other open source versions of Twitter? I could gladly use this one if I could embed mathematical equations in it - e.g. with mathJax [http://www.mathjax.org/](http://www.mathjax.org/) \- and possibly lift the 140 character limit.

</comment><comment><USER20> Is there any follow model or does every participant receive all messages sent by everyone else?

<comment><USER21> Everyone gets every message. There is no solution here to the data bloat problem. Other than that the project forks bitcoin to make a namecoin clone (distributed authorization), which I dont see the need for since a private key already identifies me.

The reason something like namecoin is to allow people to update their identity in the event the first identity was compromised/blocked.

Finally this was posted yesterday [https://news.ycombinator.com/item?id=6987396](https://news.ycombinator.com/item?id=6987396)

<comment><USER17> This is not true. Followers are established by connecting to bittorrent swarms. From the paper: "The last network is a collection of possibly disjoint "swarms" of followers, based on the Bittorrent protocol, which can be used for efficient near-instant notification delivery to many users."

Furthermore, not all clients need to store and reseed all messages they receive. More seeders is obviously better for network health, but it's not always a reasonable option. The paper suggests that clients can choose to be "achivists" which means that they keep messages and seed them to others (so it's optional). Clients like mobile phones could easily disable this behavior.

Also Twister can't use Namecoin because the incentives are wrong. In Namecoin, miners get to create domains. It would be horrible if only Twister miners could make accounts. Instead they get to make promoted posts, so it has to be a separate implementation.

</comment></comment></comment><comment><USER22> Cool, but why not make the first client a web based one so we can all it work?

<comment><USER12> Isn't that what [https://github.com/miguelfreitas/twister- html/](https://github.com/miguelfreitas/twister-html/) is?

</comment></comment><comment><USER23> I couldn't find the whitepaper link. Anyone?

<comment><USER24> [http://arxiv.org/pdf/1312.7152v1.pdf](http://arxiv.org/pdf/1312.7152v1.pdf)

>[http://www.reddit.com/r/darknetplan/comments/1u1x56/](http://www.reddit.com/r/darknetplan/comments/1u1x56/)

<comment><USER23> Thanks.

</comment></comment></comment><comment><USER9> Another win against Zooko's conjecture!</comment>


Let's build a browser engine (2014) - <AUTHOR> https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html <comment><USER2> An other very lightweight weight engine in c is dillo. Unfortunately now its development has stopped.

<comment><USER3> There's also NetSurf.

As much as saying this is probably going to get me a lot of hate from web developers, the world needs more browser engines. Simpler ones, maybe HTML+CSS only with no scripting. The idea of the Web as a flexible hyperlinked document system and not an application platform needs to gain more support. IMHO if your site is information-centric, and it's not readable in these "document- only" browsers, you're doing it wrong.

<comment><USER4> I don't understand this hatred of Javascript. The only websites I've felt were actually bloated are news sites with a lot of ads, but that's not a problem with Javascript as much as it is a problem with excessive ads.

What counts as information-centric? A lot of basic things (commenting, searching, liking a post) require Javascript. If you want to use pretty animations, there's a high probability you need Javascript.

Making information-centric sites only use HTML/CSS would significantly decrease the capabsilities and attractiveness of the sites.

<comment><USER5> > The only websites I've felt were actually bloated are news sites with a lot > of ads, but that's not a problem with Javascript as much as it is a problem > with excessive ads.

The problem is JS has too much power in the browser, and too little consideration for security. It can effectively take control away from the user, there's virtually no way to know what it's doing without source code audits, which are prohibitive, and the security vulnerabilities are legion.

> What counts as information-centric? A lot of basic things (commenting, > searching, liking a post) require Javascript.

None of these actually require JS.

<comment><USER6> > > What counts as information-centric? A lot of basic things (commenting, > searching, liking a post) require Javascript.

> None of these actually require JS.

Can you imagine a facebook doing a page reload/refresh every time you click to like a post? Or without loading more content on demand every time you scroll the page?

<comment><USER5> > Can you imagine a facebook doing a page reload/refresh every time you click > to like a post?

You're stuck thinking about Facebook as if it still had long lists of posts with infinite scroll. The UX would be completely different when the design constraints are different.

For instance, instead of infinite scrolling, you might show one post at a time with clickable previews of the last and next posts. A like doing a full postback isn't a big deal with this approach, particularly with judicious use of anchors. Certainly not as slick, but perfectly usable.

<comment><USER7> Usable, with a worse user experience, to what end? It would be nice to have more non-js built-in browser behavior, though.

<comment><USER5> A slightly worse user experience on Facebook, for a significantly better and more secure user experience on the web overall. I'm not sure that's such a terrible tradeoff.

Agreed on built-in browser behaviour though. Chrome pushing more input types a few years ago was a great thing.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I loved this walk through back when it came out and even made a ham handed attempt to write the example code in Go [https://github.com/radiofreejohn/gobinson](https://github.com/radiofreejohn/gobinson)

It is a bummer it ended with a to be continued that never happened, I remember checking up on it from time to time.

<comment><USER9> So the blog post ends with a promise of sections about:

* inline layout

* text rendering.

* networking.

* scripting.

LAYOUT

I think here could be useful to take a look at something like Facebook's Yoga [1] although maybe not great to start. There's this little layout demo that could be interesting to investigate [2].

TEXT

Regarding text probably the keyword to learn about is "rasterization". I found a few tutorials back in the day [3], [4]. In general rendering text is a PITA and you don't want to do it no matter what :-) The only lightweight solution I found was stb's truetype [3].

So if you want to render text yourself you'll need:

\- a parser for a font format format (e.g. TTF, PITA) to have a way to get the curve definitions for each font.

\- a rasterizer (could be a fun project for getting something reasonable and probably slow performant)

\- a curve filling algorithm and plugging it to your rasterizer, which will probably be able to do humble things like drawing filled triangles and other simple shapes (PITA! :-p)

\- a word and paragraph layout engine (PITA again :-)

Overall I'm happy half understanding the steps involved and not having to deal with all the messy steps in the middle.

NETWORKING

I'm super lazy in this area, and I would rather learn something like ZeroMQ to posix sockets... back in the day I followed Beej's tutorial which was nice. [6] Then you can connect your sockets to some pre-existing HTTP parser which are a dime a dozen these days [7] and you are all set! :-p

SCRIPTING

Not much to say here... hundreds of languages available. Probably Lua is a nice alternative to JavaScript, but there are also plenty of lightweight JavaScript implementations these days (I think there is a nice little one called V7). If you want to learn how to actually implement an interpreter there are plenty of resources too. If I went this route I would start by implementing some version of lisp or scheme for simplicity.

1: [https://yogalayout.com/](https://yogalayout.com/)

2: [https://github.com/randrew/layout](https://github.com/randrew/layout)

3: [https://github.com/NotCamelCase/RasterizationInOneWeekend](https://github.com/NotCamelCase/RasterizationInOneWeekend)

4: [http://www.scratchapixel.com/index.php](http://www.scratchapixel.com/index.php)

5: [https://github.com/nothings/stb/blob/master/stb_truetype.h](https://github.com/nothings/stb/blob/master/stb_truetype.h)

6: [https://beej.us/guide/bgnet/](https://beej.us/guide/bgnet/)

7: [https://github.com/search?q=http+parser&ref=opensearch](https://github.com/search?q=http+parser&ref=opensearch)

<comment><USER10> >So if you want to render text yourself you'll need (...)

Or possibly use SDL or a similar graphics library meant for game development.

You would still probably have to write a lot of code but you would get a rasterizer, font loading, simple primitives and image rendering in a cross- platform compatible API.

<comment><USER11> If you're going to use a library just use straight freetype (what SDL wraps.) It's very easy to use.

<comment><USER10> Sure, but SDL gives you more on top of just font handling.

I'm just saying, it's not necessary to reinvent all of the wheels.

</comment></comment></comment></comment></comment><comment><USER12> I bet it's possible to achieve layout completeness (in the same vein as turing completeness) with a much simpler markup and styling language.

I'm actually more interested in implementing a toy OS or a toy compiler for a toy language because the browser seems to be a more of very specific complex mess of mistakes and legacy choices rather then a serious theoretical concept. Although I'm sure you'll still learn a lot if you implement one.

<comment><USER9> I don't know about the "completeness" part but the idea of making a brower- like rendering system without the burden of having to support old standards and data formats _is_ appealing. I think this is what projects like QML [1], JavaFX [2], Avalonia [3] and more recently Flutter [4] have done (also... Flash! does anybody remember it anymore? One minute of silence please...).

It is too bad none of these projects decouple well enough the layout and rendering part, they are really very coupled to their respective environments and all of them are super idiosyncratic and make cross-language development almost impossible or unpractical (except maybe Qt but it is not quite the same model as QML), as opposed to the openness of the web platform. I think maybe all of them use Skia on the back though?

Some of these projects are similar to the browser in that they allow controlling the content using an scripting language (JavaScript for QML). What do you get when you mix a rasterizer plus a scripting system or VM plus a layout system plus some IO primitives? Macromedia Flash! Just kidding, you get a browser. Or either one :-).

1: [http://doc.qt.io/qt-5/qmlapplications.html](http://doc.qt.io/qt-5/qmlapplications.html)

2: [https://openjfx.io/](https://openjfx.io/)

3: [http://avaloniaui.net/](http://avaloniaui.net/)

4: [https://flutter.io/docs/resources/technical- overview](https://flutter.io/docs/resources/technical-overview)

With regard to browser specific problems, I came across these articles from this "Meyerovich" guy talking about some opportunities to optimize and parallelize the layout process. Honestly a lot of this stuff flies over my head (formulating the layout problem with attribute grammars? I don't even know how to use attribute grammars for the "normal" things... :-p). I have the idea of maybe coming back to these papers some day with more time and patience and go over the references, etc:

[https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper....](https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper.pdf)

[https://lmeyerov.github.io/projects/pbrowser/pubfiles/login....](https://lmeyerov.github.io/projects/pbrowser/pubfiles/login.pdf)

[https://lmeyerov.github.io/projects/pbrowser/hotpar09/paper....](https://lmeyerov.github.io/projects/pbrowser/hotpar09/paper.pdf)

<comment><USER13> Another problem would be the delivery. Yes, writing something that behaves like a browser would be nice, but it took 10-15 years for browsers to be present on enough computers to make a clear difference, and there is currently no reason to assume that a new technology that is the-same-but-simpler would have nearly as much success.

Of course, the solution would probably be to compile that code to something that works in actual browsers, which would be somewhat ironic :)

<comment><USER9> I would say, if you managed to cross compile your new browser into a statically linked binary executable weighting a few hundred kilobytes, it would become trivial to distribute and a very attractive "platform".

<comment><USER5> You could probably easily render it in a regular browser using JS as well. Instant universal deployment.

</comment></comment></comment></comment></comment><comment><USER14> This was a very useful guide for me a couple years ago. I had to print html documents (thankfully, just a reasonably-well-defined subset) from a .NET Winforms app, but driving a browser to do it was too slow and flaky. So I used the OP as the starting point for a C# layout engine.

<comment><USER15> Is it open source? Thinking about the logic for auto boxing text nodes adjacent to elements...

<comment><USER9> Can you elaborate on "auto boxing text nodes" ? Not sure what you mean. Are you trying to shape paragraphs of text? (like [1]).

By the way, anything having to do with text is more complicated to handle that one would imagine [2].

1: [https://github.com/bramstein/typeset#variable-line- width](https://github.com/bramstein/typeset#variable-line-width)

2: [https://xxyxyz.org/line-breaking/](https://xxyxyz.org/line-breaking/)

<comment><USER15> This is what I'm referring to:

[https://www.google.com/search?q=css+anonymous+block+box](https://www.google.com/search?q=css+anonymous+block+box)

Ie. when having text adjacent to an element (which is a block element), that text is automatically inserted into a box which can't be styled or referred to, but yet help to layout the document.

          I'm in a box

          Me too

</comment></comment></comment></comment><comment><USER16> Just implementing the <video> tag is a career.

</comment><comment><USER17> What happened to Matt Brubeck?

<comment><USER18> He still works on browsers, but blogs less. You can see his contributions on GitHub.

</comment></comment><comment><USER19> Should probably say [2014]

<comment><USER20> Yes.</comment></comment>


Would you do consulting and product development simultaneously? - <AUTHOR> Would you do consulting and product development (bootstrapped) simultaneously?
I left my job to start working on my own thing (SaaS based product and bootstrapped). I had created certain prototypes and sent couple of surveys to check what the market needs. Financially I set myself certain targets before I quit and have between 18-22 months of time to sustain (for myself - with no employees and zero income). So far it looks pretty good.
My initial thought process was to do consulting + product development. Unfortunately, I have ended up taking up too many hours of consulting work for the next 9-12 months (and cutting down hours means losing it completely). And the pay is near my expectations and much better than my day job (a bit above 2.5 times). This will also significantly boost my financial savings in a short time.
BUT  -  I would end up with very less time to work on my own product(s). One option for me is to hire somebody to develop the product while i just do some sales/marketing and product management work (5-6 hours weekly). The other option is to quit consulting and work on the product myself full time - and then hire people later when product starts growing.
I think I may have ended up making the wrong choice by taking up too many hours of consulting assignments. (I am weak at delegation - and this may just be a fear out of that weakness.)
Have you been through this experience before? And what choices would you make?
P.S: At the moment I am not in a situation to hire somebody and not do any consulting work - In that case I'd go bankrupt within a year. <comment><USER2> If you're making that much more than you were full-time (and remembering this is contract work), I would probably try to hire someone on to help ... to keep your head in the game I'd recommend you do a feature or two as well as architecture / spec. Once you've got the bare-bones done the new-hire can come on and start learning the code base as there are things to refactor, implement, test, etc. Meanwhile you're still contracting making money and in your free time you're focusing on the "fun" things of software dev.

</comment><comment><USER3> i envy your problem.

I tried for years to consult and do product development. I made no real progress. Eventually I was able to do the product development by delegating to my kids.

I think you have the resources to hire someone and manage it. If I can get two teenagers to learn programming and then produce something useful with just a few hours of help and supervision a week you should be able to manage a capable programmer through a project in five or six.</comment>


Who's Smarter: Bill Gates or Mark Zuckerberg? - <AUTHOR> http://bits.blogs.nytimes.com/2008/05/28/whos-smarter-bill-gates-or-mark-zuckerberg/?em&ex=1212292800&en=b491d3fd5e5affcd&ei=5087%0A

<comment><USER2> Gates created and sustained an industry and changed our lives in the process. Love him or hate him, you have to admit that.

Zuckerberg has created something that may amount to a trend, has yet to make a dime, and is still playing catch up to MySpace in many ways. Hell, Zuckerberg isn't smarter than Murdoch.

<comment><USER3> Relax people, it's just a cute story. It's not really asking whether Gates is "smarter" than Zuckerberg (if that question is even well-formed).

</comment></comment><comment><USER4> I'm gonna go out on a limb and say Bill Gates.

The man has absolutely no taste, but I really doubt Faceberg is smarter.</comment>


Why Not Haskell? - <AUTHOR> http://neugierig.org/software/blog/2011/10/why-not-haskell.html <comment><USER2> I've only written two notable haskell programs.

One (git-annex) is a large-ish, serious work, and I have been very pleased with how haskell has made it better, even though there was a learning curve (took me two weeks to write the first prototype, which I could have probably dashed off in perl in two days), and even though I have occasionally been blocked by the type system or something and had to do more work. One concrete thing I've noticed is that this is the only program where I have listed every single bug I fixed in the changelog -- because there have been so few, it's really a notable change to fix one!

My other haskell program was essentially a one-off peice of code, which converted ten years of usenet posts from the 80's into "modern" usenet posts. At that point I was over the learning curve, so I wrote it as fast, or possibly faster than I would have written the equivilant in perl, banging out a 800 lines of code in 12 hours or so. And the code is clean, pure, and even has reusable modules, which would never have happened with any other language I've used. And it all worked the first time. Converting the entire known corpus of A news articles to B news, and from there to C news, with success on the first try is an amazing feeling.

I'm going to be sticking with haskell. I do worry that some of my haskell code may need fiddling to keep working for 5 or 10 years though.

<comment><USER3> I was very excited when I first discovered git-annex. When I saw it was written in haskell that sealed the deal for me. The haskell code I run is all very robust and I was very happy you'd selected it for g-a. Have you posted anything else about how specifically Haskell has made it better? I'd enjoy reading more about that.

<comment><USER2> I've been meaning to blog about that sometime soon. (Edit: I did write this post earlier <http://kitenet.net/~joey/blog/entry/happy_haskell_hacker/>) Also been meaning to do a screencast showing what I think of as type driven refactoring, since while I've heard haskell programmers discuss it I've not seen it actually demonstrated

<comment><USER4> I would love to watch that. Sounds really exciting.

</comment></comment></comment></comment><comment><USER5> Once you manged to grok the basic stuff about Typeclasses, Functors, Applicative, Monads, Monad Transformers, different notions of recursion, a minimal understanding of how lazyness can be quite tricky, the multitude of different ways of how errors and exceptions are handled in various libraries, and perhaps basic STM, Haskell has a tendency to become even more complex. If you want to do efficient IO and prevent space leaks, you have to learn about Iteratees, Enumerators and Enumeratees. If you wish to create GUIs in a bearable manner, its imperative that you learn about FRP and Arrows eventually. Then there's the innumerable amount of language extensions to Haskell of the GHC flavor, each of which comes with only scarce documentation and examples, but with a lot of theory (Fundeps, Type families, Existential types, GADTs ...). But there's more: Comonads, Kleisli Arrows and probably things I haven't even heard about. The whole point being: If you want to be able to handle 'real world stuff' in Haskell, its not enough to stay 'mostly pure' and use StateT, unfortunately. I like Haskell - I shudder when I think of C, C++ and Java - but at this point in time I find it overwhelming.

<comment><USER6> Are most of those names for simple concepts / design patterns / types?

I'm finding more and more that the hardest part of haskell is understanding the syntax and the terminology.

<comment><USER7> A lot of stuff is quite easy, after reading <http://learnyouahaskell.com/> \- but there is a tendency in the Haskell community, perhaps not in the core but at the fringes to look more elite, and with a lot of hand waving to make simple things (Monads come to mind) something complex sounding.

Take the IO Monad. Everyone who wrote some web/servlet code, that needs to output stuff to the web over several classes (might not be the best design in the beginning) uses a Writer (or other class) to aggregate output. He therefore, as global vars are bad (and thread local are worse ;-) adds a Writer to every method.

public T doSomeStuff(T input, Writer io)

This is nasty and ugly, and the IO monad is in essence just another way to write this in a neat form, make it composable and control the IO environment.

public IO<T> doSomeStuff(IO<T> input)

But you would not get this insight from any of the monad tutorials written by Haskell people (except the link above). Simple monad insight comes form other people outside the Haskell community, e.g. James Iry

[http://james-iry.blogspot.com/2007/09/monads-are- elephants-p...](http://james-iry.blogspot.com/2007/09/monads-are-elephants- part-1.html)

</comment></comment></comment><comment><USER8> There was recently a survey on the State of Haskell in 2011 [1]. As many people here seem to be echoing, OCaml was the main possible "replacement language". Also included in the survey are ratings of various aspects of Hackage and also Haskell libraries in general.

It was a really interesting read. I made a follow-up post [2] that analyzed the free-form responses to the last question, "What do you think is Haskell's most glaring weakness / blind spot / problem?".

Number one by far was libraries (spread across: quality + quantity, library documentation, Hackage, cabal). There are a lot of people working on this though, and progress is being made.

The runners up were 'Tools', and 'Barrier To Entry'.

I think Haskell, at the very least, is a fantastic way to learn some different ways of thinking and good habits. The (little so far) coding in it I've done has been very enjoyable for me, but I don't expect everyone to feel the same way.

It has a very warm community, and a fair bit of momentum. As time goes on I predict (and hope) it will become more viable for a greater number of people to use.

[1] - [http://blog.johantibell.com/2011/08/results-from-state-of- ha...](http://blog.johantibell.com/2011/08/results-from-state-of- haskell-2011.html)

[2] - [http://nickknowlson.com/blog/2011/09/12/haskell-survey- categ...](http://nickknowlson.com/blog/2011/09/12/haskell-survey-categorized- weaknesses/)

</comment><comment><USER9> I wished I lived in the authors world. A world where you don't have to maintain the code you wrote- or worse yet, someone else wrote. Where you could declare a program "done" and walk away and never have to revisit it. A world where "mostly works" is good enough- secure in the knowledge that you're not going to be rousted out bed at 2 in the morning on a weekend because some server in outer Mongolia hit that corner case you never thought to test. A world where all programs are small enough to fit into my head, completely, in all details. So I could simply know, if I change this, that will break.

That is not, unfortunately, the world I live in. If it is the world you live in, more power to you. Count your blessing and live happily. But the rest of us need all the help we can get.

<comment><USER10> agreed, maybe I haven't expanded my mind enough but once I started using a widely used language to program in (not saying which) where I can write relatively easily, scalable maintainable code, find plenty of work and pay the bills, my desire to experiment with other, more obscure languages has kind of fallen off, there has to be a reason why some languages are widely used and others aren't. No language is ever going to please everyone but thats how life is, you can't always change the world to suit your preferences

</comment></comment><comment><USER11> Haskell is the first language I was ever fluent in. These days I mostly work in python and erlang with a smattering of ocaml but learning haskell had a huge influence on the way I think about software.

I find it hard to articulate the ideas that I came away with. Something like 'code should be built out of small, composable abstractions that obey simple algebraic laws'. It's incredible how powerful this is in combination with pure code (which enables easier composition and algebraic reasoning), typeclasses (which make it easy to express the interface to an abstraction) and quickcheck/smallcheck (which make it easy to express and test the laws which the abstraction should obey).

Others have written about this more clearly than I ever could. In particular, Conol Elliot's writing on denotational semantics [1] and Chris Okasaki's Purely Functional Datastructures [2].

The haskell community tends to be dominated by academic research so it's easy to dismiss the typical examples as impractical. Right now I'm trying to apply the same ideas to Kademlia routing in erl-telehash [3]. Hopefully I will eventually be able to demonstrate what I struggle to articulate.

[1] <http://conal.net/papers/type-class-morphisms/>

[2] [http://books.google.com/books/about/Purely_functional_data_s...](http://books.google.com/books/about/Purely_functional_data_structures.html?id=SxPzSTcTalAC)

[3] <http://github.com/jamii/erl-telehash>

</comment><comment><USER12> My company (ThoughtLeadr) is using Haskell to analyze big data (social networks) to great effect. Although, I will admit finding great Haskell programmers in the wild is rather challenging.

Network effect with programming languages is a difficult nut to crack. That's the reason most new languages build on the syntax and features of existing "successful" languages.

The toolchain aspect has been less of an issue for us since we're using it for pure data analysis rather than shoehorning it into building webapps etc.

</comment><comment><USER13> I wrote a post that was picked up by HN a while ago about why I left Haskell, so I won't rehash my arguments, but ...

On reflection, I love(d) Haskell, but the tradeoff that created the IO monad was too much for me. After 5 years using Haskell and a couple of years away from it, I've become convinced that the way Haskell isolates IO and state is not the correct solution. I'm not smart enough to know the correct solution, but creating monads, monad transformers and arrows and then providing sugar to get everything to look imperative again feels wrong. Uniqueness Types feel a bit healthier.

Now that I've said that, let me say that I'm most certainly impressed with the work around IO and state in Haskell because it was an amazing bit of intellectual horsepower and is an incredible step. But it doesn't feel like the final step/answer. Unfortunately, I had to get work done for clients and had to step away from Haskell, but I'm excited to see what the community brings forth. It's the most beautiful language on earth.

</comment><comment><USER14> I've been doing a whole lot of scientific Python lately, and every time I let my program run for like an hour only to crash on an array of the wrong dimensions, or pass in a scalar where an array is expected or vice versa, I swear and wish I was using a strongly typed language like Haskell. If only it had the same tools as SciPy I'd be all over doing my scientific work in Haskell. (Not to mention it would have faster run times.)

(There are a few array libraries, but I'm pretty sure nothing as complete as NumPy+SciPy+matplotlib exists for Haskell..)

<comment><USER15> Sounds to me like you're doing it wrong. I write scientific Python code every single day for work and I (nor anyone else who works with me) never run in to those kinds of problems. Why are you running simulations that take an hour before you even know your code work? Where are your unit and integration tests? Every piece of our software stack has (or _should_ have...) tests that verify all the bits fit together correctly in a matter of seconds or perhaps minutes tops.

Strong typing would be nice to have sometimes, but in practice I think it limits the amount of ad-hoc data analysis and exploration you can do while trying to piece together a piece of software. I think the scientists in our company would murder the software engineering team if they had to deal with strong typing to get things done.

<comment><USER16> The point is that a whole class of things that you would have to write unit tests for, you get "for free" with strong typing, and for a lot of the others, there's QuickCheck. Or as the old saying goes, why get a dog and bark yourself?

<comment><USER17> Except you don't get them "for free". You get them in the form a ton of restrictions on you that you need to be mindful of when writing it in the first place. You just pay for it in different ways. The biggest difference is that in dynamic languages, you can sometimes get away with being lazy and not writing the tests to verify the things static languages enforce to varying degrees (whether or not that's a _good_ thing is another issue).

<comment><USER18> Haskell frontloads type considerations and tests via a required, tightly- coupled type system. Dynamic languages backload them via optional testing.

In either case you still have to think about those issues when correctness is a requirement. When it isn't (ad-hoc analysis, prototyping), dynamic languages are more pleasant to work with. When it is a requirement, Haskell is uniquely powerful.

Problem is, many projects are subject to both requirements at the different times. Exploratory at the start, strict once the problem to be solved is identified. Know the tradeoffs and pick your poison.

</comment></comment></comment></comment></comment><comment><USER19> With the trend of SOA and webservers like Mongrel2, perhaps its a good time to start putting the more esoteric languages in production in the form of small services (w/ ZeroMQ for example).

<comment><USER20> Agreed, zmq and some form of cross language serialization library (we're using protocol buffers) is a seriously powerful tool to have in your box. There are some patterns that seem perfectly suited to a small piece of haskell at the end of a zmq socket.

<comment><USER16> I am using AQ to help get OCaml into "real" use: [http://gaiustech.wordpress.com/2011/05/26/ociml-new- feature-...](http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-aq/)

</comment></comment></comment><comment><USER21> I agree with the author, but for different reasons. I think Haskell suffers from a "network effects" problem. It's not made for real world use cases because nobody is using it for the real world. And guess what? To get it adopted in the real world, it needs to support real world use cases.

I think that Haskell is doomed to a life of being a research toy language for the simple reason that that's what people are using it for, not because functional programming is necessarily much harder (because I don't think it is).

<comment><USER22> Haskell has some notoriety in the financial industry. Obviously the language isn't used as extensively as, say C++ in commercial applications, but to go to such extremes as saying "nobody" uses it is plain wrong.

<comment><USER23> A couple of years ago, the only ads I would ever see on gmail in my haskell- cafe folder were for Jane Street Capital.

But they don't use Haskell. The ad basically asked if they could talk me down to OCaml. It came up for discussion on the list, and as I recall they preferred OCaml so they could write speedy code without getting hung up on lazy evaluation and its sometimes-difficult-to-predict execution time.

I still haven't looked at OCaml, although I had some exposure to SML in college. I'm looking at Scala these days (The type inference isn't even Hindley-Milner! Scandal!).

</comment></comment></comment><comment><USER24> If the question is, should we use Haskell to solve this problem, or should we use JavaScript, I can't imagine that the answer is often Haskell. (Maybe if the question is, should we use OCaml or should we use Haskell...)

That said, what really came out of left field was the OP saying that he and his friends are more and more using Go.

Is Go adoption happening? I'd love to have a systems programming language that isn't C or C++, but I'd always assumed that Go was dead-on-arrival specifically because it wasn't C or C++.

<comment><USER25> What I want to know is, is Go still undergoing major revisions? I don't seem to have been able to find an answer to this, and it's annoying. I remember there being some fairly big changes some time ago -- not so recently now, but after it was already public -- and I want to know whether that's going to still be happening before I bother learning it.

<comment><USER26> Go version 1, the first stable version of the language and implementation, is due out early next year. That sounds like a good time to start learning.

</comment></comment></comment><comment><USER27> "If you've written a Haskell program that runs, it's highly likely to be a correct solution."

having done a bit of work with haskell myself, i'd say it's even better for this for haskell programmers. _if you're using type signatures and you've written a haskell program that passes type-checking, it's highly likely to be a correct solution_

<comment><USER28> But just in case it isn't, remember that QuickCheck is a remarkably easy and powerful way to test weird edge cases:

[http://book.realworldhaskell.org/read/testing-and-quality- as...](http://book.realworldhaskell.org/read/testing-and-quality- assurance.html)

</comment></comment><comment><USER29> First, the title annoys me: "Why not X?" is almost always the wrong question to ask, because it implies that X is so great that don't even need a reason to use it. If you want me on board, the relevant question is "Why X?".

Second, _A resulting correct Haskell program is likely more reliable, maintainable, and perhaps faster_ seems fallacious to me. It might as well be that because Haskell is hard, only people with a deep understanding and appreciation of computer science ever venture into it. So, in other words, Haskell programs are good because they're written by very bright people thinking very hard about what they are doing. The same reason old mainframe code works well and average PHP doesn't.

<comment><USER30> I am guessing that you have never worked with Haskell?

Your hypothesis -- that difficult languages result in more bug-free code, due to selection bias -- is, to say the least, somewhat of a minority opinion.

But even if we accept this, Haskell is different. The difficulties of Haskell are not arbitrary. Nor are they related to the difficulty of understanding the machine at a low level. In fact, Haskell insulates you from all that; it's easily the highest level language in common use.

It's that Haskell insists on program correctness. You have to consider the entire range of values that any function could ever process. And due to its purity, Haskell applies a razor to your thought process, cutting out all unjustified or implicit assumptions.

Luckily it also gives you tools of unparalleled flexibility when it comes to creating abstractions. Creating a new abstraction (like the composition of two functions) isn't just _as easy as_ function application, that's how you _do_ function application in Haskell. Typically with less syntactical fuss than it takes Java to initialize a variable.

<comment><USER29> No, I have not worked with Haskell.

I agree that a good type system eliminates an entire class of bugs (being strongly typed is what makes Java bearable), but I rarely see bugs in well- written software caused by not having considered the full range of inputs to your function.

<comment><USER31> Really? Try harder :)

Remember that the "inputs" in non-pure languages are not only the function arguments, but can be global variables, objects (singleton or otherwise), external files, and so on. These are all inputs.

Plus, Java's type system is a toy compared to Haskell.

<comment><USER29> Try harder what? Not seeing bugs I don't see?

Yes, I'm aware what "inputs" are. One property of what I consider well written software is the absence of global state. "External files, and so on." are, unfortunately, necessary for any program, even Haskell ones, to do anything useful.

> Plus, Java's type system is a toy compared to Haskell.

Plus, so what? I'm not even beginning to compare Java with Haskell.

<comment><USER32> '"External files, and so on." are, unfortunately, necessary for any program, even Haskell ones, to do anything useful.'

I would point out that Haskell _can_ in fact do useful things, so these problems must have been solved. It is a common misconception that Haskell has "problems" with external state, when in fact what it has a way of explicitly managing such state where almost any other language does not. It isn't so much that Haskell is lacking the ability to manage external state as that _other_ languages lack the ability to manage external state, and end up with a solution that from the Haskell point of view looks like a punt rather than a great solution.

But it's difficult to explain how that works in an HN comment; I'd suggest Learn You a Haskell up through the Monad chapter, then spending some time with STM until you grok how and why the type system actually manages to guarantee proper use of STM at compile time. This is interesting because STM has proved effectively intractable in languages that can't maintain the STM constraints at the type level. While the course I've just recommended may take a week of education, that's about all it would take; it's not months, and it's actually a very valuable perspective to gain on the problem of creating quality code I'd recommend to anyone.

</comment></comment></comment></comment></comment></comment><comment><USER33> I'm learning Haskell right now. It's the most recent language I've decided to pick up since R back in 2006. Despite dabbling in Lisp about a decade ago, and the functional flavoring of R, it's been a pretty difficult ride. However, it's definitely teaching me to think about writing programs in a very different way.

I can attest to the painfulness of the IO monad. I still haven't gotten it fully. The error messages are also fairly cryptic. The first program I wrote was about 15 lines and it took me about 4 hours of time. But it worked flawlessly and efficiently. The difficulties notwithstanding, this is probably the most fun I've had learning a language ever.

<comment><USER34> I've found that the error messages quickly start making more sense (most of the time anyway...); in fact, now I parse the Haskell type error messages faster and more accurately than similar messages in Java or the like. I'm sufficiently spoiled now that error messages in languages like Python just throw me off completely...

</comment></comment><comment><USER3> For those interested in learning Haskell, I can recommend the lesser known "Haskell Road to Logic, Maths, and Programming":

[http://www.amazon.com/Haskell-Logic-Maths-Programming- Comput...](http://www.amazon.com/Haskell-Logic-Maths-Programming- Computing/dp/0954300696)

It's great to go over old and new math concepts and do so while exploring Haskell.

<comment><USER35> I don't know. For me this sounds like a very bad idea.

What is putting me off (tried building small things in Haskell a couple of times) is the already heavily buzzword compliant community, throwing not only a new language with new concept at me, but adding words that at first seem to be made up on the spot.

Additionally, as others have said here, I'm having most troubles interacting with the world (IO!). Pure functions (Math!) are ~easy~ to represent.

You suggest starting with that language and learning 'new math concepts' on the go?

(I'm sure this works for some people and hats off to you guys, but for me this increases the mental complexity immensely)

<comment><USER3> I think you raise a good point and I wouldn't want to put others off if this isn't commensurate with their learning style. I suspect the overlap between math geeks and haskell learners is pretty big, but one should, as you are, evaluate one's own preferred learning style against this approach.

I find human languages are the same for me. I have always liked to approach them from a bottom up linguistic direction, but this means largely self- structured study.

</comment></comment></comment><comment><USER36> I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work.

To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC.

Well -

I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documentation (including AWK & SED). The only reasons I have been able to do anything are Real World Haskell, Learn You A Haskell, and Stack Overflow.

I'm not going to say Haskell is useless, or has no libraries, etc. Those aren't true. It's also not a bad language because it's weirder than my Blub (Common Lisp). It's a really sweet language, and I think in the hands of an expert, Haskell can _dance_.

But, I'm going to say Haskell is nearly impossible for an experienced procedural programmer to pick up and go with on the fly. There are a few reasons for my opinion:

* Special operators out the wazzoo. >>= ` ++ :: etc. The wrong 'dialect' of Haskell leads you to believe it's Perl and APL's love child. It's just not clear what something does until you find a reference book. Google doesn't help here - I don't even know the verbal names for some of them. :)

* Monads & in particular, the IO Monad. The number of tutorials and explanations (and the number of new ones) suggest that this is not the most obvious concept in the land. It seems to be very simple if you know what you're doing (and what operators to use), though.

* The REPL is not identical to the compiler. This means that you can't _trust_ the REPL. Coming from Python and Lisp, that is a pain.

* Type messages that are quite unclear, and probably require referring to the Haskell98 report to fully understand.

 _Regardless_ , the above are surmountable problems and reasonable when moving to a new paradigm (very frustrating, though).

However, there are two key issues that are close to deal-breakers, with a third more minor one.

* Time to put a small program together. Easily 3x-10x my time working on Ocaml, a language which I am less experienced in (in both languages, I am amazingly inexperienced).

* Building the compiler on PPC (business reasons why I would need to do this). Ocaml builds with the traditional ./configure && make. Very straightforward. GHC requires a cross compile with some funky source tweaks, or _possibly_ a binary package (but the bin package dependency tree required replacing libc++, at which point I stopped). This is a dealbreaker unless I can straightforwardly guarantee my boss a good ROI with Haskell vs. (OCaml or other statically typed language).

* Human costs for my code. It's not professional to have a codebase only I can use in a team. Yes, the team could learn Haskell, but would it be a good ROI? If OCaml gets us there faster...

So Haskell is probably not going to work for me at work. :-( We'll see though.

<comment><USER21> _The REPL is not identical to the compiler. This means that you can't trust the REPL. Coming from Python and Lisp, that is a pain._

I can't agree more. This is by far my biggest issue with Haskell. It would be so much easier to learn the language if you didn't have to learn the REPL separately from the language proper.

<comment><USER37> This problem with the repl is actually going to disappear in the next ghc release (7.4.*). In particular, as of that ghc release you'll be able to interactively define types and functions (both!) in the repl.

</comment></comment></comment><comment><USER38> I agree with the author, but still it reminds me of "Beating the average" > This is the same argument you tend to hear for learning Latin.

</comment><comment><USER39> Agreed that Haskell might not be to perfect fit for most of the enterprise projects out there, BUT nevertheless it is worth learning and mastering. The perceived difficulty comes from decades of teaching of imperative programming. I'm myself the product of C/C++/Java and it's amazing how I've manage to deal with so many peculiarities of theses languages. After having learned Haskell, I realize that it's much more coherent than the vast majority of other programming languages (including the functional languages). I'm learning Scala today and frankly, Haskell is much simpler. It is just amazing what you can achieve with good abstractions (parallelism, performance, modularity).

You might be tempted to use it yet but I'd suggest you keep on eye on this language. The potential is great and Haskell is evolving quite fast.

<comment><USER18> Yes, I actually started learning Haskell recently b/c I thought it would help me better grok Scala, which seems to borrow mostly from the ML family.

Scala is definitely a better Java imho, and you get to keep the JVM and all its libraries, and the Lift web framework is superb, and you can even build Android apps with Scala.

But ironically I've found myself falling in love with Haskell and not wanting to use anything else. For the first time ever I know what a real type system is and what it's for, and Haskell basically pulls a Steve Jobs in completely rethinking how to do parallelism (strictly control global state and side effects by eliminating them by default, enabled only via monad).

Mind expanding indeed.

</comment></comment><comment><USER40> Haskell demonstrates the difference between theory and practice.

What does it matter if an arbitrary language X is beautiful in theory if nobody uses it in practice because they don't comprehend it?

Consider all those theoretically beautiful languages: APL, Ada, Lisp, Haskell, OCaml, ... How many developers use them? I think less than 1 percent in summary. Why?

Because syntax really matters. For this reason imperative languages like C++, Java, Python, Perl, Javascript, even PHP are so successfull.

As a long experienced programmer I discovered that (at least for me) the best technique is not to be fixed on one language but to use metaprogramming. That means, use your current favorite language (or create your own DSL) and compile it to the platforms/languages of choice.

My current recommendation: shenlanguage.org

</comment><comment><USER41> In the end the author seems to be using Go for a lot more development. Are people here finding it to be a good solution? It seems like it might be the language that could bridge the iOS and Android systems for app development.

<comment><USER18> _> could bridge the iOS and Android systems for app development._

How would it do that? Can it compile to Dalvik and iOS or something? Not very familiar with Go yet...

<comment><USER41> Compile to native code. Android has the NDK; they support C/C++.

</comment></comment></comment><comment><USER42> I like the shout out to go at the end. If you haven't tried that language yet I highly recommend it.

<comment><USER16> He kinda has to, being a Googler.

<comment><USER43> Nope. There is nothing that forces Googlers to either use or promote Go.

<comment><USER16> Well they ain't gonna use or promote C# are they?

<comment><USER43> Google is a very big and diverse organization, I'm sure there are some that do promote pretty much every language you ever heard of (and many you didn't).

Actually, I remember some years ago reading about some Googlers that used C#, no clue what for, and it was a while ago, but it is not unrealistic.

<comment><USER44> John Skeet?

</comment></comment></comment></comment></comment></comment><comment><USER45> My problem seems to be that despite desperately wanting to use Haskell for some decent sized project, it never seems to work out as my best option. Right now I'm interested in writing a metro styled app for win8, and even for the server side portions I feel like I'm better off just using CouchDB instead of any Haskell solution that I've seen so far. Before that it was yet-another- web-based-UI-library so my choices were pretty much coffeescript or javascript. Perhaps it's because I like to have fun with UI, but so far anything I'd like to actually spend time on -- Haskell just doesn't seem like the right tool for. My best use of it so far was solving project euler problems, and considering how much I liked it, it feels like a shame that I have nothing better to use it on.

<comment><USER46> That seems to be exactly what haskell is suited for solving, math problems. Which is great and wonderful when you are doing math related problems or things that are heavy in math but when you try and go outside those bounds that is when haskell becomes much much harder to write and work with. But alas that is both what makes haskell nice and hard to work with.

</comment></comment><comment><USER47> I've been using Haskell on and off for a few years and have written a few (small) projects in it. Every time I end up turned off of it, though.

First, I don't like how it makes side effects such a PITA. Fact of the matter is, computing is only useful for the side effects. A computation is useless if the result isn't printed to the screen, saved to a file, sent over the network, or used in some other way. So why make side effects so difficult?

Second, the community, or at least a vocal minority, come off as very condescending. If I have to ask a question on IRC I probably already feel dumb, I don't need somebody treating me like a child because I don't understand something.

<comment><USER48> One of the reasons I'd suggest Haskell to someone is exactly the community. I cannot see a question going unanswered on #haskell or at least 2-3 trying to help (doesn't matter if it's beginner-level or advanced). My experience has been the opposite.

</comment></comment><comment><USER49> Haskell is a hard language because (a) laziness is not intuitive, especially when space-performance matters (sadly, it does) and (b) pure functional programming is just not practical for most people. Like the OP said, it's awesome for brain-stretching, but not the easiest language to use.

I started writing a game in Haskell and found that the scaffolding necessary to do randomness in the "right" way was just too painful. It could be that I hadn't learned the idioms well-enough to see a better way of doing things; but if I had trouble, I think it's fair to say that most people would. Don't get me wrong: I'm a huge fan of functional programming. I just think _pure_ functional programming is impractical. Mutable state is like radioactivity: it's necessary, powerful, and sometimes very useful, but must be handled with extreme care, not promiscuously thrown about.

My favored computation model is one in which the waterline between lambda and pi calculus is clear: message-passing between agents who should ideally be referentially transparent, unless referential non-transparency is part of their design. The upshot of this is that if an agent needs to be optimized using mutable state, none of the others care. That is, it's what OOP _should have_ been.

<comment><USER50> > I started writing a game in Haskell and found that the scaffolding necessary > to do randomness in the "right" way was just too painful. It could be that I > hadn't learned the idioms well-enough to see a better way of doing things; > but if I had trouble, I think it's fair to say that most people would.

This. My current opinion as to what would constitute a perfect language is: something built on top of Haskell which would, in some as-yet-unconceived-of way, make it easy to thread mutable state exactly where it needed to go in your code.

Like monads were supposed to do, except _readable_.

Frankly, the code contains all the information you need to do this already, so perhaps we just need a source-code übereditor that marks it up so that you can see the dataflow.

<comment><USER49> Monads are not unreadable. When you finally get do-notation and realize that you can use the same idioms for (a) list comprehensions, (b) imperative-style programming, and (c) error-handling and option-chaining, there's a "Wow" moment. However, we can give up on selling monads to the masses. The name alone...

The concept of the monad is beautiful and awesome, but it's too _different_ to succeed with the masses.

<comment><USER18> _> However, we can give up on selling monads to the masses. The name alone..._

A monad is just a monoid in the category of endofunctors, what's the problem?

(for anyone not familiar with the in-joke: [http://stackoverflow.com/questions/3870088/a-monad-is- just-a...](http://stackoverflow.com/questions/3870088/a-monad-is-just-a- monoid-in-the-category-of-endofunctors-whats-the-problem))

</comment></comment></comment></comment><comment><USER51> Why haskell is a more appropriate question.

</comment><comment><USER52> The intro read like it would be a much longer article.

tl;dr - Haskell isn't easy enough to use / is lacking good toolchains for author's use cases</comment>


Fundra – funding for nonprofits using budgeting and financial transparency - <AUTHOR> http://www.gofundra.com <comment><AUTHOR> Most donation platforms don't provide details as to where funding is being applied. With Fundra, you're never in the dark about where your money is going. Fundra helps donors donate with confidence by giving you the ability to track your donation and see how the nonprofit / program you supported is keeping up on their expenses. For nonprofits, Fundra helps you raise funding for the monthly expenses you really need help with; right down to the financial statement line.

Fundra allows nonprofits to raise money for monthly expenses; ranging all the way from electric bills, to rent, or even their upkeep fees. Fundra also provides a seamless experience to donors; allowing them to discover nonprofits across the globe, and effortlessly make donations to them.</comment>


Peer-reviewed paper debunking conspiracy theories has a (deliberate?) flaw - <AUTHOR> http://littleatoms.com/david-grimes-conspiracy-theory-maths <comment><AUTHOR> and the author, in the comments, essentially agrees that a key part of his math is wrong: [http://www.plosone.org/annotation/listThread.action?root=881...](http://www.plosone.org/annotation/listThread.action?root=88142)</comment>


Researchers Worldwide Rally to Help Scientist Exposed to Ebola - <AUTHOR> http://blogs.sciencemag.org/scienceinsider/2009/03/researchers-aro.html <comment><USER2> Many, many, many years ago there was a hugely popular TV show in Germany about a hospital - _Black Forest Hospital_

And in one particular show arc, one female scientist accidentally pricked her finger with a virus of some kind and ended up dead.

So... here's hoping life doesn't imitate art.

</comment><comment><USER3> March 18th - they ought to know at this point.

<comment><AUTHOR> Yeah, you're right.

I found somewhat on an update here: <http://www.bmj.com/cgi/content/extract/338/mar23_2/b1223>

</comment></comment><comment><USER4> Hopefully this is just much ado about nothing, but if she is infected then I hope the fact that humans are much larger than previous test subjects that the live-vaccine they gave her will alert the immune system before the ebola gets to deadly ammounts.</comment>


My take on long distance cycling BibShorts - <AUTHOR> https://medium.com/@redwhite_apparel/the-redwhite-bibshorts-80777e28880b

<comment><USER2> How would this work with events like Tour de France? Wouldn't there be excessive sweating?

<comment><AUTHOR> excessive sweating isn't an issue at all. The fabrics used throughout the cyclewear industry have undergone significant developments as recently as 5 years ago.

The main principle is "moisture wicking" , where sweat is pulled away from the skin towards the outer layer of the fabrics where they evaporate, keeping you dry.

Our main fabric supplier, MITI, has been in this game since the early 20th century and they are always at the forefront of fabric technology. We are currently enjoying the advantage of "trickle down tech" where fabric technology that was currently only available on the really expensive BibShorts are now available at a lower cost - largely due to economies of scale and process efficiency.</comment></comment>


Interactive map reveals where you can afford a flat in Berlin - <AUTHOR> http://interaktiv.morgenpost.de/mietkarte-berlin/

<comment><AUTHOR> The project is Open Source. You can find the code on Github: [https://github.com/berlinermorgenpost/mietkarte](https://github.com/berlinermorgenpost/mietkarte)</comment>