Well I think it’s as simple as P vs NP. This is the primary difficulty with AI and always will be. Solutions are easy to get AI to construct. The difficulty is in verifying those solutions. This can be seen in industry even now, evals are the hardest part of non-trivial AI systems
There is absolutely virtue in spending willpower to make your body do something it doesn’t want to do - maintaining and developing self control and autonomy. Imagine if there was no way to develop self-discipline, you’d be at the whims of your environment and the world would be nothing but chaos.
Hedonism is a philosophy that posits that pleasure is the sole objective good and thus pain something bad.
This whole thing is about trying to find shortcuts to get to the pleasure of having a nice body while circumventing the pain and effort.
Pain and efforts are important, they forge character like nothing else. If you want to live in a world where adult-children simply take their soma to get what they want, you're just not thinking about the consequences.
Do you feel this way about everything? Like you shouldn't take an aspirin because you should feel the pain of your headache? You shouldn't wear shoes because you need to feel the pain of the rocks under your feet?
Important != superlative need. I mean, I know this is just rhetoric drivel, but I'm bored enough to reply. My post was clearly about a certain type of pain that the mind knows is a necessary path to achieving a stronger mind.
Also, about headaches and more generally physical pain that you know is only temporary and not a sign of radical bodily malfunction, I say yes: enduring a reasonable amount is important to develop a tolerance to it and willpower.
What I'm saying isn't new anyway, everybody knows some amount of struggle is needed to temper character and not fall to the most insidious poison of our times: constant comfort.
Correct, and that’s a good thing! Intelligence is not evenly distributed among individuals, and susceptibility to psyops and propaganda is a huge issue. The plain truth of the matter is that a majority of people simply aren’t qualified to weigh in on national issues. True democracy works when you’ve got a small group of like-minded individuals of roughly equal stature (13 original colonies) but not when you’ve got an entire empire (Roman republic)
I think you’re misunderstanding the “fail fast!” advice. You want to fail fast in development not in production. In production you want maximum robustness. Users would rather see an error saying “whoopsie, maybe try that again later” than for the program to exit. That’s part of the reason why the functional error handling patterns are becoming so popular these days. They force you to handle errors and give you type-level info about how the program can fail.
I want my programs to fail fast in production too, because it makes it less likely that even bigger problems will arise. There are many problems that are much worse than a program crashing.
It depends on the program. You don't want your whole web server to crash because of a small error in one route. You probably don't want your CAD program to instantly crash and dump an error to the console because of a divide by zero in the constraints solver.
Though in some cases like that I think it might be appropriate to use `catch_unwind()`.
If you're writing something safety critical like avionics flight control software, you probably don't want to crash in production either. I've also always interpreted "fail fast" as "Make defects obvious during development so they don't exist when you deploy to customers."
So, on a micro-level, let's say I have a function that expects x to be a float between 0 and 1, and there's some math and logic built on this assumption. Of course, in development if this expectation is violated, we fail fast and loudly and then fix the problem. In production it's not quite so clear. But still, is it ever the right thing to ignore that an invariant is violated and just hope that things somehow work out?
> Make defects obvious during development so they don't exist when you deploy to customers.
I agree with this phrasing. From another viewpoint, I would say:
If your code checks an invariant, and that invariant is broken never (never!, not even in production) just continue on and hope that things will work out.
> But still, is it ever the right thing to ignore that an invariant is violated and just hope that things somehow work out?
Yes! Of course! In many situations it probably doesn't matter that the numbers go a little wrong, and that result will be better than crashing. In other situations it will be better to crash than to give junk results. As we already said, it depends on the situation.
I'm not sure that is something you can rely in general due to panic = abort, though to be fair that's more a concern for library developers since IIRC they don't control that particular setting.
That isn't possible. The assert may not even be produced in code you control.
The reason panics/exceptions exist is it is too onerous to handle every possible error condition at all callsites (allocation failure and broken pipes are the famous examples), and it is not possible to enumerate all possible error conditions (unintentional programmer errors for example).
People have religious ideas about handling panics for some reason.
The biggest "source" of vibes that CouchDB/PouchDB is "dead/maintenance mode" is the corporate ecosystem/contributors around it:
- Couchbase has been increasingly moving away from CouchDB compatibility
- Cloudant was one of the more active contributors until it got eaten by IBM and put into a maintenance spiral (what mother can love what IBM "Blue Mix" has done to Cloudant?)
- In general the still growing number of document DBs that are Mongo-compatible but not CouchDB-compatible (AWS and Azure document DB offerings, for instance)
In Open Source the winds of commercial favor aren't always reflective of Open Source contributor passion, but there too the pace of PouchDB seemed to greatly slow down a few years ago, and lost the interest of some major contributors. CouchDB itself seems to have gotten hugely stuck in a bunch of Apache committees over the design of the next semver major version, with a ton of huge breaking changes that don't really seem to be for solving problems but do some architecture battle under the hood, some political war between Erlang and other programming languages for superiority, and some political war between Apache trying to consolidate core functionality with some of the other database-like engines in their ~~graveyard~~ custodianship.
The return type of a function is an assertion. You’re saying that values of the type exist. The return value is an assertion about the arguments. You’re saying that they imply the result. The issue is that your code is incorrect, in a logic sense, if it states that for some given value the mathematical operation of division results in both an error and a number.
The issue is not one of usability or (direct) understandability, it’s an issue of correctness. Something like “well it works fine for me if I just remember to check if I receive both” or “everyone on my team understands that receiving both means an error occurred” just isn’t a valid response, it doesn’t address the problem.
