Ig Nobel is doing more for science than Nobel:

- It's fun.

- The prizes are accessible to young scientists who actually need the career boost from the publicity (as opposed to established scientists who are mostly boosting the prestige of the prize)

- They promote awareness of how diverse and awesome science is.

I've almost caved and bought bluetooth because most stores stopped stocking wired headphones above crap-grade. But maybe I can just wait this out, if wired really is making a comeback.

It's worse than relinquishing: you get a new voice, that of the person needs an LLM to talk.

I have similar reservations about code formatters: maybe I just haven't worked with a code base with enough terrible formatting, but I'm sad when programmers loose the little voice they have. Linters: cool; style guidelines: fine. I'm cool with both, but the idea that we need to strip every character of junk DNA from a codebase seems excessive.

On code-formatters, I don't think it's so clear-cut, but rather an "it depends".

For code that is meant to be an expression of programmers, meant to be art, then yes code formatters should be an optional tool in the artist's quiver.

For code that is meant to be functional, one of the business goals is uniformity such that the programmers working on the code can be replaced like cogs, such that there is no individuality or voice. In that regard, yes, code-formatters are good and voice is bad.

Similarly, an artist painting art should be free. An "artist" painting the "BUS" lines on a road should not take liberties, they should make it have the exact proportions and color of all the other "BUS" markings.

You can easily see this in the choices of languages. Haskell and lisp were made to express thought and beauty, and so they allow abstractions and give formatting freedom by default.

Go was made to try and make Googlers as cog-like and replaceable as possible, to minimize programmer voice and crush creativity and soul wherever possible, so formatting is deeply embedded in the language tooling and you're discouraged from building any truly beautiful abstractions.

The biggest problem I ran into without a code formatter is that team wasted a LOT of time arguing about style. Every single MR would have nitpicking about how many spaces to indent here and there, where to put the braces, etc. etc. ad nauseam. I don't particularly like the style we are enforcing but I love how much more efficient our review process is.

Personally I think a lot of programmers care way too much about consistency. It just doesn't matter that much if two files use indentation / braces slightly differently. In many cases, it just doesn't matter that much.

Problem is, development doesn't operate on the level of "files". The incremental currency of developers is changes, not files -- and those changes can be both smaller and larger than files. Would you rather see different indentation/braces in different files so that the changeset you're reviewing is consistent, or rather see different indentation/braces in the changeset so that the files being changed remain internally consistent? And what about refactorings where parts of code are moved between files? Should the copied lines be altered so they match the style of the target file?

Point being, "different indentation in different files" is never a realistic way of talking about code style. One way or another, it's always about different styles in the same code unit.

Indeed, it doesn’t matter too much, as long as it is consistent.

People running their own formatting or changes re-adding spaces, sorting attributes in xml tags, etc. All leading to churn. By codifying the formatting rules the formatting will always be the same and diffs will contain only the essence.

> > programmers care way too much about consistency.

> Indeed, it doesn’t matter too much, as long as it is consistent.

Um, I think you may have missed my point. Why does it always need to be consistent?

The problems you're talking about only show up when someone runs a formatter over the entire file. One answer is, just don't do that.

Also your eyes are good at seeing patterns. If the formatting is all consistent the patterns they see will be higher level, long functions unintuitive names, missing check for return success; make bad good look bad is the idea. Carefully reading every line is good but getting hints of things to check more deeply because it looks wrong to the eyes is extremely useful.

I now really want my city to employ local artists to redraw all the street markings.

Chaos, sure, but beautiful chaos.

I really like the street sign analogy.

But in my case it was the other way around. I work in a Kowloon Walled City of code: dozens of intersecting communities with thousands of informally organized but largely content contributors. It looks like chaos, but it works ok.

Code formatting really did feel like a new neighbor declaring "you know what this place needs, better-marked bus lanes!" as though that would help them see the sky from the bottom of an ally or fix the underlying sanitation issues. As you might imagine, the efforts didn't get far and mostly annoyed people.

But as the GP said, it all depends on the culture. If you pick up and move to Singapore you'd damn well better keep your car washed and your code style black.

The major reason auto-formatting became so dominant is source control. You haven't been through hell till you hit whitespace conflicts in a couple of hundred source files during a merge...

First time I saw this hell was when a junior colleague convinced a rather senior one to use black. Of course senior went bumbling around black-ing every file he touched, including some random thousand-line files in long-lived forks of an established code base. Those files became essentially unmergable from then on.

It was a confluence of a lot of bad design features and blunders and I can't blame the formatter for the mess it caused. So I understand your point but, I'd amend it a bit: version control is the reason many projects require a specific formatting style.

In projects without an explicit style, the number one formatting rule is don't reformat code you didn't touch.

Code formatting is a bit different though, at least if you're working in a team - it's not your code, it's shared, which changes some parameters.

One factor is "churn", that is, a code change that includes pure style changes in addition to other changes; it's distracting and noisy.

The other is consistency, if you're reading 10 files with 10 different code styles it's more difficult to read it.

But by all means, for your own projects, use your own code style.

I worked on a project where having code formatting used was massively useful. The project had 10k source files, many of them having several thousand lines, everything was C++ and good chunks of code were written brilliantly and the rest was at least easy to understand.

I mean, not sure if this makes sense? The creativity you put into code is about what it does (+ documentation, comments), not about how it’s formatted. I could care less how a programmer formatted their website’s code unless it’s, like, an ioccc submission.

Is the GIL implemented as a run-time option? I thought this feature had to be enabled at compile-time.

Python is interpreted not compiled so don’t see why not

No, they mean that CPython must be compiled with --disable-gil

I think Signal (the messenger) is an interesting example: by being free, open source, and privacy centered, there's automatically no room for ads and it's difficult to monetize. Also they have to be very careful adding new features for security reasons.

The result: very few features. Which is exactly what I want.

Yet it has one feature I love (schedule send) which WhatsApp doesn't have, despite adding countless features I do not like or actively avoid (AI, channels)

People don't like your company.

But they'd probably like you.

<3

What language will humans be reading in 10,000 years?

A blend of Spanish and some Portuguese, German and Italian words here and there and English borrowings for technology (with Romance adaptations too). Some kind of Neolatin. I would expect the Chinese being reformed with a simple alphabet a la Korean but with Japanese-like marks for tones.

With all these climate change and AI, will there be humans in 10k years?

Yep, on top of trees, fighting for real estate.

Pictures.

20 years ago, I thought Esperanto might be a thing, but nope. :)

Esperanto has succeeded to become the best known of the artificially-constructed languages.

Unfortunately, its creator had only modest knowledge of linguistics, so there are many features of Esperanto that can be considered as mistakes, and they have contributed to its little success.

Some of the artificial languages that have been designed later are much better than Esperanto, but they have achieved even less notoriety than it.

What has doomed all artificial languages, despite the fact that some of them would have been much better than English for international relations and for the publication of scientific and technical literature, has been the absolute dominance of USA over the entire world after the end of WWII.

This unbalanced relationship between USA and everyone else has forced the use of English both in commercial relations and in the scientific and technical publications, excluding all alternatives and replacing not only any artificial languages, but also the European languages that previously had been more important than English, i.e. German and French.

Does FB data count against your data quota in these countries? I've been quite a few places where it's impossible to buy a sim card that doesn't give you free facebook and WhatsApp.

You can't use the real internet without asking your friends to pay for it.

That was common, as was the FB lite app

Where do you get this from? From what I could see it applied to everything from cars to laptops.

From the press release itself:

"To that end, starting from 2025, the Regulation will gradually introduce declaration requirements, performance classes and maximum limits on the carbon footprint of electric vehicles, light means of transport (such as e-bikes and scooters) and rechargeable industrial batteries."

That's another aspect of the regulation but as far as I can tell (from skimming the actual mandate, or the other summaries I found of it) it's doing both. The release itself says

> Starting in 2027, consumers will be able to remove and replace the portable batteries in their electronic products at any time of the life cycle.

Interesting that it's also introducing limits on EV carbon footprints, but that's not to the exclusion of mandating replaceable phone batteries.

cutting out quite a bit from section 11:

    A portable battery shall be ... removable by the end-user ... with the use of commercially available tools, without requiring the use of specialised tools, unless provided free of charge with the product, proprietary tools, thermal energy, or solvents to disassemble the product.

    Any ... person that [markets] products incorporating portable batteries shall ensure that those products are accompanied with instructions ...

in other words you need to either make it easy and safe with standard tooling or include the tools people need.

Waterproof products are also specifically exempt.

EDIT: the "waterproof" requirement might leave less room for abuse than you'd think. It only extends to

    appliances specifically designed to operate primarily in an environment that is regularly subject to splashing water, water streams or water immersion, and that are intended to be washable or rinseable;

under this definition you could argue that an iPhone is not exempt, since it's not designed to operate primarily in water. How this is enforced seems to be mostly up to the various countries.

Thanks. So this is not going to lead to user-replaceable batteries on iPhones.

That seems a bit less clear to me. It seems to hinge on whether the courts believe that an iPhone is specifically designed to operate primarily in a wet environment.

Just iPhones sold in the UK then perhaps.

The UK is not in the EU.

>Waterproof products

Suddenly, all phones will be waterproof.

They also have to be intended primarily to be used in very wet environments and washable/rinseable. So unless someone found Atlantis they will have a relatively difficult time using that as an out.