Interesting that this quote really contains "sender" where "recipient" was intended, but it had absolutely no impact on any reader. (I even asked Claude and ChatGPT if they noticed anything strange in the sentence, and both needed additional prompting to spot that mistake.)
Wow I completely didn’t notice that until I read your comment. My brain must have automatically filled in the correct word. I had to go back and re-read it to confirm.
Well English is not my first language, so I probably tend to go through text more slowly and/or scan the text differently, so I have higher chance stumbling upon these oddities. (I can confirm that sometimes I see unexpected amount of misspelt homophones or usage of strangely related words.) Seeing two distinct LLM chats gloss over this particular nuance in almost identical way was really interesting.
Grok, on the other hand, has absolutely no problem with concept of sender both expanding and compressing the message, and with absence of recipient. Even after super-painstaking discussion, where Grok identified the strange absence of the "recipient", when I asked him to correct the sentence, he simply changed the word "sender" to the word "themselves":
> something very strange about people writing bullet points, having ChatGPT expand it to a polite email, sending it, and *themselves* using ChatGPT to condense it into the key bullet points
This adds another twist, since I'd bet nowadays most CVs are processed (or at least pre-screened) by "AI": we're in a ridiculous situation where applicants feed a few bullet points to AI to generate full-blown polished resumes and motivational letters … and then HR uses different AI to distil all that back to the original bullet points. Interesting times.
This makes me think about adversarial methods of affecting the outcome, where we end up with a "who can hack the metabrain the best" contest. Kind of like the older leet-code system, where obviously software engineering skills were purely secondary to gamesmanship.
Could this be the reason I immensely dislike when webpages include blocks of inverse background/text, or generally combine light-text-on-dark with dark-text-on-light elements?
Fun fact: browsers' devtools consoles have de-facto standardized convenience aliases for querying the DOM, similar to jQuery [0][1][2][3][4]. This means you could do something as simple as:
to create the simplest dependency-free cheat speed runner. (And, as mentioned earlier, shrinking -- or logically also zooming in -- the page results in more DVD bounces.)
Ah, thanks for the heads-up, apparently there is something borked in Chromium wrt $ / $$ encapsulation, as it seems they are nor reachable from the (global) context setInterval so doing `window.$ = $; window.$$ = $$;` fixes that in Chrome. Not sure why. (Yet again embarrassed myself by trying a snippet that "simply must work ® according all documentations ™" in single a browser only before posting. Sigh.)
I bet it's working as intended. The $ symbol is probably a special feature of the console and is not intended to be a property of window. Inside setInterval, the function is no longer being executed in the special console environment, which has access to that symbol.
Yes, I guess there could be some intention behind that, presumably some security precautions, but still: the fact that you can see $ in the globalThis (as a non-enumerable prop), and that globalThis you see from inside the timeout-ed function is strictly equal to globalThis seen directly from the console, that makes it somewhat spooky.
And it (`setTimeout(()=>{console.log(typeof $==="function")},0)`) works in Firefox. (Interestingly, you cannot get $'s descriptor in there, but you have it always available in timeout.)
I thought that the "idiomatic pink" in fact is the "Magenta" mixture of blue/violet and red wavelengths and the "neutral light red" produced by mixing "pure red" with "pure white" you call "Pink" would be commonly perceived as "bland" or "washed out" or "too yellowish" compared to the "Magenta pink" as you call it (?)
In other words, that the colour that is commonly called "pink" and occurs in nature has always somewhat bluish tint, while the "neutral pink" you refer to is somewhat rare in the nature.
In computer terms, named colour `pink` is
rgb(100% 75% 80%)
whilst the "neutral pink" of the same lightness would possibly be a darkened variant of the the `misty rose` what is defined as
rgb(100% 89% 88%)
Arguably the "blue" accent in computer `pink` could be an adjustment addressing some technical display peculiarities, but I like to think that the real reason for the standardised `pink` being really "light magenta" is the intent to adhere to the natural counterparts (and resulting common language).
Look at how yellowish the "darkened mistyrose" rgb(100% 77% 77%) appears compared to "pink"
<p style="background: pink">
<p style="background: rgb(100% 75% 80%)">
<p style="background: rgb(100% 77% 77%)">
<p style="background: rgb(100%, 89%, 88%)">
<p style="background: mistyrose">
I think it could be neat to leverage ligatures, i.e. preceding glyph could either affect the seed of the next or even make different "cursive" connecting swashes. Words could become pictures with individual "glyphs" blended together.
that's such a cool idea, I'll play around with it. right now each symbol is independent of its neighbors (except for the bezier curves piecing them together)
And maybe also the press duration; even with preserved auto-repeat, there seems to be quite a variety in typing: getting duration from key-down to key-up between 30 and 120 milliseconds. Naturally we can "squeeze" it up to auto-repeat threshold, which is usually around 500 ms.
What surprised me is how often I have concurrently pressed two or more keys during typing, never occurred to me how frequently key press of the next key happens before the previous key was released. It could also be interesting signal perhaps.)
Interesting, in my murky memory Chrome's developer tools were at most "quite decent" but for a long period of time could hardly compete with Firefox's, maybe even with mere Firebug. It it true that in total "feature count" Chrome most probably leads now, and especially recently they seem to adapt features that used to be Firefox exclusive in remarkably increasing rate. But I really do not remember being blown away by Chrome's devtools, like, ever, actually. Even today I pretty much prefer Firefox Developer Tools over Chrome's, because they mostly has more features I actually need and also feel way less cluttered. Most of the times I need to do anything with Chrome's devtools it takes me just a little moment to stumble upon some missing detail I am used to (for example overflow/layout/event listeners badges directly in the DOM inspector tree) or to be mildly offended by unfamiliar (or missing) keybinding, or confusing layout. There are quite a few features In Chrome that I'd like to see in Firefox (command palette for example), but still prefer "living" in Fx albeit without them.
Yes, al subjective, biased and anecdotal, but wanted to leave one real (yet still virtual) vote in favour of Firefox's Developer Tools here.
That's nice resource, especially the "Tests" part showing Firefox keeps them all supported and Safari dropping most of them.
I have explored system colours including deprecated ones with intention to try to tap them into some more pleasant scheme (dimming canvastext for bordrers through color-mix() for example) and was interested about the "palette" we could use without defining own colours. Made a comprehensive "sampler" to test them [1,2] and Results were quite sad, especially outside Firefox [3].
NB, that style does not play well with non-native DPI (e.g. when you have monitor set to 150% scale); to see it mapped to physical pixels, try running this in the browser's console:
tl;dr is that `with` is a long deprecated statement that is good for casual "golfing" and raising eyebrows of JS-savvy folks. Does not work in the "use strict" mode (so in modules) and generally should not be used in any "real-world" production code, since it prevents many optimisations and could possibly make the code harder to grasp. But I guess for casual one-time console doodles it could be fine. Reportedly it is supported in all major JS engines, and I don't think it will be really removed in foreseeable future.
reply