I really resonated with the link to the MacUser article on word searches.

> Word Search will generate and print the sort of word puzzles where you have to look forwards, backwards and diagonally to Find a given set of words. Even though you can only dis¬ play and solve a puzzle of 32 X 16 on your screen, larger puzzles can be created for printing. To give you an example of what can be done with the program, a set of 10 puzzles including states, mouths and composers are on the disk.

It later goes on to describe something I've personally experienced.

> And printing seems to take a while, but when others sit and fuss over your creation, you’ll say the wail was worth it.

Over the last couple of years I've been working on a side project involving mazes and also... word searches! Last Christmas I printed off a bunch of Christmas themed word searches I generated for the family to play on Christmas day. Seeing real people have real fun with something I created felt like remembering what programming was supposed to be about – bringing actual joy to people, instead of adding another forgettable feature to some product manager's roadmap.

I posted it to HN at the time, but I have a small writeup of it here. https://www.lloydatkinson.net/posts/2024/year-in-review/#-wo...

I can’t believe such hyperbolic fantasies are on HN now too.

WhatsApp used to (still might) default to saving all photos from any chat to your phone. This led to some very surprising and unwanted photos being saved to my iPhone gallery. What a stupid idea.

I think it’s off by default and you can activate it separately for each discussion.

How can people publish articles like this and not even show some type of mockup of what it might look like?

My problem with traditional media. It's like they get the basic concept of an article but don't focus on the learning/teaching aspect.

Yes, its frustrating. Just like how they never give links to papers, websites, demos, videos, or anything either.

IS there the complete C# available for this? I looked over the original paper and it's just snippets.

This is still some code, as opposed to no code. It does seem to model everything in the research paper.

Aside from the original research paper needing to be included in the repo, it definitely does not need anything more than what's already there. It all builds and compiles without errors, only 2 warnings for the library proper and 6 warnings for the test project. Oh and it comes with a unit testing project: 59 tests written that covers about 73% of the library code. Only 2 tests failed.

Even having a unit testing library means it beats out like 50% of all repos you see on GitHub.

Blame Microsoft Research, as the link came directly from them: https://www.microsoft.com/en-us/research/project/uncertainty.... I don't think they ever really took the project past the initial paper/presentation.

Sometimes things can just be "done", and the paper is pretty good documentation if the implementation is faithful to what is described there.

They deleted their own post?

It couldn’t possibly be because AWS execs were pissed or anything… /s

Archived blog post: https://web.archive.org/web/20240719152109/https://www.prime...

I seem to remember Spotify causing big problems because of this

One day I’ll understand why some websites refuse to have a way of navigating to the home page. I had to edit the URL in the address bar.

I just wanted to find out what GMP is.

The better question is, why isn't your browser providing that feature? Or why is it making it incredibly hard to edit URLs in case you are using a mobile browser?

arbitrary-precision/bignum library

This was a really fascinating read.

The moronic Web Component cabal got their hands on it and trashed it by forcing it to rely on JavaScript, thus ensuring it would never get support.

I'm sorry, this a dumb comment that has no basis in reality.

HTML Imports was part of the initial set of the web components specs, there's no "cabal" or whatever that got its hands on it, and it didn't rely on JavaScript, not in the way you're probably referring to.

It was only opposed because it was separate from the JS module system, not because it relied on JS.

It's replacement: The HTML Modules proposal has general support from all vendors, just no one has put together a complete proposal yet.

It was rejected because it needed JS to even work.

This is simply not true, both in how it worked and why it was rejected.

HTML Imports didn't need JS to work: they used link tags and could transitively import HTML files without any JS.

You only needed JS because the wasn't anything you could do with the HTML yet because declarative custom elements don't exist yet.

HTML Imports were rejected because they created a parallel module graph to the JS module graph.

I think they could have been made to share the same graph, but that's basically what HTML modules are anyway.

For a long time web components generally built on four standards:

  - Custom HTML elements
  - Shadow DOM
  - HTML imports
  - HTML templates

https://korban.net/posts/elm/2018-09-17-introduction-custom-...

Eventually it became clear some browsers were not going to implement and the design of HTML imports was better handled be ES modules.

https://webmasters.stackexchange.com/questions/127482/on-wha...

Found this, it should answer your complaints:

> HTML Imports were redundant, since you need JavaScript to bring them alive anyways

Exactly. I think the problem wasn't that browsers (specifically Firefox and Safari) were opposed to the idea of html includes in general, but they didn't like the specific proposal, in large part because it still required javascript, and added a lot of complexity for little to no benefit.

I think rejecting that proposal was the right thing to do. What disappoints me is that there hasn't been a more declaritive, simpler proposal that has gotten anywhere.

HTML Imports and HTML includes are two different ideas. HTML Imports was never like what people want from HTML includes.

HTML Imports were shelved because they didn't integrate with the JS module graph. HTML Modules will do that someday.

> What disappoints me is that there hasn't been a more declaritive, simpler proposal that has gotten anywhere.

Possible names: Client Side Includes (CSI): Like Server Side Includes (SSI) in Apache IHTML (inline html): Like the iframe tag, but for html instead of whole page.