they have no doubt been doing it, they're just using the panic of a brainwashed population thinking they're on the brink of Islamic revolution to normalize it
414 karma · joined December 1, 2014
Software on consumers' devices that records ads seen and file complaints if consumers are still being tracked? It's very easy to detect algorithmically that you're being shown personalized ads.
> Hence, our attempt to convert high-level code to assembly code takes us one step closer to completing the dream of making a chemical compiler.
I said I like to write it this way, not that I always do it.
> why code like that
It's a fun exercise.
> it would be a huge waste of time and energy
I don't fully agree on this: from the name and signature it's pretty clear what the function does, so you don't need to waste time "parsing" the details. And with unit tests it is also very low-risk.
But that's speculative, in a real project I'd just use lodash.
I like to write it this way, using as much syntax sugar as possible:
const mapObject = fn => obj => Object.assign( ...Object.entries(obj).map( ([key, value]) => ({ [key]: fn(value) }) ) );
The amount of things you need to know in order to use react and redux is ridiculously low.
You're basically just composing functions of two types "(state, action) => state" , and "state" => html.
The boilerplate consists of a few functions (really mostly createStore and connect) that are incredibly well documented.
There's almost nothing to understand and redux itself is almost not a lib (only 318 LOC). The whole thing is a pattern and redux is just a small, very well written key component of the pattern.
When people debate redux they debate about programming, not about a tool. That's why it's interesting and why it will never end.
But in this case it's pretty straightforward to write a function like "get('b', 'c')(a)" or use a lib like lodash [1]
Instead of using web tech to build native apps I think we should focus on improving browsers so that web apps behave more like native apps and have the same capabilities. Browsers should be the cross-platform VM and webassembly is a good step in that direction.
"Hey, let's write an editor for a browser. Oh wait, we need a browser for that editor".
Something good will probably come out of this eventually. I mean if they manage to turn electron into a true native cross platform app framework it's nice.
But I fail to see which problem this tries to solve or which novel solution it illustrates. It looks a lot like React without JSX (which is not bad).
I for one am willing to contribute the day wayland becomes too mainstream.
Long live the best WM ever!
In particular, I need to be able to have desktop #x on display #y and desktop #z on display #t, i.e. have virtual desktops independent from the multiple displays setup - a feature that other DEs / WMs seem to never provide.
This is very practical to, say, keep your emails always visible on one display while switching between other tasks on other displays.
Sure, sometimes a release of xmonad will make the chrome dropdown menus stop working [1], or some other weirdness, but all in all, it's quite stable and I can focus on creating a workflow that really suits me and that I never need learn again.