I'll push back against this slightly: learning what good code is requires debugging bad code, whether by way of a symbolic debugger or judicious use of printf() or breaking an algorithm down into its steps so that you can figure out its asymptotic behaviors.
I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.
It's kind of the same distinction between backups and restores, wherein the restores are what's important, but they're impossible without the backups to restore from.
One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.
The state of affairs in C and C++ is abhorrently bad. Not only is there `char` but also `signed char` and `unsigned char`, and the standards seem to leave the signedness interpretation of bare `char` up to the implementation.
Ada explicitly settled on `Character` being an enumeration type based on a specific character set encoding. When I learned Ada 95, the ARM specified the ISO 8859-1 character set for `Character`, likewise with `Wide_Character` and `Wide_Wide_Character` explicitly settling on 16- and 32-bit implementations of UCS. I wish more language specifications made decisions like this.
D following suit with tying its `char`, `wchar`, and `dchar` to UTF-8, UTF-16, and UTF-32 is commendable.
More to the point, MAUs are a measure of reach and not revenue or business health.
Looking at this from an investment standpoint (as if, e.g., I were establishing funding requirements for a pension fund or an annuity or some other such financial vehicle), MAUs are a nice to have because they can establish a counterfactual[0] for volume, but I'd be looking at the performance of X's products relative to the financial performance of X's customers buying those products (e.g., for advertisers, things like conversion and customer acquisition cost come to mind), legal exposure (because of, e.g., CSAM distribution) and other tail risks, and also whether there's an existential risk to the liberal democratic order that enables the financial vehicle I'm working with to operate at all, among other portfolio-level risks.
--
0: Well, kinda. The counterfactual actually comes in when we ask questions like, "If the reach changes, what happens to the economic performance?" Relying on MAUs as a baseline measure of the reachable population based on observation enables us to establish these kinds of counterfactuals.
> Minimizing shareholder value will flatten the economy.
Will it though? I'm curious what the empirical basis is for this causal claim, especially given that it ignores the wealth of gray area in between these two extremes. (That goes notwithstanding that I have zero idea what is meant by either "minimizing shareholder value" or how a flattened economy could look as an operationalized outcome. Neither of these are accepted terms of art with precise definitions.)
There are some obvious counterexamples to look at, wherein a hypothetical firm doesn't intentionally maximize shareholder value or chooses explicitly not to:
- A firm can choose to pursue long-term productivity gains;
- A firm can pay higher wages or provide better working conditions and still generate substantial shareholder gains;
- A firm can keep its earnings rather than pay dividends to have cash on hand for capital improvements; or
- A firm can accept a haircut on its margins to expand along some axis, like manufacturing capacity or market share.
Shareholder value is usually taken to be a function of the firm's expected future cash on hand (or, more precisely, the equity claims on that expected future cash on hand) and its exposures to various risks to that cash on hand (optionally quantified by people like me!), and the idea of maximizing shareholder value needs to be understood as having some kind of time horizon. Commonly, in the post-Jack Welch era, this time horizon is three months.
On a much longer time horizon, however, sacrificing short-term shareholder gains for long-term productive capacity can very well be analyzed as shareholder value maximization.
> Do you really want to live in a pre-industrial agrarian society?
This seems to treat the grandparent post's social insurance and institutional design argument that shareholder primacy has contributed to the institutional arrangement that makes intergenerational care difficult as though it means, what, capitalism is bad, so we should return to farming.
I'm unsure that I can draw a comparison between these two arguments. They're very different, and the parent post's reply doesn't establish the premise it needs. Industrialization and shareholder primacy aren't binary choices, and the mere existence of modern industrial prosperity doesn't establish the fact that our particular institutional arrangement producing it is in fact necessary for that prosperity.
Pedantic clarification: The (original German) song itself didn't mention an actor in particular who had released the balloons, just that there were 99 balloons that flew to the horizon and jet fighters being scrambled in response. The epilogue tells of the consequent whole bunch of lasting destruction as the narrator talks about their patrols.
The English translation "99 Red Balloons" is considerably different as far as the details go.
99LB (the German version) has the baloons getting released and the generals deciding to treat it as an opportunity for a show of force blowing them up intentionally.
99RB, on the other hand, has the EWS confusing them with a threat causing the system itself being the source of the attack.
The message between songs is different, the German version is a warning about the wrong people being in charge of the doomsday machine whereas the English version is a condemnation of the doomsday machine itself.
Interestingly the band was not satisfied with the English version, mainly because they wanted to be a pop band and not a protest band and they thought the English version was too "on the nose" in its condemnation of MAD.
Personally I grew up hearing 99LB on the radio but thinking about the lyrics of 99RB since I don't speak German. 99LB was more popular even in the english speaking world because it's better performed but we all saw it as an anti-MAD protest song which 99RB definitely is, but 99LB is not quite.
99RB has some really great lines missing from 99LB:
The war machine springs to life
Opens up one eager eye
and
Call the troops out in a hurry
This is what we've waited for
This is it boys, this is war
> generals deciding to treat it as an opportunity for a show of force blowing them up intentionally
Only kinda!
„Hielt man fuer UFOs aus dem All / darum schickte ein General / eine Fliegerstaffel hinterher“ They believed that the balloons were unidentified flying objects from outer space. The general panicked and sent a squadron to investigate.
„Dabei waren dort am Horizont nur 99 Luftballons“ However, what they found were only 99 balloons.
Still, there was a problem: „99 Duesenflieger / jeder war ein grosser Krieger / hielten sich fuer Captain Kirk“ The pilots of those jet fighters thought of themselves as warriors on par with Captain Kirk (which is funny; Starfleet is primarily a scientific organization that only incidentally wields weapons).
The neighboring countries concurred: „Die Nachbarn haben nichts gerafft / und fuelten sich gleich angemacht“ They weren't able to suss out anything about these activities and felt provoked by them.
Here's where the war ministers make a show of force though: „99 Kriegsminister / Streichholz und Benzinkanister / hielten sich fuer schlaue Leute / witterten schon fette Beute / riefen Krieg und wollten Macht“ The war ministers brought a proverbial match and gas can to the whole affair. They thought themselves shrewd and crafty and could smell the scent of prey, so they called for war.
„Mann, wer haette das gedacht / dass es einmal soweit kommt / wegen 99 Luftballons“ Man, who could've thought that it came this far because of 99 balloons?
> 99LB was more popular even in the english speaking world
This song predates me by just a handful of years, so I never caught it during its radio heyday, but I can't verify this assertion from personal experience. Perhaps this is a UK-centric view? I'm unsure that much of this kind of cultural exchange made it to the US.
> Fords, on the other hand, have an even, predictable quality. The same with my 72 Dodge. The windows still crank up and down nicely!
I don't know if I'd say they have an even, predictable quality, but on an actuarial basis, Detroit certainly makes for easier claim severity modeling than anything out of Ingolstadt, Muenchen, Stuttgart, or Wolfsburg.
That said, I don't really understand how quality maps to cars beyond what my comprehension of Japanese has allowed me to read about how Toyota's industrial engineering contrasts against Ford's. My first may have been a 1971 Opel GT that I salvaged by bringing home in parts on a bicycle-drawn trailer as a teenager, but I only ever wrenched on it. I never drove it.
> I don't know if I'd say they have an even, predictable quality
Euphemistically at least, considering they're frequently known in car circles as "Found On Road, Dead" and "Fix Or Repair Daily". It used to be seen as an advantage that Ford spare parts were dirt cheap, although I don't know if that's still the case given the trend to have Chips With Everything.
> Companies can develop new products without your advice. In fact consumers often don't know what they want.
I'd urge reading up on revealed preference and product discovery. It cuts both ways in that, sure, a company can offer a product on the market that no buyer asked for and have it sell well, but then, the media can expose some rather unsavory facts about that same product and subsequently (consequently?) have it not sell.
> Then why do businesses have sales? If prices don't matter why would businesses choose to make less money per sale?
It's worth picking this apart. Prices not mattering is usually expressed in economics-ese as price-inelastic demand, and that's usually not what's happening. Sales are a mechanism for drumming up demand for a product, with the hope that the additional volume will compensate for the marginally lower margin.
>I'd urge reading up on revealed preference and product discovery
I'm not sure what point you are contesting.
>It's worth picking this apart.
They were rhetorical questions.
>price-inelastic demand
With this you could argue that the absolute price does not matter, but the relative price between products that can substitute each other do. In this comment chain it is being argued that this kind of device wins on relative price.
>Sales are a mechanism for drumming up demand for a product, with the hope that the additional volume will compensate for the marginally lower margin.
It is for increasing demand, but making a higher rate of profit on the item is not the main reason. Things like being able to clear inventory, or to learn about what the current demand curve looks like (to know if prices should be adjusted) are more common purposes.
Revealed preference only makes sense in a world of perfect information. They don't tell you the TV spies on you. In fact, the revealed preferences is for TVs that appear not to spy on you, that's why they hide that information!
> Revealed preference only makes sense in a world of perfect information.
No??? Revealed preference is dependent on what information is known. The analysis is made easier if the information is perfect, but that is not at all a prerequisite to being able to lean on revealed preference.
> In fact, the revealed preferences is for TVs that appear not to spy on you, that's why they hide that information!
Exactly! Consider though that, as the information landscape changes, so does the revealed preference. Notably, when things like TVs spying on their buyers comes to light, a preference can be revealed that buyers don't want TVs that spy on them.
Like, it's entirely rational for LG to want to hide this fact about their televisions, provided that they have the inkling that this would be unpopular. Their behavior in trying to suppress this press leads me to believe that they know exactly how unpopular this is, and they're trying to get away with it anyway.
It's true that the National Flood Insurance Program does this, but that's only for flooding (which, admittedly, is a big part of hurricane damage...). Flood coverage is however not a standard rider on homeowner's insurance policy products, and I'm also unsure whether it can ever be. I've only ever seen it offered as an additional policy product.
The concern over pricing below the actuarially fair value is well-placed[0], but I'd urge being precise.
I don't know if this is from the perspective of having learned Mandarin in elementary school first or if Japanese folks feel similarly, but reading words like, e.g., だいがくいんせい versus 大学院生 is actually a little more annoying because I have to scan more of the line to read the word in question. This is notwithstanding the effect that hiragana has in highlighting grammatical structures; it's a lot like setting off Finnish case endings and verb conjugations in a different color.
At least, that's the reason why I prefer still having kanji around.
Oh, hey. Nice seeing you here. I appreciate your work blazing some interesting trails with graphs and weaves in distributed version control. (Though, I must admit that I'm still left sort of scratching my head at the concept in a bytestream-oriented world instead of in the record-oriented world where I have, say, a deck of JCL cards and for which record-level inclusions and exclusions make sense.)
My criticism of TFA is grounded less in refusing to tell us about the secret sauce than it is, uh, not giving us anything at all technologically substantive to chew on, I guess. I can certainly use my imagination given my own experience in these particular salt mines, and I know that Steve and team are good for the technology, but I'm nonetheless wondering who is intended to be TFA's audience.
> I'm still left sort of scratching my head at the concept in a bytestream-oriented world instead of in the record-oriented world where I have, say, a deck of JCL cards and for which record-level inclusions and exclusions make sense
Long live CDC Update!
> who is intended to be TFA's audience
I got something from seeing that last diagram. True, I don't know what features that future work will bring, but see that what ever it is, they want to keep it mappable to Git. Staying mappable to Git is a tether that can limit or reward creativity.
You posted before Steve's response[0]. Does that help?
Yes! It's one of those things I've carried over to bitty box distributed environments.
> You posted before Steve's response[0]. Does that help?
It does a little, yeah, but I'll admit that I still feel somewhat teased by it rather than properly informed. As I wrote, I'm close enough to the technical details of this problem that I'm able to use my imagination. I wouldn't be surprised if some of my own proposed designs mesh up with what Steve and co. are doing.
I just want some more concrete messaging "from the horse's mouth," as it were, about what's being undertaken to mitigate shortcomings in Git's architecture for folks in the enterprise space of technology and procurement stripes alike who might find it an interesting contrast to GitHub Enterprise.
Certainly meant to be more of a teaser. We’ll get there.
It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say. But there’s just a lot of stuff that’s already working in existing systems that just hasn’t been productized because those companies aren’t trying to get into the version control business.
If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines. We think that workflow is very valuable for people.
We certainly know that people will want to know more details before they buy, and have shared stuff with prospective customers during the POC process. We’ll be more generally open about it over time.
> It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say.
If I can ever get around to writing about it or polishing up what I have enough that I feel comfortable with someone else looking at it, I'll poke you directly about some of what I've been working on over on the Fossil side of things.
> If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines.
Oh, hey, yeah. I'm not first-hand familiar with that tooling (I've never been at Google), but there's a similar(-ish) workflow I've been kind of missing from Plan 9, so I've been hammering on that a little. Something like `m1 client connect $remote_url --name $client_name` and `m1 workspace bind M: --client_name $client_name --name $workspace_name`, which is a slightly more obtuse take on running `9fs` to authenticate and bind the sources server into the current namespace.
I've found that, at the time of a client connecting, there's a lot of value for me in having, like, the last however many commit manifests and seldom much else as far as file data goes. I can pull down the raw blocks containing that data on demand, and at least for now, commit manifests contain a complete enumeration of what's in the file tree at that commit. That's enough for me to rehydrate a browsable filesystem projection of the repository before I decide that I need to mirror blocks locally.
I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.
reply