It's not just documentation. Everything that makes programming easier is now suddenly valued, because wasting tokens is obviously worse than wasting your employees' time.
This claim is plain malicious. Of course falling asset prices would be excellent for the median person, since they would be less extremely priced out of everywhere. This is one of the central benefits of a wealth tax.
The list of tools that Pythonheads present as a definite solution to their problems changes every year, yet the results are still far behind Rust/Scala/Kotlin/C#.
The "fix everything" button is abolishing zoning laws, and its aggregate cost is negative. Aggregate cost is not the issue preventing problems from being solved.
> on top of a well designed language constructed over past language design experience
While I believe that Chris Lattner is a great compiler designer, his language design record has been less stellar. Swift bidirectional type inference for instance feels like it was implemented because they had a compiler algorithm that they wanted to use, rather than a genuine need, and is just a completely avoidable problem. Trying to make a HPC language that is also Python compatible was doomed from the start. Hopefully the damage from going into this direction will remain limited.
Every reasonable language has a Python interop story. All it takes is C FFI. But what Mojo promised early on was the eventuality of compiling a large amount of Python code if not entire wheels as Mojo.
I don't recall they promised that. They promised it'll be a superset, but Mojo introduces new keyword. Mojo could support all Python features today exactly as they're supported in Python and you wouldn't still be able to copy Python code into Mojo and compile it
How is it possible to provide a zero knowledge proof that their circuit works for large problem instances if there is no efficient way to run or simulate the circuit with the required instance size?
The dominant cost in Shor's algorithm is the elliptic curve point addition subroutine. That subroutine can be implemented using reversible classical gates. For that kind of implementation, approximate correctness can be verified by fuzz testing classical trajectories through the subroutine.
Note you could ask the same question about Shor's original paper: how did he show the algorithm works without running it? Running X just isn't the only way to analyze X.
This is the key point, what is the meaning of "zero knowledge" here? It seems that you need to know something about the implementation, even if it is not the full implementation. Compare this to a zero knowledge proof that you have, say, a factorization gadget, which works by you running the gadget on adversarial input, thus convincing the adversary that you can factor any of their integers. That discloses no implementation details of your factorization gadget, which can be an efficient classical algorithm, a quantum computer, or a phone line to God.
"I believe that almost anything that has been formalised today in any system could have been formalised in AUTOMATH. Its main drawbacks were its notation, which really was horrible, and its complete lack of automation. Proofs were long and unreadable."
That's like saying that anything that could be programmed today in your modern language of choice could have been programmed 50 years ago in assembly. Technically yes, economically no.
reply