I had never heard that expression until I read this article today, and I spent a very big chunk of my career at FAANGs. I think he just invented it. NDAs were never a problem for me when switching jobs either.
The article was interesting and much of it rang true, but not this detail.
Counteroffers for lower-level engineers are fairly rare. These companies believe that L4s are sufficiently common that another one will come along. It’s unfortunate especially when an L4 is seriously outperforming their level. But that’s a big company for you.
Google could easily change these lines. The question is, should it?
One thing about Google living so close to head with its libc++ is that it encounters the issues downstream users will encounter, just long before everyone else. It saw this development within a day or two of the or getting merged.
The idiom is unfortunately common in C++ codebases around the world so this was a good predictor that many other users will be broken. It isn’t necessarily erroneous, unlike many of the other no-discard additions made in this patch series.
So the question becomes, “Are the false positives worth the true positives?” Not just for Google, but for the entire user base.
It is reasonable to disagree on this, and often library writers up to date on the latest and greatest miss the issues this sort of change will cause.
To use an illustrative (but inevitably flawed) metaphor: Using libgccjit for this is a bit like networking two computers via the MIDI protocol.
The MIDI protocol is pretty good for what it is designed for, and you can make it work for actual real networking, but the connections will be clunky, unergonomic, and will be missing useful features that you really want in a networking protocol.
Googling “slip over midi” gives a lot of fashion blogging about mini dresses and slips that one wears under them, so I’m not quite sure what you mean.
But if you mean “midi over slip”, then that is the inverse case from what I am suggesting. Midi over slip (and slip could be any tcpip substrate, such as ethernet) has midi messages as the payload, carried via tcpip.
I’m talking about using midi messages to carry tcpip payloads. You can absolutely do it, but it isn’t really what the protocol is designed for.
No, I meant it exactly like that SLIP over MIDI. I know there are plenty of MIDI over TCP/IP and UDP implementations but that's not what I had in mind.
And what google turns up when you enter those exact three words in a row is really none of my business.
I used SLIP all the time back in the day, and I use MIDI all the time in my home music setup. The wikipedia articles don't tell me anything I don't already know.
I suppose someone somewhere has done it (and I have always said that you can), but my best internet searches with a wide variety of terms don't show any old tutorials or products that explain how. Nor can I find anything else that uses MIDI to send tcpip packets over the MIDI connection. Not even a mention.
My Google-fu may be totally weak, but whatever.
I freshly, happily and totally concede that people have in the past used MIDI to send SLIP packets, and it is well understood how. Great. You are totally correct.
But all of this just proves the original point. It either precedes anything on the internet today, or is so obscure that no search engine can find it. Either way, if no one uses it or even bothers to explain how, I think it is pretty fair to conclude that it is rather unergonomic, and hacky, and doesn't provide all the features one really wants in a network connection.
And Harry doesn't mind if he doesn't make the scene
He's got a daytime job, he's doing alright
He can play the honky-tonk like anything
Savin' it up for Friday night
With the Sultans
We're the Sultans of Swing
The arcade classic Space Invaders had a primitive soundscape in that every time the remaining invaders advance, it plays a short bass note. As fewer and fewer invaders remain, it takes less time for them to advance, and the note repeats faster and faster, it adds a remarkable amount of increasing tension as each level progresses.
So not exactly the same, but perhaps prototypical. I think Asteroids did as well.
The game speeding up as invaders are eliminated was an unintended consequence of the hardware running full speed to draw all 55 invaders. As invaders are eliminated the draw calls finish faster and the game speeds up. There is no code in the game to throttle the speed. The 2 Mhz 8080 is always drawing full speed. It's delightfully serendipitous this happens to ramp up the difficulty as you near the end of each level in such a compellingly perfect way. (https://www.tomshardware.com/video-games/retro-gaming/space-...)
I've watched some interviews with the game's programmer Tomohiro Nishikado and, although translated (so subject to garbling), he seems to confirm this was a 'happy accident'. He indicates he set the max number of invaders based on what the hardware could draw but there was no intent to have the speed ramp up. Of course, he noticed that it did this during play testing but decided to keep it that way. Arguably, it's one of the most compelling aspects of the game. Modern emulators have to add code game-specific code to limit the speed or the game plays too fast. Leaving no CPU cycles unused is the sign of an elegant design.
That reminds me of the music in the film "Inception", in which the extremely low-register bass-heavy music in the background of scenes from lower levels of dream-in-dream is actually the main score, played back dramatically (and semantically / thematically) slower and lower.
Github does include some small amount of algorithmic feeds in its recommendation engines. I have half-a-dozen projects "Recommended for you" on my github home page.
I doubt that is enough to trigger this ruling, but algorithmic content is absolutely pervasive these days.
