real musicians don't build identities around instruments (i.e. don't call themselves pianist, violinist or singer).
(I say this as an aspiring C major pianist.)
28,665 karma · joined May 2, 2010
Interests:
* Rust
* Robots
* Machine Learning
* Cybersecurity
(I say this as an aspiring C major pianist.)
What would be examples of those "other places"?
What would be examples of the tip being part of the bill?
For me, if it IS on the bill it's a service fee and not a tip. If it's not on the bill, it's technically optional by definition regardless of social norms that'd make it practically mandatory.
15% to 20% as customary in the US is anything but "marginally more expensive".
Scylla is kind of Eurydice's dual. But also Charon and the eponymous Aeneas.
Also, "There is ongoing work to integrate Eurydice-generated code for both Microsoft and Google’s respective crypto libraries." [1] which I find incredibly cool. This link is also a brilliant intro to Eurydice.
If you want to learn more, Jasmine gave a good introductory talk about it last week at the Bevy meetup which is available on YouTube.
Compile time is not the main issue with static analysis. It's that C doesn't provide enough information and not the right information to make it efficient and effective.
If you add this info you unavoidably will end up with something looking like Rust.
(Whose long compile times are not caused by its static analysis parts BTW)
Can you chain these operations in a way that will propagate the error to the end result while simultaneously have a compiler produce code without branches after every operation. Safe integer operations alone are not enough for that.
My iTerm2 is configured to show activity, new-output and visual bell in the tab. On Linux I have an approximation for WezTerm.
I have a bell command that I can use in a pipeline or sequence to produce the bell on events I'm interested in. Trivial case is when a program finishes.
I have a fancy alias that can be used in a shell command sequence and which produces different sounds depending on the exit status of the preceding command in addition to sending the terminal bell.
The first is terribly inefficient, the second is just wrong (even if insanely common).
This is sad because there is no reason at all why integers couldn’t follow what OP calls the "float paradigm". It doesn’t even have to be slow. Most modern processors (if we ignore x86) support some form of sticky arithmetic flags. Unfortunately, programming languages don’t support them, so they aren’t used.
There is also something to be said about the special treatment division by zero gets.
In other words I want to spend 100% of my mental capacity in the problem domain for the things AI cannot do for me, like steering, grounding, verification and not for things AI could do.
Not only the intro. Many bloggers try to write as if they'd writing a story, building suspense and all. For technical writing, don't bury the lede.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
My parents were around the age of the children in the series during WW II in Germany and what they recounted matched how the children experienced the time pretty well.
If I have a sizeable amount of labeled data and need decisions calibrated to that data should I
1. Ignore the hype and train a traditional classifier
2. Finetune an LLM based decision model
3. Shoehorn (probably a small subset of) the data into the context of the LLM classifier somehow
If the answer is 3. where does the data belong? In the input content? Request wide state? In the question instructions? In the criteria? How much of my data can and should I use?
Absolutely.
"SO's upvote system and reputation system is what really refined quality."
Absolutely not!
SO's problem was exactly that they gave average users moderating power. That lead to half of the questions being closed because they were over the head of the average user/moderator regardless of being interesting and useful questions or not.
My point is that Unicode's own mission statement says: "The Unicode Consortium enables people around the world to use computers in any language."
I think it strayed from that. And I'd argue the mission was only ever fulfilled when seen through an anglospheric lens. You don't even have to summon Han Unification, the elephant in the room. Documents from Western Europe from a couple of decades ago can't be represented properly.
Example: you cannot properly represent a German telephone book today. Take "Müller" and the French surname "Haüy". Both contain the same Unicode character, but in "Müller" it is an umlaut and sorts like "ue" (Mueller), while in "Haüy" it is a trema and sorts like a plain u (Hauy). For all intents and purposes these are different letters. That they look similar (not the same, in proper typography) is a mere coincidence. Yet Unicode encodes them identically, so the information needed to sort correctly is simply not in the text anymore.
Han Unification is the other sore point, and a much bigger one.
I'd like Unicode to focus on its core mission, encoding the languages that exist, before it starts shaping new ones. For that I'd propose a grace period: a new character should have to be in significant active use for 10 to 20 years (not merely implemented on a popular device) before it is accepted into the standard.
There are nearly 300 living laureates. Enough to hold a yearly meetup for them in Lindau, where usually about 40 gather. This year, for the event's 75th anniversary, there were even about 70. Imagine that.
That's how Unicode started but nowadays Unicode expresses things that are only used because Unicode itself introduced them.
And this while many important things in the "have used text in history" category have been unfinished or not tackled at all.
Nowadays these implants must be quite common. At least I encounter people wearing ones regularly. If their life can get more convenient with an implantable version this is fantastic news.
It starts, rightfully, by pointing out risks to health and physical harm. It later goes into depth describing how automation (the nail gun example) has changed the game, and especially how dexterity is in much less demand than it used to be.
It fails to point out that the same automation has made most blue-collar jobs much safer. Where I live, the paragraphs from the beginning, where everyone knows someone with a serious injury, ring true from my childhood in the 70s and 80s, but not anymore.
That seems like an important part of the picture when comparing blue-collar work then and now.
I would argue that it is more productive for the enduser as well. Not making a decision they cannot reasonably make is better then blindly believing in a decision that is likely wrong for your usecase.
Both are kind of outside the Rust compiler's influence. Macros can be almost arbitrarily complex: you pay for what you order. Codegen is LLVM, and that's a fixed choice. You can use Cranelift to get around it, but then you pay elsewhere.
Also, generics and monomorphization regularly come up in these discussion, while common wisdom seems to be that cost for the additional static analysis over other languages like C++ is no a major contributor.
Regardless, it's nice to see performance improvements in the compiler, even if you have to cooperate to benefit from them (e.g. by keeping your macros light and use less generics).
The difference from the past is that the US has always been a melting pot, while China is pretty much a closed society. If you’d emigrated to the US, you always had a good chance of blending into that diverse society no matter where you came from. Assimilating into the homogeneous Chinese society will take generations.
For me it’ll be either the westernmost end of Europe or one of the better parts of South America, in the hope that they will prosper modestly in the shadows of the upcoming conflicts.
Unfortunately I don't remember the details. I'd be happy to learn I was right after all;-)