2,837 karma · joined June 23, 2010
American Nations is a more recent book that describes more of the United States, though with less depth.
(N.B. 0.19 has been the latest version for almost six years.)
Fine art, like painting, is almost definitionally not supposed to be touched.
Applied arts include fibers (knitting, weaving), ceramics, jewelry and metalwork, etc. Stuff that’s meant to be pleasing and functional.
Whether something should be touched is almost _the thing_ that moves a field from one category to the other.
Applied artists, and their product designer cousins, will spend a lot of time exploring and pursuing tactile qualities.
This was my (limited) experience with (introductory) formal CS.
Which is sort of amazing to me as art schools seem in broad agreement that “how to draw” can be taught, albeit in many different ways.
Cable management isn't horrible but there's a lot of room for improvement. I'd like to replace all the AC adapters with one big one that can supply everything.
I've built some outlandish and unsatisfying desks in the past, the gradual approach has been better.
1. This is unsafe for children, as they might figure out a way to flip the switch and crush themselves. Please take this consideration into account.
Mr. Burns: https://www.youtube.com/watch?v=othBTFk_W1Y
In North America alone, 30,000 square kilometers for all oil and gas[0].
For a rough approximation, the US produced 14% of oil in the world in 2021[1] and this guy on Quora[2] says that 12% of the world's oil and gas goes into aviation fuel.
[0] https://www.science.org/content/article/thirty-thousand-squa...
[1] https://en.wikipedia.org/wiki/List_of_countries_by_oil_produ...
[2] https://www.quora.com/What-percentage-of-the-world-s-crude-o...
With a zipper such a scenario isn’t possible.
JavaScript makes (1) the default. For any kind of object access (dog.legs[1].paw), assignment (const q = 5), math (Math.floor(4.2)), or DOM access in a browser (document.write('yay')), the interpreter will run each statement in sequence, completing each one before running the next.
Historically, the way ask the interpreter to "get back to me when you're done" was to use the "callback pattern," which was little more than passing in a function:
setTimeout(4000, () => console.log('second'));
setTimeout(5000, () => console.log('third'));
setTimeout(3000, () => console.log('first'));
When it came time to construct sequential-looking programs that involved lots of these calls, things could quickly get messy: http.get(catalogUrl, (err, catalog) => {
if(err) {
handleError(err);
}
http.get(catalog.products[0].url, (err2, product) => {
if(err) {
handleError(err);
}
document.write(product.name);
});
});
Promises flipped this callback style into an object. Async/await morphed those promise objects and methods into language syntax that looks like one thing happening after another: catalog = await fetch(catalogUrl).catch(handleError)
product = await fetch(catalog.products[0].url).catch(handleError)
document.write(product.name)
If the original question were "why are some APIs async and some not?" the answer would be: "JavaScript engine authors (web browsers, node) have decided that some things like network access are inherently too slow to pretend they happen instantly, and waiting on them would mean that the UI would have to become unresponsive, which would make users think something is broken. Other APIs like DOM access are fast enough to get away with freezing the UI and nobody notices."But the question was, "why can't you call an async function from a synchronous (non-async) function?" The answer there is more like, "Because synchronous functions are expected to return a result without waiting, and if you could call an async function but pretend you didn't, there's not a good solution for what should happen in composition with other non-async functions. Would you proceed without having a result? Would you force a wait anyways? None of those are acceptable answers because they break the model of 1) some things are nearly instantaneous and 2) some things take longer. We still need a mechanism to work with things that take a long or unknown amount of time, without making the UI freeze."
As lolinder points out in a sibling comment, this decision to split things into 1) fast and 2) not fast was ultimately a semantic decision of JavaScript engine/API designers. The downside of this decision is that it takes programmers some time to be comfortable with the unintuitive model. The upside is that it enables programs to be written by (fallible, mortal) programmers and not freeze up all the time.
Respiratory function in patients post-infection by COVID-19: a systematic review and meta-analysis
DOI: 10.1016/j.pulmoe.2020.10.013
I teach front end web development to a total beginner who is only just becoming aware that programming a web app with persistent state shared amongst users requires separate technologies than HTML/CSS/JS. The table API could be ideal for her. The alternatives: shared hosting with PHP/MySQL, anything AWS, or even Google Sheets/Airtable are all much bigger cans of worms that just slow down her cycle of getting things out there and learning the whole of the SLDC.
Wild that Justices Thomas, Rehnquist and Scalia dissented with the court, finding that the hitching post was not obviously cruel.
https://en.wikipedia.org/wiki/Hope_v._Pelzer#Dissenting_opin...