DavidVoid

I wish more books would come in the same format as the Macmillan Collector's Library series of books. They're tiny hardback books with thin pages. I just checked my copy of Moby Dick, it's about 770 pages, but the book has a very pocket-able size of just 15.6×10×3.5 cm (6.2×4×1.4").

Seems to be run by a married couple of (maybe) burnt out account managers. That, in combination with some AI help, explains the empty "LinkedIn slop" writing style I think.

It's not often I comment on blog posts, but this is honestly one of the most meaningless blogs I've ever read (not counting those fully AI-generated SEO ones). I don't get why it ended up so high on Hacker News; it has an interesting title I guess, but pretty much no substance.

The game Overwatch is a pretty great contemporary example of this [1]. It has some excellent fluid animations, which look really weird if you freeze frame them.

[1]: https://youtu.be/vIdeGmN__Pw?t=550

I don't think GPUs ever had branch prediction in the first place. You can however run into poor performance due to thread divergence, which is a similar kind of issue (with much less black magic).

Yes. I'm sure it would feel nice to pay off my apartment loan, but the interest rate on that is 2.75%, which is way lower than what I can (reasonably) expect to make on the stock market.

> Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifying not only that tests pass but that code conforms to the spec. This specification, and not the code that materializes it, is what the team would need to understand, review, and be held accountable for.

This just sounds like typical requirements management software (IBM DOORS for example, which has been around since the 90s).

It's kind of funny how AI evangelists keep re-discovering the need for work methods and systems that have existed for decades.

When I worked as a software developer at a big telecom company and I had no say in what the software was supposed to do, that was up to the software design people--they were the ones responsible for designing the software and defining all the requirements--I was just responsible for implementing that behavior in code.

A couple of quotes from one of the employed baristas (translated from a Swedish local news article) [1].

"I'm worried every time there's a delivery, I never know what she's ordered."

"I like it. At the interview, Mona didn't care that I have dialect or I don't have a doctorate. For her, the most important thing was that I was nice and could make coffee."

If he has learned something from the experiment, it is that it is the middle managers and all CEOs who are at risk of being replaced by AI – not the baristas.

"Without me here, it would have been difficult for Mona."

[1] https://www.mitti.se/nyheter/ai-driver-eget-kafe-i-vasastan-...

I don't think so. The cafe is a real place and it's owned by the company mentioned in the article. It was in the local news the other week [1].

If you're going to do an experiment like this, then Stockholm is a good place to do it, since the bureaucracy here is very digitalized.

[1]: https://www.mitti.se/nyheter/ai-driver-eget-kafe-i-vasastan-...

Considering the size (and significance) of the VSCode user base, it feels like someone should be in charge of ensuring that default behavior doesn't change without good reason.

Does anyone (or any team) have ownership of the extensions/git/package.json file?

See also: the distinct shape of the flap and landing gear levers (which are often located next to each other).

https://aviation.stackexchange.com/questions/22680/why-is-th...

How do you read a number like 17? "seventeen", small endian.

Language is messy, some more than others [1].

[1]: https://en.wikipedia.org/wiki/Danish_language#Numerals

There's an old German short film called Nicht löschbares Feuer (Inextinguishable Fire, 1969)[1] that I'm fond of. It was a protest film against Napalm and how some companies wouldn't really let their employees know what they were actually working on.

"I am a worker and I work in a vacuum cleaner factory. My wife could use a vacuum cleaner. That's why everyday I pick up a piece. At home I try to assemble the vacuum cleaner. But however I try, it always becomes a sub-machine gun.

...

This vacuum cleaner can become a useful weapon. This sub-machine gun can become a useful household appliance.

What we produce it depends on the workers, students, and engineers."

That last line is still very relevant today.

[1] https://www.youtube.com/watch?v=EnpLS4ct2mM

I like em dashes—and sometimes overuse them—but 37 times is absurd in that amount of text.

I would go even further and state that "you should never assume that floating point functions will evaluate the same on two different computers, or even on two different versions of the same application", as the results of floating point evaluations can differ depending on platform, compiler optimizations, compilation-flags, run-time FPU environment (rounding mode, &c.), and even memory alignment of run-time data.

There's a C++26 paper about compile time math optimizations with a good overview and discussion about some of these issues [P1383]. The paper explicitly states:

1. It is acceptable for evaluation of mathematical functions to differ between translation time and runtime.

2. It is acceptable for constant evaluation of mathematical functions to differ between platforms.

So C++ has very much accepted the fact that floating point functions should not be presumed to give identical results in all circumstances.

Now, it is of course possible to ensure that floating point-related functions give identical results on all your target machines, but it's usually not worth the hassle.

[P1383]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p13...

Unless you compile with fast-math ofc, because then the compiler will assume that NaN never occurs in the program.

It's already eroded in many countries right? Gendered patronymic names used to be common here in Sweden - Katarina Gustavsdotter (Vasa) was the daughter of Gusav Eriksson (Vasa), who was the son of Erik Johansson (Vasa), &c. - but gendered patronymic names eventually became permanent last names that got inherited over multiple generations.

So now we have a few hundred thousand people with the last name Andersson, despite most of them not being Anders's son.

> Digital payments are very convenient and deeply integrated, so long as you have a local ID which allows you use the local payment system Swish etc.

Just to reiterate how ubiquitous Swish and BankID are here: 99.9% of Swedish residents age 18-67 have BankID (8.6M users), while Swish has 8.7M private users, and 93% of those users send or receive money via Swish at least once per month.

I'm in Sweden and the only time I've ever come in contact with a check was when an American company sent me one as a refund.

Most of these reasons just sound like fee-issues to me. I use a debit card (or Swish) to pay for everything and there's never a cheaper payment option. The fact that checks somehow cost less to use than debit/credit cards sounds ridiculous tbh, especially with all the added handling that must go into dealing with them (it just seems so inefficient).

That is partially why the banks/government in Sweden have been happy to phase it out. Companies also don't like dealing with cash because it requires extra accounting, security, and transportation. In the early 2000s there were about 50 cash transport robberies per year in Sweden, in 2018 there was 1.

Swedbank offers debit cards to kids as young as seven [1]. Depending on the kid's age (and what the parents configure), there will be different limits on how much the kid can spend.

Swish is the de facto standard for sending money between individuals [2], and that's what grandparents tend to use to send money to their grandchildren. It's fee-less (for person-to-person transfers use at least) and it connects your bank account with your phone number. So if anyone wants to send you money, they can just open Swish and enter your phone number (or scan a QR code) and send you some. You also have to sign the payment with the BankID app, which is the de facto standard for authentication [3].

And when I write de facto standard I really mean it. 99.9% of Swedish residents age 18-67 have BankID (8.6M users), while Swish has 8.7M private users (93% of which use Swish at least once per month).

[1] https://www.swedbank.se/privat/kort/bankkort/bankkort-master...

[2] https://en.wikipedia.org/wiki/Swish_(payment)

[3] https://en.wikipedia.org/wiki/BankID_(Sweden)

This is also partially due to hacking incidents in recent years. In 2021, all 800 Coop grocery stores were closed for a few days due to the Kaseya VSA ransomware attack [1].

[1]: https://en.wikipedia.org/wiki/Kaseya_VSA_ransomware_attack

And a lot of the time it makes the syntax more compact than it would be with 0-indexing.

  for i=1,#arr do
    foo(arr[i])
  end

I don't feel that strongly for or against either way of indexing though, they both have their pros and cons.

I don't see how kilowatts would be more sensible than kilowatt-hours here, especially since the power output might not be consistent.

See also, "Power is not Energy": https://youtu.be/OOK5xkFijPc

Despite being written in 2009, it certainly still feels relevant.

And thank you for posting this, because it made me think of Sir Noël Coward's banger song "There are bad times just around the corner" (1952) [1], which I hadn't listened to in years.

  There are bad times just around the corner  
  There are dark clouds hurtling through the sky  
  And it's no good whining  
  About a silver lining  
  For we know from experience that they won't roll by  

[1]: https://www.youtube.com/watch?v=khEmMfMVsv4

Ran into the same thing. Changing to a non-default DNS fixed it.

> the algorithm will wrongfully report "false" for arrays like e.g. [INT_MIN, -1]

If you have INT_MIN along with any other negative number in the array then your program has undefined behavior in C. Signed integer overflow is UB (but unsigned overflow is not).

Man I hate when sites hijack the page up/down keys.

There is indeed; Watts aren't energy, and it's a common enough mistake that Technology Connections made a pretty good 52 minute video about it the other month [1].

[1]: https://www.youtube.com/watch?v=OOK5xkFijPc

This just makes me want to get back into learning stenography again. It requires a hell of a lot of practice, but being able to write at 200 WPM (without frantic finger movement) would be quite nice.

Here's a demo/explainer at 200 WPM for example: https://www.youtube.com/watch?v=7jVXrX5TDk4

It matters for reproducibility between software versions, right?

I work in audio software and we have some comparison tests that compare the audio output of a chain of audio effects with a previous result. If we make some small refactoring of the code and the compiler decides to re-organize the arithmetic operations then we might suddenly get a slightly different output. So of course we disable fast-math.

One thing we do enable though, is flushing denormals to zero. That is predictable behavior and it saves some execution time.