My laconic question was downvoted. Sorry, I was on my phone, but didn't want to forget about this. I'm sincerely interested in reading the source of this research. Searching for it now, I came across this article:
But is this really the one you mean? Even the abstract states that there is no single metric that measures developer performance, which contradicts your claim:
> Developer productivity is about more than an individual’s activity levels or the efficiency of the engineering systems relied on to ship software, and it cannot be measured by a single metric or dimension
So I'm still interested in reading the research you're talking about, and I would appreciate a reference. Thanks!
It sounds cool but also like a remarkable level of scope creep for the JVM. I realize that Java ecosystem is far beyond simple these days. Nobody is spinning up a JVM implementation as a hobby project. But sad to see the deep entrenchment that is caused when an open standards platform is made so inconceivably complex that there is simply no opportunity to innovate on alternative implementations.
This is not an observation about this specific project, just about the organizational pressure to extend standards based systems beyond their core functionality, into territory where only few players can afford to roam.
This is similar to the expression tree API of C# so no change in the JVM is required, only cooperation between the java compiler and the reflection API.
The code model can be computed by the compiler, inserted in the classfile in a specific binary or text format and read at runtime using the reflection API.
I've not taken a look to the implementation so it's speculation but I do not think the JVM need to be changed.
It's fine if the poster above me wishes to change languages. Anyone who chooses to stick with Haskell should get comfortable with the notion that functions can diverge, and accept that this is fully consistent with the Haskell type system. The return types may seem unhelpful, but they are accurate.
I think some of the confusion is because you're referring to the type variables as parameters. Parameters and type variables are not the same thing. A is a type variable, X is a parameter in your example.
Sure, it's basically JSON with semicolons... that's used to define a graph of nested lambdas which are evaluated recursively until a fixpoint representing the stable configuration is reached. Also, you can add comments, which makes it nicer than JSON!
Remember: if you're not certain that your matrix meets the prerequisites for applying the Schur decomposition, you can always apply the Unschur decomposition instead.
Whenever someone mentions building a billing system, I feel compelled to share Mark Dominus' delightful article, "Moonpig: a billing system that doesn't suck":
> Sometimes I see other people fuck up a project over and over, and I say “I could do that better”, and then I get a chance to try, and I discover it was a lot harder than I thought, I realize that those people who tried before are not as stupid as as I believed. That did not happen this time. Moonpig is a really good billing system. It is not that hard to get right. Those other guys really were as stupid as I thought they were.
