quelltext

This is a simple issue to solve if you have all the issuers in line/on the same page.

Issuers simply need tabs on this. This means, a) they only allow this for merchants that have had previous transactions. b) They reset this when a card is reused (owner of the number changes).

Ultimately you just need a system that turns on stricter checks when reuse-induced issues are likely.

Once a card is reused the issuer simply needs to turn off the recurring billing laxness until the card gets close to expiration again, i.e. a few years, which should suffice to detect any sort of problematic patterns.

This wouldn't affect the customer at all as any legitimate transaction would have been made with up to date expiry and CVV.

And then see customers complaining about the annoying extra steps. 3D Secure affects conversion rates adversely which means customers are generally happier without it and don't mind the fraud risk (as is consistent with the rest of this discussion on the thread).

Having experience in both roles (and some more, all on the technical end), I don't think so. Of course, it's not a simple harder/easier question and it doesn't apply to everyone but if you are good at supporting customers you naturally care about stuff and the customer's issues. You file an internal ticket, have to keep watching it but in many cases there's just no progress or even a response. Ultimately when there's a real bug you are just being an (internal) customer requiring support. The support quality of a company is not only determined by the right customer support employees or vendors but how good the internal support and escalation paths are.

As an internal engineer, when an internal ticket comes in I'm going to track down the issue, may realize it's a known thing that requires a lot of planning to resolve, loop in my manager, etc. but ultimately it usually ends with "we don't have time to address this right now and it doesn't affect enough users". If you're lucky there's a workaround that can be shared.

Now, I don't like that. I'd rather fix the issue for the user but I already have committed deadlines and team goals and it's rather easy to just go with a "sorry, we may revisit in Q1 or Q2 next year".

The support agent still has to a) deal with the customer's anger and b) cannot be honest with them, i.e. needs to wrap the situation in a blanket of corporate speak so as not to shed a bad light on internal teams / the company. At the end of the day they are just powerless and have to take on the responsibility in front of the user, whereas the engineer may feel unsatisfied not being allowed to spend time on it, but ultimately is far enough removed from the user to be actually affected by the situation. Granted, personally I always try my best to get a fix out but a lot of engineers would rather work on their projects and the managers want that too.

FWIW, when I did customer support I always reminded myself that nothing is personal. When I'm at the opposite end (a customer) I also don't get mad at the individual I'm dealing with unless they are not trying to understand or help at all.

The sponsor program page there is up but the program itself doesn't seem to be anymore when you try to go through it. I believe someone else mentioned it was an experimental run in the past that got axed because nobody paid.

> Nick and Andrew did a similar experiment, they found no effects whatsoever.

> And so they send this to a journal and the response they got was, well, you know, you probably wouldn't expect an effect because this is not fairly novel information to the students. So we are not going to publish this because it's not really surprising.

I don't quite understand that example.

If every one else in their papers indeed suggested that telling students of the cost should solve the issue, and everyone believed them, then how can it be claimed that the experiment results are not surprising. The whole point was to disprove what apparently was blindly accepted because of common sense; being then told that in fact the opposite is common sense seems like a slap in the face.

I didn't read the paper, so maybe I'm missing something, but I'm not sure it's actually a good example for that journal. Had they done experiment in isolation with no preexisting notion or consensus of what might solve the graduation issue, maybe.

I saw this combination of control and data flow graph before a while ago in some paper and while it made sense there (was a very small part of what they described as a whole) it seemed rather trivial / straightforward as a concept.

I also heard people reference sea of nodes elsewhere before but I couldn't really get what made it special or a "sea if nodes". Only now I learn that that's basically all it is: data flow and control flow per node/element/instruction combined.

I guess without also going into what it actually enables it's a bit underwhelming.

Hmm, I knew it was implemented in a bunch of plugins or dedicated software like PS. However I am surprised it's not found all over the place by now as part of default apps / preview / OS builtin software / img tag options, etc.

Also none of the implementations I have tried (last time I checked, not up to date on this) were as slick / realtime / interactive as the SIGGRAPH demo.

> Regardless of the type of payment you received, the full amount that the client paid will be refunded to the client by clicking on the refund button at the bottom right-hand corner of the transaction details.

That doesn't say anything about what the merchant gets charged. Stripe and PayPal also send the full amount to the card holder, so that blurb would apply to them too. The question is whether the merchant ends up with zero or minus the original processing fees after the refund.

> VAT and "revenue tax" are effectively equivalent.

I mean VAT is a type of revenue tax, sure. However it is rather uniform and generally it's rate is not affected, e.g. by the total revenue of a business, the type of business, and other such qualities.

It's very easy to just shift the burden to the customer, not only due to the above but also because there's general understanding in the population (which visibly see the government set that tax uniformly on all their receipts).

But there's typically also additional taxation on corporate income. Isn't that essentially the "revenue tax" people meant?

> If I were Twitter I'd be counting my lucky stars that my largest userbase is in the US where, as broken as our copyright system is, I can't imagine this wacky judicial reasoning prevailing.

You know that the Japan userbase of Twitter is huge, right? Not that far behind that of the US, in fact.

https://www.statista.com/statistics/242606/number-of-active-...

The amount of attention (resources, staffing, features) Twitter gives to the Japan market because of this is significant.

That depends on your PhD research area (even if in CS) and country.

In many countries PhDs are only valuable in academia and industrial research institutes, but your salary is capped quite a bit long term.

In Asia a new grad fresh out of college is seen as more employable than a new PhD grad by most companies and salary differences would be minimal. I wouldn't recommend doing a PhD if you're out for a high salary there.

On the other hand in some European countries just having any PhD degree will open up career paths and salaries unavailable to non PhDs regardless of actual skills.

I was curious and read that linked wikipedia article on the monkey selfie, which actually makes it clear that US law pretty much does have an answer to the question whether an animal can be a copyright owner.

The actually interesting part is the fact that these photos/selfie situation were set up specifically by a photographer with their equipment.

That is actually the relevant (to AI) portion in all this. If someone sets up all the right pieces but then has a subject or generally "something" else cause the actually creation of the artwork the lines get really blurry. Hypothetically if you set up an elaborate set of machinery guiding an animal/machine/human to paint a picture it wouldn't otherwise be painting, e.g. think elephant with brushes/paint on trunk walks through a guided maze of a huge canvas, the coordinator would not have copyright (by the logic of the monkey case).

P.S. While I sympathize with the photographer, the level of butthurt and entitlement is just rich:

> Slater was unable to travel to the July 2017 court hearing in the United States for lack of funds and said he was considering alternative careers as a dog walker or tennis coach.[52] "This would be a new venture for me. It would pay peanuts, but at least it would be more than photography. I am just not motivated to go out and take photos any more. I've had outlays of several thousand pounds for lawyers, it is losing me income and getting me so depressed. When I think about the whole situation I really don't think it's worth it."[52] Slater added, "Everything I did to try and highlight the plight of the monkeys has backfired on my private life. I've had my life ruined."[52]

They made an initial investment, made good on it, then decided to sue Wikimedia without the necessary funds. This is a very special case and not at all related to the viability of the wildlife photographer profession. Nothing about this means the photographer has to abandon their career and start walking dogs instead.

> that the same amount of people would die regardless

Maybe "be infected", not "die"?

Otherwise there's little reason to flatten the curve (meant to allow for better treatment).

So the arguments against my comment (and downvotes) so far have been about how people are stupid or how they base their reality on action movie knowledge.

I don't think people are that stupid, really. And I don't think they don't understand that Tesla's autopilot is not a chauffeur.

As I said, I do think Tesla can do a better job and hey they should probably consider a new name just to get this over with, but I simply cannot agree with everyone in all these threads going on and on about the name being at fault.

People would find some other thing to blame if the name were drive assistant or cruise control, as long as Tesla is advertising or wants to advertise the more modern features of it. Say Tesla says it's advanced cruise control doing a, b, and c that others don't provide, people will still blame a, b, or c when those linked with driver neglect cause an accident.

Note, I'm also not saying Tesla is great here and not at fault. If their systems don't do a, b, and c properly or steer you into a concrete wall then it's their fault. But IMO it's just not because it's called autopilot.

What I think instead is that the fact that there is a system that let's people zone out in 90 per cent of traffic without annoying the driver about paying attention is the issue. It really doesn't matter what the name is as long as there are measures in place to keep the driver focused.

I think the whole issue clashes though. It's difficult to have these auto-steering features for comfort but then demand reduced comfort. So bottom line for me is that those systems all aren't ready and the naming is simple a bikeshedding topic because it is easy to attack and also brings put this "people are stupid" superiority feeling in people.

And some cars can auto-park nowadays: https://en.m.wikipedia.org/wiki/Automatic_parking

But neither planes nor cars with autopilot + autoland/park functionality are fully autonomous.

The only place where we have this today is on some on rails systems (trains like in Paris, buses on fixed rails like in Tokyo's Yurikamome or some amusement parks, etc.).

I believe the point is nobody expects planes, where a layperson would know the term autopilot from, to be left unattended by the pilots. So why should this be assumed on the road?

Why do they think that?

It's unreasonable to assume that. Autopilot is a term most people would he familiar from where? Commercial aviation, right?

I would argue most people know it's not a system that achieves that goal. Just ask yourself. Do you think airline passengers would feel comfortable if a cabin announcement told passengers: Both pilots are going to take a nap now for the next 10 hours.

I do think Tesla should do a better job making sure it's understood that there are limitations. I don't think they need to change the name of the feature because some people claim to have a certain expectation of it which at closer inspection is not justified.

It only strengthens your point but Java 5 was actually released way earlier, in '04.

> Code containing aspects is certainly not plain Java code,

I didn't say it was. AspectJ is AspectJ, as you surmised correctly "a language in its own right", and so when you define an `aspect` that's it's own thing, not a `class`. You seem to demand that the language is Java, but that's not really a criticism of AspectJ, the language, then, rather denying that it is a language.

It's like saying a C++ class and some implicit behaviors that change behaviour of user code (via a custom assignment operator override) is crap because it's not C. Maybe it's crap because you don't like it and like C better but it's still not quite fair to demand it be "plain code" when it is plain code.

Please look more deeply into https://en.m.wikipedia.org/wiki/AspectJ. It has its own syntax and is not just some annotations plus a framework you have to run.

FWIW, your arguments against AspectJ work just as well against any language with macros or metaprogramming in general (although you probably don't like those either, and that's fair!).

> If you want to say that AspectJ is a language in its own right, then it's a language that breaks all the rules of good language design

Frankly, the kind of things that AspectJ offers or proposes to use are IMO no less sane than some of the things languages like Ruby (e.g. monkey patching, middleware decorating/nesting calls via including a module, defining methods is a dynamic call that can be intercepted and customized, etc.), Python (e.g. decorators), JS (e.g. messing with prototype behaviors), or even Prolog (e.g. metainterpreters that metalogical predicates to implement different resolutiom strategies) typically encourage.

People have called monads the "programmable semicolon", and so you can do all kinds of things that don't at all represent what a user of the monad would anticipate unless they read the docs/implementation. It could enforce some form of order of evaluation, or store additional state that is hidden, etc. Sure, this is not the same thing as aspects or metaprogramming/macros, but what they have in common is that some external definition defines the exact semantics of a application/user piece of code and has potentially a whole lot of freedom to stray from what may look like it's "obvious".

The goal of AOP is to find a solution to challenges were modularization by typical means hasn't worked. And the typical examples are usually valid. Is it great? Is it needed? I'm not sure either, but your criticism sounds a lot like you only look at it from a lense of a pure statically typed functional programmer. From that POV a lot of language designs probably look impure and crap, whether justified or not.

> It (or other libraries that do much the same thing) is the vast majority of Java as it actually exists in the real world.

Are you specifically talking about AOP or AspectJ? I believe the former. And I don't think it's AOP, you are talking about various frameworks implementing a wild set of changes to the core language via reflection, code generation, or other such things tailored to their specific use cases.

Say what you will but that, while it might fall into the AOP class of doing things, is quite different from AspectJ's goals. The idea is/was that you don't need all these different frameworks with their own conflicting custom implementations. Rather, that using AspectJ should be the common language in which these metaprogrammatic aspect-oriented concerns are defined (for instance by such a framework that's currently using it's owm custom implementation with no common set of rules), which can be analyzed and provide static tool support (e.g. "who"'s amending, wrapping, early aborting behavior for this particular method).

So, again I don't think the criticism of AspectJ is fair (abd that's what I addressed, not the modern state of Java and frameworks in general). If at all, the problem is that AspectJ itself isn't actually used but instead that its superficial ideas have been coopted and turned into a metaprogramming wild west. Maybe it's AspectJ's fault but I think it's just a coincidence. That state of affairs is not unique to Java at all, either.

You can also do it visibly in Java without too much noise IMO. The point of AspectJ is to hide this stuff completely from application code (but it's still visible in its definitions). Whether that makes sense or not I'm not going to debate (I personally don't think AspectJ is particularly great) but arguing that other languages allow you to do that in a more or less visible way is besides the point.

AspectJ is a language, these aspects are visible and have their own language abstractions, just separate from the application code. Just like you have monad implementations separate from their uses. So writing aspects is also "plain code". How the weaving happens (at compile time/load time, on source code or on bytecode, etc.) is an implementation artifact

Also, AspectJ isn't Java and the problems AspectJ tries to solve and the approach apply to a bunch of languages and variants for functional languages also exist.

> it is possible to write an amb macro that "chooses" the right argument to make a subsequent assert statement be true.

I'm not too familiar with Scheme's macro feature but how would one go about that? I was under the impression with macros you get to define what ever syntax is part if the call, but here in order to achieve what the author mentions the macro would need to be able to look at surrounding code, to look ahead for the assert. How is this possible? Is he maybe talking of a compiler plugin or a macro (not shown) that encloses the entire expression, e.g. `(make-assert-true-macro (let ...{the code snippet}... ))`?

> Unless I am mistaken, putting it on every page is not even suggested by Stripe.

https://stripe.com/docs/js/including

> Include the Stripe.js script on each page of your site—it should always be loaded directly from https://js.stripe.com, rather than included in a bundle or hosted yourself.

> To best leverage Stripe’s advanced fraud functionality, include this script on every page, not just the checkout page. This allows Stripe to detect suspicious behavior that may be indicative of fraud as customers browse your website.

Really? Often they say things like "he prefers...", etc. in some sense speaking for their character not hypothetically but as if they were close to a real person that "does" things rather than "would do".

However pretending to be personally acquainted with the character is a step higher, I feel. How common is that?

What surprised me most is that he presented himself as the biographer of James Bond, as if he were real. I wasn't aware of that history.

That's cool. I had to learn some intricacies of PHP for a job once quite a while ago and the docs weren't quite sufficient. Could have used that. Language specs are typically harder to digest then other material but ultimately you can get all the details out of them you need and they're typically worth reading.

PHP has a spec?

That's more cases for sure over the last few days, but it's not exponential growth (yet). Sure, it's likely going to grow like that, but the recent data isn't evidence for it.

Don't you mean the Interpreter pattern /s

I wonder though, what made Delphi so simple in terms of UI development? Is there anything that could not in theory also be applied to other languages, e.g. Java?

Being curious about internals and giving users the means to understand them doesn't conflict with the goal of a) putting them behind a hiding layer that reduces the aspects a user needs to keep track of and b) avoiding dependence on those internals staying the same.

You can still teach people how things work or you can still have a list of potential implementations of an interface.

Where the internals matter you would either define very strict contracts or not use abstraction mechanisms that hide internals. But where it matters is not everywhere.