mtVessel

This Is Not Working (in Firefox)

The article mentions Delta positioning itself "as a more high-end airline with premium features that can attract higher-paying leisure and business travelers".

Aren't those the customers less likely to quibble over paid wi-fi?

When I was flying for business (almost exclusively Delta), I would pay for the wi-fi every single flight. And I never thought twice, because I was expensing it.

At worst, I thought it was tacky for Delta to nickel-and-dime me (well, the client, actually). The only time it would matter to me personally, is when I was flying for pleasure, on my own dime.

What is it called? What's it for?

Or just eat a smaller, healthier lunch.

It'd be nice if you linked to a privacy policy on that page. The policy linked to on the app store page isn't very specific, either.

And almost always renders them less readable, and occasionally unparsable. I do wish they'd turn off this "feature". I've yet to hear a coherent explanation for how this improves the quality of submissions.

Let's be honest - you're describing how it was in the before times. Once the most aggrieved people in the universe began holding sway, it devolved into a place where every thoughtful disagreement became a flashpoint.

I wonder if it was auto-transcripted. It reads like it was done by someone unfamiliar with the rhythms and idioms of "English as she is spoke".

Capturing the Friedmans is brilliantly constructed. Jarecki peels the onion one layer at a time, saving key details for when they'll have maximum impact.

Sure, it's tricky to get it right, and we've already discovered a lot of ways to get it wrong. I still think it's a worthy goal.

Directing resources to those already best-placed to use them is tempting, but taking it to its logical conclusion only perpetuates "the rich get richer and the poor get poorer." That, by itself, is a recipe for collapse over the long-term.

Again, without even touching on the moral aspects.

In a zero-sum game, sure. But assuming we all live in a society, helping the disadvantaged raises the mean level of, er...advantage for all. The advantaged ones get the further benefit of living in a society that's better off as a whole. A rising tide lifts all boats, as they say.

And that's without even getting into the morality of inherent advantage.

If your vision is truly so all-encompassing, maybe that's the thing you should work on selling -- but not to investors; to the people you want to work with. Solve your HR problem, get some co-founders, and get going.

> wouldn't it be better to record this and make it available at static write-time

I think you misunderstand my position. It's better for the creator to simply specify it when they write the code - i.e. static typing.

> the type profiler makes no attempt whatsoever at discerning the "meaning" of the data

Your examples are waaay beyond what I need or expect. What I need is for the program to recognize that, for a number, 123 and 456 are valid, but "abc" will never be. Conversely, for an identifier, no matter how many runs use values like 123, someday someone might provide the value "abc" and that's ok. Also, any code that attempts to sum up a collection of identifiers should not be runnable, even if the identifiers in question all happen to be numbers.

This is something that static typing provides, and no amount of profiling will ever be able to divine.

> In the vast majority of cases, you will find that your brain already has a very specific type in mind for each variable

Sure, for the code I write. But I've seen plenty of code written by juniors where, upon inspection, it was completely inscrutable whether a given parameter expects an integer, a string, a brick wall or a banana.

Which is all to say that my default position is unchanged: dynamic typing is unhelpful for anything larger than small, single-purpose scripts.

This is only feasible if the program takes no input, or a very limited set. Once you open it up to arbitrary input, no single run (or even a large set of runs) can capture everything the program might be expected to handle.

How does the type profiler know that the variable that only contained values like "123" or "456" was handling identifiers, not numbers?

> The last mile is the same as the previous mile.

Is it, though? Maybe from a biological perspective, but definitely not in terms of lifestyle.

The times I've needed to lose weight, the first few pounds came off easily, because I usually just need to clean up a few bad habits. But then I typically settle in to a set point that's still above a healthy weight. At that point, further reductions require more and more calorie micromanagement.

There's something called "Data-Oriented Programming" and something else called "Data-Oriented Design". I can never remember which is which. This post changes nothing.

No, it doesn't. "See" refers to our visual perception, whether it occurs in the eyes, the brain, or anywhere in between.

It's clipboards all the way down...

Is it a static page? Nothing on it indicates it has been updated since, say, 1997.

It's higher-privileged randomness. As in, all GUIDs are random, but some are more random than others.

It feels like your argument is a bit of a strawman itself. I'm hard-pressed to come up with a situation where the code is broken but readable, and the quickest way to fix it is to make it less so.

Sure, there are times when I don't know or don't have the time to come up with the best structured solution, but have to put something out there that just works. I would argue that's where you should strive to make it even more readable, because the uncertainty means the odds of having to revisit it later are even greater.

> The state you want to reach is "fixed", not merely "fixable".

And my argument is that readable code is the most direct route to that state.

> > And code is always incorrect.

> This makes a strawman of my argument.

It would if it was actually part of my argument, and not a cheeky parting shot.

Here's the straightforward version. In my experience, the most productive way to approach code is to assume that at some point a bug will be found, or you will have to extend it. You may disagree, of course, but my views all flow from this assumption.

I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable.

If your code is correct but unreadable or disorganized, it will be hard to extend.

If your code is incorrect, but organized and readable, it will be easy to fix.

If your code is incorrect and organized, but unreadable, it will be hard to fix and extend, but easy to make it more readable, thus more extensible and fixable.

If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable.

And code is always incorrect.

I recently repurposed an old Win XP machine (Athlon 64 X2, circa 2010) that had been sitting unused for 15+ years. I threw in 4Gb of memory and a pci wifi card and installed Lubuntu. Works great! FF is a bit sluggish on it, but I don't care, because it's primarily a file server.

That's such shit. Companies that pull nonsense like this shouldn't be allowed to market their products. If you're in the US, try contacting the FTC.

I have the Elite 85t and it works fine with my Android phone and both my Dell Win 10 machines, so it may be a Mac issue. No excuse for their shitty behavior, but I'd research Mac-specific BT fixes.

Or it could be an issue with the button functionality. Try disabling button actions for calls in Sound+.

That's true as well, and a good thing to remember.

I agree in principle, but if there's one thing internet commenting has taught me, it's that a tragically large number of people are somehow getting though life with broken sarcasm detectors.

If you don't recognize the term as having a specific meaning in programming, it may be worth reading up. This[1] blog post has a great walkthrough of invariants.

https://reprog.wordpress.com/2010/04/25/writing-correct-code...

HN has some rules for automatically fixing up headlines. Usually it edits out small words like "the" and "a" at the beginning of a title.

I have no idea what the rationale for this is, especially considering the potential for corrupting the emphasis of the original headline, like in this case.

I think you'd be hard-pressed to find anything more than anecdotal that supports this conclusion.