Contactless 'charging errors' at Marks and Spencer - <AUTHOR> http://www.bbc.co.uk/news/business-22545804

<comment><USER2> The utter lack of control on the part of the customer, having neither an approval step nor the ability to switch the card off seems to me to be a fundamental flaw in this payment method.

This system was pretty much designed to be abused.

<comment><USER3> Time for RF-blocking wallets to become more mainstream perhaps? That gives control back to the customer.

<comment><USER4> Are there any nice, good quality RF-blocking wallets? I've only found poor quality fake-leather / synthetic fabric wallets when I've looked.

<comment><USER5> I got an RF-blocking card that you can put in your current wallet.

</comment></comment></comment></comment><comment><USER6> So with a contactless card a thief simply has to have the card - there's no chance a teller will check for matching signatures (not that most tellers do this in the US, though I have noticed in Germany tellers are more likely to). Who wanted these?

<comment><USER7> Everybody in the foodchain - well, except for the customers, but who cares about the customers, right?

<comment><USER8> Many customers wanted them - they make payment a lot more convenient.

<comment><USER9> In current implementation, no.

The card readers rarely function adequately if at all. On occasions when they do work, the screen is broken meaning the customer can't identify whether payment has been requested, the amount requested, whether payment has been made, how much you are being charged, or even whether you are paying the bill of the correct till.

The cards interfere with each other and in particular with Oyster transport card in London - people use their Oyster card frequently and therefore have that in primary location: still have to pull out whichever other card they want to pay with.

In practice, people don't often use contactless cards and most customers I've observed attempting to use them express fear and wish to revert to traditional method.

The receipt is still the final part of the transaction, which customers are more inclined to wait for because they have no other way of confirming what just happened.

<comment><USER10> This is almost entirely FUD, and 'the card readers rarely function adequately if at all' is just plain untrue. What makes you say the readers don't work? Personal experience?

I've seen a broken screen on a contactless reader once, however I've also seen lots of broken Chip and Pin readers -- doesn't make the system faulty.

All contactless systems I've seen are either built-in to the same unit as the Chip and Pin device (which has a display) -- or a separate reader, which also has a display. Both clearly state when payment has been requested, and how much you are being charged. The problem of '[..] or even whether you are paying the bill of the correct till.' is rarely ever a problem at all. With the vast, vast, vast majority of readers, it's instantly obvious which reader you should use (because it's right in front of you!). Besides, if it's not immediately 100% obvious which reader you should use, the cashier will point it out to you, but again, this 'problem' is not a regression on chip and pin, which suffers from this.

Contactless payment is a hugely popular choice of payment in central London. Take a look at a Pret or Eat (or indeed, M&S) at lunchtime. Consumers aren't in the least bit scared about contactless, nor do they 'express fear'. Everyone I've spoken to about contactless has absolutely loved it. It's unbelievably convenient for consumers and a huge win for businesses too.

Agree with the interference though, that is annoying. That said, anyone with any sense doesn't keep their Oyster in their wallet :). Having to hold your wallet out in your hand and place it on the sensor is just asking for someone to grab your wallet (keep oyster in separate pocket during journey, replace during wallet upon arrival at destination).

<comment><USER9> Yes, the FUD is gathered from personal experience of several non-City branches of Pret and Caffe Nero, in particular.

</comment></comment></comment></comment></comment></comment><comment><USER11> Perhaps a microwave oven can fry the input stage to the radio receiver, which presumably has an antenna hanging off it and so is more susceptible to damage, whilst leaving the rest of the chip intact? Anyone tried this?

<comment><USER12> That will probably visibly damage the card (I expect the loop antenna would get really hot) and it would disable the chip-and-pin feature as well, making the card useless.

I've had a MIFARE card crack starting from an edge, sectioning the loop antenna. I couldn't get it to work again even if pressing the two sides together, and it wasn't visible unless pulling the two sides apart, so this seems like a better approach.

<comment><USER11> It would be an interesting experiment to try and do it closed loop, in an effort to dump enough energy in to damage the radio front end, but not overheat the rest of the circuit. Have a computer with a card reader interrogating the chip via the near field, and cutting the power to the microwave, via a relay, as soon as the chip stops responding?

</comment></comment></comment><comment><USER13> Am I right in thinking that the only thing stopping NFC working at greater distances is signal strength?

If so, presumably someone could make a targetted aerial which would allow functioning over greater distance (like the 'pringle can wifi' approach). If I understand correctly, you will still increase the distance with only one end using a directional antennae.

If so, couldn't someone walk through a crowd and skim passers-by fairly easily?

<comment><USER14> The thing is, that NFC is NOT like RFID. That's how the cards in Korea or Hong-Kong work, and that's how early contactless cards in the US worked. RFID is super easy to abuse, because you can just read what is on the chip and clone the card, even from a large distance. NFC however, is active - if you have an NFC reader, it will NOT be able to read your bank card, because you don't have an authentication key, so your card will literally not send you the details stored on it. I have personally tested this with commercial NFC readers - bank cards cannot be read by them, they only work with approved, authorized,and connected to the internet payment terminals(so they can get the auth key from the bank). That's why it would be very difficult to skim peoples' cards off the street - you most certainly can't do it without an authorized terminal, which means that to get one you would need to register with a bank,and give them all your details and such, which would make you very easily traceable.

<comment><USER13> So the issue stopping NFC abuse is the policing of questioned payments?

[i.e. someone with a auth key can basically choose to charge people what they want (by using modified aerials), it's up the the people charged to complain sufficiently to get that auth key revoked]

I'd imagine that there might be a low bar of complaints to get a key revoked, but perhaps a higher bar to start legal proceedings?

<comment><USER14> The problem is, that if you just wire an aerial to a legit payment terminal and point it at people, it will probably pick up more than a single card, in which case, it won't charge anyone. The use case for that is extremely limited.

</comment></comment></comment></comment><comment><USER15> From the commentary on the news today, it seems that people inadvertently held another card (maybe in a wallet) too close to the reader whilst trying to use Chip and Pin with another card.</comment>


A Complete CMS with No Server and 18 Lines of Code - <AUTHOR> https://www.netlify.com/blog/2017/08/17/a-complete-cms-with-no-server-and-18-lines-of-code/ <comment><USER2> Github is down right now, so your cms is down to. So much for No Server.

<comment><USER3> Seems more like, 'no server, that you control'. Which, not sure what the selling point is there.</comment></comment>


Linguistic Harbingers of Betrayal - <AUTHOR> http://vene.ro/betrayal/ <comment><USER2> I feel the planning is the most decisive symptom. A person who doesn't see a future won't project themselves into one.

</comment><comment><USER3> The excess of positive language prior to betrayal point definitely matches my personal experience.

<comment><USER4> The reduction in politeness is also interesting. As someone who really enjoys formality, I like to think that forms are a kind of social guardrail to reduce the likelihood of misbehaviour (which would of course include betrayal), but that's probably far too pat.

<comment><USER5> > _The reduction in politeness is also interesting._

It's very counter-intuitive. I'd like to hear a rationale for this strategy.

<comment><USER2> My guess is dehumanization. The betrayer has to shove down their empathy, and that blocks them from thinking of actions that flow from caring about another's feelings - except instrumentally. So direct feeling manipulation, "positive sentiment", goes up.

</comment></comment></comment></comment><comment><USER6> They don't have an app for this yet? There's an obvious startup here.

<comment><USER7> I was thinking the same thing. Diplomacy is one of the best multiplayer games ever designed. This should be ideally suited for writing as a mobile app. I'd love to know if there any out there worth checking out.

There's this at the iPhone App Store: "The Game of Diplomacy by Chris Hughes" [https://appsto.re/us/iCIzt.i](https://appsto.re/us/iCIzt.i)

</comment></comment><comment><USER8> that is _not_ purple

</comment><comment><USER9> "Our men at the Wernicke and Broca Station Posts suggest that the good Ambassador Moustache is not as trustworthy as he seems..."</comment>


An Ode to Kai's Power Goo - <AUTHOR> http://www.macworld.com/article/3005783/software-graphics/an-ode-to-kais-power-goo.html#tk.rss_all <comment><USER2> I almost got suspended from high school for using PowerGoo on a photo of my friend. Result was a trip to principal's office, a call to parents, and a day of detention. Apparently another student was "afraid i may create something horrible out of his yearbook photo" and reported me. Later, he admitted that he just used that as an excuse to try to get me suspended as a way of bullying me (i was a nerd).

This was in 2000. Today, given the insanity about political correctness, i would expect nothing less of a SWAT team, 3 months of required psych counseling, and getting expelled as minimum punishment.

</comment><comment><USER3> Cool flashback to the nineties. I remember spending hours at school in '97 or '98 obscuring class pictures of everyone as a gag. Approved by the teacher who also loved this kind of stuff.

Here's a link to the wikipedia article about the developer, Kai Krause. [https://en.wikipedia.org/wiki/Kai_Krause](https://en.wikipedia.org/wiki/Kai_Krause)

He sold the software to Corel (remember them?) and bought a castle in Germany. [https://de.wikipedia.org/wiki/Bad_Breisig](https://de.wikipedia.org/wiki/Bad_Breisig) (the German article has more pictures).

Would be fun to have these tools back on an iPad to play around with my kids.

<comment><USER4> Perhaps you're in the market for the fractal app he helped create.

[http://fract.al/](http://fract.al/)

<comment><USER3> Instant purchase. Thank you very much!

</comment></comment></comment><comment><USER4> Just looked him up and learned that Kai lived next door to Douglas Adams and collaborated with him on book covers.

[http://kai.sub.blue/en/42spheres.html](http://kai.sub.blue/en/42spheres.html)

</comment><comment><USER5> Don't forget Alien Skin's Eye Candy, still going strong for all your _burning_ text needs! (see what I did there?)

[http://www.alienskin.com/eyecandy/](http://www.alienskin.com/eyecandy/)

I loved the hell out of those days.

<comment><USER6> Somewhere I have an Alien Skin button I picked up at a trade show.

"Computers = Ticket to Hell"

I think a lot of (especially graphics) companies were more irreverent back then.

</comment></comment><comment><USER7> Apple continued some of this UI tradition for quite a while, with Aqua and stuff like QuickTime Player, then their skeuomorphic phase on both iOS and OS X. And of course, using painstakingly rendered, depthful interface elements in general is part of the same spirit.

I will now list some Kai/MetaTools/MetaCreations products that were also awesome in part because of their crazy UIs.

Kai's Power Soap Bryce Poser Carrara Camino

</comment><comment><USER8> I made student council campaign posters with stereograms back in 1995 using KPT ... and I won! Great next-level stuff for home computers back then.

</comment><comment><USER9> I loved KPT. It looked like alien software from the mid 21st century that somehow landed in the late 1990s.

The UI was gloriously white and 3D way before skeuomorphism was even a word.

Is there an open source version of goo? Or a description of the algorithm?

It doesn't look impossibly difficult to work out, but it would be useful to know how other people approached it.

</comment><comment><USER6> The team from these MetaTools and related companies has gone on to permeate the industry - and others. From CoreImage to f.lux, from Sonos to Google - always interesting to see how people move through the industry.

</comment><comment><USER10> Very interesting. I was actually trying to remember this piece of software just the other day because I recognised a similar effect on a tv show and wanted to replicate it...

</comment><comment><USER11> Even to this day, when I'm standing over someone's shoulder "helping" them photoshop, I often say "use the Kai thingy" when I mean liquify.

</comment><comment><USER12> In 1996 I started using GIMP. It was on a Sun SparcStation 20 running RedHat 2 Linux. Can't remember whether IWarp was a feature or not yet; probably not.

</comment><comment><USER13> Bring back the power tools.</comment>


The rock-paper-scissors game and the evolution of alternative male strategies - <AUTHOR> http://bio.research.ucsc.edu/~barrylab/lizardland/male_lizards.overview.html <comment><USER2> Also,

[https://en.wikipedia.org/wiki/Nontransitive_dice](https://en.wikipedia.org/wiki/Nontransitive_dice)</comment>


Ask HN:Infrastructure for a software project - <AUTHOR>

Hi,
I'd be leading a new project soon. And I've been pondering over what are the basic infrastructure for a software project. These are the stuff that I think every project should have:
-Coding style conventions
-Naming conventions
-Standard project directory structure(eg maven standard dir layout, etc)
-Project management and issue tracking(eg trac, redmine, etc)
-Continuous Integration server(eg, hudson, cruise control, etc)
I'm not sure if I missed out anything. Would anyone like to add? <comment><USER2> If you're in this stage of setting up, there are a lot of (free) virtual machines (virtual appliances) that will do a lot of what you need.

You can spin up a VM that's got linux and already installs of things like SVN, Trac, etc, etc. Run them on something like VMWare Server (free) and you're all set in mins/hours.

There are a lot of VMWare based ones listed here: <http://www.vmware.com/appliances/>

Really handy and can save a lot of time.

If you're working remotely, or at disparate or varying locations, I'd recommend the Hamachi VPN software (www.hamachi.cc). The Linux and Mac clients are very basic, but still work well.

With this kind of setup we can take VMs of all the infrastructure, drop them anywhere and still work. We can take our laptops home, move house, sit in a cafe, go overseas and still check code in and out. All been very handy.

</comment><comment><USER3> A common image for the developer machines.

You'll easily lose a week per developer (especially ones that may join the project later) if each one is himself responsible for setting up development environment, support tools, off-line documentation etc.

</comment><comment><USER4> Version control, of course.

</comment><comment><USER5> You might want to read Cal Henderson's book _Building Scalable Web Sites_ : <http://www.amazon.com/dp/0596102356/>

</comment><comment><USER6> <http://sourceforge.net/projects/alexandria-dev/></comment>


Functor, Applicative, and Monad - <AUTHOR> https://typeslogicscats.gitlab.io/posts/functor-applicative-monad.html <comment><USER2> I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying to be presented.

This article is most readable to those who already understand OCaml code, and if you can already read OCaml code you already understand these concepts.

<comment><USER3> You claim that OCaml programmers are already versed in category theory but that's not correct. The first exposure usually comes with concurrency libraries such as Lwt which isn't very old nor in the standard library, and it provides syntax sugar so you can start being productive right away.

You can write perfectly fine production OCaml programs without knowing what a monad is. Some may, but a lot of OCaml devs don't care about them.

<comment> hope-striker This is correct, and in contrast to Haskell, where monads are a core part of the language (they are used in the definition of do-notation and list comprehensions) and currently the mainstream way to do IO.

<comment><USER4> This is misleading. There's no place in the specification of Haskell that specifically defines monads as part of the language. They aren't a language feature. They are a pattern which happens to be expressible in Haskell, and which is supported by libraries:

"Haskell's built in support for monads is split among the standard prelude, which exports the most common monad functions, and the Monad module, which contains less-commonly used monad functions. The individual monad types are each in their own libraries and are the subject of Part II of this tutorial."

[https://wiki.haskell.org/All_About_Monads#Monad_support_in_H...](https://wiki.haskell.org/All_About_Monads#Monad_support_in_Haskell)

The fact that monads are used to implement parts of the language doesn't make them a core part of it. Techniques used in implementation aren't the same as language features.

<comment><USER5> Is do notation a language feature?

<comment><USER6> it's syntactic sugar

</comment></comment></comment></comment></comment></comment><comment><USER7> An important realization that I had was that monads/functors/applicatives aren't patterns in the sense of design patterns. You don't solve a singular problem with a monad. With something like a strategy pattern you have a concrete problem: how do I select different potential algorithms? Monads don't have a specific problem that they solve. Any attempt to motivate monads in such a manner falls flat because the problem is either too general to be motivating or too specific to apply to monads as a whole.

Instead, functors/monads/applicatives are more like a technique that can be used to solve a wide variety of problems that all coincidentally use the same function signature. And therefore, it's perfectly acceptable to say "I know how monads work with Maybe and List, but not Reader" Because fundamentally, how a Reader implements bind is in no way related to how Maybe or List implement bind.

<comment><USER8> > And therefore, it's perfectly acceptable to say "I know how monads work with > Maybe and List, but not Reader" Because fundamentally, how a Reader > implements bind is in no way related to how Maybe or List implement bind.

If this is indeed true, what is the point of learning these "patterns"? From a mechanical understanding of the signature of bind and unit, you'd arrive at more sophisticated signatures, say filterM, but an understanding of what it does will still need an understanding of the specific implementation of the Monad instance it is being applied on. That sounds like a leaky abstraction. If so, why bother?

<comment><USER9> The point is that Monad, Applicative and Functor are well defined interfaces with laws (properties) you can count on.

They are in fact much better, more precisely defined than classic design patterns.

And in expressive programming languages (that support higher kinded types or that at least let you encode such types) you can also describe generic code that works over any applicative or monadic type.

Having reusable functions that work just as well on lists, maybe/option, reader, io / promise or what have you means these type classes do a very good job at abstracting over data types. These are the purest forms of abstraction.

And you can get syntactic sugar from the language as well. For example "for comprehensions" in Python work via the iterator/enumerable protocol, but that's super limiting. Haskell's "do notation" or Scala's "for comprehensions" work on any monad instead, being much more powerful and reusable.

Unfortunately it takes an expressive language to understand and work with these abstractions comfortably. You won't grok monads in Go or Java.

<comment><USER10> > Having reusable functions that work just as well on lists, maybe/option, > reader, io / promise or what have you means these type classes do a very > good job at abstracting over data types. These are the purest forms of > abstraction.

This is where I get kinda lost. Can you give an example of such a reusable function that works for all these things which does something valuable?

<comment><USER11> The simplest but still most versatile one is probably fmap (also knowns as <$>) which lets you use a function on whatever is inside the burrito:

(+1) <$> Just 1 → Just 2 (+1) <$> getIntFromThatUserThatOnlyTypes1 → IO 2 (+1) <$> [1,2] → [2, 3] ((+1) <$> ask) 1 → 2

Want let a function eat several burritos without making a mess? Keep your burritos apart with < _> :

take <$> Just 2 <_> Just "abc" → Just "ab"

etc.

You can be quite productive without moving past the burrito analogy.

<comment><USER12> No. If you attempt to write monad-generic code using the burrito analogy you will inevitably write broken code, causing serious problems for other users and/or your future self.

Burritos may be a good analogy for some subset of monads, e.g. collections, but they are not a good analogy for monads in general: the function you pass to fmap may be executed now or later, zero, one, or many times, before or after a function you pass to a later fmap.

<comment><USER11> Nah, like any bad analogy, it can be stretched :) Once you've moved past the "lies-to-children[1]" version, you can ascend to the real meat of the burrito: [https://blog.plover.com/prog/burritos.html](https://blog.plover.com/prog/burritos.html)

And once you've fully grokked burritos in terms of monads, you can finally reach that zen level where you solve your problems without even a single line of code (because you've started working at the burrito shop instead: [http://chrisdone.com/posts/monads-are- burritos](http://chrisdone.com/posts/monads-are-burritos) ).

[1] [https://en.wikipedia.org/wiki/Lie-to- children](https://en.wikipedia.org/wiki/Lie-to-children)

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Even better [http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...](http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html)

<comment><AUTHOR> I am the author of this submission. I have strong opinions about functor and monad tutorials, and here are my thoughts:

Back when I didn't understand what a monad was, I would read a bunch of tutorials and get confused by the analogies and examples. For example, I would get confused by comparisons to "boxes," or I would think that Maybe was the _definition_ of a monad, or that IO was the _definition_ of a monad.

The information in the tutorial that you link seems to be all correct. However, it's too "jumpy" for my tastes. The tutorial talks about "contexts," but doesn't really explain what a "context" is, except for making a comparison to "boxes." I get that a functor is an abstract idea, so explaining it in an understandable way is difficult. However, I wish that the article would discuss type constructors, because the idea of mapping types to types is an important part of the definition of functor. Without this explanation, I imagine that the comparison to "boxes" would have given the past me the wrong impression of what a functor is.

In my tutorial, I sought to teach the actual definition of a functor, applicative, and monad. I explain that a functor maps types to types and functions to functions in a way that preserves composition and identity, that an applicative preserves the product, and that a monad is characterized by a "join" operation that "flattens" the data and a "return" operation that "wraps up" the data. I actually would have preferred to explain the actual category theory, but I felt that it would be too intimidating, and so I attempted to convey the ideas in a non-category-theory way. With my current understanding of functor, applicative, and monad, I believe that if one doesn't learn their actual definitions, one doesn't truly understand them. I guess that I wanted my tutorial to be more rigorous.

However, I am not an expert on teaching, so maybe I'm taking the wrong approach.

See my Reddit comment: [https://www.reddit.com/r/programming/comments/cy35zz/functor...](https://www.reddit.com/r/programming/comments/cy35zz/functor_applicative_and_monad/eyshqyc/)

<comment><USER14> Thank you for taking what seems to be an interesting approach to explaining these concepts.

> I use OCaml in this tutorial, with some occurrences of Haskell.

> My intention is for anyone familiar with the basics of typed functional > programming to be able to follow along.

I don't know OCaml or Haskell and I got lost very early on due to the unfamiliar syntax. Do you think your explanation would be easy to translate to a more widely known language like Python or C?

<comment><AUTHOR> _Shrugs_ Well, Python is dynamically typed and C doesn't really have good polymorphism or first-class function support. Both polymorphism and first- class functions (with closures) are important for understanding functors, applicatives, and monads.

I admit that I'm more fluent in OCaml than I am in Python or C, so please correct me if I'm mistaken.

<comment><USER12> Python and C would indeed be unsuitable. Maybe Rust (quite OCaml-like, but with a more C-like syntax) or Java/C#/Kotlin would let you present these ideas with a more "mainstream" syntax?

<comment><USER15> You can do it in Scala which has powerful type support.

The problem with other languages is that they lack the support for the higher order types, so the implementation is dishonest or you have to build up an API (new embedded minilanguage) to express them, which is a lot of work and a distraction.

And, the result tends to be very cluttered with syntax junk, as you can see in Scala and Functional Java.

Which incidentally is why people generally don't use these ideas in Java code. You can use these design ideas in your Java architecture, but not directly express them in your Java code.

<comment><USER12> OCaml also lacks higher-kinded types. As far as I can tell, anything you can do in OCaml you can also do (perhaps verbosely, though less so in more recent versions) in Java.

<comment><USER16> OCaml have HKT, it's in the module part of the languiage, it's just verbose.

And OCaml's module language is much more powerful than Java, since module language is a dependently typed language. You can't, say, pass a class including a type for another class in java.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> there's an equivalent definition of Applicative that may be a bit less intimidating:

      class Functor f => Applicative f where
        unit :: f ()
        (**) :: f a -> f b -> f (a,b)

[source - a bit CT heavy]([https://stackoverflow.com/a/35013667/5534735](https://stackoverflow.com/a/35013667/5534735))

(i'll be writing the second operation as `××` in some places because of HN asterisk weirdness)

this gives us:

\- `unit`, a "template" container with a hole we can fill (by doing `fmap (const myValue) unit`, equivalent to `pure myValue`)

\- `fa ×× fb`, to "compose" two Applicative values. this shows how, unlike with Monads, the two computations must be "independent". for example, if IO were only an Applicative, you could do

      print "hello" ** print "world"

but not

      getLine >>= \s ->
       print ("hello, " ++ s)

(where the second computation depends on the string we got in the first one)

it also nicely shows the two ways lists can be an Applicative - `fa ×× fb` can be either the Cartesian product `[(a,b) | a <\- fa, b <\- fb]` or `zip a b` (ZipList).

(also, it's kind of like a Monoid, which is neat!)

<comment><AUTHOR> Huh? I cover this definition in the tutorial, when I discuss OCaml's (and+) operator! Did I gloss over things too quickly?

<comment><USER17> oh man, i must've missed it! tbh though, i just quickly scanned through the article to see if this needed plugging, because I remember being completely stumped by `(<×>)`. too late to edit it now though :/ sorry!

</comment></comment></comment><comment> hope-striker Nice explanation of monads!

My two cents: personally, I would've started with the fact that a monad is exactly the stringing together of functions (a -> m b), and the similarity between monoids, monads, strings / lists and functions under composition. You mentioned that

• (a -> [b]) is the type of non-deterministic computations

• (a -> Maybe b) is the type of fallible computations

• (a -> IO b) is the type of effectful computations

• (a -> (s, b)) is the type of computations with state s

• that the Monad instance merely specifies how to compose them

• all such composable constructs can be expressed as a monad

• do notation and list comprehensions automatically work across all of them

and, in my opinion, these are all much more powerful motivation than beginning with a comparison to functors.

</comment><comment><USER18> It's just mind boggling how universal these concepts are and how they show up in surprising ways. As a recent example, I've been learning the basics of composing music in Haskell with Euterpea[1] and wanted to make a function which played several notes over a list of octaves to make chords. It turns out the applicative operator was exactly the function I need to do this! It would be hard to go into the details in just a little blurb here... but here is a piece I made with with it[2]. And here's the line of code with the applicative operator:

notePlayer notes octs dur = musicSeq $ (uncurry <$> notes) <*> ((, dur) <$> octs)

Won't make much sense without context, but it's there!

[1]: [http://www.euterpea.com/](http://www.euterpea.com/)

[2]: [https://soundcloud.com/a-mathematical-way/not-enough-time- to...](https://soundcloud.com/a-mathematical-way/not-enough-time-to-read-the- manual)

<comment><USER19> I have never heard of Euterpea, nor have I seen the rest of your code, but I suggest you refactor your slightly convoluted code like this:

        notePlayer notes octs dur = musicSeq $ notes <*> octs <*> pure dur

Coincidentally, this might be a testament of the power of parametric polymorphism and equational reasoning.

<comment><USER20> My favorite part about Haskell is how you can know literally nothing about the domain and make meaningful changes to programs regardless thanks to local reasoning.

That's really one power of functor/applicative/monad - if you understand their interfaces, you can work with new unfamiliar types that have these instances without much effort at all.

<comment><USER18> It's amazing. No one could ever do something like this with an imperative language!

<comment><USER20> Nobody ever said that :)

Although abstracting over this stuff isn't possible in any imperative language unless Scala or maybe advanced C++ template count. But that isn't due to their imperative nature exactly.

But local reasoning is very hard to count on in most other languages - that's for sure. It's easier to just run a VM in your head.

</comment></comment></comment></comment></comment><comment><USER21> I always go back to "Learn you a Haskell for Great good".

[http://learnyouahaskell.com/functors-applicative-functors- an...](http://learnyouahaskell.com/functors-applicative-functors-and-monoids)

</comment><comment><USER22> Being someone who is still struggling with these concepts, I like this tutorial because at least it doesn't use the common list/maybe/state to illustrate the concepts. Somehow I feel these concepts are so abstract - unless one is well versed in category theory, maybe only a data approach can prevent people from overfitting these concepts to specific examples.

I would really hope to see a tutorial that have a diverse set of examples and just fmap each example with a light explanation of say, what is a monad in this code and what is not, and because it's a monad we can do this.

Essentially the tutorial can just train a classifier in one's head, and with a nice set of examples maybe the brain can learn a general representation of concepts for the classifier ...

<comment><USER23> In this series functional concepts are very gently introduced. I feel like it really appreciates the beginners starting point and assumes very little. Is this close to what you want?

[https://egghead.io/lessons/javascript-linear-data-flow- with-...](https://egghead.io/lessons/javascript-linear-data-flow-with- container-style-types-box)

</comment></comment><comment><USER24> After learning Elm for a few months I picked up a Haskell book. When I got to the Functor, Applicative and Monad chapters I discovered that I'd actually been using them for months without knowing it. Having had practical experience with them the theory came as a revelation. I found that I'd developed an intuition for them from all the concrete scenarios where I'd used them.

The Elm community goes out of it's way to avoid talking about them because they make learning functional programming seem far more intimidating. It's a very simple language though - Evan had always had beginners in mind when desiging the language and tools. If you're looking to improve your functional programming skills it's got a great learning curve.

</comment><comment><USER25> I should learn to read Haskell one of these days. Not today though.

<comment><USER26> "Learn You a Haskell" is sparse on theoretical foundations. I made it halfway through the book feeling like I only had a superficial understanding of the language. If you are interested in a rigorous or systematic approach I recommend "Haskell Programming from First Principles".

<comment><USER27> I think both are great books, but the book you choose is secondary in importance to the amount of time you spend just bashing your head against it until it starts to make sense.

</comment></comment></comment><comment><USER28> I still find Philip Wadler's original paper on Monads to be the clearest explanation of the pattern and concept. It remains scoped to the usefulness of the concept in programming, lays out very clear motivating examples, and proceeds to implement the pattern to solve each case in a lucid and explocit manner. I'd say the only downside is that it assumes at least some familiarity with FP and writing more "theoretical" or academic tools like evaluators, but all in all it's still much clearer than the majority of garbled explanations of monads, even those that attempt to explain the concept through its dependencies/priors (functor/applicative).

here's the paper: [https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...](https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf)

</comment><comment><USER29>
        It turns out that every generic type t has a corresponding map function map : ('a -> 'b) -> 'a t -> 'b t.

So how about x : 'w -> Bool?

<comment><AUTHOR> If there is a function `map : ('a -> 'b) -> 'a t -> 'b t`, and there exists a function `x : 'w -> bool`, then `map x : `'w t -> bool t`. Is this what you were asking?

<comment><USER30> Think `data Foo a = Foo (a -> Bool)`, pardon my Haskell. A function `map :: (a -> b) -> Foo a -> Foo b` is impossible, however `contramap :: (a -> b) -> Foo b -> Foo a` is fine (just pre-compose the given function with the stored function).

Even worse with `data Bar a = Bar (a -> a)`.

<comment><AUTHOR> Thanks. I know what contravariant functors are, but I haven't used them, so I didn't realize that was what the parent commenter was asking about.

You're right, my claim that every type 'a t has a corresponding (covariant) functor is incorrect, and I should either take that out or mention contravariant functors.

<comment><USER29> It's even worse than that. Consider

        data Foo a = Foo (a -> a)

This admits neither Functor nor Contravariant. Sadly all you can say is "If you can map, it's a functor."

I always end up finding out more about any subject I actually publish a post about when people read it...

<comment><AUTHOR> Thank you for pointing out contravariant functors; I have fixed that sentence in my post and credited you.

<comment><USER29> Oh that's much more extensive. Like the link to Julie's work.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> > According to currying, 'a -> 'b -> 'c is interchangeable with 'a * 'b -> 'c. > (The fancy math word for this interchangeability is "isomorphism.")

I thought isomorphism was when a function was reversible. I didn't think it had anything to do with currying.

<comment><USER32> It means there are two functions going between them that witness the isomorphism.

The witnesses in Haskell are the higher-order functions (they transform functions) `{,un}curry`:

        curry :: ((a, b) -> c) -> (a -> b -> c)
      uncurry :: (a -> b -> c) -> ((a, b) -> c)

</comment></comment><comment><USER33> I've always understood intuitively the existence of .map(), .reduce(), and .flat() in JavaScript, but .flatMap() felt like a weirdly arbitrary combination of two of them. Now it makes sense!

</comment><comment><USER34> Maths is what you get when you limit all your variable names to single letters.

<comment><USER35> And make symbols mean different things in different situations, and sometimes reuse symbols for the same thing, and sometimes make sin(x+3) mean the variables s * i * n * (x+3) and sometimes mean taking the sine of x+3.

Mathematical language is worse specified than markdown and has a huge amount of ambiguity and requirement that you understand the context that you're working in.

It works fairly well for mathematicians, in terms of being concise to express complex ideas on a blackboard, but overall it's a mess.

<comment><USER34> And the naming convention is absolutely horrid. It seems the main criteria is .. it should sound clever.

</comment></comment></comment><comment><USER36> Pretty weird that a comment linking a chapter from an oft referred to haskell text is a dead comment here. Surely if the alternate explantion in "Learn You a haskell for great good" is somehow sub-optimal it would be better to explain how rather than kill the comment inside 10 minutes?

You see this sort of thing from language warriors fighting silly wars but, yeah, what's wrong with Learn You a Haskell? Why must it be fought and suppressed immediately? Crazy...

<comment><USER37> It was probably automated. larusso has only made two comments ever, both containing links, so that probably triggered the spam detectors. You can manually resurrect for accidentally dead comments like this by clicking on the comment's time and then clicking "vouch".

<comment><USER21> I'm personally more the consumer type here at hacker news.</comment></comment></comment>


Ask HN: How is your developer box upgrade with OS X Yosemite going on? - <AUTHOR>

Please vote this up and feel free to share tips and links that point to issues and migration tips from Mavericks to Yosemite on your primary development machine. <comment><USER2> Upgraded to Yosemite a few hours ago on my Macbook Air 11" and have had no problems at all. Homebrew works fine. My primary languages (Erlang & Elixir) run fine. Edited files with vim. But I've only done a fraction of my work for now (today).

Expect some sort of "visual overload"[1] once you upgrade. Too much of color (It felt like the interface was done with crayons). After a few minutes of work it'll feel normal.

The phone-calls-on-mac and turn-on-iOS-personal-hotspot-on-mac features will only be available in iOS 8.1, which is slated for an Oct-20th release. I am looking forward to these two features.

[1] - My friend called it that :)

</comment><comment><USER3> If you use Asepsis then you'll get a message saying it's incompatible and won't be migrated, however if you reinstall it'll work just fine.</comment>


DIRT Protocol raises $3M to build a Wikipedia for structured data - <AUTHOR> https://medium.com/dirt-protocol/dirt-protocol-raises-3m-from-general-catalyst-greylock-lightspeed-and-pantera-to-build-a-a76c3295f227 <comment><USER2> It's unfortunate so many people come out of the woodwork to tell people their ideas are terrible or won't work.

I think it's far more interesting to ask how a thing might work, which uses cases might be dramatically underserved today and serve as a beachhead, or the tradeoffs being made rather than just say something is a "bad idea."

Dropbox launch: [https://news.ycombinator.com/item?id=8863](https://news.ycombinator.com/item?id=8863)

Coinbase launch: [https://news.ycombinator.com/item?id=4703443](https://news.ycombinator.com/item?id=4703443)

A 2012 thread discussing comment negativity where, coincidentally, the top comment is from @iamwil who posted this link and is on the DIRT team: [https://news.ycombinator.com/item?id=4363717](https://news.ycombinator.com/item?id=4363717)

A classic thread from 2012 where PG talks about negative comments: [https://news.ycombinator.com/item?id=4396747](https://news.ycombinator.com/item?id=4396747)

To me, the most interesting ideas in the world are the ones that at first blush look like they can't possibly work. But upon thinking through how they might, you learn something.

Props to everyone in the thread who is asking genuine questions and actually trying to understand what the team is building.

</comment><comment><USER3> This seems like a hilariously bad idea. You're basically building a system where whichever group has the most money to burn gets to decide the "truth". I would love you to change my mind though.

<comment><USER4> Climate change will quickly be proven as completely fake

…by big oil's dollars.

<comment><USER5> Climate change is an interesting example. An example of a DIRT registry, would not be the question of "is climate change real". It's unclear what defines "real". Rather a registry could be a list of the average air temperature in a city over time.

<comment><USER6> Average air temperature according to whom? How do you verify the values, recorded ostensibly from sensors, were ever measured? How do you verify historical data for everything pre-2018?

<comment><USER7> Ground truth can be constrained statistically.

Don't take me wrong. I don't really see the value in inventing a truth bureaucracy that rewards participants in fake money. This dirt system is just silicon valley, in it's typical naivety, trying to reinvent propaganda.

</comment></comment></comment></comment></comment><comment><USER8> Firstly, Congratulations for launching DIRT.

>If the data is incorrect, anyone can challenge the data and earn tokens for identifying these inaccurate facts.

How do you moderate censorship or conflicting information ? if someone uploads my personal info, without my consent. How do I get to purge it ? From the current model, it seems like I ll have to pay money to "request" purging my own data.

<comment><USER5> Thanks! DIRT is a fundamentally different approach because it removes the middleman and there is no central moderator. Our goal is to move the trust from a central party to a system of rules that anyone can participate in.

I think verified identity could be a registry on DIRT. Adding reputation on top of voting is something we're exploring.

<comment><USER9> I don't understand your answer. Can you explain more clearly what the process would be for removing personal info?

<comment><USER10> I can't see any obvious place to download this dirt protocol so I can check (the website seems to be 100% marketing, 0% documentation), but based on a combination of pattern recognition and the evasiveness of the above answer, I would wager the answer is "there is no process, we didn't think about data deletion".

<comment><USER11> You're being generous... this reeks more of scam than carelessness. Either way, it's going to never actually be delivered, not be GDPR complient, and based on the answers to questions raised here, full of obvious holes. If it isn't just a scam, it smells like someone went from "here's a neat idea I've spent a whole ten minutes on," to fundraising without a beat in between.

No resistance to censorship.

No resistance to conflicting information.

More money = more "truth" with no recourse, because removing info costs.

Incorrect info loses you money, but there is no functional systemic way to determine correct/incorrect.

Waaaaay too much marketing and nothing else extant.

<comment><USER12> For most of the planet GDPR is irrelevant. I personally will never give it any thought when building something.

<comment><USER11> Failing to give thought to something doesn't make it go away, but of course it's your right not to think. As long as you understand that ideology and opinion aside, it can greatly impact your ability to do business in Europe, then you go be you.

 _Most companies don 't do business in Europe._

As defined under GDPR? I'd love citations for that claim.

<comment><USER12> Most companies don't do business in Europe.

<comment><USER13> That's an interesting argument.

But unfortunately, it was beaten out by 2%.

[https://www.inc.com/anne-gherini/fifty-two-percent-of-us- bus...](https://www.inc.com/anne-gherini/fifty-two-percent-of-us-businesses- are-affected-by-this-new-regulation.html)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Can someone explain how exactly DIRT protocol will do moderation? From their site [1] it seems like they do some sort of moderating of crowd-sourced structured data. But this is where I am a bit confused: "DIRT maintains accuracy because every contributor needs to deposit tokens to write data. If the data is correct, it is freely shared. If the data is incorrect, anyone can challenge the data and earn tokens for identifying these inaccurate facts." How is the data flagged as incorrect? Who decides that the original data is wrong and the new data is correct?

Also, given that contributors have to put money up to add information, what incentive do they have to add information in the first place?

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

<comment><USER5> Hi! Thanks for the question. DIRT works well for objective information. In the cryptocurrency use case, this could be the ERC-20 smart contract address for a token or a list of investors for a project.

To flag information as incorrect, you need to take tokens and challenge the data. A challenge starts a vote and anyone in the DIRT network can vote with their tokens on what information is correct. The vote winner and majority voters earn tokens. The vote loser and minority voters are penalized.

We are planning to publish our protocol design in a few weeks with more details.

<comment> fake-name This doesn't answer the more important question. The issue isn't how do you handle "incorrect" information, it's how do you _REMOVE_ information.

Basically, when someone doxxes someone, and dumps the result onto your system, how to you remove it?

If you don't have a facility for rendering intentionally malicious information _impossible to access_ , your system is fundamentally broken.

<comment><USER5> I think the tough part is deciding who should be the arbiter or whether information is intentionally malicious. Censorship can be a real issue.

For the DIRT protocol, if want to remove information, you also need to deposit tokens and put forth evidence to convince voters in the network to side with you. If you lose the vote, then you would also lose tokens. We put forth an economic penalty for being inaccurate.

<comment><USER15> Firstly, congratulations on launching!

> For the DIRT protocol, if want to remove information, you also need to > deposit tokens and put forth evidence to convince voters in the network to > side with you. If you lose the vote, then you would also tokens. We put > forth an economic for being malicious.

Sorry if this is a stupid question but if I lose a vote, can I bring it up for a vote again? I think that should be ok, right? Even if I get some fact removed by some kind of trickery where I sneak in a vote it should be OK because if the fact belongs there, maybe someone else can add it again?

I think this works well for facts like Robert Kennedy as a matter of fact did NOT kill John F Kennedy. However, some things are not objectively clear. What happens when people keep adding "fake news" that is not obviously/patently false? Does someone need to pay to have it removed? How often do I do that? Every time someone adds it?

Now again the flip side is troublesome. We can't require identification for anyone to post facts, right? I mean I think that would be unthinkable, right? As such, how do we "rate limit" "fake news"?

Sorry if all of these have obvious answers. I just couldn't think of it...

<comment><USER5> Thanks! Great question.

1\. Repeat votes - If you lose the vote, you can vote again. DIRT works not only for correcting intentionally misleading data, but also for fixing out of data information. It's similar to a bug bounty for data.

2\. Cycle of challenges - Each time misinformation re-surfaces, you would have to challenge and vote down the data. However, every time you are successful in your challenge, you earn tokens for your efforts.

3\. Fake news - Subjective information can be harder to adjudicate with DIRT and that will not be our initial market. As an engineer, I would love to believe that the blockchain can solve fake news. However, a lot of research shows it is not the lack of data that the issue, but rather perspective. People believe what they want to believe.

</comment></comment></comment></comment></comment></comment><comment><USER16> "Wikipedia for structured data" seems like an odd tagline when Wikipedia already has a Wikipedia for structured data.

<comment><USER5> Thanks for the feedback! One of the differences between DIRT and Wikipedia is that we place a higher value on information accuracy. For example, in the cryptocurrency market project teams often list investors and advisors as affiliated with their project when they are not involved. A Wikipedia list of investors would not be sufficient. You want these project teams to have skin in the game and something to lose if they are spreading false information.

That said - the explanation didn't fit as well into a one liner :)

<comment><USER17> So wikidata but for crypto? That's pretty thin. Why didn't you try to 'update' wikidata?

<comment><USER5> With wikipedia or projects like Open Street Maps, vandalism, spam, and poor data quality are problems at scale. In particular, crowdsourcing does not work for curating commercial data or information where you can profit by spreading misinformation.

For example, in the cryptocurrency space. Projects raise funding through initial coin offers (ICOs). In an ICO, you can contribute ETH to a smart contract for the promise of tokens in the future. Having an openly editable list of ICOs and their contribution address would not work. The list would be quickly spammed because malicious actors have a really high incentive to put their personal wallet address as the contribution address.

</comment></comment></comment></comment><comment><USER18> Seems like a pretty great way to remove the middleman from populist infotainment consumption. Can't be worse than what we already have and by making it explicitly richest party wins it makes the process more transparent. It might not be the Truth but at least it is Honest.

<comment><USER5> Thanks for the comment!

Transparency would be the third benefit. With the blockchain, you can see the entire history of votes. Every transaction is recorded. Today, if a website accepts bribes for reviews, visitors to the site do not know that this happened. With DIRT, if a wealthy token holder had a lot of tokens and tries to throw a vote, you can see the attack happening.

<comment><USER19> How do you associate a token holder with an actual person or organization?

Is there a method for doing this built into the protocol, or would that be a responsibility for the implementer?

I agree that transparency could be a great benefit of this technology, but if a "wealthy token holder" can create several puppet accounts with their own tokens, throwing a vote can be made to look "organic". Does DIRT do anything to prevent this?

(Thanks btw, it's great to see you active in the comments.)

</comment></comment></comment><comment><USER20> My feeling is that this is either an illusion ("it will work out somehow") or a sham ("let's milk the crypto craze").

No answer to the question why selling votes should result in more accuracy. Buzzword Bingo. An overly broad approach. Lot's of social proof but thin on content. This reminds me of all those ICOs we see these days.

Looking forward to read the whitepaper. But somehow I have the feeling it will either never come or it will be just another marketing brochure without technical details.

<comment><USER5> Before Wikipedia, the idea that an openly edited online journal would be better and more accurate alternative to Encyclopedia Brittanica would be surprising to most people.

There's two parts of the design that leads to more accuracy for DIRT:

1\. Skin in the game - a token deposit to write encourages accuracy because you can lose the deposit if you are incorrect.

2\. Encouraging moderation - moderators can earn tokens. If you vote and challenge correctly, you can earn tokens. This creates an economic reward for moderators that can protects the data accuracy in the long term.

We're posting the whitepaper and more importantly, launching the protocol with a first application in the coming months. Stay tuned!

<comment><USER20>
        you can lose the deposit if you are incorrect

How would the system know which side is correct and which side is incorrect? From what you wrote so far, it just counts which side put in more money.

<comment><USER21> Either thats the secret sauce that got them $3m with zero openly published work, or the "who is right" is completely hand-waved over or relies on some oracle.

</comment></comment></comment></comment><comment><USER22> Kinda like WikiData? [0]

[0]: [https://www.wikidata.org/wiki/Wikidata:Main_Page](https://www.wikidata.org/wiki/Wikidata:Main_Page)

<comment><USER23> I recently began using WikiData for a large project and have to say that it's surprisingly great.

<comment><USER24> Can you say more about your project? I was thinking of using it for a project where I'd have to categorize a lot of data and I found the ontologies/modelling and program setup a bit daunting so shelved it for now. Would be curious what others are doing with it.

</comment></comment></comment><comment><USER25> I don't see how the business model causes data to trend towards truth. I can see how it would trend towards whatever the people with financial incentive to change it want it to say. While DIRT pockets a tax on the edit war, ofc.

</comment><comment><USER26> Interesting idea. How will this handle legal take-down requests ? Backed by DMCA, GDPR, and so on.

<comment><USER27> Take down requests indeed. Especially for individuals, and especially with GDPR(right to be forgotten), CA privacy law(dont sell my data), etc. If someone else writes on DIRT that I'm an alien from an alien planet bringing a virus to earth (when in fact I'm a human from SF with no viruses), do I need to 1) PAY to get a token to challenge this and also 2) correct inaccurate information with correct information with no option to totally remove the entry (however "ridiculous" the entry)?

Applied to the case of getting accurate VC listings, DIRT has a ploy to get VCs to PAY to get tokens to challenge incorrect entries. Consumers also have an interest in the quality of information, but a primary concern lies with the subject of an entry.

DIRT -If I may, my request to you is to document the heck out of your policies and expected behaviors. The grey line of "ridiculous" that I point out is something that you've mentioned in another response, that you're not in the business of fake news. At some point, you'll need to be making decisions and providing ethical guidelines.

</comment></comment><comment><USER28> This sounds like GraphPath/GraphOS initiative:[https://www.graphpath.ai](https://www.graphpath.ai)

</comment><comment><USER29> If it costs tokens to submit information, what incentive is there to submit information?

<comment><AUTHOR> It can depend on the contents of the registry and who depends on that information. For example, with a list of top 100 colleges, readers might use it to decide which colleges to go to. And hence, writers would be incentivized to submit their own college to the list.

A better, but less mainstream-relatable example is a list of ERC-20 smart contract addresses.

</comment></comment><comment><USER30> very cool! anyone have a list of useful TCRs? i haven't found one yet, but love the idea.

</comment><comment><USER31> Inspired by [https://news.ycombinator.com/item?id=17512045](https://news.ycombinator.com/item?id=17512045), I'm trying to figure out what gets me most excited about what DIRT and TCRs could enable.

For me, it's actually not data easily verifiable as true or false, but more for "wisdom of the crowds" type of knowledge—things that you couldn't put up on a source like Wikipedia. These tend to be lists or recommendations that contain some subjectivity, but also tend to coalesce around a mostly-agreed upon set of answers from a trusted set of sources.

In the centralized world, we usually rely upon institutions like the Michelin Guide to develop a fair set of criteria, but we ultimately as end users trust that institution's "objectivity" and judge whether we think that list is valuable. Sometimes when I research, I informally end up creating lists of lists and combining them ad-hoc if I can't tell which of them is more trusted. These lists also tend to end up being static or only updated once or twice a year and can fall horribly out of date.

I think TCR incentives could potentially be really interesting as an alternative to these lists which rely on the institution's brand. For example, I think Quora Answer Wikis (like this one: [https://www.quora.com/What-are- the-best-independent-coffee-s...](https://www.quora.com/What-are-the-best- independent-coffee-shops-in-San-Francisco)) and general consensus for recommendations in forums for questions like "Which cities should I visit in Thailand if I'm looking for nightlife and places to hike?" or "Which REST framework library should I use for a Django project?" It'd be amazing if DIRT could balance the incentives for community members to contribute to this type of data and keep them as living lists, with all changes and updates maintained through a community with the right checks and balances and incentives.

From the Medium post: >If the data is correct, it is freely shared. If the data is incorrect, anyone can challenge the data and earn tokens for identifying these inaccurate facts. Our protocol and platform makes it economically irrational for misinformation to persist in a data set.

I think the more interesting data would be data that's on a gray scale, e.g. using the above coffee shop in San Francisco example, obviously if John Doe tries to get his burger joint on the list as a growth hack even though they don't serve coffee, that should easily be verified as misinformation. But what if a coffee shop just closed for business, or moved to Mill Valley but thinks they should still be on the list, or just switched beans and raised the prices so that everyone agrees that it no longer deserves to be on the list?

Disclaimer: I know most of the team working on DIRT, and I don't know very much about TCRs.

<comment><AUTHOR> You're right that there's often lists that people make, but usually ends up outdated. Often in these cases, the incentives for reading the list are usually more than those maintaining the list.

People in the earlier days of the internet imagined a better world brought about by immediate and unfettered access to information. Many have tried to make freely available information on the internet. Wikipedia, IMDB, and Freebase are direct products of this school of thought. However, we can only count these on one hand. In fact, most free data projects languish and have a hard time getting off the ground.

What we all discovered as we built out the web is that only some kinds of data can be maintained for free sustainably. Sure, if it's something that engages fandom, like all the different types of starships in star trek, people are intrinsically motivated to update that list. But if it's something that's considered dry but useful, like the tax rates in every county in the US, or points of interest on a map, there won't be enough people with intrinsic motivation to keep that updated.

As builders and users of the web, we've compensated by subsidizing that dry/useful data, typically with a company selling advertising or subscriptions in adjacent services. The implicit deal we make as users is if the company provides the data for free, we're ok with the company accrue profits off the data we help curate. Recently, the sentiment has been growing that this may have been a raw deal for users of the web as a company's profits accrue to the point of immense power over our lives.

What I think the builders of the early web got wrong, was that certain types are data needed to involve other incentives besides intrinsic. While we've found other ways to incentivize users in the 2.5 decades of the internet, cryptocurrencies now give us one more tool in our toolbox to use economic incentives to design systems that converge on the curated lists that are regularly updated.

With this new toolkit, we may be able find another way to provide freely curated data without using subsidization. Instead of the value capture accruing in a single company, we may find a way to sustainably distribute it amongst the curators.

We're not as sure subjective data is a good first fit for TCRs. With any startup, it's better to find a niche application that's a great fit, and we think we've found one in objective data for the crypto space.

I think another aspect that might be exciting for you to think about is if you're able to link the data between registries. It's a non-obvious aspect that almost no one asks about.

</comment></comment><comment><USER32> So it's Wikidata but with "blockchain" stamped on it to raise more money?

<comment><USER33> The Truth is determined by the rich! Majority voting by token owners determines the facts. You just can't make up stuff like this.

Curious how this will play out. Threshold for contributing is non-trivial, so the wasteland scenario is my academic guess. The contribution scoring and ranking will help, but can you be anonymous?

<comment><USER5> In many ways, a system where the wealthy control information is what we have today. You can influence elections with donations.

Today, if a publication or data source posts information about you or your business, there is no means to correct this data. You can post about it on Twitter or email the service, and wait for a response. You can't just fix this information. With DIRT, we create a way for people to at least be part of the curation process.

Different types of data require different governance models. Some datasets are not as critical to protect and could have a low token stake. For other pieces of information, you want every writer to have more skin in the game and thus have a high stake for writing. Our bet with building a protocol is to test what incentives will curate the best data.

</comment></comment></comment><comment><USER34> Wikidata + cryptoscams? Yikes.</comment>


Ask HN: Please review my latest project (memodrops.com) - <AUTHOR> http://memodrops.com <comment><USER2> I like the concept, but think it would be better and make more as an ad- supported webapp. It looks too simple to be worth the time to download, scan for viruses, install and run on my already-cluttered desktop.

By the way, while I like the Einstein branding, be aware that his 'personality rights' (to use his name and/or likeness commercially) were bequeathed to an Israeli university and the licensing is administered by Corbis: <http://einstein.biz/> You may want to consider a more generic or abstract image, rather than get hit with a substantial bill later if your product takes off.

<comment><AUTHOR> The reason that it is a desktop application is that it is able to run in the background, and pop-up a question dialog periodically. On the internet lots of things (for example advertisements) are competing for the the attention of the user. (Sometimes in distracting ways.) This program is also competing for the attention of the user, but it is very useful for her.

Thanks for the warning about the Einstein branding. While I like the Einstein branding very much, it seems that I will have to get rid of it as soon as I get any serious traction.

<comment><USER3> "While I like the Einstein branding very much, it seems that I will have to get rid of it as soon as I get any serious traction."

It'd be better to get rid of it now, or be prepared to receive a letter demanding a payment of some X dollars. Corbis does not mess around.

</comment></comment></comment><comment><USER4> I'd be careful about using that banner image

[http://discovermagazine.com/2008/mar/05-einstein- inc/article...](http://discovermagazine.com/2008/mar/05-einstein- inc/article_view?b_start:int=1&-C=)

<comment><AUTHOR> Thanks for the warning. Now I've changed Einstein to Plato.:)

</comment></comment><comment><USER5> The home page made it very difficult to take seriously. A good spell-checker would be in order.

"From then on memodrops takes care about the word and you can be almost sure that you will learn the new word permanently without being a memory champion."

Try this:

"From there, Memodrops will take over and make sure you learn the word permanently like a memory champion."

Could probably do even better with a little more time and thought. Also, "With memodrops memorization is..." is a bit cludgy if you don't read it right the first time. I read it as "With memodrops memorization, is" instead of "With memodrops, memorization is" which obviously doesn't make any sense. So, how about "Memorization with memodrops is:"

<comment><AUTHOR> Thanks for your help, I appreciate it. Unfortunatelly English is not my mother tongue. I've applied your suggestions to the site.

</comment></comment><comment><USER6> Idea: Make this a WepApp with a small application only for the popups. So, it could be used on phones and other systems. + The question would be saved in a secure place and I could add and access them from anywhere. Also, I find the main dialog page a bit clumpsy.. too much differents concepts.. a simple application in the status bar would do the job.

Finally, by using a small application like this, it'd make it easier to add new features and create new type of application that would use the already- existing questions. For instance, an application could ask questions from time to time while another would enable me to play a game with the questions, etc. However, everyone would be free to only use the app they want.

On a side-note, to have the background service running effect, plug-in in firefox or chrome could also be a good idea - or as a home page.

<comment><AUTHOR> Thanks, these are good ideas. I have also thought about making it 'internet- based' in the future, so that using some kind of synchronization the user could use the same data on her desktop machine and on her phone.

</comment></comment><comment><USER7> Mnemosyne/Supermemo do not support crossword puzzles. Spicy Elephant is an online flashcard service.

Mnemosyne in particular is geared towards learning vocabulary, and includes 'three sided' flashcards for learning the meaning, non-roman characters and pronounciation of a word.

Something you should address in explaining your service is data export. If I am going to load a ton of words into memodrops, how can I get them out if I need to in a format usable in other programs?

</comment><comment><USER8> Agree with the others who say make it a web app.

What is the business model? Ad supported? It's definitely a good effort. Thanks for sharing it!

</comment><comment><USER9> I think having the user type answers is a huge problem. An SRS where you grade yourself (Mnemosyne, for example) allows for fuzzy answers and typos. Your system apparently does not. There are also SRSes which allow for audio and video in questions and answers. Clearly that is impossible to automatically check.

</comment><comment><USER10> What differentiates this from a product like SuperMemo? I see your licensing cost is less ($9.99 vs $50), but I also know much more about what SuperMemo is and the quality of its results.

<comment><AUTHOR> Thanks for mentioning SuperMemo, I've known about some competitors but not this one. Currently I cannot answer you, I've have to look SuperMemo in more detail. Does it support cross-word puzzles? That's something what I did not find in (other) competitor products.

<comment><USER11> SuperMemo looks dated (both the app and the web site) but it is very strong in the fundamental algorithms for learning and retention. The guy has been doing this for over 25 years! You'd do well to partner with him to produce a more modern offering based on his research than going alone. If I was serious about learning something I would live with his old school software because I'm really buying into the significant experience he has in the domain in question...

</comment></comment></comment><comment><USER12> Site does not display right on android browser using tmobile mytouch. Text is weirdly cut off on right with no way to get to it.

</comment><comment><USER13> Windows only. Looks useful, wish I could try it.

<comment><AUTHOR> Other platforms will be supported soon, I've implemented this in QT. I just wanted to release as early as possible.

</comment></comment><comment><USER14> Add an 'I know it, next!' button

<comment><AUTHOR> Hmmm, a valid point. So by trusting the user's own judgement, I could make the user experience simpler and faster. On the other hand it is a temptation to cheat, which might be a problem for some users... Maybe there should be an option in the Options dialog to turn this feature on, so that the temptation to cheat is there only if the user explicitly turned it on...</comment></comment>


How Much Time Does Rendering a Partial in Rails Really Take? - <AUTHOR> http://www.justinweiss.com/blog/2014/02/13/how-much-time-does-rendering-a-partial-really-take/

<comment><USER2> Interesting bench. Could be a bit more in depth though.

It would have been interesting to see how passing a hash with locals to it. It would have been interesting to see both the naive case when the user recreate the hash for each iteration, and the one with the hash being reused (and presumably updated in place)</comment>


Ask HN: Is Let's Encrypt the new swiss crypto ag? - <AUTHOR> Just wondering ... it does seem less far-fetched in the light of the swiss crypto ag revelations. <comment><USER2> Are you familiar with how certificates and CAs work in general? You don't _receive_ a certificate from the CA, they just sign and _attest_ that the one you made is owned by you. The ways CAs go bad is not breaking any crypto but by signing a certificate that you don't own. This vulnerability is well known and LE takes industry-leading steps to mitigate it via the certificate transparency program which is a permanent auditable log of all certificates they sign.

<comment><AUTHOR> From my understanding of the certificate transparency program does not mitigate the threat of them simply not disclosing a certificate they signed. Ultimately this still gives them MitM capabilities as long as they control the traffic or am I mistaken?

<comment><USER3> When certificates are submitted to CT logs, they are given Signed Certificate Timestamp by the log, which can be attached to the certificate. Chrome and other major browsers require that every certificate has them attached and signed by a trusted log operator, guaranteeing that each certificate is submitted to a CT log.

[https://github.com/chromium/ct- policy/blob/master/ct_policy....](https://github.com/chromium/ct- policy/blob/master/ct_policy.md#qualifying-certificate)

<comment><AUTHOR> Seems like this is currently disabled in Firefox [1]. Do you have any sources for Safari or MS Edge?

[1] [https://wiki.mozilla.org/PKI:CT](https://wiki.mozilla.org/PKI:CT)

</comment></comment></comment></comment><comment><USER4> Why are you specifically targeting LE with this post? Why not other CAs?

<comment><AUTHOR> Because I want to use LE and not other CAs.

<comment><USER5> That's misguided (I'm assuming you're the server admin).

Whether you use any specific CA, like LE, or not, has no security impact.

It's about what your _users_ trust and you don't control that.

<comment><AUTHOR> In an ideal world I would say you're right. In practice they don't even know who they trust.

</comment></comment></comment></comment><comment><USER6> As a centralized piece of software that has made itself responsible for safely massaging millions of private keys, certbot would certainly be a juicy target for NSA to compromise.

</comment><comment><USER7> Betteridge's Law says "No" ... and given certificates are generated locally, I don't see how the certificates themselves could be compromised. The trust in a certificate (or trust in a false certificate) could potentially be manipulated in by and upstream party.

<comment><USER8> The 'law' is more of an observation and generally applies to headlines. I feel you are being overly dismissive, as a question is being asked is in a dedicated section. There have been instances of CA's, most notably Symantec, which have turned out to be bad apples. There is a constant stream of news dispelling myths surrounding seemingly reputable firms regarding encryption/privacy. Whether these incidences are related or not, discussions like these need to be afforded a lot more leeway than most, and fleshed out, rather than being stifled.

<comment><USER7> I'm not arguing against having the discussion ... my point is that trust in any certificate is reliant on its chain-of-trust and so if Let's Encrypt has this problem, you can't trust other certificates either. But the implication in the head-line is that the NSA/CIA are controlling Let's Encrypt. If that's true, then we've got a real problem ... on the other hand, I think other CAs have shown that, through incompetence or malice, they can't always be trusted either.

<comment><USER9> HTTPS certs provide extraordinary limited security in any case, there is no need to single out lets encrypt.

If you can receive a http request destined to the target domain (e.g. via MITM near the real target, DNS hijacking, or route hijacking, or MITM near a CA) then you can get a cert issued for that domain by pretty much any popular CA.

With security so limited what would be the purpose of compromising lets encrypt?

<comment><USER9> Massive downvotes but no responses.

Is it because you accept that the security provided by HTTPS is limited but don't like people calling that out?

It's better than nothing. But it is my perspective that as technical experts any time we are not absolutely frank about the limitations of the current model against powerful MITM attackers we are behaving unethically.

There is absolutely no reason for any major state attacker to compromise letsencrypt. Beyond the weaknesses I enumerated above state actors have their own CAs which are accepted by browsers and pinning is effectively dead ( [https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browse...](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browser_support_and_deprecation) ).

What exactly could a state actor hope to accomplish by compromising letsencrypt that they couldn't already do more easily and stealthily?

</comment></comment></comment></comment></comment><comment><USER10> I suppose it would be trivial for them to issue compromised certificates or record the private key in a targetted attack for a specific domain without anyone noticing.

<comment><USER11> During normal certificate issuance, they do not generate or see the private key, so they can't compromise the certs they sign for you.

Like any other CA, they do have the technical ability to sign arbitrary other certs, so could issue a cert for MITM. As some other comments show, certificate transparency is starting to reduce this risk.

<comment><USER6> LE does not see the private key but certbot does. Who audits certbot?

<comment><USER12> Anyone. It's open source. You can if you'd like.

[https://github.com/certbot/certbot](https://github.com/certbot/certbot)</comment></comment></comment></comment>


Phuby 1.0.0 Released - <AUTHOR> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/360172

<comment><USER2> I can think of all sorts of things to describe this that I don't want anyone to google tomorrow, next week, 2 months from now or three years down the road. Read into it from there.</comment>


Why it Failed: Part 2 - <AUTHOR> http://wwworks.co/articles/6

<comment><USER2> I don't think the name has too much to do with it. Yes, it plays a role, it shouldn't be too long and should be memorable, but there are many successful sites that have truly sad names. Just a thought

<comment><AUTHOR> Thanks for your thought and true, the name isn't everything. But I think that a good name sure helps, especially when it comes to marketing. Color probably get a lot of traffic from being nr #1 on Google search for "color", but if you don't want to spend huge amount of money, colorapp.co or colorapp.com would probably work great as well. My point is, the name matters and adding two or three letters to a good name is better than having a short and snitzy but hard to spell name.</comment></comment>


Lean Startup Hack: Finding Early Evangelists - <AUTHOR> http://blendah.com/post/37331434653/lean-startup-hack

<comment><USER2> This is clever Tom.

Those videos by Noah are awesome - not sure how I missed those before.

<comment><AUTHOR> Marc.. Noah is a so effective in distilling actionable items for customer development and growing customers.</comment></comment>


Why Every Child in America Needs an iPad - <AUTHOR> http://www.cultofmac.com/why-every-child-in-america-needs-an-ipad/93887 <comment><USER2> I think that the main argument of this post is ridiculous.

"You should use an iPad to tranquilize your kids instead of a TV"

If you click through to the blog that he created while in the restaurant, you'll notice that the kids weren't learning or drawing or playing games, they were actually just WATCHING MOVIES.

A more detailed (if quick) response here: [http://isaacelias.posterous.com/every-child-in-america- needs...](http://isaacelias.posterous.com/every-child-in-america-needs- parents-who-are)

</comment><comment><AUTHOR> I've actually been seeing little kids with iPads more and more. Specifically, I saw a child in a baby chair deftly playing an educational game on the iPad. It struck me how different this generation will be, growing up with touch devices that are always connected to the internet.

(I also thought about how awesomely huge an iPad must be to a small child. I estimate the relative size would be holding an iPad that's a few feet wide)

<comment><USER3> Yeah, I know a 7 year old who laughed at me when I told him about 8-bit Nintendo.

I also know a 3 year old that finally sat still when given an iPad to finger paint on.

Not sure about the article. But I don't have kids. Maybe in a society where TV is so pervasive, replacing the TV is a good option.</comment></comment>


Sysadmin Posters from the 1980s - <AUTHOR> http://prostheticknowledge.tumblr.com/post/95629146221/sysadmin-posters-from-the-1980s-redditor-evandena

<comment><USER2> Or just link to the full album: [http://imgur.com/a/y6udh#0](http://imgur.com/a/y6udh#0)</comment>


Ask HN: When doing everything yourself, design or code first? Together? - <AUTHOR>

I'm working on a side product in my free time while I still work full-time. I am the only team member, and I will be building the initial prototype and MVP alone. I am neither an expert developer nor designer, but can handle both well enough to get something built.
Should I build a functional "ugly" prototype and then go back and redesign everything, or start with a shiny "we're not ready yet but give us your email" page like a LaunchRock or something, and get my logo and jazz together so I have eager users once the product is ready to launch?
I'm tempted to just do both at the same time and progress each day as I choose, but I wondered if any other solo founders had found success starting with one hand stronger than the other.
Thanks. <comment><USER2> balance this:

"If you are not embarrassed by the first version of your product, you've launched too late." \- Reid Hoffman

with this:

"Make something customers actually want." \- pg

i once designed 20 screenshots of an iOS app before spending serious time with potential users. don't do that.

after that mistake, i'm currently demoing the world's ugliest MVP to potential customers. my MVP = a google form and a graph based on the data. i got my first verbal commitment from a customer after demoing this and mocking up the final product on a sheet of paper. (we agreed on price and initial functionality, despite the fact that 0 lines of code had been written.)

simply put: i'm building something his team can use. he gave me valuable feedback, threw in a few future feature requests and gave me a short list of other CEOs he wanted to refer me to. i also asked him to tweet about using my product. he agreed (and did).

just build something that does one thing very well, and get that in front of people. they'll tell you everything you need to know from that point on.

<comment><AUTHOR> Oh I know my MVP is going to be hideous, and I'll probably have to throw it away quickly. I guess I was curious about whether or not marketing spice mattered on the front end of the product lifecycle as well... I feel like it's a balance, but given my target audience, it may be more important in this case than in most.

<comment><USER2> it's a good question to ponder but the 10 mins you spend pondering it are 10 mins you could be demoing and getting feedback.

i'm serious. wow them with ugly. (tm)

</comment></comment></comment><comment><USER3> I just started to promote my side project[0] and I guess I am in a more or less comparable situation. I work alone and my time for this is limited.

First I focused on getting the product usable and that the documentation is somehow understandable with some code examples. My design skills are very limited, and since I build something for a technical audience, I though that the look of my website would not matter that much.

That was until Zach from headlinr[1] made me change the layout. Since I have a more or less decent looking website I get significantly more sign-ups and the logs show that visitors take more time to explore the content.

So with this new knowledge, I would vote for nice and shiny with minimal functionality first. Get something online as soon as possible. Just to get indexed etc. but do not underestimate the rejection caused by bad design.

[0] [http://template2pdf.com/](http://template2pdf.com/)

[1] [http://headlinr.com/](http://headlinr.com/)

</comment><comment><USER4> The prevailing wisdom [1][2] is to sell/market the product first, so that you avoid wasting time building/designing a product that nobody wants.

[1] "Yes, but who said they'd actually buy the thing?" [http://blog.asmartbear.com/customer- validation.html](http://blog.asmartbear.com/customer-validation.html)

[2] "Validating product ideas before building them" [https://training.kalzumeus.com/newsletters/archive/validatin...](https://training.kalzumeus.com/newsletters/archive/validating_product_ideas)

[3] "Do things that don't scale" [http://paulgraham.com/ds.html](http://paulgraham.com/ds.html)

<comment><AUTHOR> I know my idea solves a real problem, and it's one that I've witnessed myself over and over. Whether or not people would actually use my product I think depends on which avenue I take it down, and that will be an experiment over time, to see which precise solution is the one.

Over time, I will develop two sets of customers hopefully, but the initial set is anyone who cooks at home and is frustrated by sharing and viewing recipes split across Pinterest / cookbooks / work docs / sticky notes / etc.

<comment><USER5> you're targeting ppl who view recipes online? Most advice about customer validation won't apply to you then. Your best bet is to cross your fingers and pray you're the next Pinterest. Because even if ppl say they think it's a great idea, most won't have the cash to pay for it.

</comment></comment></comment><comment><USER6> It is about striking a balance. You don't want to spend too long on something but at the same time, you don't want an ugly MVP that will turn off potential users.

I spent a few hours doing a decent website front with the essential details, with a working newsletter form, so that I can have that front up and running while working on an MVP. I wouldn't spend a few days or weeks on it. Same with the product - maybe allocate a certain amount of time where you would work on the design and then focus on the actual product itself.

I also agree in getting customer validation before spending too long (ie more than a year) on a certain product iteration

</comment><comment><USER7> I think it somewhat depends on the market you're going after.

If you're doing b2b with a product that is clearly a differentiator, you can probably build an mvp and talk directly to customers and get them to try it out and get feedback. For this you may be able to get by with 'good enough' design.

If you're doing a consumer product, where you won't get to speak to most of the customers until after you get them interested or even using the product, then you may need to focus more on design.

Keep in mind, the less features you have, in theory the less design you need, so keeping it bare-bones at first is always a good start.

<comment><AUTHOR> The product is B2C, and focused on women (mostly). It's in the home cooking space, so they will probably be the early adopters.

<comment><USER8> Methinks you are building a recipe-sharing website.

I thought Pinterest had that niche on lockdown.

Goodluck!

</comment></comment></comment><comment><USER9> In my opinion, the early adopters are going to give it a shot anyways whether it has a good user interface or not, so you should just let it be a ugly prototype and focus on the functionality in the initial stages. Try and keep a simple interface, but don't try and make it attractive, just build in the minimalistic of it. Go put it out and take feedback and if the response on functionality is good, re iterate and make the interface better.

</comment><comment><USER10> People (in my experience, anyways) would prefer a product that is fast and gets the job done without fault or error over a product that looks really awesome but performs poorly and is buggy.

In other words you can put as much makeup on the pig as you like, but in the end it's still a pig.

Try telling that to one of my former bosses though ;)

<comment><AUTHOR> Thanks. That's my thought as well, and my priority right now is to get a working proof-of-concept and see if anyone actually uses it.</comment></comment>


25,000-Year-Old Structure Built of the Bones of 60 Mammoths - <AUTHOR> https://www.smithsonianmag.com/science-nature/60-mammoths-house-russia-180974426/ <comment><USER2> Göbekli Tepe traditions built on a long line of building experiments. There are also earlier stone structures and undoubtably myriads of rotten and lost wooden temples.

<comment><USER3> I think "line of experiments" lends too much forethought and connectedness to these things. It certainly exists within a context of increasing sophistication in human architecture, but it was built more than ten thousand years after the site in the article. Assuming the builders are related at all, there wouldn't even be vague cultural memory extending back that far.

<comment><USER2> These are certainly different branches on the human development tree, So I agree that there wouldn't be any vague memory of the specific site. If there was any memory it was in the form of habits just like stone making techniques persisted for tens of thousands of years

</comment></comment></comment><comment><USER4> Even the name of the place sounds like it is a derivation from кости: "bones".

<comment><USER5> Yes, it's literally "bones" from Russian.

The area has been known for it

<comment><USER5> Some more background: Russian folklore attributes the name to the event when god Indra (Inder, Hindra in other spellings) was about to cross the Don river.

Indra tried to drink all of Don's water, and exploded.

The locality was then named for his scattered bones.

</comment></comment></comment><comment><USER6> > Lioudmila Lakovleva

Iakovleva (Yakovleva), for God's sake...

</comment><comment><USER7> This reminds me of a pretty niche article I found a couple months ago. It was about the bones of a bunch of cave bears that a father and his young son found in Drachenloch Cave in Switzerland in the early 1900s. They called in naturalist Emil Bachler and he got to work finding more bones in the cave, organized in tantalizingly structured ways.

> In Drachenloch, however, not only were there [crude stone] walls, but behind > these walls were found accumulations of bear bones — the long bones of the > legs and more or less complete skulls. The pattern was very consistent. > Where such walls were present, bones were present. Where they were absent, > bones were rare along the cave walls.

These and other deliberate-looking accumulations of bones (including apparent crude "chests" of limestone slabs enclosing more bones) led Bachler to suggest the idea of a prehistoric cave bear worshipping cult. But a counterargument suggests this explanation is unnecessary. It might just be bears being bears, no cult required.

> When cave bears entered a cave to hibernate, they began by scratching nests > into the cave fill. In the process, bones and small rocks were pushed aside, > often falling into crevices among the fallen blocks. This had two effects. > First, it helped to build up accumulations of bones in natural cavities > among rocks or among piles of rocks. Second, it protected the bones that did > enter such interstices from further trampling and, if they were buried > there, from weathering and decay. It is perfectly natural, therefore, that > modern excavators should find concentrations of bones in cavities surrounded > by rock. Moreover, because further weathering of the cave roof naturally > produced subsequent roof fall, it is perfectly normal that such cavities > would be covered by slabs of greater or lesser size.

I wonder if something similar happened here. Obviously, the lack of a cave is an issue. But it's a funny connection to something I read randomly a few months ago.

Cave bear stuff from [https://www.penn.museum/sites/expedition/the-cult-of- the-cav...](https://www.penn.museum/sites/expedition/the-cult-of-the-cave- bear/) which is also a fun read if you like archaeologists sniping at each other.

</comment><comment><USER8> When building houses you build with what you can find. If you buy an old house in an area without much trees, like an island, expect it to be built with a little bit of everything.

<comment> munk-a That was one specific interesting point in the article though - the other structures were built out of everything, bones from mammoths, foxes and other small game. This particular structure was entirely built out of mammoth bone and is insanely large.

<comment><USER9> Given the fact that a single mammoth could feed many for a long time, I would suspect that a building made from 60 mammoths was either a mass death, or a mass ritual killing - it certainly wasnt subsistence killing of the mammoths for food from which the bones would come from...

<comment><USER10> Couldn't it have been built out of bones from a long period of subsistence hunting and killing?

<comment><USER11> Indeed, some things had been built over thousands of years. [https://en.wikipedia.org/wiki/Rock_Eagle](https://en.wikipedia.org/wiki/Rock_Eagle)

</comment></comment></comment></comment></comment><comment><USER12> How is it identified that food scraps "remain" at the site?

<comment><USER13> I'm guessing it's tool marks on bones. Maybe they can tell if somebody was chewing on a mammoth rib or something.

</comment></comment><comment><USER14> While it did have unique qualities which could indicate ritualistic or cultural significance, I can still see one possibility could be it coming from exactly what I imagine one of my friends doing.

I could imagine their linguist equivalent of "Bro, I'm going to build this one just from Mammoth bones, it'll be freakin' huge. C'mon, it'll be awesome!"

</comment><comment><USER15> There is discussion in this article about why people would have moved these animals over vast distances. But as the Mammoth is in the same family as elephants and I remember elephants choose to die at a location that is revised by their family over time.

Couldn't it be this has been a similar behavior, people coming to a this site and just found 60 remains and build something with it?

<comment><USER16> Elephants don't do this...it is a myth.

[https://en.wikipedia.org/wiki/Elephants%27_graveyard](https://en.wikipedia.org/wiki/Elephants%27_graveyard)

[https://animals.howstuffworks.com/animal-facts/are-there- rea...](https://animals.howstuffworks.com/animal-facts/are-there-really- elephant-graveyards.htm)

<comment><USER2> Maybe the myth comes from sites like these.

And maybe sites like these were used to run down mammoth herds down a cliff:

[https://upload.wikimedia.org/wikipedia/commons/thumb/2/2d/Ko...](https://upload.wikimedia.org/wikipedia/commons/thumb/2/2d/Kostenky_model.jpg/440px- Kostenky_model.jpg)

<comment><USER16> Perhaps. I grew up in Montana where they have cliffs like those that the Indians drove bison off of. 10's of thousands at a time...

<comment><USER17> I wonder if it's true that the herds of Bison were a result of a an ecosystem in rapid change - supposedly when the natives in North America died and cities and farms went to waste because of disease from the South, introduced by the Europeans.

That would have allowed the Bison population to explode.

<comment><USER18> That doesn't jive with my understanding. The US government went about systematic elimination of indigenous people. Part of that was the elimination of bison as a food source. The population of bison declined from the millions to around a thousand in under a decade arout the 1860s.

<comment><USER19> European states in America went about systematic elimination of the _survivors_ , the pre contact population absolutely dwarfed these remnants and in their time, kept flora and fauna in check across the continent.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> This reminds me of an old PS1 game I have serious nostalgia for: [https://en.wikipedia.org/wiki/Tail_of_the_Sun](https://en.wikipedia.org/wiki/Tail_of_the_Sun)

</comment><comment><USER21> "A jaw-dropping example .."

I'm glad people at the Smithsonian get to have fun writing intro sentences like that.

<comment><USER22> On the contrary, I find these predictable puns in journalism to be lazy and annoying. If I have to read about another oil tanker spill that's "fueling" speculation...

<comment><USER23> If that bothers you, you will _love_ this whale of a tale about Oregon's 1970 exploding whale:

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

"The sand dunes there were covered with spectators and landlubber newsmen, shortly to become land- _blubber_ newsmen. For the blast blasted blubber beyond all believable bounds."</comment></comment></comment>