Hacker News Reader

pseudonom-on The Case for Writing Papers in Economics Using FaKe LaTeX [pdf]

I think that paper came up on HN before and IIRC the tasks they were measuring were things like manually positioning some figure in an arbitrary position. This is not a use case LaTeX optimizes for or one that comes up often in my experience.

Edit: See https://news.ycombinator.com/item?id=8797002 for an earlier discussion of the referenced paper.

pseudonom-on A non-profit that figured out how to massively cut suicide rates in Sri Lanka

Whoa, that seems like a very strong claim claim and is contrary to my understanding. I know that instrumental variables can be a powerful approach, but it's not always easy to find a good instrument. And you can try to control for confounders, but it's hard to convince yourself you've gotten all of them. See, for example, https://arxiv.org/abs/1706.04692 where standard controls were of limited efficacy and it's only when they include an additional 3,700 controls that things start looking up.

Then there are things like https://en.wikipedia.org/wiki/Parameter_identification_probl... and whole books like https://en.wikipedia.org/wiki/Causality_(book) examining the problem and its' difficulty.

Can you explain what you mean?

pseudonom-on Elm, Elixir, and Phoenix: Reflecting on a Functional Full-Stack Project

Are you confused or am I confused? Elm does ship it's own runtime and standard library. Or at least it used to.

pseudonom-on How Do We Learn?

Choice quotes include:

> The past half-century of empirical research on this issue has provided overwhelming and unambiguous evidence that minimal guidance during instruction is significantly less effective and efficient than guidance specifically designed to support the cognitive processing necessary for learning.

> Our understanding of the role of long-term memory in human cognition has altered dramatically over the last few decades. It is no longer seen as a passive repository of discrete, isolated fragments of information that permit us to repeat what we have learned. Nor is it seen only as a component of human cognitive architecture that has merely peripheral influence on complex cognitive processes such as thinking and problem solving. Rather, long-term memory is now viewed as the central, dominant structure of human cognition.

> These results suggest that expert problem solvers derive their skill by drawing on the extensive experience stored in their long-term memory and then quickly select and apply the best procedures for solving problems. The fact that these differences can be used to fully explain problem-solving skill emphasizes the importance of long-term memory to cognition. We are skillful in an area because our long-term memorycontains huge amounts of information concerning the area.

> The aim of all instruction is to alter long-term memory. If nothing has changed in long-term memory, nothing has been learned.

I'll quit there, but that's only a few pages in and it's all quite good and definitely worth reading IMO.

pseudonom-on How Do We Learn?

https://www.tandfonline.com/doi/pdf/10.1207/s15326985ep4102_...

"Why Minimal Guidance During Instruction Does Not Work: An Analysis of the Failure of Constructivist, Discovery, Problem-Based, Experiential, and Inquiry-Based Teaching"

> Evidence for the superiority of guided instruction is explained in the context of our knowledge of human cognitive architecture, expert–novice differences, and cognitive load. Although unguided or minimally guided instructional approaches are very popular and intuitively appealing, the point is made that these approaches ignore both the structures that constitute human cognitive architecture and evidence from empirical studies over the past half-century that consistently indicate that minimally guided instruction is less effective and less efficient than instructional approaches that place a strong emphasis on guidance of the student learning process. The advantage of guidance begins to recede only when learners have sufficiently high prior knowledge to provide “internal” guidance. Recent developments in instructional research and instructional design models that support guidance during instruction are briefly described.

pseudonom-on How Do We Learn?

Committing things to long-term memory is an absolutely essential component of any sort of learning. There are many studies talking about how doing doesn't necessarily imply any learning at all and only implies learning insofar as it leads to committing information to long-term memory. Furthermore, there are studies talking about how problem-based/inquiry-based learning (what it sounds like you might be thinking of) generally produces worse outcomes than direct instruction (which places substantial emphasis on committing things to long-term memory).

This all makes sense in light of the "human cognitive architecture". Working memory is severely limited while long-term memory is effectively unlimited. Thus, committing things to long-term memory frees up the scarce resource of working memory. In fact, there are many studies which indicate that the key differentiator between experts and novices is that they have a huge long-term store of schemata which can be applied in the problem domain and allow more efficient representation and manipulation in working memory.

pseudonom-on Some Notes About How I Write Haskell

One semi-real problem with `Arbitrary` is that quickcheck itself can only define a fairly small set of instances since it doesn't want to incur a dependency on all of Hackage. Likewise, other packages are unlikely to bring in quickcheck as a dependency just to define the instance.

This means these instances must be defined in standalone packages where they're necessarily orphans. The cultural prohibition against orphans means there aren't as many of these orphan instances packages as you'd like so you can end up redefining instances in every consumer project.

With the Hedgehog approach, there's no problem whatsoever with creating separate packages for these instances.

pseudonom-on Ikea founder leaves fortune to no one, structures it to ensure it lasts forever

This doesn't seem like an accurate assessment:

"He finds that codetermination laws are negatively associated with productivity, but profit sharing, worker ownership, and worker participation in decision making are all positively associated with productivity." ---http://library.uniteddiversity.coop/Money_and_Economics/Coop...

"The positive effects are found most uniformly with respect to profit sharing and, to a slightly lesser extent, individual capital (share) ownership and participation in decision-making by workers." ---https://www.sciencedirect.com/science/article/pii/0147596787...

pseudonom-on It’s Surprising How Much Small Teams Can Get Done [audio]

> It seems the bigger a company gets the more they favor predictability over excellence.

This is one of the key themes of the book "Seeing Like a State". It describes many efforts by states to regularize their populace and make it "legible".

pseudonom-on Bitcoin is none of the things it was supposed to be

Can you give an overview of or pointers to critiques? My prior is that Krugman is more likely to by correct than the average crypto person, even after adjusting for interest in and attention to crypto.

pseudonom-on Silicon Valley Software Engineer Salaries by Experience Level

The first principles argument is consonant with my actual experience in the Midwest and SV. I have vastly more money left over after living expenses in SV.

pseudonom-on Hired – Technical Interview Score

Table 1 here: http://www.flume.com.br/pdf/Scmidt_The_validity_and_utility....

pseudonom-on Hired – Technical Interview Score

FYI, most evidence suggests unstructured interviews (talking to the candidates) have very low predictive power about job performance and that work sample tests (take home problems and on-site coding) fare much better in that regard.

pseudonom-on Rolling Your Own Blockchain in Haskell

Actually, I realized I follow the "abstract recursion out of your structures" intuition but don't really realize why you chose Cofree instead of some of the other options:

    import Control.Monad.Free
    import Control.Comonad.Cofree
    import Data.Functor.Foldable

    data A f
      = ANil
      | ACons f
    type AList a = Cofree A a
    a :: AList Int
    a = 1 :< ACons (2 :< ACons (3 :< ANil))
    
    data B a f
      = B a f
    type BList a = Free (B a) ()
    b :: BList Int
    b = Free (B 1 (Free (B 2 (Free (B 3 (Pure ()))))))
    
    data C a f
      = CCons a f
      | CNil
    type CList a = Fix (C a)
    c :: CList Int
    c = Fix (CCons 1 (Fix (CCons 2 (Fix (CCons 3 (Fix CNil))))))

You wanted to ensure it's non-empty? Something about the actual Comonad (extend, etc) interface?

pseudonom-on Rolling Your Own Blockchain in Haskell

FWIW, I appreciated the example of Cofree in use.

pseudonom-on Ask HN: Distributed tracing service with critical path analysis?

My company actually has and uses Zipkin. The thing that I'm looking for that I think is lacking is a way to identify critical paths without manually clicking through a bunch of traces and eyeballing them.

pseudonom-on U.S. Malaria Donations Saved Almost 2M African Children

https://www.effectivealtruism.org/ is substantially about bang for your buck.

pseudonom-on The US has forgotten how to do infrastructure

This is a central idea in https://en.m.wikipedia.org/wiki/The_Logic_of_Collective_Acti... .

pseudonom-on A Look at the Ugly Side of Getting Rich

Finding 1 here: https://www.gwern.net/docs/genetics/2016-plomin.pdf

> All psychological traits show significant and substantial genetic influence

pseudonom-on What programming languages are used late at night?

I'm pretty sure Simon Peyton Jones is still at Microsoft Research.

pseudonom-on Most Vegetarians and Vegans Eventually Return to Meat

You may already know both of these things, but due to your request for more info, I'll err on the side of overinforming:

> I have more problems with the consequences of the FAM argument - that we inexorably ought to use all our life for the benefit of others if we profess to care for others at all. This, to me, is such an absurd consequence as to throw the entire enterprise of morality as a chain of material implication following from axioms (very attractive to a computer scientist!) into doubt.

This line of argument is called "the demandingness objection". There's a decent bit of philosophical literature under that heading.

If one embraces the implications of FAM rather than rejecting them, that probably ends up looking something like "effective altruism". (https://www.theguardian.com/world/2015/sep/22/extreme-altrui... is an article about effective altruism that seems relevant to your concerns)

pseudonom-on Why OO Matters in F#

ML uses "functors" in a different sense than e.g. Haskell.

pseudonom-on Let’s not demonize driving, just stop subsidizing it

I don't follow. You're saying that the store didn't provide parking to help some future, possible me-with-a-car? How is that relevant?

pseudonom-on Let’s not demonize driving, just stop subsidizing it

You pay for private parking spaces, in part (i.e. in combination with other customers). I also pay for parking spaces, in part, by my patronage but never use them. Consequently, your share of the usage is higher than your share of the payment. So again, even private parking of this sort is subsidized.

pseudonom-on Towards Idris Version 1.0

I think the proposal people are making is better thought of as indexed monads and effects rather than indexed monads or effects.

Normal extensible effects looks like:

    data Union :: [Type] -> Type -> Type where
      ...

    data Free :: (Type -> Type) -> Type -> Type where
      ...
    
    type Eff fs = Free (Union fs)
    
    class Inject f fs where
      inj :: f a -> Union fs a
    
    data File :: Type -> Type where
      Open :: FilePath -> File ()
      Close :: FilePath -> File ()
    
    send :: (Inject f fs) => f a -> Eff fs a
    
    -- The inferred type would be more general
    openClose :: Eff '[File] ()
    openClose = do
      send (Open "foo.txt")
      send (Close "foo.txt")

You can then generalize this by also indexing everything:

    data HList :: [Type] -> Type where
      Nil :: HList '[]
      (:>) :: a -> HList as -> HList (a ': as)

    data Union :: HList fs -> HList is -> HList is -> Type -> Type where
      ...

    data Free :: (is -> is -> Type -> Type) -> is -> is -> Type -> Type where
      ...
    
    type Eff fs = Free (Union fs)
    
    class Inject f i o fs is os where
      inj :: f i o a -> Union fs is os a
    
    data FileStatus = Open | Closed
    
    data File :: FileStatus -> FileStatus -> Type -> Type where
      Open :: FilePath -> File 'Closed 'Open ()
      Close :: FilePath -> File 'Open 'Closed ()
    
    send :: (Inject f i o fs is os) => f i o a -> Eff fs is os a
    
    -- The inferred type would be more general
    openClose :: Eff (File ':> 'Nil) ('Closed ':> 'Nil) ('Closed ':> Nil) ()
    openClose = do
      send (Open "foo.txt")
      send (Close "foo.txt")

Does that help at all?

pseudonom-on Towards Idris Version 1.0

Extensible effects arise from combining a free monad with an open union of functors. Using an indexed free monad with indexed functors instead is a generalization that provides more expressive power.

Intuitively, I like to think of it as:

- Extensible effects describe what we permit (read from console, print to console) - Indexed monads describe what we demand (you must auth before you can access db, you must open file before you can read it)

I'm actually working on doing a version of this in Haskell. You can see Oleg's version of it here: http://okmij.org/ftp/Haskell/extensible/ParamEff1.hs

I may have a more informed opinion after I read the states-all-the-way paper.

pseudonom-on Haskell vs. Clojure (2014)

It's pretty handy to only have to be vigilant at the boundary layer. With the untyped approach, all consumers of the deserialized map have to guard against data which doesn't conform to expectations. With the typed approach, all subsequent functions only have to work with data conforming to the specification as laid out by types.

pseudonom-on SF YIMBY Platform

https://en.m.wikipedia.org/wiki/Community_land_trust is certainly relevant.

pseudonom-on A Farewell to FRP

Can you talk a little more about your thoughts on one big atom? I've been looking at Redux and they also seem to follow this approach. The re-frame readme quotes the Elm Architecture as justification, but that same document goes on to describe nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting.

I come from a Haskell perspective and having one big blob of state sounds to me like it makes your type signatures less informative and increases the scope for error.