See, that's your problem. You don't throw a house party because you want to go to other house parties. You do that because and only because, you want to throw a house party.
I can understand how you'd read that I dont throw house parties from a single HN post. The greater context is I've tried variously over the past decade, spent 1000s on parties, and have found a recurring negative impact on my own well being because I outlay of my resources (mental, energetic, monetary) in a dissipative way that is not poured back into me. I am a zero sum being and so the cost to me is realistically taken away from other places I can maintain my own health, sanity, and other desirable outcomes.
Maybe the truth is I dont want to throw a house party -- I want the outcomes of a house party... Friends, community, being known, meeting someone who might become a friend/spouse, not being alone on isolating holidays (like thanksgiving / christmas / NYE) .
Yeah, that's one of those "tough pills to swallow". Everyone of course wants everything and they want to give up nothing. Prioritizing/triaging your own desires is a very tough skill to build, but if you can try to figure out "what do I want" and "what am I willing to trade to get what I want", you will probably find happiness in short order. If you genuinely don't want to spend the cash for a house party, don't do it. If you just want to run it cheaply, run it cheap: I recommend simple card games (Flip 7 is $10 and works with big groups) and some cheeeeeaaap potato chips, with water as the beverage (or ask people to bring their own whatever if they want). Tell them you're here to host games and chatting. Host, keep hosting, and get picky about who you invite back.
An empty loop, under some non-obvious conditions, on some compiler flags but not others, silently transforms into a system call. In a systems programming language.
Destructors run predictably at list, and are pervasive everywhere. You know that when you exit a scope, be that a function or whatever it may, the destructors of variables in that scope are called. That is clear and consistent. The transformation mentioned above is not.
Understanding the code requires understanding the destructors of the objects you're using. Since they are invisibly inserted, they are a source difficulty in entirely understanding the code.
I do wonder if any of the language servers that insert implied type annotations would ever also show things like destructor calls in a similar manner. It seems like it would be quite useful.
Since AFAIK I'm still the only person to write a correct C++ (C++98) compiler from preprocessor to object file, I know all about destructors.
Here's a fun one for your amusement:
foo(a, b, c);
The parameters are pass by value. a, b and c are objects that have destructors. Have a look at the code generated for that.
It is nice that the compiler does the dirty work for you, but the various paths with exceptions and recovery with invisible code may not be well tested.
In the context of that particular complaint, yes. From what I understand the gist of it is basically that you should be able to tell what is going on by looking at the code locally (i.e., the code is "explicit").
> I think Linus's complain was before there was a c++ standard.
These emails [0]? IIRC those are the most well-known ones and they are from the mid-2000s
> If you have formulas that actually match reality, what do you need the LLM for?
Because one could be in that state where they are trying to use a tech they know preciously little about to solve a problem they know nothing about.
This reminds me of a request we got from our "AI Department": if you build us a proper shares market simulator, we will build you an awesome agent that can trade shares. They seemed quite confused when I pointed out that if we could build such a simulator, we wouldn't need them anymore.
While I agree the extra CL games are not a great idea, they are not a very bad one either.
The Nations League is a good idea, for a number of reasons:
1. It gives smaller teams, like Gibraltar, Malta etc, a chance to play competitive football against teams their level and a chance to actually get better. In the old system, the only way for Gibraltar to play a competitive game, was to play in the Euro or WC qualifications, against the likes of Germany, Spain, England etc and get trashed. They can't get better if they have no chance to win.
2. Nations League brings money to the various FAs, a google search suggests anything between €750,000 to €10.5 million, as opposed to extracting money from the FAs.
3. The Nations League games replaced a bunch of friendlies. Now those games matter.
Not if you do the magic with getattr and comparison overrides.
You actually need to do it on the metaclass because the Field as I wrote it isn't an instance but this works:
from datetime import datetime
class Filter():
def __init__(self, name):
self.name = name
def __gt__(self, value):
return {
"field": self.name,
"operator": ">",
"value": value
}
class FieldMeta(type):
def __getattr__(cls, name):
return Filter(name)
class Field(metaclass=FieldMeta):
pass
print(Field.end > datetime(2024, 1, 1))
You can make python return arbitrary values for comparisons by overriding __gt__ (and lt, eq) on the first operand (which we control here since it is a Field class), it doesn't have to be a bool.
Edit:
You can even make a little adapter to use this with the current filter system if you really want to:
from datetime import datetime
class Filter():
def __init__(self, name):
self.name = name
def __gt__(self, value):
return {
"field": self.name,
"operator": "gt",
"value": value
}
def __lt__(self, value):
return {
"field": self.name,
"operator": "lt",
"value": value
}
def __eq__(self, value):
return {
"field": self.name,
"operator": "eq",
"value": value
}
class FieldMeta(type):
def __getattr__(cls, name):
return Filter(name)
class Field(metaclass=FieldMeta):
pass
def _(*args):
kwargs = {}
for arg in args:
k = arg["field"] + "__" + arg["operator"]
kwargs[k] = arg["value"]
return kwargs
def filter(**kwargs):
for k, v in kwargs.items():
print(f"{k} = {v}")
filter(**_(Field.end > datetime(2024, 1, 1)))
That's a well established pattern in Python, for instance with Numpy. That's the point. Operations in Python aren't "mean to return" anything in particular. Each class can define the operations as it wants. That's a powerful feature that allows creation of specialized expression languages, as used by other ORMs besides Django.
Yeah, but that's different from the operator. It's a different way of thinking about it. Maybe that's the reason they used dou le underscores for everything, to keep it consistent.
Not really. Both method calls and operators are consistent with how Python normally works. Outside of Django you never do `obj__op(value)` or `obj__meth(value)` to do the equivalent of `obj op value` or `obj.meth(value)`. It is Django that is inconsistent with how operations are done in Python.
No it won't, because there's no requirement that the result of `>` be True or False. It can return an object that then can participate in further expressions that "keep track" of what operations are done to the fields.
See, that's your problem. You don't throw a house party because you want to go to other house parties. You do that because and only because, you want to throw a house party.