244 karma · joined July 1, 2020
> In a previous paper, MIT researchers had introduced a technique to “distill” giant data sets into tiny ones, and as a proof of concept, they had compressed MNIST down to only 10 images.
* Apps eventually degenerate in a mess of interconnected components triggering events on each other. Building UIs felt more like writing Verilog than writing functions. Nothing like chasing event ordering bugs through library components. With React I never saw 'enqueue a new event for component X' anti-pattern. All callbacks flow from children to parents in a fairly regular manner.
* Related, there is no need to manually manage repaint events in React. Visual updates happen automagically. See, for example, https://stackoverflow.com/questions/952906/how-do-i-call-pai... for a hair pulling session related to manual repainting.
* On the ergonomics side, having a markup language allows for terse but readable definitions of component trees. I see 2020 Qt has introduced a markup language, this was not the case circa 2005.
* Hooks give an extra layer of niceness. Declaring a component is as easy as declaring a function. Local state becomes almost as simple as declaring a local variable.
* The inspector capabilities of modern browsers are very handy when debugging layout and styling issues.
Regarding performance, modern JS is plenty fast, but it's not in the 'terrible' category. It's memory usage, perhaps ;) https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For performance critical code JS is not the answer, but good enough for most uses, including UIs.
Regarding UI paradigms, I'm not sure what the problem is, or what significantly better alternatives are. I did MFC/C++ in '90s and C++/Qt in the '00s, and both were vastly inferior to modern browser development. React+StyledComponents is a wonderful way to build UIs. There are some warts on the CSS side, but mostly because Stackoverflow is full of outdated advice.
This is half true. The other half is that OOO execution does all the pipelining a "good enough" compiler would do, except that dynamically at runtime, benefiting from just in time profiling information. Way back in the day OOO was considered too expensive, nowadays everybody uses it.
https://buy.garmin.com/en-US/US/p/702902#specs: CONNECTIVITY Bluetooth®, ANT+®, Wi-Fi®.
From Garmin website, featured items:
https://buy.garmin.com/en-US/US/p/711488: CONNECTIVITY Bluetooth®
https://buy.garmin.com/en-US/US/p/707174/pn/010-02427-02: CONNECTIVITY Bluetooth®, ANT+®
https://buy.garmin.com/en-US/US/p/713363: CONNECTIVITY Bluetooth®, ANT+®, Wi-Fi®
Older school hiking GPS:
https://buy.garmin.com/en-US/US/p/699779: WIRELESS CONNECTIVITY yes (Wi-Fi®, BLUETOOTH®, ANT+®)
The weighting scale apparently has no wifi, so that's drone safe. Though not quite portable.
top3 - max 3 values in the group
y.d | a | b
-------------------
y0 | a0 | b0
y0 | a0 | b1
y0 | a1 | b0
y0 | a1 | b1
y0 | a2 | b0
y0 | a2 | b1
y.d | a | b
-------------------
y0 | a0 | b0
y0 | a1 | b1
y0 | a2 | null retrieve (a=count(y.i by y.d where y.str = "ii*" or y.str = "foo"), b=max(count(y.i by y.d)))
Not a particularly clear 'jumps at you' obvious semantic:* Are a and b aggregation functions or window functions? If aggregations, how do they compose if the 'by' scopes are different?
* What does max(count(... by ...)) mean? What is the aggregation (window?) scope of max?
* How would an outer where clause compose? What is the evaluation order?
Hmmm. Not a big lover of SQL, but this is a bit imprecise. While the unit of composability is slightly smaller for from=>where=>select (expression) vs select+from+where (subquery), in practice they both encode the same fundamental compositional principles, based on relational algebra. Any from=>where=>select query can be translated into a select+where+from query almost 1:1, if only via:
from t ::= select * from t
q => where p ::= select * from q where p
q => select xs ::= select xs from q
Sometimes the select+where+from ends up more verbose, sometimes there is more brain twisting to grok a given select+where+from query, but that's not a composition limiting factor. Granted, the readability of SQL is sometimes lacking, but it is fully capable to compose recursive relational algebra queries.Unless we can get to reusable glass. Living in US and walking the aisles of the local supermarket, I don't see how that's possible. The glass-packaged foods come from all around the world, with each company apparently intent on having its own distinctive glass shape. As 'recyclable' material ends up in the landfill more often than not for cost reasons, it seems a monumental task to build a 'reverse distribution' path to send back glass containers thousands a miles away to their original producer for reuse.
Right now is a great time to delete your accounts. The only better time is yesterday.
https://www.theguardian.com/us-news/2019/jun/21/us-plastic-r...
For example, yogurt. Ubiquitous. Comes in nice little plastic cups, which will, at best, end up in a landfill. Suppose there is a wide agreement in society to phase these plastic cups out:
* Do we ban yogurt?
* Do we use recyclable glass instead?
* Do we use recyclable glass, and only dispense yogurt if you bring a recyclable container for an exchange?
* Do we use recyclable glass, only dispense in exchange for a recyclable container, and standardize container shape such that the recycling actually recycles, as opposed to sending the "recycled" container to a landfill anyways?
* Do we limit the amount of yogurt containers one can buy in a given timeframe?
* Do we create a heavy tax on the container, say 10x the price of the content?
Life is short and people may get overwhelmed by too many details. Problem which compounds if there is too much choice. Almost always better to have a standard recipe to follow, than having to figure out a recipe on a case by case basis.
--r<TAB>ecursiveSandstones. Sandstones originate as far as hundreds of million years in the past. Occasionally they harbor fossils, which are indeed rare. But a lot of sandstone is made of sanded up organic material which we can readily identify, even if we can't point to the specific organism they originated from. We only need a tiny industrial-related grain of sand (ceramic, glass, metal, plastic traces) to point to a past civilization. Nobody ever noticed such a grain of sand.
Betteridge's Law confirmed. We can track down fossils billions of year back by observing the way they shaped the encasing rocks, and not once have we noticed a ceramic shard, a metal bit or the silhouette of a plastic object.
* Total ocean volume: 1.3e18 cubic meters, 1.8e21 oil barrels equivalent [1]
* Current oil consumption: 35,442,913,090 barrels per year [2]
* Oil share of total energy consumption: 34% [3]
* Number of years of reserves at current consumption levels: 17,577,561,935 years.
Assumptions:
* Consumption levels are flat, definitely false.
* Energy cost of retrieval: 0, definitely false.
* Retrieval rate: 100%, definitely false, as the concentration dilutes over time.
[1] https://ngdc.noaa.gov/mgg/global/etopo1_ocean_volumes.html