> And it’s not just a Trump or Republican thing either. For example crime stats in blue cities ...
Trying to "both sides" dismantling oceanographic science by equivocating it with "blue cities often tell a misleading story" is disingenuous at best and can easily be interpreted as deceitful by a reasonable person.
Oil prices are indeed determined by the expected future cost, including expected future reserves, and not only current reserves. Futures expiries extend quite far. Where does your short term reserves claim come from? Genuinely interested.
Regarding 118, this is about probability. Given we're at 96 and backwardated? What is the probability that we hit 150?
> Where does your short term reserves claim come from? Genuinely interested.
Familial experience in one of the major US energy (oil) corporations headquartered in east Texas.
> Regarding 118, this is about probability. Given we're at 96 and backwardated?
The 118 peaks are separated by 4 weeks and the local minima of 92 from a week ago has already risen to almost 98 as of 6/3 close-of-business. This does not support a backwardation trend and, instead, could be reasonably identified as the beginning of another spike.
> What is the probability that we hit 150?
This is a question energy executives must answer. Fortunately, one did:
The price of physical Brent oil cargoes will spike to $150
to $160 per barrel when inventories hit all-time lows in
coming weeks, the executive said. “When the price gets to a
certain level, demand destruction brings it back into
balance,” he said.[0]
> So what do you think the true reason is that the market is so backwardated?
It is not.
The only way to support a backwardation claim is to ignore the 24 months of pre-war market behavior. If analysis is limited to the last three calendar weeks, then the local minima might be called a backwardation.
Problem is, there are no geopolitical, market demand, and/or military indicators to support this point in time being an actual backwardation.
On a random day last month there where 17 commits, and commits happen daily by the same author. It’s true dedication.
Browsing through them requires understanding / translating Slovenian. Translation has never been cheaper, just recently the author has switched to English.
When I started development on the language, my English knowledge wasn't that great, so I preferred writing commits in Russian, but using Latin alphabet instead of Cyrillic to avoid changing keyboard layout (I hate doing this).
The conclusion was made by Deepl auto translate based on a random commit. Perhaps due to the use of Latin characters the ai was derailed, which is entertaining to see
My concern is not the number of years, but instead the number of commits. It implies linguistic volatility and a lack of a coherent design and/or vision.
Where is the rationale which explains the voluminous number of commits?
Something is wrong with that commit count. There are a total of ~4k commits over nine years [1].
It looks like the author revived the project recently with the help of AI, but the majority of commits are from 2017-2024. Github might be counting all the branch activity from agents.
From the description of the graph you kindly provided:
Contributions per week to master, line counts have been
omitted because commit count exceeds 10,000.
So I am confused as to the "total of ~4k commits over nine years" determination, unless this is in reference to commits Panzerschrek has made spanning the last two years (not nine).
I could swear it showed 4k commits for the "All" timeline. Probably a UI fluke. Wrong on both counts anyway, see author's comment! Either way, over 8-9 years that's not an abnormal pace.
No LLMs and "agents" were involved. All code is written by hand. In past several years I have had a lot of time for developing Ü, since I have quit my day-job.
I got that impression from the volume of english comments in the recent commits, vs russian commit messages, and the massive amount of feature branches. That's impressive dedication.
> Does it automatically filter my email into tabs for primary, promotions, social, and updates?
This is where email MUAs[0] shine. Mail user agents such as Thunderbird[1], KMail[2], Apple Mail[3], and nmh[4] (for hard-core Unix command-line aficionados) support filtering and automatic categorization to varying degrees.
I've tried Thunderbird, Kmail, and Apple's client, and maybe I just have too many emails, but these apps completely crumble under my inbox. I don't see any "shine" with these third-party clients. Mimestream, my favorite email client on macOS, "just works" because it uses the Gmail API. It seems like Fastmail made JMAP, but this doesn't seem widely supported.
Are there mail clients that actually support things like priority inbox and categorization that don't simply crumble for large inboxes?
> Are there mail clients that actually support things like priority inbox and categorization that don't simply crumble for large inboxes?
Of the exemplars listed, nmh is by far the most flexible and capable of handling large inboxes. The reason why is that it is a set of command-line executables which can be scripted with whatever language you prefer. So prioritization and/or categorization is a matter of how one wants each to be defined.
I used IMAP via fetchmail[0] with nmh to allow multiple MUAs (on different machines and/or OSs) access/management to the same email accounts with great success. IIRC, for nmh I used lynx to render HTML messages and xview to display image attachments. Other attachments were processed separately but had similar workflows.
Thunderbird does not seem to have auto-categorization from what I see, just filtering. Neither does KMail. Unless you’re referring to some addons? For apple mail you have to add it on each client. And a lot of comments are about how to disable it because it categorizes wrong.
Frankly I've tried quite a few clients and haven't found one I can settle for. I used Mailspring for a while because it was close to being a gmail experience, but that went some kind of bad way I don't remember and I don't think is developed anymore.
I want a client that is simple but flexible by default, extensible, themeable would be nice, and for the love of god has key shortcuts for everything THAT CAN BE CHANGED. LOOKING AT YOU, THUNDERBIRD.
Thunderbird is almost usable for me, but the UI is just absolutely abysmal. The kicker is not being able to change key shortcuts, making Thunderbird unusable for me.
> Can we have Exception monads? Asking for friend.
This is nonsensical. Monads define a strict set of behaviors formalized as "monad laws"[0].
Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions. Two exemplars of same are Haskell's Data.Either[1] and Scala's Either[2].
I don't think it's nonsensical, it's just another name for the same thing. E.g. in the Haskell wiki it says, "the Error monad, also called the Exception monad".
I was unaware of "Exception monad" being an industry equivalent term for Either/Error. Given no other context, desiring an "Exception monad" could be interpreted as "a type which handles raising Exception types." Which is how I did.
Was a desire to have "a type which handles raising Exception types." Until now, I was unaware of "Exception monad" being an alternate moniker for Either/Error types.
> Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science.
No contributor to Go is responsible for "introducing monads to computer science", as the Monad concept is a member of (or defined by if you prefer) Category Theory[0].
As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science. The paper usually credited with that is: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b... Which the parent rightfully points out was written by the same person primarily responsible for the design of generics in Go: https://homepages.inf.ed.ac.uk/wadler/topics/go.html
> As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science.
With full respect given to Wadler and his contributions to computer science, the very paper you cite authored by Wadler declares:
The concept of a monad, which arises from category theory,
has been applied by Moggi to structure the denotational
semantics of programming languages.
Therefore, one cannot assert that a computer scientist whom identifies a predecessor's contributions such as above is, in fact, responsible for said contributions.
And with full respect also given to Moggi, introductions are only introductions if they are heard.
If we were talking about the first person to discover monads, Wadler clearly would not be he. Wadler was but a wee toddler barely sputtering out his first words when the term "monad" was coined. As we are talking about who introduced monads to computer science, the signs I see continue to point to Wadler. His work is, by all appearances, what caught the attention of the computer science community. "Monads for functional programming" is regularly cited as the seminal paper. They are strongly associated with Haskell. It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.
If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.
> If we were talking about the first person to discover monads, Wadler clearly would not be he.
We are not. Remember what the OP stated, to which I originally replied:
Funnily enough, Go's generics were designed by the same guy
who introduced monads to computer science.
This is demonstrably incorrect, as Wadler did not "introduce monads to computer science" and is what I disagreed with alone.
Did Wadler take monads to new and important levels in both computer science and software engineering? Absolutely!
> It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.
I quoted the Moggi attribution due to it being present in the paper you kindly provided. Whether Moggi has any influence socially is irrelevant as it pertains to the original thesis discussed above.
> If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.
Again, this is not germane to the aforementioned OP statement.
Moggi's social influence is everything as introductions can only happen in the social realm. It continues that all evidence I can find suggests that his work went unnoticed until Wadler pushed it into view. In other words, people came to learn about his work only because of Wadler making the introduction. Nobody, except where one may find it trying to be implied in https://news.ycombinator.com/item?id=48304692, has suggested Wadler invented monads. The OP clearly wrote "introduced", not "invented".
In 2019 I wrote a short survey of C constructs that do not
work in C++. The point was not that C is sloppy or that C++
is superior. The point was that C++ is not a superset of C,
and that C programmers crossing the border should know
where the checkpoints are.
C++ was a superset of C 30-ish years ago. Now, as the author correctly identifies, it is not as both have taken different evolutionary paths.
30 years ago, in C89 and pre-standard C++, it was the case that `int foo()` in C is a function that accepts any parameters, and in C++ it is a function with no parameters. In C89 you have to write `int foo(void)` if you want no parameters. This counterexample to C++ being a superset of C was well-known even back then.
Another well-known counterexample is implicit conversion from void*. In C89 you can do `int* foo = malloc(100);` but in C++ it requires an explicit cast from void* to int*.
I don't believe there was ever a time, even pre-standardization, when C++ was a strict superset of C; it always had little incompatibilities here and there.
> Their usage of upsert appears different than I was used to:
> Them: Upsert = Get or Insert
I agree that their choice of labeling the proposal as "upsert" is less than ideal. However, this functionality is reminiscent of a very useful Perl capability known as autovivification[0] as described in the motivation section:
A common problem when using a Map or WeakMap is how to
handle doing an update when you're not sure if the key
already exists in the map.
> Yes, where would I be without the _RelationshipBackPopulatesArgument type of ...
(proceeds to list a signature with over 40 parameters)
You would be left wondering which of the 40+ arguments provided to a given invocation is not what was allowed without a compiler to tell you.
Have fun tracking down which one, or ones, is causing the problem.
reply