- It does not.
- Not it's not.
- What's hard in this case is that you end up making it 80% of the way through the article before you start to wonder what the heck this guy is talking about. So you have to click away to another page to figure out who the heck this guy is, then start again at the top of the article, reading it with that context in mind.
One word would have fixed the problem. "Why does the Mozilla API blah blah blah.". Perhaps "The Mozilla implementation used to...". Something like that.
THAT is not hard.
- Your data sounds a bit anecdotal. :-P
Here's my anecdotal data. Number of blogs that I personally follow: zero. And yet, somehow, I end up reading a lot of blog posts (mostly linked from HN, but also from other places in my webosphere).
(More than a bit irritated by the "Do you have data to back that up" thing, given that you don't really have data to back up your position).
- The benefit accrues to developers, who get more consistent behavior across browsers. In the bad old days, errors that one browser might silently recover from would trigger unspecified recover behavior on other browsers that wasn't consistent.
- Sure. But it's not the browser that did that. You see the dialog because the app HANDLED the error condition, and application code displayed an dialog. Had the error not been handled, the browser's behavior is to log a message to the browser console (which you, as a user, never see), and carry on, pretending that the error never happened. So the page would have continued on in some non-functional, or half-functional state.
- ... then the "owners" will own EVERYTHING. Fixed that for u.
- Google search results: a dozen sponsored links; a dozen links to videos (which I never use -- I'd rather read than watch); six or seven pages with gamed SEOs; if you're lucky, what you actually want is far down near the end of the first page, or perhaps at the top of the second page; the other 700 pages of links are ... whatever. Repeat for our five times with variously tweaked queries, hoping that what you actually want will percolate up into the first or second page.
Claude: "Provide me links to <precise description of what you actually want". Result: 4 or 5 directly relevant links, most of which are useful, and it happens on the first query.
Claude is dramatically more efficient than Google Search.
- My specific use-case was breaking syllables in lyrics embedded in sheet music so that they line up with the associated notes on the staff above. (I write a lot of lead sheets).
- hamburger icon: originally, in older Android UI guidelines, provides access to a list of items that can be used to navigate between parts of a large UI. But at this point, pretty much evolved to mean "click to access a menu" on UIs that don't have a menu bar.
Three vertical dots: "More stuff that doesn't fit on a toolbar because the display on your current device isn't wide enough".
Three horizontal dots: click this item to access a dialog.
Point-down triangle: Select an value from a list.
There may be slight variations depending on the UI guidelines for the platform you are using (or designing for).
All enormously useful icons that provide specific context and meaning. I can't say that I've ever seen a piece of serious software that abuses those conventions.
- The entire English language is a series of unambiguous errors that have been rescued by the popularity of the mistake. Were it not, we would be speaking some version of Ur-German.
- Oh, nice! I've been using '-'s, but I'm going to switch.
- There are no "expected" scaling factors anymore.
- Or things a senior engineer would write late in their career to make it easier to train junior programmers. <shrugs>
- I don't really see anything in it that particularly difficult our counter-productive. Or, to be honest, anything that isn't just plain good coding practice. All suitably given as guidelines not hard and fast rules.
The real joy of having coding standards, is that it sets a good baseline when training junior programmers. These are the minimum things you need to know about good coding practice before we start training you up to be a real programmer.
If you are anything other than a junior programmer, and have a problem with it, I would not hire you.
- Presumably why it says "Avoid recursion if possible".
- If only it would do something entirely different faster. :-(
Somebody really needs to rethink the entire commitment to meta-programming. I had some hope that concepts would improve reporting, but they seem to actually make it worse, and -- if they improve compile times at all, I'm not seeing it.
And it has nothing to do with historicity. Every time I visit another modern language (or use it seriously) I am constantly reminded that C++ compile times are simply horrible, and a huge impediment to productivity.
- Is an XLST page a valid atom feed? Is it really so terrible to have to two different pages -- one for the human readable version, and one for the XML version?
- Sounds like EVERYBODY agrees that there isn't sufficient market value then. Even the original maintainer. And the that is indeed why the feature is being dropped: insufficient market value. Happy happy happy!
The overhead of threading seems pretty obvious: call and return instructions are expensive compared to the cost of the one equivalent instruction that would have been executed in a compiled implementation. And placing arguments on a stack means that all operands have to to be read from and written to memory, incurring additional ferocious overhead, whereas a compiler would enregister values, particularly in performance-critical code. Not unreasonable to expect that Forth code is going to run at least an order of magnitude slower than compiled code.