h2j24

The errors package is really useful for generating stack traces in Go 1: https://godoc.org/github.com/pkg/errors

The reason one can represent 3D "quite comfortably" on a 2D monitor can best be explained using linear algebra. The 3D space in the video is "projected" (linearly) onto a 2D space the same way a single one of our eyes project 3D space onto a 2D space. This is just one choice of projection though. For instance, when he shows the 2D beings perspective, he's chosen a different projection from 3D -> 2D and it looks quite foreign to us. The reason you feel comfortable with the normal projection is because your eyes do it all the time. Your eyes don't however, project 4D -> 3D so you don't feel it as natural.

I think Germans genuinely enjoy paying taxes. One need not look farther than Germany's close neighbors (Italy, Greece) to see that many people do underreport cash revenue.

One interesting article I read had an interesting point: one thing Java does better is to use type Erasure. This was surprising to me because reified types are often touted as one of the best things about C#. The author's argument was that type erasure made implementing different type systems on the JVM easier, because type erasure isn't as strict, which makes the JVM a more attractive language target than the CRT.

Is that truly the case for games? I thought game logic was usually programmed against a clock, so that the game logic isn't dependent on running at some pre-determined frequency. However, is it typically the case that the number of ticks per second is independent of the render time?

I think the article largely paints a favorable picture of Kilian.

I have to disagree with you here regarding "enterprisization". Having worked in multiple large Java code bases leveraging multiple DI frameworks (Spring, Guice, and Dagger), I've definitely seen both sides of the argument first hand. I'm targeting DI specifically here, because it is most often complained about when talking about "enterprise" software. What I've learned is that proper use of DI is hugely beneficial in large code bases. Where things really break down is when the code base suffers from a lack of philosophy. The biggest issue with DI is that it is very easy to abuse, but these abuses have very specific patterns and can easily be avoided by applying a principled approach to development.

Regarding the beauty of DI, let me provide an example of a typical large application. Such an application may need a UserInfo class to model a user's information in the app. This user info class will likely have many dependencies: it needs a way to persist itself to disk, to make network calls for server syncs, and any other ancillary components. As an app component, I don't need to understand any of this. I just add a component to my constructor and I immediately have access to any functionality I may need. Using DI in this way also has a nice side effect: classes can be stateless singletons and still be easily testable with mocks. And the best part is none of this is magical. All of it is governed by a few simple rules.

I work on zbuild, which is a cross-language build tool designed to make vending and versioning artifacts sane in large, multi-team environments. If you're interested, I can help you get started with a simple task or two: https://github.com/dimes/zbuild

    class Answer {
        getAnswer(input: number) { return (input * 6 + 4) / 2; }
    }

    interface Operation<T> {
        apply(input: T);
    }

    class Addition implements Operation<Number> {
    }
    class Multiplication implements Operation<Number> {
    }
    class Division implements Operation<Number> {
    }

    function compose(Operation<T>... operation, T input) {
        T last = input;
        for (Operation<T> op : operations) {
            last = op.apply(last);
        }
        return last;
    }

Is currying useful other than as a shorthand for "value object" creation? You can easily create the equivalent of a curried add function:

    class Adder {
        base: number;
        constructor(base: number) { this.base = base; }
        add(o: number): number { return this.base + o; }
    }

I don't think that's really true. The difference between a quantum computer and a classical computer is that a classical computer can represent N states given N bits, whereas a quantum computer can represent 2^N states given N q-bits. However, this has a major caveat: you can never know the state of the system. You only get to measure one value at a time and you can never re-create or copy a previously obtained state.

Still, some clever people have figured out how to exploit this to achieve polynomial speedup on problems where certain properties of the problem are exploited to get around the limitation of measurement in a quantum system.

Not an expert, but I believe most of the benefits will come from quantum annealing, which is capable of escaping local minima in optimization problems.

David Mermin has written a very good introduction specifically targeted towards computer scientists and mathematicians looking to learn and contribute to this field. His book "Quantum Computer Science" is really great, and I highly recommend reading it if you're interested in learning more. Basic linear algebra is pretty much all that's required, although familiarity with mathematical notation definitely helps.

A good place to start might be this paper by Mermin, which defines classical computing bits (Cbits) in a specific mathematical framework and then expands that definition to define Qbits and their states: https://arxiv.org/pdf/quant-ph/0207118.pdf