It seems perfectly plausible to me that the economic incentives are such that there is no need to "design" any of this, no smoke-filled back room needed.
Economic incentives never point in just one direction. There’s always tradeoffs around time horizons, risks, etc which is where individual people’s decisions come into play.
Should we subsidize industry X is rarely a question decided on economic merits alone. And so it goes with individual interests shaping the entire global economy in surprisingly profound ways. Extreme ultraviolet lithography for example shapes industries, but has a history steeped in various public/private partnerships and global politics.
What?! That statement is self contradictory. If you have economic incentives then somebody or a group of people put those incentives into place in order to reach a desired outcome(typically accumulation of wealth and/or power for a target group).
We're not talking about facts of nature like gravity or the speed of light. You don't exist in a truly random system but one where you're playing by the rules made by someone else, rules that can change on a whim, as the government intervenes at every level to manipulate the scales, for better and for worse, resulting in it picking winners and loosers.
I wonder why round-trip is such a small concern for people implementing serializers/deserializers of various kinds.
I usually throw in an "Unknown" node type, which stores things unaltered until I can understand things again. The parsers I usually write are very small, so I haven't seen what issues comes up at scale, maybe there are dragons lurking .
Yes, and there are probably a lot of other clever ideas. But the better solution is probably just to implement more of the spec. Once you get through maybe 80% of the tags, you've eliminated 99.9% of the memory issue given their frequency distribution.
That is what mise from the same author is for. It lets you define per-project sets of tools with specific versions (including languages). I find it quite useful and I'm planning to get my team at work to adopt it once I get some round tuits.
No, in logic that is a vacuous truth.
All my hats is true for zero hats. But that would not be a lie. And since the liar always lies, that can not be case.
For me, this is one of those types of examples that illustrates the problem with logics allowing vacuous truth.
It amounts to an assumption of an implied conditional ("If I have hats...") which is not always warranted. The "gotcha" here says more about the vacuous truth assumption than it does someone who falls for it.
I think it is very logical to allow for vacuous truths. Doing otherwise would not be logical. The actual key insight is to accept that in a lot of cases everyday communication itself is not logical, because it is more efficient to communicate skipping always being logically correct. This builds social intuition that goes against the logic. It is interesting to observe and point out those cases, which this puzzle does.
Because for efficiency reasons you make a lot of assumptions constantly that may or may not be true, and 99% cases it would work for your favour.
Sometimes assumptions need to be challenged or we need to be reminded of that it can be good to challenge assumptions in certain cases, it can allow us to discover some new things.
> I think it is very logical to allow for vacuous truths. Doing otherwise would not be logical.
I guess I disagree, although I don't mean that disrespectfully. Vacuous truth is one reason why nonclassical logics exist. The wikipedia article gives a good example of how allowing for vacuous truth can lead to absurdities: "All my children are goats" said by someone without children. This is a statement that is vacuously true technically, but (assuming laws of biology hold, and a human is making the statement), it is something that could never be true even if the antecedent ("I have children") were true. It's not just something playing on incorrect intuition, it's a statement that is true only by convention or a certain line of reasoning that to me is made only out of convenience because of certain implications.
It stretches the definition of "true" so far that the term "vacuous truth" no longer means "truth" in the general sense in which it is understood. It plays on the use of the term "truth" more than anything else to me; one could redefine "vacuously true" statements as "vacuous" statements in the sense of "undefined" and then the "gotcha" would no longer apply.
I think the example also captures a sort of flaw in applying classical logic (at least classical logic with vacuous statements) to everyday speech in another way that I don't think is just incorrect intuition. If someone asserts "All my hats are green", it's understood to be an assertion that the speaker does in fact have hats, otherwise there would be no point in structuring the statement as it is. That is, the statement is evaluated as true or false with reference to the antecedent because it (the antecedent itself) exists, and another, different statement could have been made. Classical logic evaluates the statement "All my hats are green" as if it were the same as "If I had hats, all my hats would be green" — but they are not the same statement, they have different meanings. There's a counterfactual possibility in natural language, which I think requires nonclassical logic.
Thank you for taking the time to write this. I don't have any formal training in the field but it matches my intuition and I am surprised, astonished even, to see this explanation so far down.
i think its relevant that the liar has to say false things, which is more limited than just not-true things.
if you dont assume the vacuous truth, and instead leave it undefined, then when hes got no hats, "all my hats are green" is absurd, rather than false.
the gotcha only stops applying when you put a vacuous false, rather than true or undefined.
is this really a flaw in applying classical logic? with the vacuous true, the only information you get from "all my hats are green" being false is that they have at least a hat, same as the intuitive result
Yes. So we will apply logic, but assume the people making the statements are otherwise ordinary people and do not do strange things like defining ‘all’ to include ’none’.
Let's say that saying 'all my hats' implies that the set of hats is non empty, then you have the two following statements
my-hats is not empty
for every hat in my-hats, is-green(hat) is true
We know that the speaker always lies, so both statements must be false: my-hats must be empty, and it must be that it exists at least one hat in my-hat that is not green. This is a contradiction. So either the speaker or the puzzle is not consistent (and uninteresting), or the 'my-hats is not empty' is not a valid assumption.
I was initially thinking that, but you can parse it as one statement "my-hats is not empty AND for every hat in my-hats, is-green(hat) is true", in which case it's still consistent for that single statement to be false, and it can be false by my-hats being empty.
He said 'all my hats are green' either that statement is to be interpreted to require that the set of hats is not empty or it isn't. In the first case that interpretation would be part of the statement he made.
This person‘s argument hinges on trying to make two statements rather than one, I’ll illustrate with a quote:
> We know that the speaker always lies, so both statements must be false: my-hats must be empty, and it must be that it exists at least one hat in my-hat that is not green.
No. Since it is one statement as written, and the rules of common logic are not created by the liar, as I said up in the thread, either possibility is true. The person may have no hats or have one hat that is not green.
One of the points of this puzzle is to see beyond your social intuition. So yes, this puzzle plays on being able to figure out the logic while it goes against common social intuition.
True, but "programmer's intuition" is because most programming languages are more or less based on formal logic so they agree with the formal logic interpretation even if many programmers have never studied formal logic.
"More or less" is the key and the rub. The specific semantics must be determined and utilized in place.
For me, the evaluation of the empty set should have separate semantics than that for how a non-empty set's elements are logically combined to produce a value.
This is the result of doing stats programming for grad students, doing lots of database design and programming, and lots of regular programming in imperative and functional languages.
The key is that we are always working within a context, and this problem's context involves both formal logic and regular old language. And, whew!, is there a disconnect and interference pattern.
The best I've found are languages like F# that allow you to return a pair of values, which for your example would be a tuple of (bool, bool), where the first is isError and the second is the evalResult. Of course, you better not mix `em up!
As to paradigms, I've not seen anything yet, but I haven't seen it all, and corporate America has their legacy systems that limit their explorations.
For years, "self-hosting" Gitea wasn't done because it was missing a bunch of useful collaboration features. Now, it looks like that gap has been closed. All of the specific features mentioned in that issue seem to have been fixed, and the big remaining task is figuring out below to actually migrate all the existing data out of GitHub -- which doesn't seem to be super high on the priority list.
I used to have lucid dreams regularly until I was 17, until I told a friend and never had a "real" one since. I am not sure if it is connected.
I mostly used it to avoid nightmares as a child, unfortunately after a while, I got psychological nightmares instead. Waking up multiple times within a dream (There is no Limbo from Inception for me) with something really stressful having happened (dead body under the bed and police knocking on the door, it's just a dream there are no police, but the body is there, type stuff).
I still have partially aware lucid-dreams occationally.
> These include statements before super(…), which would give developers greater freedom in expressing constructor behavior – meaning string templates. This would make it easy to express strings that include values computed at run time – meaning scoped values. This would enable sharing of immutable data within and across threads; and implicitly declared classes and instance main methods.
I don't like the restriction on code before super. But I don't have a clue what they are referring to here. The code example doesn't use a template either.
PositiveBigInteger(long value) {
if (value <= 0)
new IllegalArgumentException("non-positive value");
super(value);
}
Once you call super, you invoke the base constructor. This can cause issues beca not all fields in the sub class has been set yet. Setting the fields before calling super prevents this issue.
Trivial method calls such as „toString“ can already cause issues and it’s worse once you want to guarantee certain value types properties.
The intention for "nothing before super" is clear, but that rule never delivered on its promises. Because all those footguns are still in place, in field initializers as well as in function calls inside the super() argument list:
class Sub extends Super {
int field = footgunA();
Sub() {
super(footgunB());
}
}
It's a zero merit headache factory and good intentions alone cannot change that.
I should have checked instead of replying from memory: It's actually footgunB that is refused by the compiler. footgunA is accepted and will even call happily into an overridden implementation from a field initializer in the superclass. That way you can get a method to see a final field null on one call and non-null on the next.
That paragraph appears to be plagiarized from an Infoworld article [0] but with nonsensical changes to the punctuation (e.g. some of its semicolons changed to "– meaning"), which is why it makes no sense.
I agree that the wording of that was really weird. String templates aren't really the first thing that comes to mind when thinking of "freedom in expressing constructor behaviour".
I am not a mathematician but have some interest on a pop-sci level.
I believe this presentation at G-Research by Alex Davies would be of interest.
https://www.youtube.com/watch?v=Mp_skPK-X9M
