- 0815test parentPower, perhaps. But I'm a bit skeptical about usability. Lean doesn't even use one of the most obvious things that make interactive proof systems far more usable - a declarative mode instead of the usual tactics-based scripts. (Yes, you can kinda sorta fake the former with "structuring" tactics, except not really - declarative proofs are really their own kind of thing.) There even used to be systems that automatically rendered inputed definitions and declarative proofs in natural language (given that the basic terms and symbols were previously defined of course) which does enable even an average mathematician to easily figure out what the system is up to. You just can't do this properly if all you have is a list of "tactics" fiddling with the prover state.
- How so? Rust is much, much less complicated than C++, a language that's routinely taught to beginners. Python is far more complex than either of those, especially once you account for the incidental complexity in whatever "packages" you're interfacing with - Rust simplifies a lot of that stuff without giving up on performance.
- Indeed, the "at a mere fraction of a UBI’s cost" claim is outright ignoring the economic cost associated with very high marginal tax rates. But Acemoglu also mentions the NIT, which would work a lot better than either. And, to be fair, the best-known economic models of non-linear income taxation imply that marginal tax rates on a NIT should actually be fairly substantial (60% or so would not be out of the question!), so as to keep the break-even point from getting too high; the rates just shouldn't be as high as 100% or more!
- A bit of a clickbait title. Acemoglu does say that a 'UBI' is a bad idea, but then advocates for the NIT (Negative Income Tax), which actually works in much the same way. What he actually seems to be saying is that way too much UBI advocacy makes unrealistic claims about what a UBI-ish system might look like - and it's hard to disagree about that!
- Debian's current, supported version is the stable version. The reason why it's only released every two years and why it feels so 'old', is because it takes Debian Developers many months to "further harden" it before release. It wouldn't make sense to release it under a quicker schedule. Debian does offer "rolling" channels with prompt updates (testing, unstable) but those are officially not meant for real, production use.
- I wouldn't be so sure. Linux still makes very good use of spinning rust media, and on a modern system with 2GB+ RAM (and a reasonably light distro like Debian) much of it ends up being used as disk cache so drive speeds aren't even that relevant. SSD's do speed up the boot process though, I'll give you that.
- This, so much. I for one find the vast majority of so-called "high art" and "high culture" to be frankly depressing and off-putting, rather than "grand" or "transcendent" in any way. In the best of cases this is somewhat offset by the HNish intellectual interest and curiosity one can take in the stuff (and some variant of this is an often-cited point that's supposed to demonstrate the superiority of "high" culture) but all things considered, I'd rather explore the hidden intellectual interest of things that are usually dismissed as mundane, "middlebrow" or even "lowbrow".
- IME, touch screens are simply way too error-prone for any sort of serious work. You can make them work, but only by adding a "swipe to confirm this input" step for any potentially-destructive activity. (AOSP "recovery" environments do have this, for a reason!) Current command-line environments are not well setup for this, but you could make this work in combination with a "web"-like interface (especially if designed around REST principles).
- Implementation inheritance does more than break encapsulation. It creates inherent fragility because of how it makes code defined in a base class dependent on behavior that may be overridden willy-nilly in a derived class; the possibility of overriding means that the whole bundle of public and protected methods/fields is essentially part of an object's external interface, due to its open extensibility - with method implementations typically calling through that same interface. This is far worse than what you would get with a plain old non-OOP program, even one that doesn't use encapsulation at all! In most cases, implementation inheritance can be treated as simply a bad idea that should be avoided altogether - composition is clearly the better approach.
- > I am sure within 10 years every professional mathematician will use formal proofs.
They said the exact same thing 10 years ago - see e.g. https://www.vdash.org and the AMS Notices special issue on formal proof from around the same timeframe. Formal proofs are hard, sometimes tedious and not always very intuitive. They're slowly spreading out from the most "synthetic" subfields of math (the ones where you're basically working with unfamiliar "rules", but not with a huge library of proven results), but progress is really slow - definitely slower than many people would expect!
- Fubding may be a big deal for museums in the abstract, but how much funding do these museums raise from selling "licenses" to reproduction of these public domain works? It can't be that big of a deal, and museums can still request payment for endorsed reproductions (basically a quasi-sponsorship arrangement targeted at high-profile reusers of these works, driven by signaling goals - "we pay for the museum's endorsement, this shows we're serious!" and broadly-aligned incentives - "the more reproductions the better, for both the museum and the reuser") without any need for quasi-copyright claims.
- Lanczos interpolation seems to beat a gauss filter for me. It has some overshooting/ringing effects of course, but the improved sharpness is a great tradeoff compared to the blurriness of gauss filtering. Of course, gauss filtering might still play a residual role in analog systems, such as the one that physically displays stuff via a CRT screen.
- A "new cause of cell aging" might cause trouble for the somewhat-speculative programme of SENS, the pursuit of long-term "negligible" senescence via regenerative medicine. In this case, if it turns out that telomerase is needed to prevent cellular senescence, it seems you can't use whole-body inhibition of telomerase as a cure for cancer, which is the approach SENS is proposing. It doesn't make all regenerative medicine useless, but it might be a challenge.
- > An in-shape, muscular person looks like they have dedicated a non-trivial amount of time to not software.
Hitting the gym can actually be pretty complementary to writing software or doing other sorts of engineering in the best possible way. For example, many people are psychologically messed up due to some sort of mental "baggage" that basically shows up as a somatic fight-or-flight response, albeit generally in an in-set, chronicized form rather than a literal stress reaction. This can place a significant cap on both your executive function and your self-perceived mental acuity. Hitting the gym is an excellent, time- and cost-effective way to work that stress out of your body and mind!
- > Drop the Ai, it's overkill.
Well, if you do want to use AI, this project is totally open source, "real" AI and pretty damned easy to use,[0] and generates something that's pretty darn close to SOTA as far as actual "musical" interest goes! Unfortunately, it seems to need Python 2. It would be really nice if someone forked the project (it's pretty researchy/proof-of-concept right now!) and committed to maintaining it for the foreseeable future, to run on whatever supplants Python 2 as the "standard" platform for Theano, when that version of Python goes EOL.
[0] https://github.com/hexahedria/biaxial-rnn-music-composition
- To the extent that "the what it's like to be conscious" is part of physics - that is, to the extent that it enters into causal relations with the rest of the universe, it can of course be described as such. However, the way by which such casual relations occur is itself of interest, since it opens up other means of description that are not dependent on the inherent limits of an "outside" observer, acting through known physical mechanisms to make her observations.
- Implementation inheritance may have its uses, but it's not for the faint of heart. Its defining feature is _open recursion_; that is, defining an object's external interface (its bundle of public and protected methods) in terms of itself (in that any method may be defined as calling any other method of the same external interface) and then leaving the whole thing open for arbitrary overriding in "derived" classes, via a "tying the knot" trick. Most treatments of OOP brush over this feature, but it creates a huge amount of complexity. It is even proper to say that something like this should be avoided at all costs, IMHO.
- > Much cheaper and more realistic than a rewrite.
I really have to dispute this, these tools are not simple to use. You'll probably have a far easier time rewriting the code piecemeal, i.e. function-by-function (which will involve a lot of unsafety initially, since you're not using the idiomatic global patterns of a memory-safe language!) and then refactoring into something idiomatic for the language you're using. Projects like Firefox are basically taking a similar approach, only "rewriting" small portions of the codebase that can be deployed immediately once rewritten.
Where similar tools might be useful is for preventing logic-related issues that are not encompassed under simple memory safety. Unfortunately it's still not possible to endow, e.g. Rust code with automatically-checkable proofs, showing that the logic in the code preserves some appropriate conditions/invariants; while this is feasible, e.g. in Agda or Idris. Hopefully by the time these concerns become pressing, practical memory-safe languages will also offer this.
- I'm not going to defend the article's writing style, but Rust is effectively a functional language with controlled use of procedural-programming features. Not that much different from how Haskell places safeguards on the very same things. (No, I'm not saying Rust today is just as safe or just as elegant as Haskell - far from it! But it can get there with some work.) Even FP is not what it was back in the 1980s and 1990s!
- This article is just not very good, the author keeps talking about a zillion different things without really focusing on the actual, underlying issues. But one thing it does say right away is that mutable state is not a problem as far as it goes, what's problematic is mutability plus promiscuous sharing. This is what makes it unfeasible to reason about what the code is doing.
Similarly, encapsulation (bundling code and data) definitely has its uses - in preserving class-wide invariants, or in providing a "common" interface that makes it possible to disregard the inner workings of some data structure, and interact with it in a way that's not dependent on the implementation. But in practice, implementation inheritance in OOP often encourages what amounts to breaking encapsulation and making it possible to violate class invariants, all in search of some dubious "code reuse". If you can't express your desired code reuse pattern via some combination of simple interface inheritance, delegation and dispatch over "sealed", non-extensible variants (the mechanisms that plain old composition/FP gives you) there are probably some underlying problems with it that you haven't thought through.
Of course the standards of programming improve continuously over time. Even FP and broadly "FP-like" programming is not what it was in the 1980s, and some of that progress was brought (if perhaps incidentally!) by OOP languages. This is to be expected!
- > Should the insurance just find a way to exclude massive, correlated events?
Why exclude when reinsurance can deal with them fairly easily? The insurance company sells bonds that only pay when the massive, correlated event doesn't occur. Financial markets like those, because while they may be 'correlated' in a sense, they are still largely uncorrelated with global growth trends - they're free diversification from their POV. And the "wisdom of the masses" takes care of the modeling - the bond price tells you (and the company) how likely the massive event is expected to be. No added model risk!
- > Also, there might be a more interesting consideration at play in this particular case: if a work is never published, then AFAIK, it never enters copyright
This isn't really true in the U.S. AFAICT - unpublished works do enter the public domain, 120 years after creation. It is true elsewhere, e.g. in Europe, but the standard for publication is lower than you might expect; if one can argue that the work wasn't genuinely private to the author (e.g. copies were made, it was used for public performances, etc.) that's enough to consider it "published".