devons

Ooh, thanks for the additional details. Do you have any preferences for alternatives than Jenkins? (especially OSS)

Please elaborate -- do you object to Jenkins (as a tool, specifically), CI/CD, or some other aspect (added complexity, etc.)?

There's a Twitter thread critiquing Progress Studies from a similar angle. This reply in particular caught my eye:

https://twitter.com/WordsByBennett/status/115630161497577063...

It compares the proposed approach to WW2 Abraham Wald airplane bullet pattern analysis [1] and Survivor Bias.

[1] https://medium.com/@penguinpress/an-excerpt-from-how-not-to-...

Interesting - do you know if the negative effects of circular swimming pool affect fish hatcheries? (fish are forced to swim against current)

If I had to guess, I'd say not as much b/c of the size of the fish.

Ditto - these are exactly the questions that must be asked, frequently:

> he asked “one of the good ones, or one of the bad ones?” A designer on his team — a “bad one” — asked too many questions. Questions like “Why are we building this now?” “Are we sure this is the right problem to solve?” “Why don’t we approach the problem in a different way?”

Calling those questions 'doubts' just doesn't seem quite correct.

In the best teams I've worked with/on, designers [1] aren't afraid to frequently ask these questions. I have yet to see a case where that's been a problem. Quite the opposite - far too often, there aren't enough deep / 'stupid' questions asked, especially at the outset & middle of projects.

[1] and everyone else on the team

I use Pinboard for this. It doesn't have the masonry-style layout, but it's quite functional.

You can make your posts public and they'll be shown on your usage page, for example: http://pinboard.in/u:incredimike/

Those are excellent insights, thank you.

Do you have any pointers to get started on this for someone whose last practice of scientific method was a middle-school science fair project? (Asking for a friend)

I picked up the book "Uncontrolled" by Jim Manzi, which is ostensibly about this subject. Would love to hear any recommendations you picked up from learning about this material and applying it.

Very cool, thanks for creating this and sharing!

I've been interested in (U)GA and related subjects for a while. Looks really promising and its advocates make it seem like it solves all kinds of problems. But I hesitated to dive in because the learning curve looks rather steep, and it's not clear if the cost-benefit of ascending that curve ends one up in the black.

How useful is (U)GA, really? In other words, what are the concrete benefits relative to traditional vectors, matrices, quaternions? Are those benefits worth the additional complexity (or is GA actually a simplification)? Are there applications where GA is the clear win, or is it simply an alternative way of expressing what can already be expressed through the 3 primitives I mentioned?

On another tack, how would you characterize the power / utility of (U)GA? For instance, it _seems_ like (U)GA is a super-powerful tool that's just misunderstood and everyone would benefit from learning it (like Lisp in the early 2000s). On the other hand, papers often extol the virtues of (U)GA by showing how it can solve (seemingly) esoteric higher-order math problems.

Google (and others) gave them so much money because ML is aiming to build a platform that is not only the thing after smartphones, it's the thing after the Web: spatialized information seamlessly interleaved with reality, everywhere.

At that time (>2 years ago), Magic Leap seemed to have achieved the holy grail of Mixed Reality: optics that selectively block out light in real-time. Combined with demos, mockups, and sketches of real-world applications, this tech provided compelling evidence that ML was going to unlock true Mixed Reality real soon.

As erikpukinskis commented, even if Magic Leap fails to deliver, it will likely end up with an extremely valuable IP in an emerging space. Magic Leap did not invent Mixed Reality, but they filed patents on many first-order applications of the tech (there are countless others).

The Lua community experienced a similar "Cambrian explosion" of module standards followed by standardization. This stemmed from Lua's "mechanisms, not policy" design philosophy:

"Despite our “mechanisms, not policy” rule — which we have found valuable in guiding the evolution of Lua—we should have provided a precise set of policies for modules and packages earlier. The lack of a common policy for building modules and installing packages prevents different groups from sharing code and discourages the development of a community code base." [1]

The same problem occurs when implementing commonly-used patterns where standards aren't defined, like OOP class hierarchies and object instances. History repeating, etc.

[1] The Evolution of Lua - http://www.lua.org/doc/hopl.pdf