lambda

> We tax gasoline because it has negative externalities (same as us taxing cigarettes and alcohol).

This is contradicted by the difference in taxation for diesel fuel and heating oil (which is also the case in the US as well). Or used for generating electricity, as you point out.

I think that like many things in government, there are multiple reasons for taxing gasoline; negative externalities is one of them, but acting as a proxy for usage fees is another.

In the US at least, the federal gas tax is specifically earmarked for transportation expenses (https://en.wikipedia.org/wiki/Highway_Trust_Fund), which indicates that it's explicitly intended as a proxy for usage fees.

> Until relatively recently that's not really been possible (ANPR makes it possible), hence taxing fuel as a proxy.

Yes, but times change, and it is possible now. Lots of people bring up the problem of not collecting gas taxes to fund roads when electric cars usage grows. So every time someone brings that up, I suggest a fairly simple solution. Electric cars also weren't previously possible, but they are now, so rather than complaining about how we won't be able to fund the roads, how about charging more effectively for road usage.

> Given that the cost of a road is wear and tear (which a pedestrian or bike causes pretty much zero) > > Charging more than £5 a year for even the most extreme cyclist wouldn't make any sense.

I addressed this in my comment, indicating that it doesn't make sense to charge usage based amounts for cyclists:

> while a bicycle uses so much less (and pretty much equivalent to any use of public space like walking, using a scooter, etc) that it makes the most sense for that to just be accounted for out of the general fund.

There is the cost of constructing the roads in the first place, and wear and tear from weather, but that can be adequately accounted for out of the general fund; and when I say that, I mean the taxes collected at whatever level of government is responsible for paying for road maintenance that are not based on road usage at all, such as income tax, sales tax, VAT, property tax, or the like.

As someone who lives in the Northeastern US, I know very well that it isn't just vehicle weight that leads to road wear and tear; I've ridden on dedicated bike paths that were unmaintained, and frost heaves and roots of trees cause quite a lot of trouble, though it does take a lot longer for it to become unusable than roads used by cars and trucks.

Anyhow, I think we're mostly in agreement here. It is absolutely possible to do more effective taxation of vehicles based on their direct costs to infrastructure as well as other externalities.

> Because damage increases at 2^4, 1 mile car does about 1/100,000th of the damage of a lorry. A bike and car is a similar ratio - therefore if you charged a bike 1p per mile, you should charge a car £1000 a mile and a lorry £100 million a mile.

The damage per axle is proportional to the weight per axle to the fourth power. You multiply that by the number of axles to get the total amount of damage. Also, tandem axles do substantially less damage than single axles. This ends up at being a factor of about 5,000 between a passenger car and a truck, not 100,000.

It's still a big difference, and it's not accounted for by gas taxes, tolls, or vehicle registration fees, at least in the jurisdictions I've checked. Most of them seem to just go up proportional to the weight or the number of axles, not the fourth power of the weight per axle.

If you want to do it right, you'd charge fees based on equivalent single axle load times mileage, plus a congestion factor in congested areas based on the area taken up by the vehicle, times the amount of time it's within the congested area, times a time-varying congestion factor. And of course a carbon tax which covers all forms of carbon emission, and possibly a particulate emission tax that varies with density.

But despite how obvious it all sounds, it would be somewhat expensive to implement, and would face huge political opposition from industries and individuals who are effectively subsidized by paying into the highway systems way less relative to their usage than other users.

It seems to me that taxing something based on its use is a pretty much just a way to set up exactly these kinds of loopholes that continually need plugging.

Instead of taxing gasoline to help fill in the road budget, why not tax vehicles based on actual road usage, and their size and weight? Then you don't have all of the "electric cars and bikes don't pay gas taxes" stupid debates. An electric car uses just as much (if not more, due to weight) of the road as a gasoline car, while a bicycle uses so much less (and pretty much equivalent to any use of public space like walking, using a scooter, etc) that it makes the most sense for that to just be accounted for out of the general fund.

You could do this based on odometer, or based on automatic toll collection devices, or whatever. Automatic toll collection devices are probably better, because you could also include congestion charges for places where roadway real estate is low and congestion is high, like big cities.

The main reason to have taxes on something like fossil fuels would be for emissions reasons, as there is an external cost being imposed on everyone else by their emissions, and that money could go towards paying for health care costs, providing tax breaks for HVAC systems with air purification, carbon offsetting, and the like. But such a tax should be imposed regardless of use, as any use is going to wind up with the same or similar emissions.

Every person who is riding one of these scooters is someone who could have been using some other form of transportation.

Now, some of them may have switched from walking; in which case the small amount of sidewalk space taken up by a scooter not in use is an increase in use of space over the status quo; but not a very big one.

But many of them may have changed from driving. A car takes up far more space than a scooter. For each person who switches, you free up that much more space both on the streets while they're driving, and in parking at their final destination.

Having scooters available won't generally mean people will give up their cars. But a combination of scooters, bike facilities, car shares, buses, trolleys, commuter rail, and so on can make it possible to live in a city without a car, or by reducing a family from two cars to one.

One thing that bike and scooter share systems can help do is solve the "last mile" (or more likely "last quarter mile" or so) problem of public transportation. Walking to the nearest bus stop or train stop, coupled with the wait and then time to reach your destination, is a big factor in how efficient public transit is. Having options for being able to get to and from these places more quickly and conveniently can be a big benefit.

And parking spaces are being reclaimed, especially in cities with high levels of foot, bicycle, and public transportation travel: https://www.nytimes.com/2015/01/11/business/when-the-parking...

Anything that reduces the number of people who haul around a couple of tons of metal wherever they go, while burning black gold that funds crazy religious monarchies and failed democracies to do so, seems like a good tradeoff to me.

> Maybe try to figure out how to make the work fun?

I don't think this is the right approach, because you need the ability to focus on work even when it is not fun.

You do need something that makes the work rewarding in some way, but I wouldn't push to hard to try to make it fun.

> Or, try and instill a goal less of "getting the grade" and more "attain mastery of the subject"?

This was my approach in high school as well. It led to me being the one everyone wanted to study with because I picked up the material the best, but then I flunked classes because I never did the homework.

I would flunk classes that depended mostly on homework, and ace classes that depended mostly on tests. Since I had convinced myself that mastery was more important than grades, this reinforced my behavior.

Somehow, the acing the tests part allowed me to get into an Ivy League college. Which I then flunked out of because at that point, I couldn't get by without actually doing the homework and studying outside of class.

This pattern of behavior continues to be something I struggle with as an adult. I can be quite productive for short bursts of time, but have a hard time keeping on track with longer term projects that don't pay off immediately.

I think what you need is to learn the value of steady incremental work that only shows significant results after a long period of time. Basic reinforcement training techniques can be used for this; provide rewards for getting incremental work done, but better to provide them intermittently. Eventually work up from smaller rewards for smaller goals to larger rewards for larger goals.

I think that reinforcing consistency, habit, and small incremental progress rather than brilliance is a big part of what you need. The problem with brilliance is that you can easily get a lot of positive reinforcement for it; people are impressed at how well you understand something, at how much you know, at how quickly you pick it up. But even if you are better than average at picking things up and figuring things out, you will eventually hit the limits of what you can do through brilliance alone; there are some things that will just take long hard work no matter what, and then all of that reinforcement for brilliance comes back to bite you because you're not getting the same kind of reinforcement, and you can easily get stuck and lose faith in your self-image.

I need to deal with end user data a lot; which frequently has spaces in it.

I'm one of those people who finds perverse pleasure in writing portable Bourne shell, and doing so correctly. I know I spend far more brain cycles on it than I should; once it gets past a certain complexity limit, I should just switch to Python. But I always say "It's just a little bit more code, there must be a good way to do this," and there generally is, but only after passing over several bad ways to do it first.

Oh, and of course in doing so, I always try to minimize the amount of calling out to other processes. Why call awk when you could use `while read` instead?

You only get one array to work with in portable Bourne shell, $@. You can parse lines using read, and strip prefixes and suffixes using parameter expansion (`${parameter%pattern}`). It's a restrictive little language, with a lot of quirks and edge cases, but it always makes a nice little challenge to figure out how you can use it safely.

One of the constraints I impose is that spaces in pathnames should always be handled correctly; the biggest form of trouble you can easily get in is to forget to quote something or to parse something on space delimiters when it can include spaces. I've seen someone write a script that accidentally turned into an `rm -rf /path/to/important/data` because of poor handling of spaces.

I generally do not attempt to handle newlines in pathnames. While it's possible to do so in some cases with null delimiters, I have never seen a case of newlines in pathnames in the wild. Of course, this means that I have to make sure that these scripts are never exposed to anything that could contain malicious filenames.

Also, I move away from portable shell if it will really make the code too convoluted or fragile. For instance, if I need to parse long options (--foo), I use GNU getopt rather than the built-in getopts (with appropriate test to make sure the getopt I'm using is GNU, so it won't break silently on a system without GNU getopt), or move to a real language.

Anyhow, while I know it's counterproductive, the puzzle-solving part of me really likes trying to solve the problem of implementing something in portable Bourne shell.

> almost the majority

Trump was not elected by a "majority of Americans". He was not even elected by a majority of Americans who voted. In fact, he did not even win by a plurality of Americans who voted.

Because of weirdness of the way the Presidential election process works in the US, it's possible to win the election with fewer votes than your opponent; you just need a majority of electors, but most states allocate electors in a winner-takes-all fashion.

> there should be such travel restrictions

Voting for someone does not mean that you agree with all of their policies. It's possible that a large number of Americans disagreed with those policies, but preferred other policies Trump held over Clinton, like lowering taxes and reducing regulations. Or that enough people were sufficiently uncomfortable with a woman as president. Or that enough people were convinced by the combination of Clinton conspiracy theories with the email scandal.

> From user-space? hold my beer.

You can follow that link to see how it does it.

It has two modes of operation; one in which it uses ptrace with PTRACE_SYSEMU, which was implemented so that User Mode Linux could intercept all syscalls. This works in all environments, whether or not hardware virtualization is available (included VMs which don't enable nested virtualization).

The other is that it can use KVM, without any hardware emulation, to utilize hardware virtualization support and do it more efficiently.

Neither way relies purely on user-space; they both use kernel features that are designed specifically for allowing one user-space process to virtualize another.

Rust is increasingly frequently taught in schools; and when Haskell or OCaml are taught in schools, it's usually as part of a "programming languages" survey course where you learn a little bit of a few languages of different paradigms, and I expect that most students won't really retain much from the class a year or two later unless it helped them develop an independent interest in functional programming.

Except it wasn't Amazon's domain they were using; it was souq.com, an online shopping site in the Middle East that is owned by Amazon.

Ah, looks like the registrars were still coming online when I tried. When I first tried Gandi, it didn't seem to like .app, but now it does and lets me choose "landrush," which I assume is the way to buy a domain during the EAP.

Is there a list of which registrars are participating in the early access period? None of the ones I tried seemed to recognize .app.

This particular article is about a Firefox developer deciding to spend a little bit of time applying some of his knowledge on profiling and optimizaiton to the Rust compiler, without being a core compiler developer and involved in any of the big performance-related initiatives that are ongoing.

So it's going to focus on a few micro-optimizations that someone can find by doing a little bit of profiling and making some small, isolated changes.

This is the tracking ticket for the larger-scale reworking of the compiler internals for better performance: https://github.com/rust-lang/rust/issues/48547

I think there are a couple of major reasons why rustc is slow, and then a lot of ones which just boil down to "we haven't gotten to that yet."

One of them is that rustc was originally written as a self-hosting compiler while the language itself was still in flux. So for the early years, there was a lot of churn just due to keeping up with the language changes, and just implementing the language, not being able to really focus on performance and optimizations.

Once the language stabilized, the compiler was not really the best written piece of code in Rust because it had been written before some features existed, before people had figured out idiomatic ways to do things in Rust, and because it had been written with the assumption that it could just work with the AST and a high-level IR and translate that directly to LLVM and let LLVM handle all of the optimizations.

Shortly after the 1.0 release, a big project began to define and use "MIR", a mid-level IR between the high-level IR that is much closer to surface syntax and LLVM's low-level IR for generic optimizations and code generation. That project took a while to complete, but has finally been completed; that lays the base for new language features, improvements in existing language features, and being able to do better work on optimization; it has led to several major improvements in compiler performance that have already landed.

Another issue is, pretty similar to the C++ issue; Rust has generics, which offer many of the same compilation issues as C++ templates. They are constrained a bit more than C++ templates, and don't have the SFINAE philosophy, so I think it's possible for the compiler to be smarter with those, avoid monomorphization in some cases, and so on, but it is still likely that in heavily generic code, you may not be able to do much better than heavily templated C++ code.

There are also some issues that are just holdovers from the fact that language evolution, correctness, and ease of development was prioritized over compiler performance in the the initial versions; for instance, the de-sugaring of high-level constructs causes rustc to produce a lot of LLVM IR that LLVM winds up just optimizing away. Having rustc be smarter and produce less of this is a major optimizaiton goal.

A few major examples of improvements that are underway or being considered: sharing generic code between crates (if two crates in your dependency graph each instantiate Vec<i32>, you shouldn't have to compile that twice), sharing closures between generic instances (if there's a function that depends on some generic type T, but a closure in it that does not, there's no need to duplicate that closure for both instances of that function), doing some inlining in MIR (lots of high-level Rust features depend on inlining to produce "zero-cost abstractions", so doing that earlier in the process may reduce the amount of work that LLVM has to do).

And then there are improvements for allowing for better parallelization and incremental compilation, better link time optimization, and so on.

tl;dr: it will get faster, in a real sense, not micro, but in the end it will be constrained by language design to be closer to the C++ compiler end of the spectrum than the Go end of the spectrum

So that you can easily rebuild and re-run each one with difference in build settings, instrumentation, etc, and get comparisons between the baseline and the modified version, without having to check out a different branch each time.

Sometimes it's just quicker to work with two separate working directories than switching branches in one.

Ah, I'd forgotten about that usage. Thanks, that does make a little more sense.

In what way is GEDmatch "open source"?

It looks like it's free as in beer, but I don't see any reference to source code.

The thing is, bad questions don't really matter in the grand scheme of things. If a question is bad, and it gets no answers, it will just languish. You don't need to do anything about it. Maybe have an auto-close after a week of inactivity or something. It probably doesn't really matter, as long as you actually sort questions by things like score, answer score, etc, so the bad questions just go down to the ends of all of the lists on pages no one ever browses to. Bits are cheap, a few bad questions being present on the site and not closed doesn't really hurt.

I don't expect every bad question will lead to a valuable mentorship opportunity. I've certainly encountered my fair share of those that weren't worth spending my time on.

Bad answers are more problematic; there's good reason to be vigilent about those.

And of course spam, obvious homework, and just completely incomprehensible questions should be closed instantly.

What I see is questions which are not phrased well but you can actually work out what they're asking being closed. So by the time I've written up an answer, the question is closed, and my answer is wasted. I can copy my answer elsewhere, and vote to re-open, maybe after editing the question to make it more clear, and it might get re-opened, but then I have to spend a lot more time and attention waiting for that. By closing out questions too aggressively, not only are people putting off newcomers, but also wasting the time of those answering questions.

> The first post review and triage queues are intended for providing this help. You can see that this doesn't always work well ( https://stackoverflow.com/review/first-posts/19570266 or https://stackoverflow.com/review/first-posts/19569647 - note the not even trying to fix the grammar of the question or asking for the necessary information or providing help on how to improve the question, just no action needed)

Yeah, one of the things that really frustrates me about the review process is that they just incentivize taking some quick and easy action, not actually doing the right thing.

Effective moderation is not easy, and a very different skill set than answering technical questions, but the rep needed to perform many of these mod duties is just given to those who accrue enough rep.

Ooh, got to love any article about intellectual property that starts with a analogy to the game Paranoia.

OK, this may be a new feature, since I stopped paying close attention several years back when I got frustrated with the direction the community was going.

But I don't think that "audit" questions do much to address my issue. They enforce that someone is paying at least a little bit of attention; but they still emphasize things like voting to close a "bad" question, rather than helping the person asking the question ask a better question. They might help a little bit with people who are just not paying attention at all for questions which are black and white as to whether they are "good" or "bad" (such as blatant spam), but they don't help at all with pushing the "grey area" questions in the right direction.

That's the crux of the issue; the community is so focused on just cleaning up bad questions by closing them, rather than working with the person asking to help get them to be able to work better with the community.

> No one wants the rules to change in a game that they perceive that they are winning (or have won). Moreso if they worked hard to win.

I'm one of those people who wants the rules to change in a game that I'm already winning. I worked hard to win; I fully engaged in the gamifiction, spending days at a time making sure I hit the max daily rep level, optimizing how I answered questions to get the highest score.

Even then, I tried to focus my optimization on ways that would help people more. For instance, one way to optimize is to post a very short quick answer, so you are able to get early upvotes before there's been a flood of answers for a question; but I would then edit and flesh out my answer. This has both advantages for reputation, since I could get early upvotes, and then later provide a more detailed comprehensive answer that would be likely to get further upvotes. It's also helpful for the person asking; it's possible that the very quick reply will be helpful, so they get an answer soon, but it's also possible that the more detailed reply with references to docs is what they need, so it's a way of making the gamification actually work to help people out more.

I think one of the big problems is when they added gamification of moderation. They added the review queues, which prompt you to review questions and answers that had been downvoted, voted to close, edited by other people, etc, and gave out badges based on numbers of reviews done. This means you'd go through a queue of questions and answers on topics you might know nothing about, and be prompted as for whether or not you agree with someone else's close vote or edit or the like.

When a question is not great, you could just vote to close it, or you could try to engage with the person asking the question and help edit it into a better form. I generally try to talk to the person asking and edit the question to be better; but getting internet points for getting through a lot of reviews quickly incentivizes people to make quick judgements, sometimes on topic they don't know much about. After they added the review queues, I found a lot more questions were being closed before you had a chance to answer or to engage with the person in comments to get them to clarify their question.

And while lots of people these days argue that closing a question is just a way to indicate that it's not up to standards but it can be fixed and re-opened, for people new to SO who aren't familiar with the culture it feels like a slap in the face and a rejection of their question. After a question is closed, it's a lot more likely that they'll just delete it, delete their account, or just stop participating.

Anyhow, yeah, there is an aspect of people not wanting to change the rules of a game that they are playing and winning; I just wish either the incentives were changed, or more people would take the view that the point of the scoring is as a rough measure of how much they are helping people out, and helping people out is the ultimate goal, rather than being an end in itself.

And I should also say that I'm not against closing truly bad or unsalvageable questions; I've had cases where I've tried to engage with someone to make their question better, and they just haven't made any effort, or cases in which people are obviously asking homework questions. But I really think that there should be some effort to help people out with asking their questions before just blindly deciding to close them out.

Except part of the problem is that it's not even doing a very good job of giving a good authoritative answer either.

In the earlier days, it was designed to straddle the line more with a wiki; there were "community wiki" questions and answers, but people couldn't get reputation for those, and if someone's question or answer was edited enough it would automatically converted to "community wiki". However, people would get upset about losing the potential karma, so that feature was taken away, and major edits to other people's answers that change the meaning of it started to be discouraged.

However, there's no way for anyone other the person who originally asked a question to change which answer is accepted. So if someone asked a question 10 years ago, and someone gave a bad answer or an answer that is now out of date but which was accepted, and those two people have now left the site, there's no good way to get the first answer to the question to be the correct one. You can write a better answer, and even if it's upvoted, there will still be the accepted answer ahead of it.

I've tried following the original, more wiki-like spirit of the site by editing such answers, and then gotten other people reverting me because the edit would "give reputation to someone who didn't deserve it."

I feel like the incentives, and balance, and community of the site are just off right now. It still serves a useful purpose, but it could be a lot better, but whenever I've tried making suggestions for how to improve, I've gotten so much pushback that I've just given up.

> The additional level of moderation doesn't seem to have added much value over my time participating. The closest thing I can think of as nice is combining duplicates, though moderators often seem to miss subtle differences between questions and in some cases information gets lost in the end. Generally, the moderation focus often seems legalistic or driven by artificial incentives rather than primarily focused on improving the breadth, depth, and quality of the site as a technical resource.

The problem is, they added the review queues, which prompts people to review questions on topics they might know nothing about, and give badges based on how much people review. So people go through those review queues and might be motivated to just get through things quickly without thinking very much about the effect of what they are doing; there is no meta review, no downside to just making hasty decisions that just prevent other people from engaging in useful discussion.

I'm a high-scoring user who has been put off by this exact behavior. The problem is, the behavior is pervasive among other high scoring users, and whenever I advocate against this kind of behavior, I get a whole bunch of pushback about it.

No one seems to want to change. No one seems to want to even engage with criticism about the culture; they just push back and pile on when criticism is brought up.

After a couple times of seeing this kind of behavior, and pushing back, and then getting piled on by people rejecting the criticism, I started to get tired of it and withdrawing somewhat. Later on, I some blatant sexism in a chatroom that was laughed off when I pointed it out to the moderators.

I've pretty much given up. I'll occasionally reply to questions people ask on my existing answers or if I see something that needs an answer or edit I'll make it, but I don't really feel like fighting the overwhelmingly elitist, sexist, and uncaring attitude on the site.

I think that this post is a nice gesture, and good that it's coming from the company and not just another user, but I worry that's it's much too late. The community has been attracting people who like it the way it is, and repelling people like me who don't, for a long time.

You would generally want the general purpose string type in your language to always be escaped when serializing, and only allow avoiding that if you opt-in explicitly.

So, for instance you'd have an H1::new(contents: TextNode) constructor, and you'd have to build a TextNode; if you build TextNode::new(text: &str), then it would escape it. If you wanted to explicitly pass in raw HTML, then you'd need something like HTMLFragment::from_str(&str), and it would parse and return the fully parsed and appropriately typed fragment object that could then be used to build larger fragments.

There might be some way to unsafely opt out, like HTMLFragment::from_str_raw(&str), that would just give a node that when traversed would just be dumped raw into the output, but that would be warned against and only used if you wanted to avoid the cost of parsing and re-serializing some large, known-safe fragment; it wouldn't be what you would normally use.

What good work is it doing in HTML?

In HTML, as far as I can tell, it appears to be copying features from the WHATWG standard, paraphrasing them, and including them in their standard, with only a small notice on the acknowledgements page the the HTML standard contains parts derived from the WHATWG standard.

The browser makers did participate. They participated in the W3C working groups up until they were shot down when trying to propose to work on features that users actually wanted and would be backwards compatible rather than backwards-incompatible XHTML 2.0.

The browser makers then proceeded to do their work on rich web applications, with features like canvas and XMLHttpRequest, as well as actually putting together a spec for how to consistently parse HTML that would be compatible with real content, in the WHATWG.

When it was clear that the WHATWG standard was the one that actually mattered because it was what was actually implemented, the W3C invited them back in to start working on the standard together. That's what HTML5 was; the W3C agreed that they would start from the WHATWG standard, that they could have the same editor (Ian Hickson), and they wound down the XHTML 2.0 group.

However, various people involved in the W3C process proceeded to use bureaucratic moves to raise formal objections to things that had been changed, and escalated the issues above the editor. Eventually, he got fed up and left the process, and most of the browser vendors proceeded to continue working through the WHATWG. Microsoft was the last holdout, but eventually they too left the W3C process and moved over the the WHATWG as well.

So, the browser vendors have tried to work directly with the W3C on the HTML spec twice, once before the WHATWG split off and once as part of the attempted reconciliation. Both times, they were stymied by other people involved in the process who were more interested in purity and process than actually providing a forum for working out a good specification for real world implementation.

Well, flexbox was much simpler and easier to standardize on and implement sooner. It has been available in all major browsers since 2015.

Grid is great, and now works in most places, but it was good to have flexbox while grid was still in process; it only became available in Edge, in the final form, late last year, making it now available on all major browsers.

You're always going to have cases like this; where there's something that's simple that works now, and something better that comes later. If you always wait for the better one, it will take forever for things to get done. Not to mention that flexbox is probably simpler and easier to understand and use for some of the simple use cases, so people will still probably continue to use it despite the fact that grid is available.

You can give input to the W3C without that, but yeah, it's the input from the paying members that counts the most.

Additionally, the W3C has some private mailing lists, does private working group meetings, and so on. So yeah, the WHATWG is a lot more open when it comes to input.

I'm pretty sure Ian Hickson is no longer involved with the WHATWG. I think he's working on Flutter now (https://news.ycombinator.com/threads?id=Hixie).

In fact, I would say that it's not quite like a cathedral and bazaar here.

The W3C is like a legislative committee. Lots of things done by committee vote. Formal process that must be gone through to advance beyond committee. Petty politics that screw with actually getting things done. The committee chair having the ability to block work by procedural means.

The WHATWG is more like an open forum. The work happens out in the open. Anyone can participate in the discussion (the W3C committees frequently have private meetings, there have been private mailing lists, and so on). There are a few people who have commit rights to the repo, so who actually control what goes in and what doesn't, but they are generally willing to let in changes that have broad support, and are implementable, rather than letting such features get held up by political processes.

Besides the difference in structure, there's just a difference in attitudes. The W3C tends to strongly favor certain principles, like accessibility and modularity, but to the exclusion of compromise for technical reasons or real-world reasons. They also seem to have a tendency to get very attached to particular ways of doing things, without being willing to compromise. I think the biggest example of this was longdesc; it was never implemented properly in pretty much any browser, and very few people actually followed the spec and had it point to a URL (many people just copied the alt tag, or provided a longer description in the attribute instead of a URL), so even if browsers or screen readers had implemented it, the content wouldn't be useful. But people in the W3C made a big stink about removing this, and spent a lot of time and effort fighting and litigating over that, rather than actually trying to work on a different feature that could gain wider adoption.

The WHATWG tends to take a more pragmatic approach; pave the cowpaths, if there are differences between implementations do it in the most sensible way that preserved compatibility.

Now, what the WHATWG has produced hasn't always been the best; there are times when it's made mistakes in its approach. The drag and drop spec, which had been reverse-engineered from IE's drag and drop support, was a pretty bad; not sure if it's gotten better since.

But overall, the WHATWG has been a lot more productive in getting standards done that are actually used on the web, because they involve the implementers, and don't override them with tedious, drawn out, political battles over obscure features that no one uses.

I agree with you that we do need to do better about writing more robust software, and type safe languages are a good way to do that.

But what you're saying is as if you suggest that since the metric system is more consistent and more widely used than the English, I as a bolt distributor should start selling my bolts in metric sizes, despite the fact that the nuts that everyone has are in English sizes.

The browser vendors, at least, are working on implement their browsers in more type-safe languages (https://github.com/servo/servo), but even still they have to work with the content that is produced by thousands of different languages, frameworks, and tools, and millions of hand written HTML files, templates, and the like. Just turning on strict XML parsing doesn't make that go away, it just makes your browser fail on most websites.

Ian Hickson, the editor of the WHATWG spec at the time, acted as editor of the HTML5 standard at the W3C for a while after the two groups agreed to work together. However, the committee had chairs who could override the editor.

However, despite a couple of years of effort working together, the W3C process allowed for a lot of people to raise objections that re-litigated a lot of things that had already been decided in the WHATWG process, or just didn't have implementer support, or whatnot. This led to the HTML5 draft specification being stale, as these objections held up migrating the editor's draft (which was the WHATWG specification) to the TR on the W3C site.

So lots of people who still saw the W3C as the "official" source of HTML were brought to an out-dated copy of the standard, because publishing more interim drafts was held up with all kinds of bureaucracy; and the W3C objected to linking to the WHATWG copy to suggest a more up to date version with bug fixes, so there was a fight over this.

The combination of the W3C's heaviweight process making it easy for lots of people to raise objections to slow down the process, and having the ability for those objections to be escalated above the editor, eventually made Hixie give up on editing HTML5 and just go back to editing the living specification.

The thing is, a specification only makes sense if it's actually implemented. Lots of non-implementers raising blocking issues on wishlist features, and then having to take the time to formally resolve all of those issues, does not make for a productive environment; and when the resolutions of those issues are escalated to chairs of the group or higher up in the W3C against the support of the implementers, it really hampers the process of coming up with a productive spec.

By the way, I haven't followed this drama in a few years, but taking a look at what's happening now, it looks like the W3C is essentially just plagiarizing the work of the WHATWG.

Features are generally discussed in the WHATWG, or implemented by browsers and then proposed, and the spec writing goes on there. After the spec is reasonably well worked out, the W3C is copying and editing some of the text into their standard.

Now, the WHATWG spec is under a Creative Commons attribution license, and the W3C does provide a small attribution in the acknowledgements section, so they are not violating copyright.

However, what they are doing essentially amounts to plagiarism as they are presenting themselves as the source for the standard. The introduction to the standard doesn't indicate that the actual work is going on in another group; they invite people to make comments on the W3C's GitHub. This is confusing, it gives people an out-of-date view of the standard, and it seems to be a move to make the W3C seem to still be the relevant authority when it's basically just cloning the standard from the WHATWG, but with enough wording and formatting differences that it could conflict and is hard to tell when it would.

Alternatively, they could fork the standard but do so more in the way that distributions package packages; take what's from upstream, have a separate set of patches that they apply on top that make it clear what the differences are. For instance, those patches might apply their layout, their disclaimers and the like, possibly disable some things that they think are underdeveloped or contentions and likely to change, and otherwise mostly just freeze the text. They could push any patches that they thought were for meaningful differences that they've fixed to the upstream project. They could properly attribute the WHATWG spec as the original source at the very top of the article, and list the editors of the WHATWG spec as the primary editors and the people doing the W3C release as maintainers of that particular fork.

But instead, they are listing as editors people who are basically just doing light paraphrases of the WHATWG spec.