That's precisely the point of using tabs for indentation: you don't need to fight over it, because it's a local display preference that does not affect the source code at all, so everyone can just configure whatever they prefer locally without affecting other people.
The idea of "skins" is apparently to push that even further by abstracting the concrete syntax.
I don't see why? Your window width will presumably be tailored to accommodate common scenarios in your preferred tab width.
More than that, in the general case for common C like languages things should almost never be nested more than a few levels deep. That's usually a sign of poorly designed and difficult to maintain code.
Lisps are a notable exception here, but due to limitations (arguably poor design) with how the most common editors handle lines that contain a mix of tabs and spaces you're pretty much forced to use only spaces when writing in that family of languages. If anything that language family serves as case in point - code written with an indentation width that isn't to one's preference becomes much more tedious to adapt due to alternating levels of alignment and indentation all being encoded as spaces (ie loss of information which automated tools could otherwise use).
I find it tends to be a structural thing, Tabs for indenting are fine, hell I prefer tabs for indenting. But use tabs for spacing and columnar layout and the format tends to break on tab width changes. Honestly not a huge deal but as such I tend to avoid tabs for layout work.
I love the idea of "tabs for indents, spaces for alignment", but I don't even bring it up anymore because it (the combination of the two) sets so many people off. I also like the idea of elastic tabs, but that requires editor buy-in.
All that being said, I've very much a "as long as everyone working on the code does it the same, I'll be fine" sort of person. We use spaces for everything, with defined indent levels, where I am, and it works just fine.
I completely agree, hence my point about Lisps. In terms of the abstraction a tab communicates a layer of indentation, with blocks at different indentation levels being explicitly decoupled in terms of alignment.
Unfortunately the discussion tends to be somewhat complicated by the occasional (usually automated) code formatting convention that (imo mistakenly) attempts to change the level of indentation in scenarios where you might reasonably want to align an element with the preceding line. For example, IDEs for C like languages that will add an additional tab when splitting function arguments across multiple lines. Fortunately such cases are easily resolved but their mere existence lends itself to objections.
Do you mean that files produced with "wide" tabs might have hard newlines embedded more readily in longer lines? Or that maybe people writing with "narrow" tabs might be comfortable writing 6-deep if/else trees that wrap when somebody with their tabs set to wider opens the same file?
Sometimes I wonder if the throat-clearing is an indispensable part of getting to the "good bits" that follow. Like, do those extra tokens give it more "room to think" even if they're basically meaningless in themselves?
The output tokens are the only information that is carried forward through each inference pass, so "more room to think" is incompatible with "basically meaningless". Perhaps one could imagine it somehow stenographically encoding information in its precise choice of meaningless throat clearing, but there are only so many variations on that theme - word choice is heavily constrained, so it doesn't feel like you could store a whole lot of information there without it starting to read froopiliciously.
I thought PP was saying that the "Thinking" text is only used for one turn, and the response text is the compressed thinking that survives into future turns.
It seems to me that the distinction becomes irrelevant as soon as you connect inputs and outputs to the real world. You wouldn't say that a 737 autopilot can never, ever fly a real jet and yet it behaves exactly the same whether it's up in the sky or hooked up to recorded/simulated signals on a test bench.
I'm sure it's fine you do it properly ([1] for example). The issue here was the utter lack of engineering, not the specific manufacturing technique (although those do seem to be highly correlated, due to low-end 3D printing having become very cheap and easy).
The extra fun thing about this is that eval has different semantics if it's assigned to a different name, in order to allow JavaScript implementations to apply extra optimizations to code that doesn't call a function literally named "eval": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
The "scraping helped slow it down" theory makes no sense to me. What do you think has a higher coefficient of friction - tire rubber on asphalt, metal on asphalt, or metal on metal?
I would hesitate to chalk it up to just theory, given it was in the NTSB report and they don't really mess around with throwing baseless stuff around. I'd be interested to take another look at it. They likely go into the material science and physics behind this very thing. They're usually filled with gems.
You also have to keep in mind, it wasn't just rubber against asphalt, it was rubber on a wheel that spins. I'm not sure if the front nose gear on a 767 has any brakes but even if it did, I can't imagine it would be sufficient at the speeds they were going.
I mistyped, as this was Canada it wouldn't be the NTSB but the Canadian equivalent at the time: Canadian Aviation Safety Board. The report is a good read.
Rubber likely grips much better than metal, however three wheels have massively lower surface area than the body of the plane, or even a small section of it like the head.
Of course we don't land tireless for other reasons (metal transfers heat exceptionally well unlike rubber, paint doesn't survive high speed impact, and it tends to deform upon impact with anything, making any future flights unsafe), but the fastest way to slow down if you don't care about safety or comfort would probably be to land tireless, if you could introduce some rotational spin, that might be faster (more force directed in multiple directions).
Also, on the note of "coefficient of friction", remember that this number is not just some innate property of a molecule - as the metal scratches the pavement and deforms, its coefficient of friction goes up as micro-deformities accrue.
reply