defanor

It is just a hash map with a few common functions defined; hash maps are occasionally useful, but what is all the praise about?

The mentioned "simple" bit is arguable: as a language's building block, a hash map is relatively complex and specific, since those can be built out of lists (or trees, though lists/arrays may be preferable for efficiency), which can be built out of pairs (product types, cons cells, tuples; unless going for that efficiency, though it can still be pretty efficient with trees). Maybe it is one of those "simple versus easy" mix-ups.

It calls its terminal multiplexer functionality "terminal emulator", it seems. Unless it has a GUI, but then "terminal-based" is wrong.

I am not a fan of nano, as it is not even qualified to attend the editor war, but this one adds JSON configuration, "curl | bash" installation, has a JS-dependent website, and generally looks even more awkward than nano. Apparently both nano and this editor have their target audience, as do all those other "modern" editors, but observing this triggers the feelings likely similar to those that lead to flamewars: it is painful to observe seemingly inefficient and otherwise awkward tools used by others, and tempting to suggest to look into better options.

AIUI, Go intentionally avoids programming language features considered too advanced by its authors in order to lower the bar (to make it easier for most programmers to pick up, that is) and to keep the code uniform, supposedly to the advantage of companies using it. While hammering unidiomatic approaches into a language virtually always is awkward: there are other libraries and programmers, even if you are fine with the rules you have to follow in order to emulate the desirable features using a library. The combination of those things looks even stranger than they do separately.

And the article only mentions reduction of costs with automation. Would be strange enough for some tech-oriented magazine, but this one is called "The Economist". Though maybe it is supposed to be read just as a futuristic speculation, or as an overview for people unaware that automation is possible.

As should the contents.

A few issues spotted:

- It is not obvious how to get back to equipment selection: the history does not change, and it was not apparent that those step numbers are buttons.

- With JS off, there is an empty page in the beginning.

- The website does not allow to select forearms after choosing just "bodyweigh[t]" and "pull-up bar" as equipment, even though musclewiki.com shows chin-ups as an exercise for forearms.

To offer a different perspective: I find XML simpler in that it tends to correspond more closely to most arbitrary data models. From ADTs to C structures, there are product types and sum types to encode, along with more or less arbitrary basic types, which have text representation. With XML you get a straightforward way to encode all those, while in JSON there is no single agreed upon method to encode sum types, but you get something like string-indexed arrays (or hash tables) instead, which are normally implemented on top, using simpler types (and are not restricted to strings). And a few arbitrary built-in types, but you have to use strings for others anyway. And no built-in extensibility, so ad hoc hacks are used when it is needed. It would be particularly awkward to use for documents, too.

I preferred JSON initially myself, since it seemed a little less verbose, I did not care about extensibility, did not consider its usage for documents, validation, did not care about using it for different data models, and it just seemed simple (FSVO) and straightforward. But then more of XML made sense. It is not perfect for everything, either, but the decisions behind it seem more justified to me than those behind JSON (though JSON still fits JS, at least).

"Federated App" sounds odd: protocols are federated, and apparently they are criticized in the article, not software.

The "Learning curve" argument suggests that oligopolies tend to form, so it is not worth bothering. But that applies to pretty much any organizational activity, not just federated protocols, and often people try to push back against oligopolies or monopolies; often it is desirable and possible.

The "Authentication" one only applies to web-based clients, but you can login to remote instances even with those: converse.js supports it for XMPP, for instance. Possibly not in the way the author imagines it should though; perhaps that is closer to OpenID/WebID/OAuth. Still, generally users are not meant to login to every instance directly: even with just Google and Microsoft, you do not login to a Microsoft server to send them a message from your Gmail account, as you do not login into the receiver's email account to place a message for them. Maybe this section should have been titled "learning curve" instead.

The "Search Engine Optimization" probably describes the current state of things (I am not familiar with that), though does not apply to many federated protocols (e.g., I do not want my email or XMPP messages to be SEO'd), and I do not see a technical reason for that when it may be useful (e.g., public blogging or discussions); certainly does not sound like a drawback of federation itself to me, but maybe that of certain search engines' policies.

I personally usually saw discoverability/exploration as the primary issue with both federated and distributed protocols, especially when it comes to social ones, and hoped that RDF with FOAF will help with it. But ActivityPub and Mastodon seem to handle it rather well now, out of fairly widely used protocols.

Indeed, I was just about to comment on the linked page overstyling fonts and colors while suggesting to avoid overstyling other elements. The title can be clipped to "Don't use custom CSS" while reusing the same justifications.

Apparently it shows Cornish on the map for each "<language> in <place>" to me (FF 102.10.0esr, JS allowed on that page), and nothing otherwise.

ML-family languages are placed in Schemaria as well; apparently it is a catch-all for functional languages.

FWIW, I waited longer (30 to 60 seconds) now, and it did load (though was too laggy to interact with). It would be too painful to profile/debug at these speeds, but if you will be looking into further optimization, a few options that come to mind are: a textual representation (an article name and lists of referenced and referencing ones), a 2D interactive graph (those made with D3.js tend to be not so laggy), or a static graph -- a picture. Pretty sure an interactive 3D graph can also be made to work, but likely that would require to find out what is causing the lags.

My Firefox 102.10.0esr hangs on that page after enabling JS (the tab is unresponsive, one CPU core is loaded completely).

Perhaps worth mentioning that since 2004 there are RDFa and FOAF, serving a similar purpose (among other things). While XHTML is merged into HTML 5 (XHTML5).

If this was a comic strip (or some other kind of parody/satire), I imagine it would have been explained by Google noticing that "the decision is final" is not great to write in public, wondering how to improve it, and deciding on this informal-looking style, instead of fixing the wording itself and/or actually fixing the issue.

That's nice. Why no multiline messages though? Perhaps akin to those on modern telnet BBS systems, making use of pseudographics, or simpler ones, like in MUDs, with a line editor.

And SSHFP RRs (along with DNSSEC) would be nice to have for a public SSH service.

Indeed, at least for verification. I didn't mean for HN users to trust those, but perhaps should have warned about it: copied the fingerprints primarily for people searching on this page, so that they can follow the link to GitHub (and rely on PKIX to build a trust chain). I did `ssh-keygen -R github.com` myself, and saw the ECDSA key's fingerprint while connecting (which wasn't mentioned in the linked post, and wasn't on this page either), so figured it would be somewhat helpful for others following the same route.

Here are the expected fingerprints (since they don't publish those via SSHFP RRs): https://docs.github.com/en/authentication/keeping-your-accou...

    SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s (RSA)
    SHA256:br9IjFspm1vxR3iA35FWE+4VTyz1hYVLIE2t1/CeyWQ (DSA - deprecated)
    SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
    SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)

I don't know about Germany, but sometimes they are sorted in the order they are visited by a bus (describing the route), not alphabetically. Which makes it harder (O(n)) if you know the name, but don't know where it is located on the route.

Listing them alphabetically would be closer to this approach though, and likely more accessible.

Makes sense with the context, but at first I, too, was confused. And it's not the first time I see such usage of "sic!" as confusing. <joke>Perhaps it should be "(sic! sic!)" in less obvious contexts to clarify that the first "sic!" is actually intended there.</joke>

Seems to be so: in the past year I encountered notably more seemingly geoip-caused HTTP 403 errors than previously, often with CloudFront or Cloudflare, but usually they don't provide a list of blacklisted countries like that. It's rather surprising to see Hungary there, but not NK and Iran, assuming it's just political (and not a response to some attacks, or has to do with some legal issues).

> Restricted.

> Sora isn't available in Belarus, Hungary and Russia.

Why these countries in particular? I guess it's about having oppressive/authoritarian regimes and being in Europe, but why to restrict it that way?

Edit: or perhaps it's because of the war, but Hungary doesn't seem to be involved as much. Though maybe I missed something there.

I like GNU documentation (texinfo): reading those both as info manuals (usually in Emacs) and as HTML (in a web browser). Nice search and convenient navigation in an info viewer, available (and convenient) both offline and online, hyperlinks, HTML versions don't rely on JS (and do try to stay compatible with ancient web browsers), and it's rather generic (not language-specific).

Edit: I think pretty much all the GNU documentation (and most of texinfo documentation) I saw was nice, but as particular and common examples, there are manuals for Emacs and Elisp, GNU libc, coreutils, bash.

> programming languages lead to bigger diffs than necessary (adding an entry to a static list is a 2 line change instead of 1 line)

I think in ML-family languages it's fairly common to format like this, which avoids bigger diffs:

  foo = [ 1
        , 2
        ]

In C-style languages something similar goes as well, though perhaps used less commonly:

  int x[] = { 1
            , 2
  };

> The name "AirJet" gave it already away though, that this is likely something different.

They mention that those are MEMS membranes in the presentation [1]. But it also sounds like Airjet developers (or marketers) count MEMS membranes as solid-state, and piezoelectric fans as not, while I wonder where the line is.

[1] https://youtu.be/YGxTnGEAx3E?t=146

Do piezoelectric fans count as being solid state too, then? If so, this one wouldn't be the first.

As the article's author, I like to rant about articles ranting about bloat being bloated themselves, but here's an opportunity to rant about an article ranting about rants about bloat being bloated, being bloated itself! The page has 1 MB of rather unnecessary illustrations (many of which are just amusing pictures), which is larger than most of the books (as it compares other pages to books).

It is surprisingly common for content to contradict presentation in such articles. Well, it is mentioned in the article already, but still strange how common it seems to be.

Edit: though this is not exactly an article, but rather a presentation's/talk's "text" version, and the illustrations are slides. So it probably wasn't meant to look/be quite like that.

Neat, but this part is a bit odd:

> As a fan of CSS Naked Day and a firm believer in using JS only for progressive enhancement, I’m obviously in favour.

...And the page it is written on is slightly broken (images follow enlarged thumbnails of themselves) in FF with JS off.

Not GP, but using a similar setup (.org.gpg files for textual private data, on top of encrypted partitions as well), and Emacs comes with an EasyPG interface; doesn't need an intermediate temporary plaintext file. It can also handle an encrypted .authinfo, .authinfo.gpg, and encrypted bits of configuration (.el.gpg).

That's one of the nice things about common/basic/widespread standards and tools: good compatibility and support.

Handling non-GPG encryption in a similar way should be possible too, but won't work out of the box.

At work, we've finally replaced a large part of a custom (mostly-)web backend with PostgREST recently, and that's quite a relief: considerably less code to maintain in that project now, and that was a rather awkward code. Something akin to PostgREST's "Embedding with Top-level Filtering" [1] had to be provided for all the tables, with OpenAPI schema and a typed API (Haskell + Servant); I avoided manually writing it all down, but at the cost of poking framework internals, and maintainability suffered. It was particularly annoying that the code doesn't really do anything useful, except for standing between a database and an HTTP client, and simply mimics the database anyway. Whenever a change had to be introduced, it was introduced into the database, the backend, and the frontend simultaneously, so it wasn't even useful for some kind of compatibility.

Now PostgREST handles all that, and only a few less trivial endpoints are handled by a custom backend (including streaming, which I'm considering replacing with postgrest-websocket [2] at some point).

During the switch to PostgREST, the encountered minor issues were those with inherited tables (had to set a bunch of computed/virtual columns [3] in order to "embed" those), and with a bug on filtering using such relations (turned out it was an already-fixed regression [4], so an update helped). Also a couple of helper stored procedures (to use via /rpc/) for updates in multiple tables at once (many-to-many relationships, to edit entities along with their relationships, using fewer requests) were added (though the old custom backend didn't have that), the security policies were set from the beginning, the frontend was rewritten (which allowed to finally switch without adding more work), so it was only left to cleanup the backend.

Not using views, since as mentioned above, database changes usually correspond to frontend changes, and the API doesn't have to be that stable yet.

Happy with it so far.

[1] https://postgrest.org/en/stable/api.html#embedding-with-top-...

[2] https://github.com/diogob/postgres-websockets

[3] https://postgrest.org/en/stable/api.html#computed-virtual-co...

[4] https://github.com/PostgREST/postgrest/issues/2530