Certainly helped!
3,627 karma · joined December 12, 2011
Your criticism may be reasonable; but does it really cut at the heart of the issue? Also; some of these options are occasionally oddly named, so let's not ignore the possibility that the article's author is right on this.
However, the example is a slightly tricky basis to form an opinion on best practice: you're proposing that the clearly named example function name is_enabled is better than an expression based on symbols with gibberish names. Had those names (x, foo, bar, baz, etc) instead been well chosen meaningful names, then perhaps the inline expression would have been just as clear, especially if the body of the if makes it obvious what's being checked here.
It all sounds great to introduce well named functions in isolated examples, but examples like that are intrinsically so small that the costs of extra indirection are irrelevant. Furthermore, in these hypothetical examples, we're kind of assuming that there _is_ a clearly correct and unique definition for is_enabled, but in reality, many ifs like this have more nuance. The if may well not represent if-enabled, it might be more something like was-enabled-last-app-startup-assuming-authorization-already-checked-unless-io-error. And the danger of leaving out implicit context like that is precisely that it sounds simple, is_enabled, but that simplicity hides corner cases and unchecked assumptions that may be invalidated by later code evolution - especially if the person changing the code is _not_ changing is_enabled and therefore at risk of assuming it really means whether something is enabled regardless of context.
A poor abstraction is worse than no abstraction. We need abstractions, but there's a risk of doing so recklessly. It's possible to abstract too little, especially if that's a sign of just not thinking enough about semantics, but also to abstract too much, especially if that's a sign of thinking superficially, e.g. to reduce syntactic duplication regardless of meaning.
Consider a though experiment: In a fast-growing world, taxation limited to profits when honestly applied and without exploitable loopholes (not an obviously satisfied precondition) might be able to cover costs of shared concerns, i.e. government's primary business. But imagine for a moment that that growth were to significantly slow or even stop - without profits, taxation could fall to a trickle (limited to those niches that have zero-sum profits yet lack the ability to amortize over loss making periods and lack the ability to strike a deal to fiscally merge with a loss-making business for tax purposes). Clearly, that's not sustainable. I think it's hard to imagine that the the only "just" way to tax is one that is fundamentally dependent on permanent significant growth, even if we've been lucky enough to live in such a world for quite a while, at least on paper. Given how some costs (e.g. depletion of natural resources and pollution) aren't on the fiscal books, and that from an idealistic free market stance one might prefer to include those costs on the books, the true global growth is surely already lower than it looks on paper, even if it's still hopefully positive.
Doesn't mean rust will ever grow like that, but merely slow adoption doesn't sound like a death knell by itself to me.
However, to me this mostly looks like a practical issue, and the traditional dogma that a broader tax base is a better one likely holds here too. Taxes should be on all three categories, and for both legal and real persons - and thus each specific category lower (and in particular thereby reducing the height of specific niche corners cases such as this one, and also reducing the opportunity to game the system).
Also, it's interesting to listen to anecdotes like this, but caveat lector; the article's author's experience may not be the norm; and the issues they experienced may be due to the specifics of norway's taxation system or their personal choices, not the principles behind it; and last but not least as long as money can flow mostly freely between tax systems it's not enough for a system to be fair and well designed in a vacuum; it also need to consider how shifting wealth/income/profits across borders will affect outcomes.
To my mind, this is all pretty orthogonal to justice. Clearly, you see that differently. Why does this smack of injustice to you?
Anyhow, I can't say I'm thrilled that some deeply nested subtree of divs for instance might be closed by a open-button tag just because they were themselves part of a button, except when... well, lots of exceptions. It's what we have, I guess.
It's also not a (fully) solved problem; just earlier this year I had to work around an issue in the chromium html parser that caused IIRC quadratic parsing behavior in select items with many options. That's probably the most widely used parser in the world, and a really inanely simple repro. I wonder whether stuff like that would slip through as often were the parsing rules at all sane. And of course encapsulation of a document-fragment is tricky due to the context-sensitivity of the parsing rules; many valid DOM trees don't have an HTML serialization.
Much as nuclear energy is both green, reliable and safe - it's also hard to imagine it becoming cost-competitive at the scale that wind and solar are. Better regulation might help a bit, but even in places like South Korea where nuclear costs are unusually low and solar/wind costs unusually high they're basically competitive - and I wouldn't be surprised for solar+wind to fall in price there too, once they've slightly more mass in the market.
The focus on wind+solar over nuclear is less due to greenwashing that due to penny-pinching.
- That it's not feasible to incorporate this style of traffic design elsewhere since cultures differ
- That we need to consider how traffic engineering (eventually) shapes user behavior.
I'm convinced the second one is the one that quite quickly is much more predictive of outcomes. These Dutch-style intersections make the safe behavior natural and intuitive, and habits will adapt quickly where they're used _consistently._
To be explicit: the whole point of road design like this is that it does _not_ rely a lot on training users on details of the rules of the road. In fact, precisely those remaining quirks (e.g. scenarios when traffic approaching on-road white yield triangles nevertheless has the right of way in the Netherlands) are the exceptional vestigial weakness that proves just how obvious the rest is.
Of course, if every town picks it's own patterns to follow, that's going to be less predictable for road users, and thus frustrating and ultimately dangerous.
On the other hand; the size constraints on storage will be less severe than those on tags in each http request, so perhaps this is being overly clever with risks of accidentally huge payloads suddenly being sent along with each request.
Law and ethics are barely related, in practice.
For example in the vehicle emissions context, it's worth noting that even well before VW was caught the actions of likely all carmakers affected by the regulations (not necessarily to the same extent) were clearly unethical. The rules had been subject to intense clearly unethical lobbying for years, and so even the legal lab results bore little resemblance to practical on-the-road results though systematic (yet legal) abuse. I wouldn't be surprised to learn that even what was measured intentionally diverged from what is harmfully in a profitable way. It's a good thing VW was made an example of - but clearly it's not like that resolved the general problem of harmful vehicle emissions. Optimistically, it might have signaled to the rest of the industry and VW in particular to stretch the rules less in the future.
Additionally, Microsoft has an outsized influence on the C# ecosystem. As a result, they wrote quite a few architectural and style guidelines that, naturally, target themselves. It makes sense for a hyper-widely distributed library to consider things like binary compatibility as critical features, but the design rules that follow from that have zero utility for apps, and low utility for most libraries. The C# ecosystem also has an unhealthy veneration for MS provided code. While I'm sure most of the authors are quite competent, there's less experimentation and fewer hidden gems because the ecosystem is tilted towards being followers behind the framework providers path.
As a result, it's much harder to refactor code in that style than code in a less (runtime) flexible style, and it's worse when the libraries heavily used are frameworks that have so many extension points. There's a tradeoff between runtime flexibility and codebase flexibility, and the default .NET C# style heavily leans towards runtime flexibility, which isn't a good tradeoff for most software.
By good ARM, do you mean specifically (and only) Apple? Given their budgets (both financial and transistor), their very long history and investment into their chips, their deep integration of stuff like memory and GPU, and their tendency to be a process node ahead of their competitors, Apple is a particularly hard example to interpret when it comes to ISA impact.
Hard to imagine another company making all those choices, since they all have costs too, which many won't be willing or able to bear, and some of those costs (like the lack of flexibility due to the deep integration) are possibly a non-starter for many niches.
It's pretty clear that the ISA/frontend is much more impactful than the data-width on this set of workloads, and that also seems to jive with more indirect evidence from performance patterns more broadly.
i.e. it's the new instructions (and potentially register width) that matter significantly more than the actually wider data-path.
Even if the spec just listed occasional version and the webpage could choose which one; that means a potentially tricky maintenance burden on browser to support old versions of a potentially no longer supported sqlite, and each version is another megabyte.
Why not then just choose this solution, and let each website pick its own poison?
If the concern is the repeated downloads of common resources, well, we've accepted that for other CDN's too, and a solution for shared caching of common dependencies would in any case be more valuable than merely for sqlite.
The current approach seems better than a browser-provided version.
People sound like they are angry because they feel it's extortion - and I don't think it should matter what the judicial technicalities of some law say about some legislative definition of "extortion".
And in any case; ideally the law follows common sense not vice versa, so in the event that the law disagrees with common sense as a person with no stake in this game the legal ruling just doesn't interest me except as to the degree of damage done due to the judgement.
Finally, there's a very good chance all of this will be settled and we either won't hear about the terms in detail; or we'll hear some agreed upon compromise that won't reflect either of the party's actual beliefs, nor common sense, nor a judicial ruling - merely some negotiated settlement.
It's pretty easy to forgive mistakes if you believe people made them for the right reasons, and especially if those reasons are important and the consequences of the mistake fairly diffuse, as might be the case here. Also, given Zeldman's prior work he clearly believes in the power of big ideas; he's surely more likely than most to see the need for pain now to prevent much more later on.
Doesn't mean we have to agree with him; just that it's not hard to empathize with it.
Even the kind of leverage/threats he was making aren't abnormal. What's threating to defame or emphasize looked at from one side is offering to sign a non-disclosure or non-disparagement from the other.
The content of these threats may be less tolerable than other negotiating tactics, but they are entirely normal in negotiations we don't label extortion. He's not donating horse heads.
As to pulling access to plugins - if at its heart this is about freeloading, then that action seems proportionate in principle as it's one of the few possible leverage points - it did not block existing installations, merely new ones - but the effect was likely poorly thought out as it relates to updates. Then again, WP engine had a workaround in pretty much no time, so even the update issue is not a big one; i.e. that power you state that Matt has does not appear to actually exist.
The whole saga seems very much in the eye of the beholder. Whether the end result will end up achieving Matt's apparent aims is of course another.
I doubt current wordpress sites will suffer much long-term harm in the crossfire, but they will perhaps have a short-term mess. But the power balance shift may well harm the overall ecosystem severely. The loss of trust alone is problematic; and if this takes down the de-factor maintainers of the wordpress core, which seems possible right now, that would be bad. Or worse, if it convinces them to go semi-closed source, and they then drag out their decline in a way that makes a finding momentum for a replacement hard.
People routinely make choices that have long term outcomes they don't agree with; and we all know they do and thus the information industry quite explicitly exploits this - the difference between what we "really" want and short term impulses has never been larger due to such intentional exploitation.
Secondly, network effects. The way intellectual property happens to work allows platforms to effectively own networks their user's create. A group of entirely rational users might well each individually choose to join a network since for them doing so is extremely valuable, even in the knowledge that it'd be better for everyone to choose a different alternative if they could manage to do so collectively, especially since IP laws mean it's quite unlikely for any such alternative not to eventually develop similar weaknesses. Business plans work when profiting off content involves controlling it simply because that's how the law pretty much defines it - IP doesn't support creativity directly, it supports monopolies and leaves the support to exploiting that monopoly.
The implied argument sort of infers a cause by default - people are choosing the proverbial tiktok (or whatever other new thing), people are rational, therefore there must be a reason, therefore tiktok is better for people (and we don't need to know why). But each of those steps is quite weak; the overall link is tenuous at best.
Additionally, I find that in practice such "unusual" code is actually beneficial - it often makes it easy to see at a glance that the code is somehow in sync with some external spec. Especially when it comes to implicit usages such as in (de)serialization, noticing that quickly is quite valuable.
I'd much rather trash every languages' coding conventions than use subtly different names for objects serialized and shared across languages. It's just a pain.
- greppability does not preclude IDE or language server tooling; there's often special cases where only certain e.g. context-dependant usages matter, and sometimes grep is the easiest way to find those.
- projects that include multiple languages, such as for instance the fairly common setup of HTML, JS, CSS, SQL, and some server-side language.
- performance in scenarios with huge amounts of code, or where you're searching very often (e.g. in each git commit for some amount of history)
- ease of use across repositories (e.g. a client app, a spec, and a server app in separate repos).
I treat greppability as an almost universal default. I'd much rather have code in a "weird" naming style in some language but have consistent identifiers across languages, than have normal-style-guide default identifiers in each language, but differing identifiers across languages. If code "looks weird", if anything that's often actually a _benefit_ in such cases, not a downside - most serialization libraries I use for this kind of stuff tend to do a lot of automagic mapping that can break in ways that are sometimes hard to detect at compile time if somebody renames something, or sometimes even just for a casing change or type change. Having a hint as to this fragility immediate at a glance even in dynamically typed languages is sometimes a nice side-effect. Very speculatively, I wouldn't be surprised if AI coding tools can deal with consistent names better than context-dependent ones too; greppability is likely not specifically about merely the tool grep.
And the best part is that there's almost no downside; it's not like you need to pick either a language server, IDE or grep - just use whatever is most convenient for each task.
If this trend were merely about format, then websites that just host videos would be a viable model - they're not really. I think this is more about the power of platforms than of the format.
I'm sure the format _also_ helps, given how donation-dependent small-scale publishers are which works best if publishers are humanized, but I'd guess the more impactful matter is the way platforms can keep consumers onboard and help them discover new publishers than the format.
In the very unlikely hypothetical that youtube were to allow other formats such as articles or images, I suspect many publishers would be able to make that work - on that plaform, as opposed to on a standalone website without the traffic attracting algorithm to help crowdsource valuable content for users.
It's also definitely going to depend on the cost of the hash function and comparison function - for something like strings, where those can be quite expensive, binary search probably has a better chance of applicability than for guid's say.