In other words, right now if a human wants to DELETE a widget, the human has click on an HTML form to `POST /widgets/123/delete` - i.e. use an incorrect verb on an incorrect URL/object - or use some other workaround like smuggling a special `_method=DELETE` variable. This is unnatural and semantically incorrect, resulting in ugly hacks that break HTTP-level expectations like idempotency; and it also requires additional app-level logic to process.

Meanwhile a machine is allowed to simply `DELETE /widgets/123` because their interface to HTTP is not clicking on HTML forms.

We humans could converse with websites in semantically correct HTTP, have clean URLs in which both REST APIs and human-facing URLs are identical without hacks, and require no extra app/framework logic, if HTML forms simply allowed all (human-relevant) HTTP verbs.

It's like putting your car's engine in the passenger seat - rude, intolerable, and plain stupid. What if Grandma was browsing her home folder and deleted `~/snap/` because she has no idea what it is?

[1] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053

I had no idea that you could do that asynchronously, and then have ZSH update the already printed prompt with the status later! That blows my mind!

I personally worked on the Forsyte saga. If you think something was done in error, please let us know and we'll be happy to fix it.

Machinery at the dawn of the industrial revolution was supposed to be a time-saving miracle that freed capitalists from having to deal with workers, and also freed workers from backbreaking labor, letting them spend their hours in the pursuit of leisure.

Of course, the opposite happened. Machinery meant workers could produce more output in the same amount of time, so they didn't work less, they worked at least the same and eventually even more to keep up with competition and the demands of consumers. It took decades of unrest and bloody conflict to give us the 8-hour workday.

This article is rediscovering that same history, but for a different class. AI is to white-collar knowledge workers what steam-powered machinery was to the rough-handed working class of the 1800s. It promises capitalists freedom from having to deal with highly-paid knowledge workers, and it promises highly-paid knowledge workers freedom from their labor so they can spend their time in the pursuit of leisure.

Look to history to see how that worked out.

Comments URL: https://news.ycombinator.com/item?id=47894660

Points: 1

# Comments: 0

The renderer is atrocious and is holding back the entire industry, much like IE6's crappy renderer and monopoly on users held the entire web back a decade. Browsers (and thus ebooks, which are just HTML/CSS) can now do pretty decent typography, but Amazon inexplicably refuses to get on board with epub.

Their file formats are equally garbage. Mobi, a format that has hardly changed since circa the year 2005, was still in active use until just recently. Their other proprietary formats are confusing in feature set and are opaque to create. The official tool to create Amazon ebooks only runs on Windows![1]

Kindles still can't natively read epubs, but since they accept epubs via email, their customers get confused and email me about it. (Epubs sent via email are quietly convert to Amazon's propriety format, meaning all bets are off on the result. Good luck, publisher!)

I always tell people, buy literally any other ereader.

[1] Calibre can also create them but it's reverse-engineering and not the official implementation.

These items make XML deeply tedious and annoying to ingest and manipulate. Plus, some major XML libraries, like lxml in Python, are extremely unintuitive in their implementation of DOM structures and manipulation. If ingesting and manipulating your markup language feels like an endless trudge through a fiery wasteland then don't be surprised when a simpler, more ergonomic alternative wins, even if its feature set is strictly inferior. And that's exactly what happened.

I say this having spent the last 10 years struggling with lxml specifically, and my entire 25 year career dealing with XML in some shape or form. I still routinely throw up my hands in frustration when having to use Python tooling to do what feels like what should be even the most basic XML task.

Though xpath is nice.

We also require that the art have some kind of connection to the book itself, so it's not just some random fine art. Sometimes the connection is a little fuzzy, but we do the best we can given that art must be pre-1930 and also must have been previously published.

(My personal favorite artwork selection of the books I worked on is The Communist Manifesto[1]. That painting was actually made specifically for a different book by Willa Cather[2], but I thought the peasant laborer, holding a sickle in one hand, with a faraway look in her eyes as the red sun rises behind her was just too good to pass up for Marx!)

1920ish was when it started becoming much more common for books to have illustrated dust jackets, so now that more books from that era and onwards are entering the public domain, we opt to use the first edition dust jacket if it's in the appropriate style. Fortunately for us, that era also happens to be the so-called Golden Age of Illustration so it's not hard finding beautiful art to use!

[1] https://standardebooks.org/ebooks/karl-marx_friedrich-engels...

[2] https://standardebooks.org/ebooks/willa-cather/the-song-of-t...

First-time contributors should select something from the appropriate section, because that gives you the greatest chance of succeeding and the least burden on our reviewers as you get started.

Our toolset has a help wanted section and some outstanding issues: https://github.com/standardebooks/tools#help-wanted

[1] https://github.com/standardebooks/standard-blackletter