seandougall

PG’s argument is a meaningless non sequitur. The question isn’t about what new technologies people adopt; it’s about what product designs they go for. The former of course will start in CS departments and research labs, because that’s where they’re developed. That’s really not saying anything, and has no bearing on the latter.

If you only train one fingerprint at a time, most people can rotate up to nine times. It's a bit inconvenient, though. :)

Back when I was in college, our department secretary often mused about being the last person left on campus who used shorthand, having started at a time when it was how all meetings were transcribed.

Then again, she was also the only person on campus who could get away reasonably safely with writing her passwords on Post-Its around her monitor.

A friend of mine used to work on research in this area, which is really fascinating from the outside. In practice it meant she spent much of her time trudging through the jungle collecting primate feces, but on the other hand she got to say she was a zoopharmacognosiologist, which IMO is one of the cooler job titles out there.

You go through all that trouble, and yet ... you have a Facebook account?

Anyway, the info being leaked here isn't dependent on browsing history. Companies have been gathering these sorts of profiles far longer than most people have been using the Internet. The only way to avoid it is not just to never have Internet access at all, but never have a credit card or a bank account, never own a house or sign a lease, never drive a car, never register to vote, etc. If you do any of those things, even temporarily, you could be leaking information that can't be unleaked.

That's what makes me nervous about interpretation of GDPR. The EU has 28 member states. Let's say each one of them has a 90% probability of their regulators being reasonable at any given time. Does that mean the chances of the regulators on the whole being reasonable are 0.9^28? (In other words, about 5%?)

As an outsider, I would love to hear that that's not how it works. Do the member states have any checks on each other's enforcement?

I agree with your meaning, and I think it goes beyond that. SSNs really are PII by definition; what we need to do is stop pretending that we can use any kind of PII in general as a form of authentication. Whether it's SSN, mother's maiden name, or any of these inane "security questions" that (thank goodness) finally seem to be receding from their peak, we need to move away from the fundamentally broken "tell me something about yourself that only you would know" model of authentication.

Northwestern used to be nwu.edu, but they rebranded in 1999 (which happened to be my sophomore year there).

Opposable thumbs help an awful lot, too.

If you have the resources to proactively keep your data up-to-date, then a lookup API is trivial. But it also doesn't begin to address remittance, which is by far a bigger burden.

That page doesn't appear to factor in filing costs, which run up to $5000/year.

Also, I wouldn't generally classify it as "a little more work", since in many cases the old system could be hard-coded and the new system requires reworking the checkout flow to capture the full mailing address and pass it through an external API before calculating the transaction total.

> With more competition it will likely become cheaper.

I wish I shared that faith in market forces. What seems more likely to the cynic in me is that a big player like PayPal will incorporate it into their merchant services, obtain some overly broad patents on the process, use those to stifle competition, and make the service a nominally cheap add-on (but only for their own customers).

Not to mention fatal JS errors on mobile.

I also find autocompletion invaluable when I'm working with an API I don't interact with regularly enough to have everything memorized, mere mortal that I am. I might not remember exactly what naming convention the methods conform to, or what order the arguments need to be in, and autocompletion gets me both of those essentially for free, without having to pull up the docs for every method call.

In the case of classical music, there are two things that need to be clarified:

1) Classical music is still being composed today, and there’s a huge volume of post-1927 work that is very much under copyright in the US (excessive though that may be IMO).

2) Even if a composition is PD, the recording is absolutely copyrightable if it’s post-1927, and the arrangement may be as well. This isn’t a matter of confusion; it’s an actual piece of intellectual property.

Not to say that any of this is right; I believe fair use protections need to go much, much farther than they do.

Yyyyeeesss... that’s rather my point, that we’ve accumulated so much debt at this point that this doesn’t really move the needle as much as it sounds like when you ignore that accumulation and look only at a single month.

Again, I’m not arguing that it’s a good idea. It is irresponsible, for sure. But the scale of it is akin to somebody with $10k in credit card debt opting to go out for dinner once.

Out of curiosity, how many of those would you say were cars less than a few years old? That more than anything is what catches my attention about this story — anecdotally, I’ve seen car fires on the highway, but always older cars, and a Tesla seems like it shouldn’t have had time to accrue that degree of wear and tear and deferred maintenance. But I’m curious what someone with more data points makes of it.

In most cases, it feels like absolutely nothing.

Above roughly 150 systolic, it can start to manifest as headaches (as others have mentioned), but doesn't always.

In my case, after it had gone undiagnosed long enough (by an incompetent doctor), I had extremely severe headaches, constant nausea and vomiting, and vision problems that turned out to be capillary hemorrhages in my retinas. That was at around 240/120.

BUT: I am extremely lucky to have had all those horrendous symptoms. They alerted me to the severity of the problem, and caused me to escalate to a competent doctor. For many people who get up to that level of blood pressure, the first (and potentially last) symptom is a stroke or a heart attack.

From what I've read, that's another everybody-is-different sort of thing. The median effect is marginal (like a few mmHg, if I recall correctly), but there's a wide distribution, and some people are affected much more than others.

A 66% increase in the monthly deficit, in this case, amounts to about a 0.4% increase in national debt, by my back of the napkin math. I agree that it’s a dumb move, but I don’t think GP was wrong to say that it barely affects the momentum.

You’re free to disagree, but it will help the discussion if you can find a way to do so without the ad hominems.

Re bread, this is one of many great reasons to make your own! It isn’t particularly hard — it takes time, but most of that time is just waiting.

The sugar in bread is rarely there for flavor. It’s a way to cut corners by feeding the yeast and causing the dough to rise faster. Leave it out and you just have to wait a bit longer, but you get a better developed flavor as a result.

“Sugar” is a broad category of chemical compounds, each of which is metabolized differently. Even if they all had the same caloric density (which they don’t), that would give you a woefully incomplete picture of their effect on your health.

Thanks for that — it helps start to make sense of it. I wonder how sustainable the practice is; presumably a property owner making that sort of calculated decision is also looking at the negative impact on their other tenants.

I’ve been wondering the same thing. There’s a former Borders in Pasadena that sits empty for most of the year, and only houses a Halloween costume store seasonally. They finally brought down the part of the sign that said “Borders” a few months ago, but they left up the “Books - Music - Cafe” part.

It’s clearly not worth renovating, but maybe the seasonal business brings in enough that it doesn’t need a tenant the rest of the year. But also, the store is huge and its layout is unwieldy for most types of retail.

What I don’t understand as well is how many empty storefronts around here still have Radio Shack signs above the doors, even in what should be prime locations. I’ve started wondering if having been a Radio Shack is a curse of some sort.

That benchmark seems to list only Kitura. I wonder what it would look like with Perfect, Vapor, or Zewo.

> Concurrency hasn't moved at all

Yeah, it hasn't moved because GCD is already pretty mature, and they don't seem to have made any effort at other concurrency paradigms. I'd love to see how something more like CSP would work (Zewo has an implementation, but I haven't had a chance to work with it yet).

> There is also nothing for cross-platform development (real cross-platform, not just iOS and macOS).

Not yet; it doesn't quite seem like it's ready to be a practical goal. I'm curious to see if that changes when they manage ABI stability.

I'm not sure where your friend was getting that information, or what small details he was referring to. Calling Objective-C from within Swift is remarkably transparent -- where you might have called `[foo bar:baz];`, you call `foo.bar(baz)`.

In some cases, wordy Objective-C names will get mapped to Swift's tidier conventions, but the public APIs are all documented in both languages, and Xcode's auto-complete is pretty good at helping you figure it out.

These complaints largely seem to come down to Swift not really being what the author expected it to be. His list of speculations as to Apple's motivations, in particular:

> It should scale from App/UI language down to system language.

Did I miss something where Apple or the Swift team said anything about writing a kernel in Swift? They wanted to make it fast enough for performance-critical situations, yes, but there are plenty of those in userspace -- and I haven't found Obj-C's inability to perform in those situations to be an asset.

> It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication.

This is missing the forest for the trees. Bringing Swift-native Foundation APIs into the standard library means they're available on non-Mac platforms, which is huge. I'm also not sure what alternative would be preferable -- should it _not_ interop with Foundation/Cocoa, and totally fragment the ecosystem? Or should _not_ reimplement them with native calls, so that it inherits the performance penalty of objc_msgSend?

> It is functional, object-oriented and protocol oriented all at the same time.

Apple describes Swift as protocol-oriented. It's flexible enough to support other paradigms, but I don't see how that's a liability, and I haven't seen Apple claim "Swift is an FP language".

> It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design.

[citation needed]

This complaint is so vague as to be impossible to address, except to say that I haven't managed to come across a case of it yet. An example would really help make the case.

> It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't.

Again, I haven't heard any claim that "Swift is a scripting language". Sure, it's not, but neither is Objective-C, so... I'm not really sure what the complaint is here?

> It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development.

This sounds like a complaint about strong typing and static dispatch in general. Yes, you have to code more carefully, but the flipside is that a huge number of errors that crop up at runtime in Objective-C become compile-time errors in Swift. I'd much rather bang my head against the compiler for a while before I ship than have reams of undebuggable crash logs pour in.

> It is meant offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex.

That's true, but that's also kind of a big part of why playgrounds exist. So again, what's the complaint? Is the fact that playgrounds make the language more accessible a problem somehow?

Also, the only way I can view Objective-C as "simple" is by ignoring the C underpinnings and looking only at the relatively thin layer of classes and message passing on top. For somebody coming to coding with fresh eyes, both Swift and Objective-C are going to have a learning curve; the difference is that with Swift you don't have to pick up K&R first.

1) I've been doing Cocoa development for 13 years, and I absolutely love Swift. I've switched to it for all my own projects (at least the ones where I would previously have used Objective-C), and I'm never looking back.

2) For medium projects: absolutely. For large projects: I haven't had the pleasure yet, but the truth is that Swift encourages a much better approach to modularity, and if you're working in a large project as a monolith, you're probably doing something wrong.

3) Hands down, yes.

And I imagine the energy savings of such a change over billions of devices can be phenomenal in some cases. I’m glad there are still people working on these things.

I think it’s true, though, that it’s now a much narrower subset of people — it’s not really desirable or practical for most hobbyists to dive deep into assembly, the way I remember seeing back in the ‘80s.

Yup. And if I had a nickel for every time a patent was granted despite the existence of prior art...