mopierotti

Proof is a hard goalpost in any domain, but science, and by extension the scientific method, can support the belief that murder is wrong through a couple plausible paths.

The study of evolution gives a mechanism through which a sense of morality is 'hardwired' into us for its adaptive benefits. Or, less teleologically, the study of our own brains can provide evidence for us as humans just not liking certain things.

Additionally, a technique like group simulation could show that allowing murder is against the average individual's interest.

I'm not claiming I come to my beliefs through deliberate scientific reasoning, but I do think that science has important things to say about most things.

This site claims that different sugars have different glycemic indexes. E.g palm sugar (from date trees) at 35 and brown sugar at 65. https://www.eatthis.com/sweeteners/

I'm a fan of the cross modal congruence school of thought here. In which experiences in one sense are similar in structure to experiences in another sense, imparting them meaning. For example, "Flight of the Bumblebee" by Rimsky-Korsakov (https://www.youtube.com/watch?v=M93qXQWaBdE), in which the franticness of the notes/rhythm have a similar variance and speed to what you see visually when watching a bee fly around. Or maybe even what you imagine the bee's internal thought process would be like.

I'm not sure if "cross modal congruence" is an actual term people use however, someone correct me if you know a more accurate label.

I would strongly recommend the post he cited. It is the same style but features interactive visualizations: https://dataorigami.net/blogs/napkin-folding/79031811-multi-...

I implemented something like this for my company and found the latter article quite helpful in explaining the concept to people who understood the basics of probability but not programming.

The first point is actually something that game developers have failed to do in many cases. For example if they want client syncing to require transferring very little data, they may only send player inputs across the wire, meaning that each client needs to know everything, even if the final decision about game state is made by a server.

Correctness can just mean "does what it's intended to do". This is fairly unambiguous in cases such as if you intend to implement A* Search. If you hit a NPE and your program explodes, or if you aren't calling your heuristic (central to A*), then you have skimped on correctness. Furthermore, basically any time you hit something like a runtime error you likely did not intend to hit it. Therefore, regardless of problem domain, taking approaches that minimize these types of errors is an uncontroversial way that correctness can be prioritized.

I wish he would have gone further into detail on why "stuff like Scalaz has no place outside academia". While I understand there's a bit of mental overhead, I've found there to be much real world utility in using that genre of libraries/patterns in production.

It's also interesting that he wants the ability to "run your tests for the intermediate refactoring steps that wouldn’t typecheck and then let you fix up things later."-- I'm not sure what it means to want to run code with ambiguous types in a type aware language like Scala. Type information is deeply involved in runtime program behavior. (E.g pattern matching on types, resolving typeclass instances)

I certainly agree that nontrivial sbt work is rough.

I've never heard entropy used in this context. What do you mean by it?

The title is a clever reference to Dawkins' book about evolutionary fitness: The Selfish Gene (https://en.wikipedia.org/wiki/The_Selfish_Gene)

This answer written by the Ethereum team addresses why cost spent won't necessarily rise to equal block reward in their PoS formulation. https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ#doe...

I haven't watched the full video, but here are some things that a hypothetical Person class brings to the table that you might be missing:

1) A Person class can guarantee that a Person can not exist unless it is fully specified. E.g. you prevent Persons from being created that don't have a date of birth.

2) A Person class provides a syntactically nice place to put pieces of code that rely on the instance fields. E.g. a function like Person(...).computeAge(DateTime.now)

3) A Person class can be a nice place to put inter-field validations. E.g. Maybe you don't want to allow Persons to be constructed if their last name is the same as their first name

4) A Person class can bring clarity to function signatures that depend on it. Basically resolving the problems that Duck-typing introduces

Is there a particular feature that's suited to machine learning? I'm having trouble understanding the connection.

I think the point was that cyber weapons are effectively as dangerous as nukes because they could cause nukes to be launched.

I'm not the op, but I would charitably assume that they meant that those blog posts demonstrate that the blog's strongly geared toward attracting talent.

Hmm I would expect the results to be based on the data structure holding the values you're flattening. An in-order depth first traversal if the data structure you're applying it to has an inherent order (e.g a List) and in an undefined order if it's something unordered like a Set.

  List(List(1,2), List(3,4), List(5,6)).flatten -> List(1, 2, 3, 4, 5, 6)
  Set(Set(1,2), Set(3,4), Set(5,6)).flatten -> Set(5, 1, 6, 2, 3, 4)

I would agree with you if we were talking about more complicated features like monad transformers or monoids or something like that, but list operations like this are very high-leverage, not that complicated under the hood, and becoming part of the standard required knowledge for most programming ideologies. (Eg. Java has recently embraced them in Java 8, Python has them, etc)

Your logic about an abstraction being "legitimately obfuscated" "until you grok" it could apply to nearly every advancement in programming, and needs to be qualified with some notion of why you've decided to apply it to the layer of abstraction that you have.

Fair point. The for-comprehension is not quite as magical as I describe it. However, as long as the futures are created outside of the comprehension, the behavior is nearly as described. I'll include a note about it.

Does anyone know why most graph libraries that I see of this type have nodes that seem to bounce all over the place? Is there a practical motivation for this? I would think a less animated version would be more usable.